Hi folks,
On 16 May 2011 22:25, Etienne Kneuss wrote:
> Hi,
>
> On May 16 16:52:08, Andrew Curioso wrote:
>> Well, that wasn't where I was expecting that thread to go, but to wrap it up
>> what do you think...
>> Is it too late to put this on the 5.4 roadmap for consideration?
>>
>> I'm assuming
I remember error messages have been improved since last decade, but
they were engine ones.
Parser ones have never been touched, so to improve them, I +1 your
idea Felipe :)
Julien
On Mon, May 16, 2011 at 7:52 PM, Florian Anderiasch wrote:
> On 16.05.2011 14:15, Felipe Pena wrote:
>> Other exampl
>From what I can tell, whatever changes made to fix this bug, are independent
of #54384.
Bug #54384 happens when the parent ctor is not called. This bug is triggered
only when it is called.
I did a quick check of the code and that seems to be the case.
But the existence of that bug makes me think
I need karma to commit test fixes:
1) session_encode_basic - added serialize_precision=100 ini setting
2) fix for http://bugs.php.net/48203: there's a segfault when
CURLOPT_STDERR file pointer is closed before calling curl_exec, i.e.
like this:
$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w'
hi,
On Tue, May 17, 2011 at 3:40 PM, Alexey Shein wrote:
> I need karma to commit test fixes:
> 1) session_encode_basic - added serialize_precision=100 ini setting
Is it not fixed already?
> 2) fix for http://bugs.php.net/48203: there's a segfault when
Pls open a bug report and attach the patc
2011/5/17 Pierre Joye :
> hi,
>
> On Tue, May 17, 2011 at 3:40 PM, Alexey Shein wrote:
>> I need karma to commit test fixes:
>> 1) session_encode_basic - added serialize_precision=100 ini setting
>
> Is it not fixed already?
>
As Tyrael already said this one was missed.
>> 2) fix for http://bugs
2011/5/16 Felipe Pena
> Hi all,
> As I have proposed previously in an old thread... What about we name all
> the tokens to have an improved parser error message? (i.e. anymore
> T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc)
>
> [...]
>
>
Other examples and patch at:
>
Created http://bugs.php.net/bug.php?id=54798.
--
Regards,
Shein Alexey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Em Tue, 17 May 2011 14:40:53 +0100, Alexey Shein
escreveu:
2) fix for http://bugs.php.net/48203: there's a segfault when
CURLOPT_STDERR file pointer is closed before calling curl_exec, i.e.
like this:
$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
$ch = curl_init();
curl_setopt($ch
On Tue, May 17, 2011 at 3:54 PM, Pierre Joye wrote:
> hi,
>
> On Tue, May 17, 2011 at 3:40 PM, Alexey Shein wrote:
> > I need karma to commit test fixes:
> > 1) session_encode_basic - added serialize_precision=100 ini setting
>
> Is it not fixed already?
>
>
there were other tests with missing s
> A few remarks:
>
> * Isn't this supposed to be fixed? Was there something that triggered a
> regression?
As far as I can see Jani checked only case when already closed file
descriptor was passed to curl_setopt. Here's the check is performed in
curl_exec, i.e. in curl_setopt file descriptor was v
Hi Felipe,
Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and agreed
to keep it as a historical landmark. Let's not have the discussion yet again
within the same year. Google it just to see the # of mentions.
What we could do as a compromise between history and improving ma
Em Tue, 17 May 2011 17:01:26 +0100, Andi Gutmans escreveu:
Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and
agreed to keep it as a historical landmark. Let's not have the
discussion yet again within the same year. Google it just to see the #
of mentions.
What we cou
On Tue, 17 May 2011, Felipe Pena wrote:
> 2011/5/16 Felipe Pena
>
> > Hi all,
> > As I have proposed previously in an old thread... What about we name all
> > the tokens to have an improved parser error message? (i.e. anymore
> > T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages
On Tue, May 17, 2011 at 6:01 PM, Andi Gutmans wrote:
> Hi Felipe,
>
> Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and
> agreed to keep it as a historical landmark. Let's not have the discussion
> yet again within the same year. Google it just to see the # of mentions.
>
>
M
Em Tue, 17 May 2011 17:07:09 +0100, Gustavo Lopes
escreveu:
[...]
Anyway, +1 to the change from you.
Sorry, it should read "from me".
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
+1 with Andi's improvement.
Gustavo - I realize it's not about changing the token's name, but nobody (=very
few) looks at the token names. The point is to keep the tradition of also
exposing this specific token name to the user, but still making it clear that
what was expected was :: - without
Hi!
I think we need to keep token name in the message, since it makes it
easier to understand what parser expected if you need to debug the
parser (as opposed to your code). So I think we need to have both the
human-readable name and the token name, as Andi suggested.
--
Stanislav Malyshev, S
On Tue, May 17, 2011 at 6:49 PM, Stas Malyshev wrote:
> Hi!
>
> I think we need to keep token name in the message, since it makes it easier
> to understand what parser expected if you need to debug the parser (as
> opposed to your code). So I think we need to have both the human-readable
> name an
On 05/17/2011 09:58 AM, Ferenc Kovacs wrote:
On Tue, May 17, 2011 at 6:49 PM, Stas Malyshevwrote:
Hi!
I think we need to keep token name in the message, since it makes it easier
to understand what parser expected if you need to debug the parser (as
opposed to your code). So I think we need to
Martin Scotta
On Mon, May 16, 2011 at 4:10 PM, Anthony Ferrara wrote:
> Personally, I really don't care for something like this. Would it be
> caught by a __call declaration if one existed (since it is a call to
> an undefined method)? Would you expect it to?
>
Although current PHP implement
21 matches
Mail list logo
