On 2 August 2012 13:00, Adam Harvey ahar...@php.net wrote:
On 2 August 2012 12:30, Kris Craig kris.cr...@gmail.com wrote:
First we'll need to consolidate the information regarding when each version
was EOL'd. Are they all in news announcements, or are they scattered
between announcements,
So... I was thinking of proposing that we perhaps leave Arrays as is
w/r/t undefined indices, while fixing up the ArrayObject gaps and
making that the smart one (wrap/box in an AO if you want
expanded/overloadable functionality).
That idea was based on my belief that ArrayObject::offsetGet
On 2 August 2012 07:35, Adam Harvey ahar...@php.net wrote:
Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or
would we rather have a manual array?) Specific notes on
vulnerabilities to add to branches? Better versions of the copy in the
initial blurb?
Why is this information
On 2 August 2012 15:56, Peter Cowburn petercowb...@gmail.com wrote:
On 2 August 2012 07:35, Adam Harvey ahar...@php.net wrote:
Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or
would we rather have a manual array?) Specific notes on
vulnerabilities to add to branches? Better
On 2012-08-02 19:56, Peter Cowburn wrote:
On 2 August 2012 07:35, Adam Harvey ahar...@php.net wrote:
Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or
would we rather have a manual array?) Specific notes on
vulnerabilities to add to branches? Better versions of the copy in the
Adam Harvey wrote:
Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or
would we rather have a manual array?) Specific notes on
vulnerabilities to add to branches? Better versions of the copy in the
initial blurb?
A little academic now, but I was convinced that 5.1 had some more
On 2 August 2012 09:36, Morgan L. Owens pack...@nznet.gen.nz wrote:
Just as each release announcement dated with detailed kept on a distinct
page (linked in that list), all that's needed there is a date when support
ended, with (any available) information on what was obsoleted in the process
On 2012-08-02 20:42, Peter Cowburn wrote:
On 2 August 2012 09:36, Morgan L. Owens pack...@nznet.gen.nz wrote:
Just as each release announcement dated with detailed kept on a distinct
page (linked in that list), all that's needed there is a date when support
ended, with (any available)
On 2 August 2012 16:51, Morgan L. Owens pack...@nznet.gen.nz wrote:
On 2012-08-02 20:42, Peter Cowburn wrote:
The details on things being obsoleted should be in the migration guides.
Then that would be where the links go, in a similar manner to the Changelog
links.
I've added links to the
I've added http://php.net/eol
Thank you. For PHP 5.x I had created a blog post which is not that complete
just reflects the work on scanning through the news items:
http://hakre.wordpress.com/2012/07/30/historic-php-end-of-life-dates/
I started this to create a timeline graphic, a first
No date for 5.3 yet. Depends how development goes on the next version
after 5.4. EOL announcements are in the release announcements. 5.2 EOL
was announced here: http://www.php.net/archive/2010.php#id2010-07-22-1
Yes, I've seen that with release announcements often (but not always) a
(more
Hmm, in that case, why do ini defaults differ significantly from those compiled
in?
--
Sent from Samsung Mobile
Andrew Faulds
http://ajf.me/
Johannes Schlüter johan...@schlueters.de wrote:
On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote:
The default if it's not included in the .ini is
Andrew Faulds wrote:
Hmm, in that case, why do ini defaults differ significantly from those compiled
in?
There was a discussion about that not long ago? Aren't the PHP5.4 bits now all
tidied so that the defaults match a production .ini file? So only development
changes something?
I've not
Hi,
Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't cause
an error though.
JS's || operator supresses this error though, which is great for e.g. x = x ||
new Object();
--
Sent from Samsung Mobile
Andrew Faulds
http://ajf.me/
Stas Malyshev smalys...@sugarcrm.com wrote:
OK
No discussions on why register_globals has been removed we all understand why
and now have to live with that ... I'm not winging here!
The question is Does anybody have an 'elegant' fix to quickly update a legacy
site that relies on globals to pass variables between page views?
My
On 02/08/2012 13:51, Lester Caine wrote:
OK
No discussions on why register_globals has been removed we all
understand why and now have to live with that ... I'm not winging here!
The question is Does anybody have an 'elegant' fix to quickly update
a legacy site that relies on globals to
rich gray wrote:
OK
No discussions on why register_globals has been removed we all understand why
and now have to live with that ... I'm not winging here!
The question is Does anybody have an 'elegant' fix to quickly update a legacy
site that relies on globals to pass variables between page
Lester,
On Thu, Aug 2, 2012 at 8:49 AM, Lester Caine les...@lsces.co.uk wrote:
rich gray wrote:
OK
No discussions on why register_globals has been removed we all
understand why
and now have to live with that ... I'm not winging here!
The question is Does anybody have an 'elegant' fix to
On Thu, Aug 2, 2012 at 2:34 PM, rich gray r...@richgray.com wrote:
On 02/08/2012 13:51, Lester Caine wrote:
OK
No discussions on why register_globals has been removed we all understand
why and now have to live with that ... I'm not winging here!
The question is Does anybody have an
On 02/08/2012 15:56, Ferenc Kovacs wrote:
On Thu, Aug 2, 2012 at 2:34 PM, rich gray r...@richgray.com
mailto:r...@richgray.com wrote:
On 02/08/2012 13:51, Lester Caine wrote:
OK
IMO - this should be posted on PHP general not internals -- have
you tried extract() ?
Anthony Ferrara wrote:
I'm specifically asking in relation to helping users migrate from PHP5.2 ...
trying to expand the documentation of making that process easier. Pointing
at a single manual page is a good example of why we need a more consistent
support for all those users
Em 2012-08-02 18:07, Lester Caine escreveu:
[...]
In the meantime some links to this old material would be helpful, if
only to get access to them on the migration guides. Because I'm
actively looking, hopefully the problem will not arise, but you can
guarantee something will pop up that has
Hi,
I don't know how to tag this kind of discussion (because it's not RFC
request).
I've interested in runkit PECL extension and think that it should be part
of the PHP core runtime.
I do think that the implementation should be different and don't mind to
suggest my implementation as RFC, but
On Aug 2, 2012 5:44 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi,
I don't know how to tag this kind of discussion (because it's not RFC
request).
I've interested in runkit PECL extension and think that it should be part
of the PHP core runtime.
I do think that the implementation
On Thu, Aug 2, 2012 at 7:56 PM, Leigh lei...@gmail.com wrote:
On Aug 2, 2012 5:44 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi,
I don't know how to tag this kind of discussion (because it's not RFC
request).
I've interested in runkit PECL extension and think that it should be
What do you think?
I think I need to get my lens prescription updated. I thought the subject
line read, Add *rootkit *to PHP Runtime and was already sharpening my
pitchfork before I realized my error.
For the record, I am firmly opposed to adding a rootkit to the PHP runtime.
A runkit
This is a great idea (the runkit, not the rootkit).
On Thu, Aug 2, 2012 at 1:12 PM, Kris Craig kris.cr...@gmail.com wrote:
What do you think?
I think I need to get my lens prescription updated. I thought the subject
line read, Add *rootkit *to PHP Runtime and was already sharpening my
2012/8/2 Andrew Faulds a...@ajf.me:
Hi,
Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't cause
an error though.
JS's || operator supresses this error though, which is great for e.g. x = x
|| new Object();
Could be cool to make this in PHP with the 'or' operator (or
For all those things you probably shouldn't have been doing anyway
That description is on the package because you... probably shouldn't
be doing these things.
Further, any discussion of runkit should focus on individual features of it.
Custom Superglobals: I consider these fairly
Sandboxing: Complicated by the fact that it only works in a threaded
build, can't transfer all types (e.g. resource, complex objects), and
can't run concurrently. Until/unless these problems can be
meaningfully solved, I wouldn't consider it a functional
implementation.
To me the thread
On Thu, Aug 2, 2012 at 4:17 PM, Leigh lei...@gmail.com wrote:
Sandboxing: Complicated by the fact that it only works in a threaded
build, can't transfer all types (e.g. resource, complex objects), and
can't run concurrently. Until/unless these problems can be
meaningfully solved, I wouldn't
I do think that some of the runkit features should not be included in PHP
core but I wish to focus on extending classes with extension methods,
constants, traits and members.
Just like all other complicated and powerful features in PHP, one should
use them with a good reason and when he/she
Yahav,
On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
I do think that some of the runkit features should not be included in PHP
core but I wish to focus on extending classes with extension methods,
constants, traits and members.
Just like all other complicated
On 03/08/12 01:22, Sara Golemon wrote:
In all seriousness, I'd love to hear how you'd do Sandboxing without
using the tsrm context hack I used in runkit. That approach had
nothing to do with being in PECL, it had to do with that being the
only mechanism available to swap globals in and out at
On Fri, Aug 3, 2012 at 3:07 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Yahav,
On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar g.b.ya...@gmail.comwrote:
I do think that some of the runkit features should not be included in PHP
core but I wish to focus on extending classes with
On 2 August 2012 16:58, Adam Harvey ahar...@php.net wrote:
On 2 August 2012 16:51, Morgan L. Owens pack...@nznet.gen.nz wrote:
On 2012-08-02 20:42, Peter Cowburn wrote:
The details on things being obsoleted should be in the migration guides.
Then that would be where the links go, in a similar
I don't see why this is not a good programming practice, lets get the
following example:
class Member {
public static function create(...) { }
public function update(...) { }
public function remove(...) { }
// ...
}
now you wish to add, for example, a ban functionally to
For my vote: I think keeping this in pecl is fine, because they're all
things which can be done from the extension space.
If my vote still counts (I was somehow involved in the creation of runkit at
one point (-: ), I say the same: extension is fine. Don't monkeypatch
production.
S
On Aug 2, 2012, at 17:16, Ángel González keis...@gmail.com wrote:
On 03/08/12 01:22, Sara Golemon wrote:
In all seriousness, I'd love to hear how you'd do Sandboxing without
using the tsrm context hack I used in runkit. That approach had
nothing to do with being in PECL, it had to do with
On Fri, Aug 3, 2012 at 5:46 AM, Sherif Ramadan theanomaly...@gmail.comwrote:
I don't see why this is not a good programming practice, lets get the
following example:
class Member {
public static function create(...) { }
public function update(...) { }
public function
Hi!
I've released PHP 5.4.6RC1 which can be found here:
http://downloads.php.net/stas/
Windows binaries as always are at:
http://windows.php.net/qa/
This is a regular bugfix release, the full list of issues fixed can be
found in the NEWS files. Please test and report if anything is
Hi!
https://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
IMO makes sense. Nulling-out $this makes most of the sane code (like
de-facto static functions not marked as static) work, and breaking
insane code in 5.5 in acceptable.
--
Hi!
Can you try using a stock version of libxml or using the latest version?
I met some issues in the past on Centos because of bad patches applied
to libxml.
I've built both 2.7.8 and 2.8.0 from source - same result. amp; is
ignored when parsing with PHP xml extension.
--
Stanislav
43 matches
Mail list logo
