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.
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
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
On Fri, Mar 2, 2012 at 1:33 AM, David Soria Parra d...@php.net 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
On 2 March 2012 01:56, Philip Olson phi...@roshambo.org 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
+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
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
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com 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
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
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
isnt option3 and option1 the same ? (unless i cant read properlly {very
possible})
On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye pierre@gmail.com wrote:
hi,
It should have been done before 5.4.0 was out, but better late than never.
I put together four options here:
fixed
On Fri, Mar 2, 2012 at 1:45 PM, Keloran ava...@gmail.com 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 pierre@gmail.com wrote:
hi,
It should have been done before 5.4.0 was out, but better
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.
On Fri, 02 Mar 2012 13:34:21 +0100, Pierre Joye pierre@gmail.com
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
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
On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes glo...@nebm.ist.utl.pt 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
Hi,
We already discussed LTS
On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara ircmax...@gmail.com 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
On Fri, 02 Mar 2012 14:00:51 +0100, Pierre Joye pierre@gmail.com
wrote:
On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes glo...@nebm.ist.utl.pt
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.
On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara ircmax...@gmail.com 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
On 2 March 2012 21:05, Gustavo Lopes glo...@nebm.ist.utl.pt 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
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 ahar...@php.net wrote:
On 2 March 2012 21:05, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
Fair enough. Option #1 seems the
On 2 March 2012 21:34, Simon Schick simonsimc...@googlemail.com 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
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
On Fri, Mar 2, 2012 at 2:43 PM, Adam Harvey ahar...@php.net wrote:
On 2 March 2012 21:34, Simon Schick simonsimc...@googlemail.com 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
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
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
On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu adi_mut...@yahoo.com 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?
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/
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 tyr...@gmail.com
To: Adi Mutu
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
On Fri, Mar 2, 2012 at 2:57 PM, Adi Mutu adi_mut...@yahoo.com 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
On Fri, Mar 2, 2012 at 8:51 PM, Adi Mutu adi_mut...@yahoo.com 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 - \
On Fri, Mar 2, 2012 at 10:12 PM, Adi Mutu adi_mut...@yahoo.com 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
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!
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
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
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 sebast...@php.net wrote:
On 03/02/2012 07:34 AM,
hi Sebastian,
On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann sebast...@php.net 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
On Fri, Mar 2, 2012 at 4:54 PM, Pierre Joye pierre@gmail.com wrote:
hi Sebastian,
On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann sebast...@php.net
wrote:
On 03/02/2012 07:34 AM, Pierre Joye wrote:
https://wiki.php.net/rfc/php53eol
I discussed with Arne Blankerts and
On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs tyr...@gmail.com 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 |
On Fri, Mar 2, 2012 at 5:06 PM, Pierre Joye pierre@gmail.com wrote:
On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs tyr...@gmail.com 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,
On Thu, Mar 1, 2012 at 21:00, Adam Harvey ahar...@php.net 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
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
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
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
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 (now)
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
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] + \
What's the problem you're having with them?
--Kris
On Fri, Mar 2, 2012 at 10:36 AM, Derick Rethans der...@php.net 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
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! =)
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
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 kris.cr...@gmail.com
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 tyr...@gmail.com wrote:
On Fri, Mar
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 kris.cr...@gmail.com wrote:
From the timelines I've seen floating around, I was under the impression
that the next one would be
On Fri, Mar 2, 2012 at 7:47 PM, Kris Craig kris.cr...@gmail.com 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
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 pierre@gmail.com 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
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
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
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.
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
2012/3/2 Johannes Schlüter johan...@schlueters.de:
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,
On Fri, Mar 2, 2012 at 8:11 PM, Kris Craig kris.cr...@gmail.com 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
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 11:05 AM, Pierre Joye pierre@gmail.com 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
On Fri, Mar 2, 2012 at 8:25 PM, Alexander Moskaliov ir...@irker.net 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.
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 tyr...@gmail.com wrote:
On Fri, Mar 2, 2012 at 8:25 PM, Alexander Moskaliov ir...@irker.netwrote:
it already happened.
Actually, my vote would be for PHP Vista
--Kris
On Fri, Mar 2, 2012 at 11:33 AM, Ronald Chmara rona...@gmail.com wrote:
On Fri, Mar 2, 2012 at 11:05 AM, Pierre Joye pierre@gmail.com wrote:
that's totally off topic... but we have no idea yet when will be php
6, or whatsoever.
On Fri, Mar 2, 2012 at 8:34 PM, Kris Craig kris.cr...@gmail.com 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
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
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
On Fri, Mar 2, 2012 at 7:51 AM, Anthony Ferrara ircmax...@gmail.com 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
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
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
Someone mentioned having trouble with the form so I#039;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
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.
On Fri, Mar 2, 2012 at 11:44 PM, Kris Craig kris.cr...@gmail.com 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
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,
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 tyr...@gmail.com wrote:
On Fri, Mar 2, 2012 at 11:44 PM, Kris Craig kris.cr...@gmail.com wrote:
This was me, please
On Sat, Mar 3, 2012 at 1:56 AM, Kris Craig kris.cr...@gmail.com 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
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
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
81 matches
Mail list logo
