Just for info: GCC-4.1 now uses faster hand-written recursive-descent parser
(instead of bison generated).
Thanks. Dmitry.
> -Original Message-
> From: Zeev Suraski [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 10, 2006 2:26 AM
> To: Marcus Boerger
> Cc: Sara Golemon; internals@lists.p
Seems that needs fixing then (non-TSRM). We should support the
realpath cache also in non-TSRM mode.
At 10:31 PM 3/9/2006, Rasmus Lerdorf wrote:
Andi Gutmans wrote:
Are you sure VCWD_REALPATH doesn't use the realpath cache? It did
last time I checked and I think is still the right method to us
Rasmus Lerdorf wrote:
Andi Gutmans wrote:
Are you sure VCWD_REALPATH doesn't use the realpath cache? It did last
time I checked and I think is still the right method to use there...
quite
#define VCWD_REALPATH(path, real_path) realpath(path, real_path)
By the way, I agree that expand_filepa
Andi Gutmans wrote:
Are you sure VCWD_REALPATH doesn't use the realpath cache? It did last
time I checked and I think is still the right method to use there...
quite
#define VCWD_REALPATH(path, real_path) realpath(path, real_path)
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing Li
Are you sure VCWD_REALPATH doesn't use the realpath cache? It did
last time I checked and I think is still the right method to use there...
At 09:13 PM 3/9/2006, Brian J. France wrote:
Does anybody see a problem with this patch (which is currently
against the 5.1.2 release)?
expand_filepath wi
Does anybody see a problem with this patch (which is currently
against the 5.1.2 release)?
expand_filepath will eventual do a realpath, but it also uses the
realpath cache before calling realpath. VCWD_REALPATH just maps
directly to realpath and doesn't use the realpath cache so for every
Fix bugs in APC and occasionally introduce new ones.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3/9/06, Steph Fox <[EMAIL PROTECTED]> wrote:
> Please, Xuefer! Your vote was already recorded, shhh!
i wasn't to vote more than once. it's same vote but with a bit
different syntax changed. oh well, the result is out, this is only my
explaination.
Hi,
Just got home from a month in South America and is trying to catch up
on old posts...
On Sat, 18 Feb 2006 17:02:32 -0800, in php.internals [EMAIL PROTECTED]
(Andi Gutmans) wrote:
>I'm nuking safe_mode and I found something odd. In streams,
>php_plain_files_unlink() only checks php_check_ope
Hello Zeev,
yeah! which is why there is no need to do anything on that front :-)
marcus
Friday, March 10, 2006, 12:26:20 AM, you wrote:
> No speed boost with opcode caches, which will be bundled in PHP 6 :)
> Zeev
> At 01:15 10/03/2006, Marcus Boerger wrote:
>>Hello Sara,
>>
>> but if we
No speed boost with opcode caches, which will be bundled in PHP 6 :)
Zeev
At 01:15 10/03/2006, Marcus Boerger wrote:
Hello Sara,
but if we were moving from flex to re2c for that tokenizing scripts we'd
get a nice speed boost, too. Typically re2c based scanners are 2 to 3 times
faster than le
Hello Sara,
but if we were moving from flex to re2c for that tokenizing scripts we'd
get a nice speed boost, too. Typically re2c based scanners are 2 to 3 times
faster than lex based ones. And oh-re2c allows unicode scanning (2 byte
input) and you can use the same .re to generate two .c files if
Steph Fox wrote:
Perhaps there could be just the one hard rule. 'If it's possible to
implement it as an extension, do so.' There'd be nothing to prevent
co-opting essential functionality into the core, but also nothing
preventing fly-by-night technologies from having support in PHP. The
bigge
At 22:43 09/03/2006, Lester Caine wrote:
Zeev Suraski wrote:
You are back to the main problem, you cannot educate people by keeping
them away from the "dangerous" functions.
Uhm, of course you can. Avoiding problems is by far the best way
of solving them. But it has nothing to do with our to
Zeev Suraski wrote:
You are back to the main problem, you cannot educate people by keeping
them away from the "dangerous" functions.
Uhm, of course you can. Avoiding problems is by far the best way of
solving them. But it has nothing to do with our topic.
So can we have a 'disable' switch
The reason for using jump is "because it is not a full analog of C's goto
statement". It's my guess that experienced developers will want to lookup
what the behaviour in PHP is.
Cool. You just gave an excellent argument for not calling it 'goto' :)
Seriously, the manual entry will probably use
i've done some more analysis and I see where it uses
/usr/lib/nss_files.so.1 during the start up phase- probably this very
getgroups call.
I think that would do it. but why?
another question: is the ext/posix/posix.c bypassed when configured
--disable-posix?
your help is very much appreciated.
Steph Fox wrote:
If someone is searching for "goto" he/she most likely knows what
he/she is looking for. So this also helps experienced developers who
are new to PHP.
An experienced developer would know how to use it...!
That was kind of the point.
- Steph
The reason for using jump is "bec
> How do we do it? Unfortunately, I can't come up with a real mechanism
> to 'enforce' a due process and reasoning for new features.
One mechanism that the MapServer project[1] has adopted is that all "major"
features require an RFC before they are accepted and implemented. Whoever
is proposin
If someone is searching for "goto" he/she most likely knows what he/she
is looking for. So this also helps experienced developers who are new to
PHP.
An experienced developer would know how to use it...!
That was kind of the point.
- Steph
--
PHP Internals - PHP Runtime Development Mailing L
Steph Fox wrote:
BdB>>Even though I like "jump", people will most likely be searching for
BdB>>"goto" (PHP manual) or "goto PHP" (Google) when they're trying to
BdB>>find out if PHP has such a functionality. So, maybe it's better to
BdB>>just call it "goto".
For such people we might have a page
I'd like to raise a motion to 'Give the Language a Rest'.
Tired inbox? :)
Almost a decade since we started with the 2nd iteration on the syntax (PHP
3), and 2 more major versions since then, and we're still heatedly
debating on adding new syntactical, core level features.
Is it really neces
At 19:37 09/03/2006, Pierre wrote:
On 3/9/06, Steph Fox <[EMAIL PROTECTED]> wrote:
> > BdB>>Even though I like "jump", people will most likely be searching for
> > BdB>>"goto" (PHP manual) or "goto PHP" (Google) when they're trying to
> > BdB>>find out if PHP has such a functionality. So, maybe i
Being the colleague Sean refered to in his first post I thought I
might weigh in.
While I agree that once I looked at the base case that Sean worked out
of my code the problem didn't take too long to recognize, that's not
where I first experianced the problem. Problems first rear their head
deep w
DZ>>The web is one of the most quickly changing areas in computer technology.
DZ>>PHP, being primarily a language for web sites and applications, has to
DZ>>change constantly in order to be able to remain competitive. And it still
I don't see any real connection between new Web technologies and ch
The inability to inject tokens and expressions into the lexer and
parser is another limitation on what can be done from extensions in
terms of syntax level features. Yes, I know this is more of a problem
with bison and flex than with the design of ZE, but that doesn't make
it any less bothersome.
SF>>Erm, wouldn't those people who need to refer to the manual be exactly the
SF>>same people we wanted to protect from goto in the first place? :)
OK, make it:
goto: you don't really want to use it, but if you are still curious, see "jump".
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL
On 3/9/06, Steph Fox <[EMAIL PROTECTED]> wrote:
> > BdB>>Even though I like "jump", people will most likely be searching for
> > BdB>>"goto" (PHP manual) or "goto PHP" (Google) when they're trying to
> > BdB>>find out if PHP has such a functionality. So, maybe it's better to
> > BdB>>just call it "
BdB>>Even though I like "jump", people will most likely be searching for
BdB>>"goto" (PHP manual) or "goto PHP" (Google) when they're trying to
BdB>>find out if PHP has such a functionality. So, maybe it's better to
BdB>>just call it "goto".
For such people we might have a page in the manual sayi
Sure, after you folks implement named parameters. :)
*ducks and tries to hide*
Jared
On Mar 9, 2006, at 2:57 AM, Zeev Suraski wrote:
I'd like to raise a motion to 'Give the Language a Rest'.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/u
Sara Golemon schrieb:
> The inability to inject tokens and expressions into the lexer and
> parser is another limitation on what can be done from extensions in
> terms of syntax level features. Yes, I know this is more of a problem
> with bison and flex than with the design of ZE, but that does
Even though I like "jump", people will most likely be searching for "goto"
(PHP manual) or "goto PHP" (Google) when they're trying to find out if PHP
has
such a functionality. So, maybe it's better to just call it "goto".
Agreed. As the man said this morning, let's "Consider our Audience".
"G
Apart from namespaces, I can't think of any other "syntactical core
level feature" missing that could not be implemented as an extension.
Goto can't...
Well, okay fine. It can, but at a significantly greater cost and
complexity. By that token namespaces can be done in an extension too (You
BdB>>Even though I like "jump", people will most likely be searching for
BdB>>"goto" (PHP manual) or "goto PHP" (Google) when they're trying to
BdB>>find out if PHP has such a functionality. So, maybe it's better to
BdB>>just call it "goto".
For such people we might have a page in the manual sa
Zeev Suraski wrote:
> I'd like to raise a motion to 'Give the Language a Rest'.
+1
Brian Moon
dealnews.com
--
How to go broke saving money.
http://dealnews.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 9 Mar 2006 11:03:48 +0300
[EMAIL PROTECTED] ("Dmitry Stogov") wrote:
> Hi,
>
> The solution (2) - "goto only" is the winner.
> So in case of no serious objections, I'll commit the "goto.diff"
> patch in 24 hour.
>
> The last question:
> What do you thin about Andi's solution about using
On Thu, 9 Mar 2006, Bart de Boer wrote:
> Even though I like "jump", people will most likely be searching for "goto"
> (PHP manual) or "goto PHP" (Google) when they're trying to find out if PHP has
> such a functionality. So, maybe it's better to just call it "goto".
>
> PHP will give some kind o
On Thu, 9 Mar 2006 11:03:48 +0300
[EMAIL PROTECTED] ("Dmitry Stogov") wrote:
> Hi,
>
> The solution (2) - "goto only" is the winner.
> So in case of no serious objections, I'll commit the "goto.diff"
> patch in 24 hour.
>
> The last question:
> What do you thin about Andi's solution about using "j
Greg Beaver wrote:
Dmitry Stogov wrote:
Hi,
The solution (2) - "goto only" is the winner.
So in case of no serious objections, I'll commit the "goto.diff" patch in 24
hour.
The last question:
What do you thin about Andi's solution about using "jump" instead of "goto"?
It may make sense, beca
Windows binaries are available in a slightly different place:
http://downloads.php.net/edink/php-5.1.3RC1-Win32.zip
Edin
Ilia Alshanetsky wrote:
> Here goes the first RC of the 5.1.3 release, a whole slew of bugs fixes
> and a few minor feature enchantments. Please test this release as
> extens
Dmitry Stogov wrote:
> Hi,
>
> The solution (2) - "goto only" is the winner.
> So in case of no serious objections, I'll commit the "goto.diff" patch in 24
> hour.
>
> The last question:
> What do you thin about Andi's solution about using "jump" instead of "goto"?
>
> It may make sense, becaus
Here goes the first RC of the 5.1.3 release, a whole slew of bugs fixes
and a few minor feature enchantments. Please test this release as
extensively as possible and let us know via bug reports if you come
across any problems. The tarballs are available here:
http://downloads.php.net/ilia/php-
At 10:03 09/03/2006, Dmitry Stogov wrote:
>>The last question:
>>What do you thin about Andi's solution about using "jump" instead of
"goto"?
Great! Yet another keyword. PHP keeps surprising the world...
>>It may make sense, because it is not a full analog of C's goto
statement. It
>>is a lim
I might be missing something here, but I thought the people
discussing things on this list are members of the user base. Thus,
they likely propose syntax changes and improvements because they need
them.
I have to say that I don't really get that argument some people bring
forward over and
Good response, but it wasn't even 30 minutes :)
Zeev
At 13:07 09/03/2006, Sebastian Bergmann wrote:
Zeev Suraski schrieb:
> we're still heatedly debating on adding new syntactical, core level
> features.
Apart from namespaces, I can't think of any other "syntactical core
level feature" missi
Zeev Suraski schrieb:
> we're still heatedly debating on adding new syntactical, core level
> features.
Apart from namespaces, I can't think of any other "syntactical core
level feature" missing that could not be implemented as an extension.
Sara and Marcus have already shown (with the Operat
jump makes more sense than goto. We bounced it off in the Paris
meeting, IIRC it was fairly popular in case we go down the route of
this semantics.
Zeev
At 10:03 09/03/2006, Dmitry Stogov wrote:
Hi,
The solution (2) - "goto only" is the winner.
So in case of no serious objections, I'll comm
I'd like to raise a motion to 'Give the Language a Rest'.
Almost a decade since we started with the 2nd iteration on the syntax
(PHP 3), and 2 more major versions since then, and we're still
heatedly debating on adding new syntactical, core level features.
Is it really necessary? I'd say in
Jon Dowland wrote:
At 1141902889, Andrey Hristov wrote:
sorry for sending second email. Another choice could be `leave`, which
seems better than `escape` (clashes with escaping sequences).
I think `leave` has too many connotations with `break` and similar
commands, and could be misleading.
At 1141895342, Derick Rethans wrote:
> On Thu, 9 Mar 2006, Dmitry Stogov wrote:
> > The last question: What do you thin about Andi's solution about
> > using "jump" instead of "goto"?
>
> I don't really mind... but I wonder why you want to do this? Both work
> equally well and most people are fami
At 1141902889, Andrey Hristov wrote:
> sorry for sending second email. Another choice could be `leave`, which
> seems better than `escape` (clashes with escaping sequences).
I think `leave` has too many connotations with `break` and similar
commands, and could be misleading.
--
Jon Dowland
http:
Hi,
sorry for sending second email. Another choice could be `leave`,
which seems better than `escape` (clashes with escaping sequences).
Andrey
Andrey Hristov wrote:
Hi,
Dmitry Stogov wrote:
I am indifferent - "goto" or "jump", but may be others don't.
what about `escape`?
Thanks. Dmi
Hi,
Dmitry Stogov wrote:
I am indifferent - "goto" or "jump", but may be others don't.
what about `escape`?
Thanks. Dmitry.
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 09, 2006 11:09 AM
To: Dmitry Stogov
Cc: internals@lists.php.net
Su
I am indifferent - "goto" or "jump", but may be others don't.
Thanks. Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 09, 2006 11:09 AM
> To: Dmitry Stogov
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] GOTO and/or BREAK LABEL
On Thu, 9 Mar 2006, Dmitry Stogov wrote:
> Hi,
>
> The solution (2) - "goto only" is the winner.
> So in case of no serious objections, I'll commit the "goto.diff" patch in 24
> hour.
>
> The last question:
> What do you thin about Andi's solution about using "jump" instead of "goto"?
I don't
Hi,
The solution (2) - "goto only" is the winner.
So in case of no serious objections, I'll commit the "goto.diff" patch in 24
hour.
The last question:
What do you thin about Andi's solution about using "jump" instead of "goto"?
It may make sense, because it is not a full analog of C's goto sta
56 matches
Mail list logo
