On 2 August 2012 13:00, Adam Harvey wrote:
> On 2 August 2012 12:30, Kris Craig 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, listserv threads, etc? If we're
On 2 August 2012 12:30, Kris Craig 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, listserv threads, etc? If we're going to do this,
> we may as well cover as many
On Wed, Aug 1, 2012 at 11:45 AM, Rasmus Lerdorf wrote:
> On 08/01/2012 11:16 AM, Ángel González wrote:
>
> > There should be a page like http://www.php.net/ancient-versions listing
> the
> > versions with the date they went EOL and how much time has passed since
> > them.
> > Some scary warnings
On 08/01/2012 01:24 PM, Kris Craig wrote:
There should be a page like http://www.php.net/ancient-versions listing
the
versions with the date they went EOL and how much time has passed since
them.
Some scary warnings about "Known remote code execution vulnerabe" may be
good too.
The goal? To serve
On Tue Jul 31 12:21 PM, Anthony Ferrara wrote:
> Jonathan,
>
>
> Again, implementing something in the core that's not verified and
> can't be implemented well by the vast majority of developers out
> there.
Alright so I found some people supporting my claims:
http://blog.mozilla.org/webappsec
>
> Also, be aware that BCrypt only uses the first 72 characters of the
> password field. So if you use a hex encoded sha512 output, a good deal
> of entropy would be lost (almost half of it)...
>
Good to know, do most hash algorithms have limitations on the # of chars as
input?
That would ex
2012/8/1 Ángel González :
> I'd go with the hashing. I'd would however produce a slightly different
> prefix
> than with bare bcrypt.
Like that. And I thought some about it. Currently, there is no real
need for that. And no one is hindered to implement his own
version-information into it.
But to d
On Wed, Aug 1, 2012 at 8:16 PM, Ángel González wrote:
> On 01/08/12 20:02, Kris Craig wrote:
> > On Wed, Aug 1, 2012 at 6:13 AM, hakre wrote:
> >
> >> I have some simple questions about PHP 5.x End Of Life (EOL) dates:
> >>
> >> PHP 5.0 - Is there some official news-item or changelog entry on
>
On 08/01/2012 11:16 AM, Ángel González wrote:
> There should be a page like http://www.php.net/ancient-versions listing the
> versions with the date they went EOL and how much time has passed since
> them.
> Some scary warnings about "Known remote code execution vulnerabe" may be
> good too.
> The
2012/8/1 Christoph Hochstrasser :
> I'm lately using @$var["key"] a lot (despite it's slowness) and I like it a
> lot. It makes
> most code a lot more readable. I would be +1 for it, if we can make it fast.
>
> I think most people (me included) want only to avoid the notice for accessing
> undefi
On Wed, Aug 1, 2012 at 11:16 AM, Ángel González wrote:
> On 01/08/12 20:02, Kris Craig wrote:
> > On Wed, Aug 1, 2012 at 6:13 AM, hakre wrote:
> >
> >> I have some simple questions about PHP 5.x End Of Life (EOL) dates:
> >>
> >> PHP 5.0 - Is there some official news-item or changelog entry on
>
Hey guys,
Sorry for the delayed report. They never responded to my last follow-up
email a couple weeks ago and I kinda forgot about it until now.
Fortunately, I checked the website and it looks like they do have us listed
finally. Here's the URL: http://internetdefenseleague.org/
Please feel
On 01/08/12 20:02, Kris Craig wrote:
> On Wed, Aug 1, 2012 at 6:13 AM, hakre wrote:
>
>> I have some simple questions about PHP 5.x End Of Life (EOL) dates:
>>
>> PHP 5.0 - Is there some official news-item or changelog entry on php.netthat
>> says at which date PHP 5.0 went End Of Life?
>>
>> PHP
On 31/07/12 22:20, Peter Lind wrote:
> On 31 July 2012 22:02, Anthony Ferrara wrote:
>> Peter,
>>
>> On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind wrote:
>>> On 31 July 2012 18:21, Anthony Ferrara wrote:
>>>
>>> *snip*
>>>
Also, be aware that BCrypt only uses the first 72 characters of the
>>
On 08/01/2012 06:13 AM, hakre wrote:
> I have some simple questions about PHP 5.x End Of Life (EOL) dates:
>
> PHP 5.0 - Is there some official news-item or changelog entry on php.net that
> says at which date PHP 5.0 went End Of Life?
>
> PHP 5.2 - Does the "End Of Support" that was announced t
Hi,
> Traceback (most recent call last):
> File "", line 1, in
> KeyError: 'a'
>
> And it's just as annoying as in PHP. Actually, probably more annoying
> :). But it has .get() which solves the problem usually, albeit in a bit
> more verbose way. Also, Python has defaultdict which I would usua
On Wed, Aug 1, 2012 at 6:13 AM, hakre wrote:
> I have some simple questions about PHP 5.x End Of Life (EOL) dates:
>
> PHP 5.0 - Is there some official news-item or changelog entry on php.netthat
> says at which date PHP 5.0 went End Of Life?
>
> PHP 5.2 - Does the "End Of Support" that was anno
Hi!
> I've looked a bit into other languages (Ruby, Python, Go) and
> all of them do not generate an error when an undefined dict/hash/map key is
> accessed.
Python would definitely throw an exception:
>>> a = {}
>>> a
{}
>>> print a['a']
Traceback (most recent call last):
File "", line 1, in
Hi,
> I'd be very happy if we could have something like @$var['foo'] just work
> by not generating any errors, but if not then probably having some
> syntax saying "this variable or null, no notices" will be good - if say
> it's $?foo then we could easily add defaults by doing $?foo ?: 'bar'.
> Ma
On 07/31/2012 04:23 PM, Stan Vass wrote:
I'd like to point out some puzzling behaviors in Traits as they exist in the
production releases of PHP 5.4.
Regardless of the outcome of the mail thread, can you review the traits tests
and create new tests for
any behaviour not already covered?
Ch
On Aug 1, 2012, at 7:01 AM, Johannes Schlüter wrote:
> On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote:
>> The default if it's not included in the .ini is ON, but the
>> sample .ini's both switch it off, and that is what the distributions
>> follow when creating a clean install.
>>
>> ALL
On 08/01/2012 05:38 AM, Lester Caine wrote:
> Andrew Faulds wrote:
>>> Then can you explain why >> a number
>>> >of ISP's who have recently updated from 5.2 to 5.3 ...
>> Which? "A number of ISP's"? How many are we talking about?
>> Also, is it our problem if ISPs changed their configuration during
On 01 Aug 2012, at 16:31, Stan Vass wrote:
>> Because it is not a matter of horizontal reuse.
>> Why don't you get a warning when you override an inherited method?
>> Because that is precisely the way things are supposed to work.
>>
>> The body of a class is not a trait. These methods are not 'e
I'd like to apologize for my language. My goal isn't to insult anybody,
especially PHP contributors of major features like traits.
I hope we can talk strictly implementation issues, I think I have a good
idea how we can move this forward, I'll email you a list of behavior changes
that I think
Because it is not a matter of horizontal reuse.
Why don't you get a warning when you override an inherited method?
Because that is precisely the way things are supposed to work.
The body of a class is not a trait. These methods are not 'equals'.
I still think that design decision is a sensible on
On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote:
> The default if it's not included in the .ini is ON, but the
> sample .ini's both switch it off, and that is what the distributions
> follow when creating a clean install.
>
> ALL that was required when the problem was identified was that ha
Hi Stan:
On 01 Aug 2012, at 14:56, Stan Vass wrote:
>> From that follows that traits override the super class's methods.
>> And, conflict resolution is only done between traits, not between a class
>> and its traits.
>> The class body is a definite thing. Why would you purposefully add something
I have some simple questions about PHP 5.x End Of Life (EOL) dates:
PHP 5.0 - Is there some official news-item or changelog entry on php.net that
says at which date PHP 5.0 went End Of Life?
PHP 5.2 - Does the "End Of Support" that was announced twice for PHP 5.2 has
the same meaning as "End Of
From that follows that traits override the super class's methods.
And, conflict resolution is only done between traits, not between a class
and its traits.
The class body is a definite thing. Why would you purposefully add
something to a class body that conflicts with a trait?
The class needs to
Andrew Faulds wrote:
Then can you explain why of ISP's who have recently updated from 5.2 to 5.3 ...
Which? "A number of ISP's"? How many are we talking about?
Also, is it our problem if ISPs changed their configuration during an upgrade?
How do we know it's our fault? Debian or RedHat or some o
Hi Stan:
On 01 Aug 2012, at 13:54, Stan Vass wrote:
>> The methods in the class have *always* higher precedence.
>> This is the same 'overriding' behavior used for inheritance.
>> From my personal perspective, changing this would lead to a major
>> inconsistency with how subclassing works.
>
>
Could you please point me *exactly* to the paragraph where we have
something written about static properties? I do not see that I wrote
anything special about static properties in the RFC. And I do not find it
in the docs either. static properties should work like normal properties.
I'd like t
Hi!
On 01 August 2012 at 09:36 Lester Caine wrote:
> Rasmus Lerdorf wrote:
> >>> Only with short tags on ... 5.4 has detached it from that, but 5.3 still
> >>> >>switches it off by default, and convincing ISP to switch short tags on
> >>> >>again is
> >>> >>a lost cause:( Fixing it in PHP5.3
The methods in the class have *always* higher precedence.
This is the same 'overriding' behavior used for inheritance.
From my personal perspective, changing this would lead to a major
inconsistency with how subclassing works.
Hi, I've subsequently read your RFC carefully and saw some of those
Slightly off-topic, $this being equal to NULL reminds me of how ECMAScript 5
changed the value of "this" to "undefined" in strict mode when not being called
as a method. I agree it's a more sensible solution, as the disappearance of a
variable might be more difficult to deal with than a variable c
Rasmus Lerdorf wrote:
Only with short tags on ... 5.4 has detached it from that, but 5.3 still
>>switches it off by default, and convincing ISP to switch short tags on again
is
>>a lost cause:( Fixing it in PHP5.3 was rejected:(
>
>Errm... So you are complaining we're not going back in time no
On 08/01/2012 12:57 AM, Stas Malyshev wrote:
> Hi!
>
>> Only with short tags on ... 5.4 has detached it from that, but 5.3 still
>> switches it off by default, and convincing ISP to switch short tags on again
>> is
>> a lost cause :( Fixing it in PHP5.3 was rejected :(
>
> Errm... So you are c
Hi!
> Only with short tags on ... 5.4 has detached it from that, but 5.3 still
> switches it off by default, and convincing ISP to switch short tags on again
> is
> a lost cause :( Fixing it in PHP5.3 was rejected :(
Errm... So you are complaining we're not going back in time now and make
diff
Stas Malyshev wrote:
setting without considering the consequences (
Err, I'm not sure what you mean - Only with short tags on ... 5.4 has detached it from that, but 5.3 still
switches it off by default, and convincing ISP to switch short tags on again is
a lost cause :( Fixing it in PHP5.3 wa
On Tue, Jul 31, 2012 at 11:55 PM, Lester Caine wrote:
> Stas Malyshev wrote:
>
>> Helping to solve the problem would also help everybody else upgrade TO
>>> PHP5.4?
>>>
>> OK, so what help do you require?
>>
> PEAR and PECL that work with PHP5.4 out of the box?
> At least the core of PEAR that do
Hi!
> PEAR and PECL that work with PHP5.4 out of the box?
> At least the core of PEAR that does not throw strict warnings from a stock
> install of PHP5.4 as E_STRICT is on.
For PEAR is think it is a wrong list, as for PECL most extensions are
maintained by their maintainers, and internals speci
41 matches
Mail list logo
