Hey all,
Here's a much more robust and updated patch (actually, it seems good
to go to me, but needs significant review)...
https://gist.github.com/1963999
One potential issue is that it requires an API change to
zend_verify_arg_type (which appears to only be called in zend_vm_def.h
- and by gene
Both. I'd never read anything about that before so was kinda curious how
that works given how chaotic the PHP dev process can be at times.
I think it's a solid approach but I've always been a fan of having written
policies and clear procedures as opposed to the more ad hoc approach that
this appe
On Sat, Mar 3, 2012 at 1:56 AM, Kris Craig wrote:
> Ahh ok that makes sense. I actually didn't realize there was an added
> "admin" layer. How was that list generated?
>
> --Kris
>
>
>
what do you mean by that?
from the technical POV? that list is maintained manually.
from the policy POV?
usua
Ahh ok that makes sense. I actually didn't realize there was an added
"admin" layer. How was that list generated?
--Kris
On Fri, Mar 2, 2012 at 3:30 PM, Ferenc Kovacs wrote:
>
>
> On Fri, Mar 2, 2012 at 11:44 PM, Kris Craig wrote:
>
>> This was me, please disregard. Someone in our local me
Hi Stats
The new strict session patch is not ready, yet.
I'll prepare path for 5.3/5.4/trunk.
I was asked for session id collision detection, so
I'll also add that for create_sid() functions.
>> I've also added 2 new escape functions to pgsql in trunk
>> a while ago, pg_escape_literal()/pg_escape
On Fri, Mar 2, 2012 at 11:44 PM, Kris Craig wrote:
> This was me, please disregard. Someone in our local meetup group mentioned
> having some problem with the form but it seems to be working just fine as
> far as I can tell.
>
we had some problems with the box hosting master.php.net, it caused
This was me, please disregard. Someone in our local meetup group mentioned
having some problem with the form but it seems to be working just fine as
far as I can tell.
While I'm thinking about it, who actually approves (i.e. moderates) these
requests, anyway? I've always wondered about that.
--
Someone mentioned having trouble with the form so I'm just doing a quick
test. Also curious to see where these requests actually go. Please disregard.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
https://wiki.php.net/rfc/php53eol
I'm undecided between 1+2 and 2 for both. I guess it depends on adoption
of 5.4 and progress with 5.5...
Side note: looking at the new email subjects, spent some time wondering
why we have this huge thread discussing line endings on the list and
what'
Hi!
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
It is fine to discuss it and you can still support PHP 4 now if you want
to, but who's going to be doing it otherwise? I wouldn't really want
On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara wrote:
> Well, there are a few questions about the implementation:
>
> 1. *Which* type casting rules should it follow?
>
> a. Regular cast rules (like $foo = (int) $foo), where it converts
> always without error?
> b. Internal function cast rules, w
Hi!
I'll work on the patch for strict session patch so that both
PHP 5.4 and 5.3 has the same functionality.
OK, do you have the latest patch for that? I remember originally it
involved some non-BC changes and there were other questions, but I'd
like to see the final one. In general, if ther
PHP 6 comes out sometime around 2024 when, at PHP 5.27 Ramus decides
to say, "screw it" - 6.
Sorta like what happened with the Linux Kernel (which was 2.26 FOREVER)
Tongue in cheek remark aside, we need to be cautious about avoiding
using the major version tag (although the stupidity of the brows
On Fri, Mar 2, 2012 at 8:34 PM, Kris Craig wrote:
> Awesome, thanks for the info guys!
>
> Does anybody know what the timeline is on having everything ported over to
> Git?
>
> --Kris
>
>
>
php-src will be migrated in the next two weeks or so (Stas asked David to
wait a little bit, so if somethin
Actually, my vote would be for "PHP Vista"
--Kris
On Fri, Mar 2, 2012 at 11:33 AM, Ronald Chmara wrote:
> On Fri, Mar 2, 2012 at 11:05 AM, Pierre Joye wrote:
> > that's totally off topic... but we have no idea yet when will be php
> > 6, or whatsoever.
> > However next is in around a year
Awesome, thanks for the info guys!
Does anybody know what the timeline is on having everything ported over to
Git?
--Kris
On Fri, Mar 2, 2012 at 11:33 AM, Ferenc Kovacs wrote:
>
>
> On Fri, Mar 2, 2012 at 8:25 PM, Alexander Moskaliov wrote:
>
>> > it already happened.
>> Not for all projects.
On Fri, Mar 2, 2012 at 8:25 PM, Alexander Moskaliov wrote:
> > it already happened.
> Not for all projects.
>
>
the question wasn't about whether all projects are moved or not.
but that the credentials are migrated or not.
at least this is what I understood from the original question.
for that qu
On Fri, Mar 2, 2012 at 11:05 AM, Pierre Joye wrote:
> that's totally off topic... but we have no idea yet when will be php
> 6, or whatsoever.
> However next is in around a year :)
"PHPME", "PHPXP", "PHP Feisty Foxbat", "PHP#"
Let's name this bike shed*!
-Ronabop
*http://en.wikipedia.org/w
> it already happened.
Not for all projects.
>how/when will that happen
You can see what projects already moved on git.php.net
With regards, Alexander Moskaliov
ir...@irker.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Mar 2, 2012 at 8:11 PM, Kris Craig wrote:
> Hey guys,
>
> Please forgive me if this has already been addressed elsewhere, but what
> can we expect to happen with regard to migrating Subversion credentials
> over to Git? I.e. how/when will that happen, or has it already happened?
>
>
> Th
2012/3/2 Johannes Schlüter :
> So to sum it all up: I would prefer to promise security fixes only to
> the outside (2 years if people here think that's a good time) and then,
> as a group, agree to do additional bug fixing during that time.
So, to sum it one step further, option #1
--
Pierre
Hey guys,
Please forgive me if this has already been addressed elsewhere, but what
can we expect to happen with regard to migrating Subversion credentials
over to Git? I.e. how/when will that happen, or has it already happened?
Thanks!
--Kris
I think that caching part you're talking about is in function
zend_mm_alloc_int..i don't see what caching has to do with these macros...
but i maybe mistaking of course. What i don't understand is those additions and
substracting in those macros..but i'll read more tomorrow.
Kris Craig wrote:
I'm probably missing something, but why not just do it like we did with
5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate
it and be done with it?
Like I said, I'm probably missing something lol, so if someone could
explain why this is different I'd be
Hi,
the primary goal should be to encourage people to move to 5.4 as soon as
possible. The clear marketing message should be along the lines of "PHP
5.4 is the best version there is, it has all of 5.3's bug fixes and
additional improvements". We have to drive the 5.4 adoption.
I also don't think
Ok, I'm up to speed now. I agree that Option 1 is the best approach.
--Kris
On Fri, Mar 2, 2012 at 10:58 AM, Pierre Joye wrote:
> again, we have a clear EOL process now for 5.4 and later.
>
> Only 5.3 does not have any. We have to define it now instead of doing
> it in 1-2 years without givin
On Fri, Mar 2, 2012 at 7:47 PM, Kris Craig wrote:
> What's the problem you're having with them?
>
> --Kris
http://comments.gmane.org/gmane.comp.php.devel/70417
the commit mail format is different on the current git setup than the
current svn setup.
for svn there is one email for each commit and
that's totally off topic... but we have no idea yet when will be php
6, or whatsoever.
However next is in around a year :)
On Fri, Mar 2, 2012 at 8:00 PM, Kris Craig wrote:
> From the timelines I've seen floating around, I was under the impression
> that the next one would be 5.5, followed by 5.
>From the timelines I've seen floating around, I was under the impression
that the next one would be 5.5, followed by 5.6, etc. PHP 6 is at least a
few years off according to every projection I've seen.
--Kris
On Fri, Mar 2, 2012 at 1:26 AM, Ferenc Kovacs wrote:
> On Fri, Mar 2, 2012 at 1:33
again, we have a clear EOL process now for 5.4 and later.
Only 5.3 does not have any. We have to define it now instead of doing
it in 1-2 years without giving our users any kind of reasonable delay
to plan a migration.
Cheers,
On Fri, Mar 2, 2012 at 7:54 PM, Kris Craig wrote:
> I'm probably mis
On Mar 2, 2012, at 10:36 AM, Derick Rethans wrote:
> Hi!
>
> Can we please fix the GIT commit mails before we move anything else
> over?
+1
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm probably missing something, but why not just do it like we did with
5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate
it and be done with it?
Like I said, I'm probably missing something lol, so if someone could
explain why this is different I'd be much obliged! =)
-
What's the problem you're having with them?
--Kris
On Fri, Mar 2, 2012 at 10:36 AM, Derick Rethans wrote:
> Hi!
>
> Can we please fix the GIT commit mails before we move anything else
> over?
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, v
Hi!
#define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \
(zend_mm_free_block*) ((char*)&heap->free_buckets[index * 2] + \
sizeof(zend_mm_free_block*) * 2 - \
sizeof(zend_mm_small_free_block))
#define
ZEND_MM_REST_BUCKET(heap) \
(zend_mm_free_block*)((char*)&heap->rest_buckets[0] + \
sizeof(zend_mm_
Hi!
Can we please fix the GIT commit mails before we move anything else
over?
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
> > https://wiki.php.net/rfc/php53eol
>
> I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
> and Stefan had an interesting idea: why not announce (
hi Sebastian,
Thing is that we already have well defined lifecycle for anything
after 5.4. So the question is only about 5.3.
That's why, given that it is already a couple of years old, I would
rather go with a statically defined EOL now. As php-next is very
unlikely to be the moment where people
On 03/02/2012 10:54 AM, Pierre Joye wrote:
And when do you think it is one year after php-next? In two years. So
much about one year being the only option ;-)
I am capable of learning, but that's besides the point. The point is
static (two years after release) vs. dynamic (one year after next
they are totally unrelated. The discussion here is not about whether
next will be late but when 5.3 will end.
The key here is not the date itself but the ability for hosting
companies, distros, etc. to plan a migration or an EOL. One or two
months less or more do not change anything, as long as th
On Thu, Mar 1, 2012 at 21:00, Adam Harvey wrote:
>
> - New Mirror Management System (Daniel Brown): not sure if this is
> relevant — systems guys? Daniel?
No, the system I had been drafting was mainly to fix a few issues
and introduce some new features to make mirror management easier. In
th
On Fri, Mar 2, 2012 at 5:06 PM, Pierre Joye wrote:
> On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs wrote:
>
> > that's just the schedule
>
> Yes, and as of now this is the plan. The idea is the same, that does
> not affect the EOL of 5.3 is php-next is a month late, not at all.
>
>
yep, and I ex
On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs wrote:
> that's just the schedule
Yes, and as of now this is the plan. The idea is the same, that does
not affect the EOL of 5.3 is php-next is a month late, not at all.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.o
On Fri, Mar 2, 2012 at 4:54 PM, Pierre Joye wrote:
> hi Sebastian,
>
> On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann
> wrote:
> > On 03/02/2012 07:34 AM, Pierre Joye wrote:
> >>
> >> https://wiki.php.net/rfc/php53eol
> >
> >
> > I discussed with Arne Blankerts and Stefan Priebsch over brea
hi Sebastian,
On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann wrote:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
>>
>> https://wiki.php.net/rfc/php53eol
>
>
> I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
> and Stefan had an interesting idea: why not announce (now
I like that. That way there will always be 2 stable maintained
versions, and possibly a third (depending on timing) that's security
only...
Solves the problem quite nicely IMHO...
Anthony
On Fri, Mar 2, 2012 at 10:41 AM, Sebastian Bergmann wrote:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
>>
On 03/02/2012 07:34 AM, Pierre Joye wrote:
https://wiki.php.net/rfc/php53eol
I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
and Stefan had an interesting idea: why not announce (now) that PHP 5.3
will go into EOL a year after PHP 5.5 comes out?
* Now until PHP 5
Am 02.03.2012 15:15, schrieb Sebastian Bergmann:
On 03/02/2012 08:34 AM, Simon Schick wrote:
It's really hard to make a decision here because you also have to care
about big companies in one way, that have not updated to PHP 5.3 now
Such companies are using LTS releases of their OS distributio
Already added in google reader..now i see the site is accesible also,
strange.
I've looked at the picture, read your explanation, but i still didn't get
it.i'll think some more about this and perhaps i'll suggest you a better
translation at the end.
Thanks!
On Fri, Mar 2, 2012 at 10:12 PM, Adi Mutu wrote:
> Now that's really awesome.:)
> I have to do something so i can access and subscribe to that blog.
Hi:
Google reader is a good choice~ :)
I am so glad you like it.
thanks .
> Are you serious about that firewall?
> That would be my first time
On Fri, Mar 2, 2012 at 8:51 PM, Adi Mutu wrote:
>
>
> Hello,
>
> Can somebody shed some light on these 2 defines? Thanks.
>
>
> #define ZEND_MM_SMALL_FREE_BUCKET(heap, index) \ (zend_mm_free_block*)
> ((char*)&heap->free_buckets[index * 2] + \ sizeof(zend_mm_free_block*) *
> 2 - \ sizeo
On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu wrote:
>
>
> Thanks Julien,
>
> but i've already read your article using translator and did not found an
> answer to that (i've also sent you an email about Zend mm a few days ago)
>
Not seen that.
Anyway, I dont master all ZendMM stuff, I couldn't expla
On 03/02/2012 08:34 AM, Simon Schick wrote:
It's really hard to make a decision here because you also have to care
about big companies in one way, that have not updated to PHP 5.3 now
Such companies are using LTS releases of their OS distribution (RHEL,
SLES, ...) where the vendor will take c
Now that's really awesome.:)
I have to do something so i can access and subscribe to that blog.
Are you serious about that firewall?
That would be my first time i actually encounter a problem because of this.
From: Ferenc Kovacs
To: Adi Mutu
Cc: jpauli ; "
On 03/02/2012 07:34 AM, Pierre Joye wrote:
https://wiki.php.net/rfc/php53eol
One year with bugs fixes (both security and normal bugs) seems to be
the only feasible option to me.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu wrote:
>
>
> Thanks Julien,
>
> but i've already read your article using translator and did not found an
> answer to that (i've also sent you an email about Zend mm a few days ago)
> laurence site looks down to me. Perhaps the link is wrong?
>
> Thanks,
>
Hi, all
It's really hard to make a decision here because you also have to care
about big companies in one way, that have not updated to PHP 5.3 now ...
But instead of that I read some posts from November last year that they
have PHP6 in their control-panel, what is basically PHP 5.4 beta ...
One
Thanks Julien,
but i've already read your article using translator and did not found an answer
to that (i've also sent you an email about Zend mm a few days ago)
laurence site looks down to me. Perhaps the link is wrong?
Thanks,
A.
From: jpauli
To: Adi Mutu
On Fri, Mar 2, 2012 at 2:43 PM, Adam Harvey wrote:
> On 2 March 2012 21:34, Simon Schick wrote:
> > One or two years is way to short if you'd ask me. A major release should
> be
> > supported with all kind of bug fixes for min. 3 years after a new release
> > has been brought out. Specially if i
Laruence and I wrote articles about ZendMM internals.
You would find them at http://www.laruence.com/2011/11/09/2277.html and
http://julien-pauli.developpez.com/tutoriels/php/internals/zend-memory-manager/
.
You can use any translator to get them in English
For basic use, see the readme at
http:
On 2 March 2012 21:34, Simon Schick wrote:
> One or two years is way to short if you'd ask me. A major release should be
> supported with all kind of bug fixes for min. 3 years after a new release
> has been brought out. Specially if it's a wide-spread language like PHP that
> has been implemented
btw, thanks for those who keep the discussion focused on 5.3 EOL :-)
For the votes, the votes phase will begin next week :)
On Fri, Mar 2, 2012 at 2:12 PM, Adam Harvey wrote:
> On 2 March 2012 21:05, Gustavo Lopes wrote:
>> Fair enough. Option #1 seems the most appropriate then. The others seem
On 2 March 2012 21:05, Gustavo Lopes wrote:
> Fair enough. Option #1 seems the most appropriate then. The others seem too
> drastic to implement with such short notice.
+1. We can't drop bug fixes immediately without warning, and I don't
think the overhead of backporting security fixes is too one
On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara wrote:
> Would it be worth while to discuss the possibility of LTS releases
> (Long Term Support) with 5 or 7 year support (from time of initial
> release)...?
>
> 5.3 is 2.5 years old now. Which means depending on the option that's
> chosen here,
On Fri, 02 Mar 2012 14:00:51 +0100, Pierre Joye
wrote:
On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes
wrote:
I'd go with another option:
One year of bug fixes, one year of security fixes and bug fixes that are
trivial to backport.
Won't work. It is then two years bug fixing.
The idea
Hi,
We already discussed LTS
On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara wrote:
> Would it be worth while to discuss the possibility of LTS releases
> (Long Term Support) with 5 or 7 year support (from time of initial
> release)...?
>
> 5.3 is 2.5 years old now. Which means depending on the
On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes wrote:
> I'd go with another option:
>
> One year of bug fixes, one year of security fixes and bug fixes that are
> trivial to backport.
Won't work. It is then two years bug fixing.
The idea of security only is to reduce both the amount of work and
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
5.3 is 2.5 years old now. Which means depending on the option that's
chosen here, it'll be completely out of support a mere 3.5 to 4.5
years after ini
On Fri, 02 Mar 2012 13:34:21 +0100, Pierre Joye
wrote:
hi,
It should have been done before 5.4.0 was out, but better late than
never.
I put together four options here:
https://wiki.php.net/rfc/php53eol
I'm in favor of option #1, as it gives enough time to our users to
migrate by reduci
Well, there are a few questions about the implementation:
1. *Which* type casting rules should it follow?
a. Regular cast rules (like $foo = (int) $foo), where it converts
always without error?
b. Internal function cast rules, where it warnings on error and
prevents execution of the function.
c.
fixed
On Fri, Mar 2, 2012 at 1:45 PM, Keloran wrote:
> isnt option3 and option1 the same ? (unless i cant read properlly {very
> possible})
>
> On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye wrote:
>>
>> hi,
>>
>> It should have been done before 5.4.0 was out, but better late than never.
>>
>> I p
isnt option3 and option1 the same ? (unless i cant read properlly {very
possible})
On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
Hi Pierre,
Option 1 and 3 are the same ;-)
Option 1
One year with bugs fixes followed by one year with security fixes only
Option 2
Two years with security fixes only
Option 3
One year with bugs fixes followed by one year with security fixes only
Option 4
One year with security fixes only
hi,
It should have been done before 5.4.0 was out, but better late than never.
I put together four options here:
https://wiki.php.net/rfc/php53eol
I'm in favor of option #1, as it gives enough time to our users to
migrate by reducing the maintenance period to only one year.
Suggestions or comm
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw wrote:
> No, you've misunderstood. The average new not-really-a-developer has no
> concept of security. Every SQL query they write is vulnerable to injection.
> Every echo exposes their site to XSS vulnerabilities. Every form is
> vulnerable to CSRF
Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
+1 for the syntax. There are two nice side effects I would like to
underline.
1.
Error-raising can be clearly delegated to the type juggling mechanism.
There will be no need to implement anything new here but reuse the existing
type juggling system of PHP. That would be very consistent. At the en
On 2 March 2012 01:56, Philip Olson wrote:
> Hello!
>
> Please clarify whether or not get_magic_quotes_gpc() and
> get_magic_quotes_runtime()
> are deprecated, because I do not think they are. Deprecated means people
> should not
> use them while writing new code, but they are perfectly sensible
On Fri, Mar 2, 2012 at 1:33 AM, David Soria Parra wrote:
> Hi internals,
>
> just a heads up. The PHP_5_4 branch is open for commits again.
>
> - David
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
On a somehow related topi
Hi Stats,
I'll work on the patch for strict session patch so that both
PHP 5.4 and 5.3 has the same functionality.
I've also added 2 new escape functions to pgsql in trunk
a while ago, pg_escape_literal()/pg_escape_identifier().
Is it okay to merge 5.4 branch also?
You mentioned it's okay for 5.
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP
>
> This is a potential concern if the aliases for scalar were included (bool,
> int, float, string), as Anthony mentioned, although merely implementing the
> first part of the proposal (scalar type hinting) wouldn't cause any trouble.
>
Yes, exactly. I was only talking about this specific aspect.
81 matches
Mail list logo
