from:"Johannes Schlüter"

Hi Derick,

On Mon, 2008-03-03 at 09:28 +0100, Derick Rethans wrote:
 On Sun, 2 Mar 2008, Marcus Boerger wrote:
 
  However, we had to drop multibyte support as well as the encoding 
  declare.
 
 Just wondering, why did you have to drop the declare(encoding=...) ? 
 It's just ignored in PHP 5.x - and it is useful to have for migrating 
 php 5.3 apps to 6. So can you atleast make the new parser just ignore 
 this statement?

It is not ignored in PHP 5 as Marcus and I found out while reading the
code :-)
If you compile with --enable-zend-multibyte you can change the encoding
using declare even multiple times per file using declare it seems.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer

Hi,

On Sun, 2008-03-02 at 14:47 -0800, Stanislav Malyshev wrote:
 Hi!
 
  be much easier, switching to re2c promises a much faster lexer. Actually,
  without any specific re2c optimizations we already get around a 20% scanner
 
 I think 20% faster is very cool.
 However, as I understand re2c is not a standard tool found everywhere. 
 So what happens if you wanted to use it on some exotic system where re2c 
 is not readily available as manintainer-supported software? Also, flex 
 is available on Windows for example as part of cygwin, while I don't see 
 re2c there.
 I understand this can be of low importance since we keep generated files 
 in our repositories, but I think we still have to keep it in mind.
 I understand also current patch requires non-release version of re2c - 
 maybe we should have some release version at least until we make PHP 
 depend on it?

We need a change there anyways, flex 2.5.4 is bundled with less systems,
even my Solaris 20 box has 2.5.33 instead of 2.5.4 by default. And I
think changing to something which is maintained by one of our main
contributors might be beneficial for us.

 Note - pecl/intl does nothing towards multibyte support etc., at least 
 for now. If there are voloteers to change that, it can be discussed, but 
 so far it is for doing entirely other things (locale-dependent 
 functionality mostly).
 So, I think before re2c parser can be merged the issue with multibyte 
 compatibility must be solved - otherwise it will make the users that 
 rely on it unable to use newer PHP. As cool as 20% faster is, I think we 
 can't drop support for such feature, especially not in 5.3.
 
  Commit to 5.3 between the 5th and the 15th of March. Synch to HEAD a couple
  of days later. Moving pecl/libintl to ext (depends on the 5.3 RMs decision).
  After that is done, decide about multibyte support. Along with the commit to
  the 5.3 branch there will be a new re2c version available.
 
 I think we first need to figure out what happens to multibyte support, 
 and not commit anything before we have it figured out. Multibyte support 
 is important piece of functionality for some PHP users, and it works 
 now. Breaking it without providing any alternative - especially that we 
 have now 5.3 mostly ready for the release cycle, and solving multibyte 
 problems with re2c may take undefined amount of time, as far as I 
 understand. I do not think it would be acceptable to release 5.3 without 
 multibyte support, so the option here either merge it now and have 5.3 
 waiting until MB is figured out, or try to figure it out before commit 
 and if we can't in a reasonable term, go forward with 5.3 and defer the 
 parser change for 5.4.

Since there's no documentation about zend-multibyte stuff I spent some
time searching for other resources about it, but except bug reports I
found nothing whee it was required. I'm sure there are some but comments
like TODO: support widechars in the code give me the impression that
it doesn't really work... and I guess many people just enable it sinceit
sounds important not due to the fact that hey really need it. Of course
I might be wrong so I'd be interested in use cases for
--enable-zend-multibyte stuff. Maybe we can fullfill the needs without
the switch.

If there are good use cases for that switch I won't like to replace some
small engine thingy with a huge external library like ICU.

And I doubt that more than just a few people know what it really does -
Marcus and I just found out while working on that stuff over the
weekend.

 Again, while I think the speedup is great and congratulate Marcus, Nuno 
 and Scott on great work, I think we should keep in mind we have working 
 parser right now and changing it in an incompatible way is very 
 high-risk and should not be taken hastily.

Right, it's great work they did there but a broken scanner would be one
of the worst things we might ship. So I'd invite everybody to checkout
that version from SVN (see Marcus's mail) and test it using the worst
stuff you can think off :-)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: PHP 5.3 Autoload+Namespaces+Functions incorret (atleast wierd) behaviour.

Hi Fredrik,

On Fri, 2008-02-29 at 16:02 +0100,
=?ISO-8859-1?Q?Fredrik_Holmstr=F6m?= wrote:
 Basicly, the call is this: Demo::Functions::test(); where both Demo
 and Functions are namespaces, and test() is a function inside the
 Demo::Functions namespace. If you have an autoload handler here and
 the file containing the Demo::Function::test()-decleration isn't
 loaded, autoload will be called.
 
 Now everything seems fine, but the problem is that when the autoload
 hooks have all fired php looks for the class Demo::Function, because
 autoload seems to be interpreting the Demo::Function::test(); call as:
 Namespace::Class::Function, when it should be
 Namespace::Namespace::Function, and since the Function class
 doesn't exist it will trigger a fatal error.

autoload was designed for loading classes not functions. Wen resolving
Demo::Function::test() and no function having that name is being found
it's assumed that Demo is the namespace, function a class name in there
and test a static method call. There's no way for the engine to see what
else might be meant. So the result is expected and changing it woud mean
to do major changes wich just creates new problems.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 5.3 Autoload+Namespaces+Functions incorret (atleast wierd) behaviour.

Hi Marcus,

On Mon, 2008-03-03 at 13:27 +0100, Marcus Boerger wrote:
 new namespace::class()
 new namaespace::namedspace::class()
 
 and so on, or:
 
 namespace::class::functoin()
 namespace::function()
 
 and so on. That is, when detecting braces after it and a new in front
 than it is a class. If there is no new in front it must be a function and
 autoload needs to be called for all but the last part. With new it needs
 to be called for all parts. Since the compiler already knows whether it
 generates a ctor call we must have an issue that should be fixable.

new in front is easy but take you're last example:

ns::func()

How can we detect, that we don't look for a class called ns with a
(static) method func but for a namespace ns with a regular function
called func? We do the lookup for ns::func in the function table,
then a class lookup for ns and then trigger autoload...

So the declaration for the thing called above could either look like

?php
namespace ns;
function func() {}
?

or like

?php
class ns {
static function func() {}
}
?

And since we do only autoloading of classes, not functions, the autoload
is only triggered looking for the second case.

Every approach which might be cleverer would, imo, need some list of
known namespaces which the current design doesn't have at all.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] 5.3 Release Planning

2008-03-06 Thread Johannes Schlüter

Hi all,

recently there were quite a few proposals about stuff for 5.3. If we implement 
them all we won't finish in a soonish time and we get new ideas postponing 
the 5.3  release therefore the following:

- Scanner based on re2c:
  Going to re2c promises to make maintenance simpler and increase the parsers 
  performance. Currently the prototype does not provide support for Zend 
  multibyte mode. This seems doable within April. Hence I ask for finishing
  by end of April the latest. Once that is done we will go over to a freeze and
  switch to bug fixing only mode. 
  If this is done sooner than we'll freeze sooner, too. If there are delays 
  we'll freeze anyways and use the scanner for a later release.

- bundling pecl/intl
  According to Stas it's ready for being bundled and was voted in. The only
  question I see there is the how to bundle it. There we should definitely
  find a better thing than symlinking around on the CVS server, an option
  might be to to switch to subversion and use svn:externals or keeping stuff
  in pecl and then having some scripts (maybe part of buildconf/the release 
  scripts) fetching them into a checkout. Just ideas ... For the moment 
  symlinking might be the best.

- bundling pecl/phar
  Lots of work has been done there, I'd like to have it in, general PECL
  discussion: See above.

- Large File Support
  That's a thing on the todo for ages. A patch was proposed by Wez once[1]. The
  patch should be, according to Wez, improved to use php_config.h for the
  defines instead of passing them using CFLAGS. Additionally one should mind
  Joe's comments[2] in that old thread. If somebody has time I'd welcome it, if
  not: It waited for so long already so it might wait a bit more. ;-)

  [1] http://www.mail-archive.com/internals@lists.php.net/msg31117
  [2] http://www.mail-archive.com/internals@lists.php.net/msg31124

- All the other stuff
  Extension maintainers always like improving their extensions, There will be 
  improvements to GD I think and other stuff, I don't list that all - the
  timeline is mentioned above.

- FixesTesting
  Test snaps, report bugs, fix bugs, ... That's the most important thing. That's
  where really everybody reading this can contribute and do important things. 
:-)


You might miss some stuff in the list above, at first one might think about
these:

- Traits: Interesting concept, basically most of us want it, some decision
  about some details needed, then some implementation, i had a short discussion
  with Stefan and we agreed that we don't call it release critical for 5.3 and
  plan 5.3 without traits.

- Closures/Anonymous functions: Basically the same as with traits, some detail
  discussions left, then a bit time for updating the patches, not planned for 
5.3.

Surrounding all this stuff we'd also have another topic we should start
working on:

Updating guide, something like README.UPDATE_5_2. I think our new wiki
might be a good place to create such a list. I'll find some place there
and come than back to the list, but you might already start thinking
about stuff you know that should be mentioned there. That's again a
thing everybody can contribute.

That's enough for the moment,
johannes
PHP 5.3 RM


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: 5.3 Release Planning

2008-03-07 Thread Johannes Schlüter

Hi,

On Thu, 2008-03-06 at 20:43 -0600, Gregory Beaver wrote:
 Just a quick note: I'd like to consider another possible approach,
 having pecl/phar synced from stable pecl release.

Yes, that's what I'd like, too. Te problem there is that developers
using CVS checkouts should get a CVS checkout f it, too so it's being
tested and can be fixed if needed. And if you read my mail you see that
I mentioned doing it during buildconf, which is better than configure, I
think ;-)

 I am also fine with symlinking until this can be perfected, as it is
 just an idea to be implemented right now.

right. /me has no powers for actually doing that.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Loading PHP Files from a PHP Extension

2008-03-08 Thread Johannes Schlüter

Hi Jacob,

On Sat, 2008-03-08 at 01:50 -0600, Jacob Santos wrote:
 Anyway, I remember once upon a time a PHP extension which loaded PHP files 
 within the PHP extension MINIT or RINIT function. I had thought it was SPL 
 which 
 did this, but I appear to be wrong. Searching for material on the subject 
 only 
 brings up generic PHP Extension writing.

It's SDO in pecl, I think. But I don't think it's a good idea to execute
a script while still being in the startup. So you should do that
carefully.

 I thought that php_execute_script() might work, but from the Extending and 
 Embedding PHP book, it is used within the context of Embedding and not 
 Extending 
 PHP.

Embedding means calling PHP code from some C app, in your case the C app
is an extension, but still, that doesn't matter.

You could use php_execute_script, the problem there might be that it
also executes auto_[pre|ap]pend files not only your script so it might
be better to use zend_execute_scripts.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Namespace syntax decision

2008-03-22 Thread Johannes Schlüter

Hi,

On Fri, 2008-03-21 at 22:36 +0100, Marcus Boerger wrote:
 PHP is very close to Java and C++ in terms of Syntax. And many of our users
 are familiar with one or even both of them. Also we have a tendency to
 especially take syntax from those two or be in line with those two
 languages. That said I see two ways:
 
 1) namespace foo { }
 
 2) package foo;
 
 I favor 1) if we allow namespace nesting and 2) if not. The current way of
 nesting is very confusing:
 namespace foo; namespace bar;

I said in some previous post I won't like multiple namespaces per file
using the 2nd syntax. So imo: either on ns per file and the 2nd syntax
or allow multiple and use brackets. And then I prefer the latter.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

2008-03-22 Thread Johannes Schlüter

Hi,

On Fri, 2008-03-21 at 21:13 +0100, Marcus Boerger wrote:
Hello Stanislav,

Friday, March 21, 2008, 9:08:02 PM, you wrote:

However the '?echo' I mentioned would work. We could also go for something
like '?phpecho'. I for one would really appreciate it. And I would not

?phpecho is too long. Really, saving one space here isn't worth a
trouble. If we had something short and nice like ?= that'd be good and
would make PHP templates look clean, but doing ?phpecho instead of
?php echo - how does it make any real difference?

The thing is that ?php echo would require a ; while ?phpecho wouldn't.
And if you ronly argument is saving a few keystrokes then we should really
get rid of short open tags completely. And definitively not making their
use easier.

You don't need a ; in front of the ? therefore ?php echo $foo ?
works, so the only thing ?phpecho saves in fact is one character.

The point about ?= is that it is _very_ short. ?=$foo? can work quite
nice in simple templating stuff (PHP is a templating language)

I also think that there aren't many people who preprocess PHP Hypertext
preprocessor files with XML-Tools, and if they do they won't use ?.
The XML issue I see there is the conflict with XML-PIs like ?xml which
starts PHP's processing. See [1] as a starting point for that. Already
the second result there [2] shows a real life example where the patch
Stas committed might be useful. In a file called header.php - which
certainly isn't the main script - the developer made sure that his
script works with both settings, so on the one hand he has to print the
?xml PI using PHP, so there's no problem with short open tags, but
for outputting variables on the other hand he uses the long tags since
one can't rely on the fact that short tags are working. Using the patch
Stas proposed (and committed) this might be made nicer. I could look for
my own code where I had the same problem inside complexer stuff, but I
guess that random example, which took me 5 minutes to find shows the
possible benefit.

So as long as we have open tags I'd like Stas' patch. The only downside
I see are confused users (Why doesn't that work for the script I have
that in) but well, we have such users for all stuff we do ;-)

Now we have the big issue: Do we want to have short open tags forever?
Well, without tooo much thinking my idea would be to drop ? but keep
?=, ?= shouldn't conflict with ?xml tags in the same file, but
make it simple to do templating using PHP, on the other hand when not
echo'ing stuff you already have to write more soo the four additional
characters (php ) don't matter that much - especially every decent
editor/ide should be able to give you a completion on that, if you want.
But such a change in the language should go with other breaks to 6.0 or
so.

johannes

[1] http://google.com/codesearch?hl=enlr=q=lang%3Aphp+%3C%5C%3Fphp
+echo+%5B%22%27%5D%3C%5C%3FxmlbtnG=Search
[2] http://google.com/codesearch?hl=enq=+lang:php+%3C%5C%3Fphp+echo+%
5B%22%27%5D%3C%5C%3Fxml%22
+show:r_a97k72yKQ:0ofXUwlCDds:HkOUVl3hPgMsa=Ncd=2ct=rccs_p=http://managedtasks.com/wpthemes/gespaa_v2.zipcs_f=gespaa_v2/header.php#first

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing

2008-03-23 Thread Johannes Schlüter

Hi,

On Sun, 2008-03-23 at 13:01 +0100, Hannes Magnusson wrote:
 On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote:
   does anyone have any objection to the proposal at
   http://wiki.php.net/rfc/peclversioning?
 
 The first step in fixing the core-pecl relationship? \o/
 
 Looks good.
 But what about extensions that are symlinked to core? Will they need
 to update their version info during core release cycles?
 It obviously shouldn't have a -dev version when distributed with PHP..
 Is it up to the RM to hunt those extensions down and make sure the
 version info is accurate?

Just removing the -dev in the version number would be wrong (as is
symlinking), a Stable PHP release should include stable extensions.
Not dev versions of the extension. So one of the ideas is to fetch the
last stable extension release for a PHP release, but well, then there's
the problem that everybody (people using snaps, people using CVS, ...)
end up with different versions which makes QA hard. (not to mention bug
hunting trouble with people using the latest release but updated a
single extension, )

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP's Zend multibyte support

2008-03-23 Thread Johannes Schlüter

Hi,

On Sun, 2008-03-23 at 15:26 +0100, Hannes Magnusson wrote:

   You can provide a --SKIPIF-- section to detect MB support 
  (http://qa.php.net/write-test.php ).
   --SKIPIF--
   ?php
   if (!in_array(detect_unicode, array_keys(ini_get_all( {
die skip Requires --enable-zend-multibyte option;
 
 WTF? Where did that INI entry come from? :)
 
 It isn't in php.ini-dist and the only docs I can find is
 (http://no.php.net/manual/en/ini.php):
 detect_unicode1 PHP_INI_ALL Available since PHP 5.1.0.
 Removed in PHP 6.0.0.

According to my research when the MB issues popped up that setting was
added as a hack to help the scanner to have less confusion with it's
encoding detection when using __HALT_COMPILER(); There's an internals
discussion, but i don't have it at hand right now.

 Is it really PHP_INI_ALL? That doesn't make much sense to me. I
 thought the multibyte scanning was compile time?
 (Or is it like the current short_tags proposal;
 ini_set(detect_unicode); include ...; ?)

Yes, it's for the latter, I guess.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?

Hi,

On Wed, 2008-03-26 at 16:07 -0400, George Wang wrote:
 OK, let's back to the topic, is there any conclusion on this topic yet?
 I certainly would like not to miss the release of 5.3 and ready to help 
 with any issue.

I think it makes sense, you, as the server's vendor, supports it and
whatever the exact usage number are there seem to be users who certainly
benefit from it.

  As to user request, here is one :-)
 
  http://bugs.php.net/bug.php?id=42987
 According to this ticket, this has been assigned to johannes, should I 
 follow up with this ticket to get it going?
 His last update to the ticket is
 
 I saw that some files use another license than PHP License and other refer
 
 to an outdated version. when bundling they should be licensed under the
 current PHP License 3.01.
 
 
 Our LSAPI library code has been license under BSD license, and there are 
 other BSD licensed code get into PHP core, like PCRE, GD, etc. Is that 
 really a concern? Do I have to change it to PHP license?

Well, the idea is that all PHP-specific code is licensed under the same
license terms. PCRE and GD are external libraries which live outside
PHP's context and which are simply bundled. That's why the clear
preference there is PHP License.

Additionally it would nice to follow the PHP coding standards. Like
always having  { } after an if statement. This helps PHP developers who
might (possibly) help fixing reported (simple) bugs or apply API
changes.

Other than that we, again, have our problem about what's the best way to
bundle something from pecl. I guess the symlink on the CVS server is
the best option we currently have...

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Backporting to 5_3


On Wed, 2008-03-26 at 10:04 -0300, Felipe Pena wrote:
 Hello,
 
 I would like know which itens below needs be backported to 5_3:
 
 - Added runtime JIT auto-globals fetching and caching. (Dmitry, Sara)

Not sure if this has benefits without the encoding stuff which is
planned for PHP 6.

 - Added jump label operator (limited goto). (Dmitry, Sara)

No objection, while it adds yet another keyword.

 - Removed support for continue and break operators with non-constant
   operands. (Dmitry)

-1, also just two use cases were found I don't like to break that with
5.3.

 - Removed undocumented and incomplete support for strings in list()
 operator. (Dmitry)

What exactly does that change?

 - Changed instanceof and catch operators, is_a() and
 is_subclass_of() functions to not call __autoload(). (Dmitry)

+1, makes sense.


 Let me know, and then i could post the patch for aprovation.

Please do that.

Thanks,
johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Namespace syntax decision


On Tue, 2008-03-25 at 23:35 -0700, Paul Chandler wrote:
 Can't both (brackets and non) be supported? 

NO! This just creates confusion.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Namespace syntax decision

Hi,

On Fri, 2008-03-21 at 22:36 +0100, Marcus Boerger wrote:
   we all were asked to stop discussing syntax of namespaces as we were told
 that we would decide after the namespace functionality was fully implemented.
 Now I think that the functionallity is pretty much settled we should
 revisit the syntax. We all have been very patient so far. Anyway here goes
 my take on it:

Allowing multiple namespaces per file using the namespace foo; syntax
feels really bad for me. Therefore I basically agree with Marcus on the
two options.

 1) namespace foo { }
 
 2) package foo;
 
 I favor 1) if we allow namespace nesting and 2) if not. The current
 way of
 nesting is very confusing:
 namespace foo; namespace bar;

About the options I don't have strong opinions but I see that people
want multiple namespaces per file. We aren't like other languages which
enforce one class per file and I don't think we should enforce one
namespace per file. Therefore I prefer 1).

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Backporting to 5_3


On Thu, 2008-03-27 at 00:48 +0100, Pierre Joye wrote:
 On Thu, Mar 27, 2008 at 12:34 AM, Johannes Schlüter [EMAIL PROTECTED] wrote:
 
   On Wed, 2008-03-26 at 10:04 -0300, Felipe Pena wrote:
 
   Hello,
   
I would like know which itens below needs be backported to 5_3:
   
- Added runtime JIT auto-globals fetching and caching. (Dmitry, Sara)
 
   Not sure if this has benefits without the encoding stuff which is
   planned for PHP 6.
 
 If the JIT is actually enabled by default (as far as I remember it is
 not), it can be useful as a request will simply not process any JIT
 data if it is not actually used. The current behavior now is to do a
 compile time JIT (detection of possible GPCES usage). The encoding is
 useless in 5.3 without unicode support, it is binary as we know it ;)

And compile time JIT is fine as long as we don't have to care for
encoding, right? So this change won't be needed in 5.3.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Backporting to 5_3


On Thu, 2008-03-27 at 01:01 +0100, Pierre Joye wrote:
 On Thu, Mar 27, 2008 at 12:54 AM, Johannes Schlüter [EMAIL PROTECTED] wrote:
 
 
   And compile time JIT is fine as long as we don't have to care for
   encoding, right? So this change won't be needed in 5.3.
 
 Except when one sends a xxMB post that you are not expecting and will
 not use. But that has been so for years, too bad though, 5.3 is the
 perfect time for such thing.

which is handled by post_max_filesize and as long as we don't add error
handling it doesn't make a difference if that happens at compile- or
runtime.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-QA] BC break with php 5.2.6

2008-03-31 Thread Johannes Schlüter

Marcus,

On Mon, 2008-03-31 at 17:14 +0200, Marcus Boerger wrote:
 Hello Derick,
 
   it is a BUG FIX. Not fixing it means more people will turn it into a
 feature and we will never be able to remove it. Becuase next time you
 will say we cannot remove it in a minor version as by then you accidentally
 rely on it yourself.
 
 We made a mistake! Lets stand up and admit we did. Probably I was involved
 in making that mistake, so sorry. Done.

I have to agree with Derick here we shouldn't add a fatal error within a
bug fix release at such a place. People (hosters...) tend to update
versions without checking all incompatibilities - since you don't expect
them and they want to get security issues fixed.

Yes, the previous behavior was wrong! Yes we shouldn't encourage people
do do that.

I'd propose making it an Warning or something in 5.2 and fixing it in
5.3.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Is it possible to add support for multiple extensions directory ?

2008-03-31 Thread Johannes Schlüter

Hi Sririam,

On Mon, 2008-03-31 at 13:56 -0700, Sriram Natarajan wrote:
   In this regard to fit more with Solaris file layout traditions, we 
 would like to keep the core PHP modules under /usr/php5/modules and the 
 user specific downloaded PECL/PEAR modules under /var/php5/modules.  
 However, if I am not mistaken,  PHP core doesn't support loading PHP 
 modules from more than one location.  So, I was wondering if  this 
 feature can be considered within PHP core ?
 
 For example, within PHP.ini , a user can more provide more than 1 
 location to look for PHP extensions
 extension_dir=/usr/php5/modules;/var/php5/modules

As of PHP 5.3 you can use the full path with the extension= directive in
php.ini. Additionally you can use identifiers as variables therefore the
following would be possible:

extension_dir = /var/php5/modules
solaris_extension_dir = /usr/php5/modules

extension=${solaris_extension_dir}/foo.so
extension=bar.so

Would that be enough for you? :-)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: destroy the current object (PDO)

2008-04-10 Thread Johannes Schlüter


On Wed, 2008-04-09 at 10:14 +0200, Olivier Bonvalet wrote:
 public function __construct( $dsn, $user, $password )
 {
 try {
 parent::__construct( $dsn, $user, $password );
 } catch( PDOException $e ) {
 echo 'there is an error... but continue the script', PHP_EOL;
 }
 }

The correct thing is to either re-throw the PDOException or use your own
exception and throw that.

   } catch( PDOException $e ) {
   echo 'there is an error... but continue the script', PHP_EOL;
   throw $e;
   }

Everything else is broken on oyur side, no internals@ issue.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3 == PHP 6?

2008-04-11 Thread Johannes Schlüter

Hi,

On Fri, 2008-04-11 at 16:07 -0400, (Wietse Venema) wrote:
 According statistics at nexen.net, PHP4 is now 68% of the installed
 base (8 years of deployment) and PHP5 is 32% (almost 4 years). The
 lesson I draw from this is that a major release every couple years
 would heavily fragment the installed base, and complicate support.

The problem with these stats is that they count the public available
installation base into account. There are many systems which simply run
without any change to anything you will find lots of outdated software
there. I have other stats about systems used when installing some piece
of software and there PHP 5 is  60% which is a completely different
picture. So in summary: Statistics are nice, but not everything.

For fans of random statistics:
http://phpmyfaq.de/stats/svg/php_versions_minor_20080409230429.svg is
the chart for installations of the phpMyFAQ package since 2008/01/01.
(Counting only users who accepted sending their system information)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Welcome GSoC students!

2008-04-21 Thread Johannes Schlüter

Hi,

Google just announced the final assignments for their Summer of Code
program for this year.
On behalf of the PHP project I'd like to welcome our students and give
you some general information about the project.

The following projects have been accepted for the PHP project:

  Zend LLVM Extension  
by Joonas Govenius, mentored by Nuno Lopes 
  PHP Optimizer  
by Samuel Graham Kelly IV, mentored by Derick Rethans 
  PhD Improvements and Updates  
by Nicholas Sloan, mentored by Hannes Magnusson 
  Replace auto* with CMake  
by Alejandro Leiva Rojas, mentored by Pierre A. Joye 
  gsoc:2008 - XDebug  
by Chung-Yang Lee, mentored by David Coallier 
  Rewrite the run-tests.php script  
by Cesar Montedonico, mentored by Travis Swicegood 
  PHP Bindings for Cairo  
by Akshat Gupta, mentored by Anant Narayanan 
  Algorithm Optimizations  
by Michal Dziemianko, mentored by Scott MacVicar 
  PECL, Website Improvements  
by Barry Carlyon, mentored by Helgi Þormar Þorbjörnsson 
  Implement Unicode into PHP 6  
by Henrique do Nascimento Angelo, mentored by Scott MacVicar

See http://code.google.com/soc/2008/php/about.html for details about
these projects.

Important Mailing lists:
   php.net mailing lists are open discussion lists which can be
   subscribed by anyone and collected in public archives. Main language
   is English, as most people on these lists aren't native speakers
   don't be ashamed of writing bad English - I guess there are
   mistakes in this mail, too. 
   For subscribing send an empty mail to the mentioned address and
   follow the instructions given in an automatic response.
   The complete rules can be found on 

   internals   This list is For everybody working on the PHP core or
   it's  run-time, all decisions about PHP's core should be
   made there  the list is also open for questions about PHP
   internals. Please mind that this list is, most likely,
   the most read one of these I mention here so please think
   before spaming it ;-)
   address: internals@lists.php.net
   subscription: [EMAIL PROTECTED]
   pecl-devThis list is for discussions about extensions for PHP or
   the PECL website.
   address: [EMAIL PROTECTED]
   subscription: [EMAIL PROTECTED]
   doc Everything related to documentation, talking about the
   documentation build system (PhD) and documenting new
   features.
   address: [EMAIL PROTECTED]
   subscription: [EMAIL PROTECTED]

   Depending on your project there might be other lists, please talk to
   your mentor for getting details.

General rules on mailing lists:
   When writing to a mailing list please mind that you're writing to a
   whole bunch of people from different cultures with different
   background so try to be polite and clear about what you are saying -
   and don't feel insulted if you get impolite answers - we're all
   humans and make mistakes! When answering to mails please avoid top
   posting but cite the parts you're responding to and answer below
   them. See http://www.netmeister.org/news/learn2quote.html
   When starting a new thread please don't response to another mail but
   start a new mail, else it will be sorted to the wrong place with mail
   clients. Please write plain text mails, not HTML mails.
   The php.net mailing lists don't set the Reply-To Header (on
   purpose) please remember to use your mail client's Reply to All
   button when answering to the list, use Reply for sending a private
   reply.

Chats:
   Chats are an important way for communication, it's a place to get
   questions answered fast, at least sometimes. As most PHP developers
   are either from Europe or the states the most traffic in general is
   there from European noon till late evening or during American
   daytime. There are no official channels but #php.pecl on EFNet is a
   place with many developers hanging out.  Please mind that IRC is no
   place for decisions. Decisions should, in general, be made on the
   list else you only get responses from people who are randomly around.
   An introduction about IRC can be found on
   http://www.irchelp.org/irchelp/irctutorial.html Please ask your
   mentor for further advice for your specific project.

Code management:
   The PHP project uses CVS for tracking it's code. For using php.net's
   CVS server please check http://php.net/anoncvs.php For getting write
   access on a repository you can request an account on
   http://php.net/cvs-php.php - before doing that please check with your
   mentor to define what kind of access you need for your specific
   project.

Coding styles:
For code written in the C programming language please mind our
general standards: http://php.net/reST/php-src/CODING_STANDARDS
Projects written in PHP should follow the PEAR Coding Standards:

Re: [PHP-DEV] Re: Building PHP. Clean builds. Noisy redefines.

2008-04-22 Thread Johannes Schlüter


On Tue, 2008-04-22 at 13:57 +0200, Hannes Magnusson wrote:
 On Tue, Apr 22, 2008 at 1:53 PM, Elizabeth M Smith
 [EMAIL PROTECTED] wrote:
   Hmmm - I don't get the first set of long to short warnings - what
   compiler/sdk are you using?  Second set of (highly annoying) warnings is
   due to a file in TSRM - in readdir.h - and I'd love to have fixed but
   there is a very small set of people with karma there and even fewer who
   care about windows compiler warnings.
 
 ...but many read patches sent to internals@ (especially people with
 karma) and could commit them after reviewing :)

And a few might even grant karma after they saw a few good patches for
that area...

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Welcome GSoC students!

2008-04-22 Thread Johannes Schlüter


On Tue, 2008-04-22 at 14:23 -0400, Daniel Brown wrote:
 Of interesting note: the list rejected my earlier (second) reply
 to your message, Johannes.  It claimed the Google BlogSpot URL was a
 SPAMMY URL.
 

looks like the same happened to my mail - while I didn't get any
response :-)

For all: 

We published around 16 ideas on the wiki (didn't count them) but we were
open for other ideas, too. We got quite a few proposals with some
favorite ideas, I'm not sure what Google thinks about publishing
detailed numbers and stuff - some overall statistics can be found in
Google's OpenSource blog: google-opensource dot blogspot dot com

Maybe it works now :-) (and didn't I always say that Google was evil?)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?

2008-04-22 Thread Johannes Schlüter

Hi George,

On Tue, 2008-04-08 at 10:12 -0400, George Wang wrote:
 Either a symlink or moving the directory physically to where other SAPI 
 code are should work. I can check in the code to a different location if 
 need.
 
 Please let me know if anything I can help. :-)

Derick just copied it on the CVS server to php-src/sapi/litespeed and
gave you karma, please make a checkout of the PHP tree and test if all
works, then do a cvs rm on the old files in PECL so that's cleaned.

Thanks,
johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Unresolved external symbol __mysqlnd_debug

2008-04-23 Thread Johannes Schlüter

Hi,

On Tue, 2008-04-22 at 22:56 -0400, Edward Z. Yang wrote:
 I'm getting this fatal error compiling mysqli under Windows:
 
 Creating library Release\php_mysqli.lib and object Release\php_mysqli.exp
 mysqli_api.obj : error LNK2019: unresolved external symbol
 __mysqlnd_debug referenced in function _zif_mysqli_debug
 Release\php_mysqli.dll : fatal error LNK1120: 1 unresolved externals
 
 A similar error is occuring in the snapshot builds at snaps.php.net.
 
 Where can I get a more recent version of the library files? (if that is
 the problem?)

mysqlnd is part of PHP so it had to be fixed in PHP, I've just committed
a fix and my windows build seemed to work.

Please do a cvs up and try again, thanks,
johannes
-- 
Johannes Schlüter, Software Engineer
MySQL GmbH, Dachauer Str.37, D- 80335 München, www.mysql.com
Geschäftsführer: Kaj Arnö - HRB München 162140


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Calling a class constructor

2008-05-02 Thread Johannes Schlüter


On Fri, 2008-05-02 at 12:03 +0200, Marcus Boerger wrote:
 Hello Antony, Johannes,
 
 seeing this thread I agree. So that makes the list: PCRE, Reflection, SPL.
 Johannes?

I was under the impression that was already the case for Reflection, so
I don't mind.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [HEADS UP] pecl/phar is now ext/phar

2008-05-13 Thread Johannes Schlüter

Hi,

On Mon, 2008-05-12 at 16:45 -0500, Gregory Beaver wrote:
 It's time for helly's birthday present from me (and indirectly, Derick,
 who did the cp -r) :).
 
 As Johannes requested, pecl/phar has been copied to php-src/ext/phar,

Great work! :-)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar

2008-05-13 Thread Johannes Schlüter


On Tue, 2008-05-13 at 14:41 +0100, Steph Fox wrote:
  Sorry Hannes, should've kept it on-list. The clue was in Tony's mail, I'm 
  just testing a fix now.
 
 Access denied, insufficient karma.
 
 Fix is in PECL CVS, what do I do now? Mail in a patch against 5_3?

You should try again, karma should be there, now.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: unicode.semantics ad infinitum

2008-05-14 Thread Johannes Schlüter

Steph,

On Wed, 2008-05-14 at 13:59 +0100, Steph Fox wrote:
 I wrote a macro to allow us to use the same code for the extension in both 
 branches, but it occurs to me that the zstr union definition might change or 
 even disappear when PHP 6 becomes Unicode-only. Is that likely? I don't 
 know. So keeping it all together is total guesswork at present.

In general: No. We still need both string types at most places, the
effect of the u.s setting is the default type for strings in the engine.
Most other functions still need to work with both kinds of string as
parameter and such. (strlen(bäöü) vs. atrlen(uäöü))

johannes




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Proposal for a PHP-BASED Make facility

2008-05-15 Thread Johannes Schlüter

Hi,

On Thu, 2008-05-15 at 00:49 -0400, Hector Santos wrote:
- All that is needed with a source distribution or as a
  separate distribution, is a PHPMAKE package that
  might include a root folder:
 
  phpmake/bin minimum php binaries for the platform
  i.e, php.exe, php5ts.dll for windows

That's a hen and egg problem then - one would need PHP to build PHP and
we don't have the infrastructure to provide binaries for all the
platforms we support (there's more than Linux and Windows)

And then you have to do quite some work others already did for finding
system difference - and keep the systems database and/or checks up to
date - that's far from our scope.

Please read about what the autotools, cmake and others are doing.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Proposal for a PHP-BASED Make facility

2008-05-15 Thread Johannes Schlüter

Hi,

On Thu, 2008-05-15 at 04:21 -0400, Hector Santos wrote:
  On Thu, 2008-05-15 at 00:49 -0400, Hector Santos wrote:
 - All that is needed with a source distribution or as a
   separate distribution, is a PHPMAKE package that
   might include a root folder:
 
   phpmake/bin minimum php binaries for the platform
   i.e, php.exe, php5ts.dll for windows
  
  That's a hen and egg problem then - one would need PHP to build PHP and
  we don't have the infrastructure to provide binaries for all the
  platforms we support (there's more than Linux and Windows)
 
 That's what I thought too, but you still still have the same 
 (chicken/egg) issues of PHP being dependent on what OS the 
 AutoTools/CMake facility works on.
 
 The basic requirement of being able to port the minimal set of PHP files 
   for an OS would still need to required in either case.
 
 If the porting is simpler for autotools/cmake than raw PHP, then I can 
 see that as a plus.

Well the difference ist: For an own build system _we_ do to have it our
own and verify it on each platform, autotools/cmake are used by lots of
other projects with many many more contributors which keeps the things
running. Additional most OS packagers add these tool to their packages
themselves as they are essentially for compiling basically anything. 

Without autotools you can't compile many stuff PHP depends on on the
platform so the autotools have to be ported anyways before PHP can be
build there

 Personally, as a side note, I think PHP makes should be separated (each 
 using a common/structure methodology for PHP).  I'm still catching up, 
 but there seems to to be a tremendous amount of complexity when trying 
 to auto configure and build it all as one big make. For example, it 
 would be ideal, IMO, if I can do:
 
 domake MYEXTENSION
 domake PDO
 domake MYSQL
 domake PHP5TS_DLL
 domake OFFICIAL_RELEASE_MODULES_ONLY
 domake ALL

build extensions shared (--with-foo=shared) then you can do make
$target where target might be modules/$extension.so so it's all there
and works in a way everybody used to the autotools way of doing things
can understand witrhout reading any documentation. An own system would
need lot's of documentation so Joe Admin can compile it the way he wants
it.

 and not worry about all the erroneous errors and warnings you might get 
 with its attempt to build other parts that you don't need to rebuild.

make only compiles the things it has to compile for building the
specified target, if your target is all (which is the default) it
compiles the php executables and all modules requested (if sources have
changed after the last build).

In the end: our build system works (mostly) and I doubt a PHP based
system can fix the remaining issues in a sane way, especially not
without making it more complex. Every *nix admin knows how to use
autotools, no admin knows about PHP and a PHP-specific build system and
that's the main target group for a build system.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Short syntax for array literals [...]

2008-05-22 Thread Johannes Schlüter

Hi,

On Thu, 2008-05-22 at 12:33 +0200, Pierre Joye wrote:
 Agreed, we should simply go through a vote and be done with that.

Vote until all are annoyed and don't vote against it anymore just to
stop voting? (it's less annoying to have it than vote about it every
two months) There was some voting about this feature quite recently,
don't have the archive link at hand.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]

2008-05-24 Thread Johannes Schlüter

Hi,

On Sat, 2008-05-24 at 13:55 +0100, Steph Fox wrote:
 Warning: crc32() expects parameter 1 to be strictly a binary string, Unicode 
 string given in ...
 
 Surely if a function's *expecting* a binary string it should do a silent 
 conversion, and only throw a warning if the conversion fails? I don't see 
 why the onus should always be on the user to adapt to this.

For some functions taking binary strings is critical for working nicely
with an automatic conversion in this case 
   crc32(uäöü)
and
   crc32(bäöü)
would give completely different results depending on the runtime
encoding, relying on a implicit conversion there is most likely a bug
(at least for apps written with PHP 6 in mind).

Oh and I might probably also argue that
   crc32(uäöü)
should give the crc32 of the internal representation (utf-16...) of the
string, which is a total wtf for the user then.

The correct solution is to make safe use of the S modifier and not
using it too much.

As binary casts are allowed in modern PHP versions I don't see this as
an issue, while such a cast isn't absolutely the best thing to do: I'd
go with unicode_encode() to be sure about the encoding being used,
everything else is prone to fail some time (some code changing
unicode.runtime_encoding for some random reason...)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unicode progress [Was: unicode.semantics adinfinitum]

2008-05-24 Thread Johannes Schlüter

Steph,

On Sat, 2008-05-24 at 20:37 +0100, Steph Fox wrote:
 Heya Johannes,
 
  For some functions taking binary strings is critical for working nicely
  with an automatic conversion in this case
crc32(uäöü)
  and
crc32(bäöü)
  would give completely different results depending on the runtime
  encoding,
 
 Yes - but why should the user have to do the casting? Why can't the function 
 itself cast to binary when it has an 'S' modifier? Like, during 
 zend_parse_parameters() for example? Whatever happened to keeping PHP 
 simple?

Since only the users knows the correct encoding. The function might
fallback to unicode.runtime_encoding which can be wrong. And it's hard
to track the reason.

  relying on a implicit conversion there is most likely a bug
  (at least for apps written with PHP 6 in mind).
 
  Oh and I might probably also argue that
crc32(uäöü)
  should give the crc32 of the internal representation (utf-16...) of the
  string, which is a total wtf for the user then.
 
 Nobody's asking to be able to cast it to unicode. I'm asking whether it's 
 entirely necessary to force users to cast to binary all over the place, and 
 a strict binary parameter spec looks like being one place where the cast 
 could be done internally.

In this case there's no cast but the most simple implementation of
crc32() on a unicode string.

  The correct solution is to make safe use of the S modifier and not
  using it too much.
 
  As binary casts are allowed in modern PHP versions I don't see this as
  an issue, while such a cast isn't absolutely the best thing to do: I'd
  go with unicode_encode() to be sure about the encoding being used,
  everything else is prone to fail some time (some code changing
  unicode.runtime_encoding for some random reason...)
 
 You're telling me an explicit cast to binary could fail internally but not 
 externally? That doesn't make a lot of sense somehow.

Externally the user is responsible to select the proper encoding
internally PHP has to guess.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Short syntax for array literals [...]

2008-05-29 Thread Johannes Schlüter


On Wed, 2008-05-28 at 09:19 +0200, Derick Rethans wrote:
 Right, and I will add immediately to my coding standard that this is 
 forbidden to use.

... which doesn't help people having to read code without being able to
influence the coding style...

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Algorithm Optimizations - string search

2008-06-11 Thread Johannes Schlüter

Hi,

On Wed, 2008-06-11 at 01:01 -0700, Texin, Tex wrote:
 When I looked at the code, I assumed that it wasn't intended for 
 international use
 I'll have to go back and look to give you details, but it doesn't work for 
 international use or unicode.
 It would be ok for 8859-1. 

That's the default case in PHP  6, in current PHP versions all string
operations use on binary strings, so all references to offset work on
byte not character base. That's one of the main reasons for PHP 6.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Fw: [PHP-DEV] Dummy calls for 5.3.0 up? [Was: HEAD tests broken under Windows]

2008-06-12 Thread Johannes Schlüter

Hi,

On Thu, 2008-06-12 at 10:53 +0100, Steph Fox wrote:
 There is far too much of this kind of thing. Can we please consider adding 
 dummies into at least 5.3.0 and possibly even the 5_2 branch for:
 
 is_binary()
 is_unicode()

These can be easily emulated using PHP like
  if (!function_exists(is_binary)) {
function is_binary($s) { return is_string($s); }
  }

 file_put_contents(FILE_BINARY)

Would a const FILE_BINARY = 0; be enough or would that break the
function in some way (didn't check it)

 and any other major 'gotchas' that people can think of that will make it 
 impossible to write future-compatible PHP 5 code?

as long as such an emulation is possible I'd prefer putting them in a
compatibility layer (like PEAR PHP_Compat) using PHP instead of putting
useless (mind the quotes ...) functions into PHP.

Stuff like the b prefix or (binary) casts are different as they can't be
emulated using userland stuff.

johannes

 Thanks,
 
 - Steph
 
 
 - Original Message - 
 From: Steph Fox [EMAIL PROTECTED]
 To: internals internals@lists.php.net
 Sent: Thursday, June 12, 2008 3:32 AM
 Subject: [PHP-DEV] HEAD tests broken under Windows
 
 
 
 
  Hi all,
 
  I'm hopeful that run-tests.php will now work as advertised under CVS HEAD 
  in most places. However it's still not right under Windows, and I finally 
  tracked that down to the fact that file_put_contents() in PHP 6 will 
  insist on creating a file with DOS line endings. The test files are 
  created from .phpt --FILE-- sections using file_put_contents(), so there 
  are a vast number of fails under doze due to an extra character in output 
  strings there.
 
  There's a *closed* PHP bug on this which was raised by Zoe over a year 
  ago, see http://bugs.php.net/bug.php?id=41609. For some obscure reason it 
  was seen as a documentation problem at the time. This is an extreme change 
  in behaviour, not a documentation problem, and needs proper analysis.
 
  Could someone please look into it?
 
  Thanks,
 
  - Steph
 
  -- 
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
  
 
 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] extensions status, to move to pecl or to drop

2008-06-12 Thread Johannes Schlüter

Hi,

On Thu, 2008-06-12 at 16:31 +0200, Pierre Joye wrote:
 * Extension being deleted (not removed, a cvs rm will be done)
 
mhash, no impact as we provide a compatibility layer via ext/hash
 (Thanks to Scott)

We should keep this somewhere in Siberia like we did with other
extensions we removed. (PHP 4 XML stuff for instance)

 * Extension looking for love (if noone raises the hand, they will end
 in PECL too)
 
  -  ncurses
  I can help here for the windows port and pdcurses support on unix and
 windows. Hartmurt agreed for the move it to pecl for 5.3.

hm, I thought this was already done, go for it.

  - smnp
  nice ext, any ISP out there willing to help? I can help for the windows 
 support

Last time I checked it worked nicely and I know other user which have no
problems either, so I guess there's not much maintenance needed. The
only thing I see is implementing new parameter parsing API.

So I don't see a reason to move it to PECL.

 Can be moved PECL
 - interbase
 - fpdf
 - fbsql
 - sybase and sybase_ct

Moving fpdf shouldn't be a problem, for the others I can't really judge,
I don't know a user of these, but that's me.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] towards a 5.3 release

2008-07-02 Thread Johannes Schlüter

On Wed, 2008-07-02 at 22:24 +0200, Hannes Magnusson wrote:
 On Wed, Jul 2, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
  @Philipp: Since you are the god of documentation .. How are things looking
  on the scratchpad [8] you started?
 
 Philip, one p, recently moved to Nicaragua (last weekend actually) and
 isn't really available these days :)

Nice :-)

 Furthermore I haven't seen Nuno for a while and you guys stole
 Felipe from us and I recently found out that school is heckofalot
 easier than work :]
 
 So... any and all help in the documentation area would be appreciated.
 The scratchpad wiki page is a good start, but I doubt these are the
 only changes/new features in 5.3...
 Of the top of my head; a list of error changes (especially
 functions/features now throwing E_DEPRECATED) is missing...

Also the changes to zend_parse_prameters() should be checked for tiny
changes (like the current()/next() changes already documented on that
wiki page)

Help from any lurker here is appreciated!

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaces for internal classes

On Fri, 2008-07-04 at 10:28 +0200, Lars Strojny wrote:
 Hi Derick,
 
 Am Freitag, den 04.07.2008, 10:14 +0200 schrieb Derick Rethans:
  I'd say this is a BIG no-no. PHP owns the top-level namespace. Why
  make things harder? And on top of that, you're suggesting just to
  break code for no good reason in Backwards compatibility and other
  constraints.
 
 Quoting the proposal: The current names are available as deprecated
 aliases until their removal. This means that until we decide to remove
 the old names, the current ones are available. I'm currently
 investigating how to implement an ADD_DEPRECATED_CLASS_ALIAS-macro.
 Classes/interfaces created with this warning would trigger an
 E_DEPRECATED warning.

That's not entirely true, there are minor BC breaks: Let's say Bar is an
alias for Foo::Bar. now to $r = new ReflectionClass('Bar'); echo
$r-getName(); and you'll get 'Foo::Bar' as that's the name in the CE,
same goes for error messages, stack traces, ... (I'Ve seen people
parsing them...)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Closures: updated proposal and patch

Hi,

On Thu, 2008-07-03 at 22:30 +0400, Dmitry Stogov wrote:
 I don't see big problems with closures. The patch is simple and
stable.
 It's main part isolated in zend_closures.c and it doesn't affect other
 parts of engine.

Changes too the languages always introduce some side effects and
therefore we have too be careful there. Even stuff which is from engine
point of view nice might have some effects on the userland which might
not be too nice, just see the ongoing discussions about details about
namespaces... But back to closures:

I spent the last weeks with less mail reading and am still 112 mails on
internals behind so maybe I missed something there but even short tests
showed me things which might need cleanup:

A tiny thing I saw is different naming in different places:

php -r 'is_callable((function () {}), true, $name); var_dump($name);'
string(6) lambda

vs.

php -r 'var_dump(function(){});'
object(Closure)#1 (0) {
}

Do we really want to use both names in userland? Is a string lamda
really the best represantation for callable_name? (this might even be an
issue if somwbody has a function called lambda ... for whatever reason,
oh just checked people even do:
http://google.com/codesearch?hl=enlr=q=lang%3Aphp+%22Function+lambda(%
22sbtn=Search )

Another issue I found during my short testing period today is
reflection: In a previous position I had to deal with callbacks, for
making the code more robust I checked the callback using reflection
before accepting it, the code looks something like that:

   function setCallback($cb) {
   if (is_array($cb) {
   $r = new ReflectionMethod($cb);
   } elseif (is_String($cb)) {
   $r = new ReflectionFunction($cb);
   } else {
   throw new Exception();
   }

   if ($r-getNumberOfRequiredParameters() != 2) {
   throw new Exception();
   }
   /* ...  morre checks of that kind ... */
}

Now such a check isn't possible, all reflection information on the
callback I can get is that it is an object of type Closure having a
method __invoke() with zero required parameters. There's no further
information on the function, so probably we need a ReflectionClosure
class or something

Both of them are tiny issues which can be fixed in a quite simple way
(or be documented as expected) but my concern is that we'll find way
more of them.

So the final question is: Do we want to go in a higher pace to get
things out and have other features ready which can be added early for a
new release cycle or do we want to go a bit slower with the risk of
stopping and probably going backwards, again.

I'd prefer the first way (even so I do really like closures and wanted
to have them for some lng time...)

 I expect more problems with GC

GC can be problematic yes, but imo gc can either be disabled by default
and documented as use only with care for  running your unit test suite
or completely dropped, even in a later stage if there are problems, I
don't see there much potential for long going detail discussions. Even
if it's, technically, more critical.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Closures: updated proposal and patch

On Fri, 2008-07-04 at 11:31 +0200, Lars Strojny wrote:
 Hi Johannes,
 
 Am Freitag, den 04.07.2008, 11:18 +0200 schrieb Johannes Schlüter:
  Now such a check isn't possible, all reflection information on the
  callback I can get is that it is an object of type Closure having a
  method __invoke() with zero required parameters. There's no further
  information on the function, so probably we need a ReflectionClosure
  class or something
 
 Couldn't ReflectionFunction play that role. Classes and instances with a
 defined __invoke method can be reflected with ReflectionFunction?

At the moment: not enough.

$ php -r 'echo new ReflectionObject(function ($a, $b) use ($c) {});'
Object of class [ internal final class Closure ] {

  - Constants [0] {
  }

  - Static properties [0] {
  }

  - Static methods [0] {
  }

  - Properties [0] {
  }

  - Dynamic properties [0] {
  }

  - Methods [1] {
Method [ internal public method __invoke ] {
}
  }
}

it's not mentioning the parameters or the used variable, and yes, it's a
tiny issue which can, most likely, fixed within an hour or so but I
guess we'll have many more of that kind: Tiny issues which end up in
discussions about taste (should we add a new class or simply add
special treatment in ReflectionMethod for Closure::__invoke?) and all
this stuff can delay things... That's the risk I'm seeing.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespaces for internal classes

Hi,

On Fri, 2008-07-04 at 11:26 +0200, Lars Strojny wrote:
 Am Freitag, den 04.07.2008, 11:15 +0200 schrieb Johannes Schlüter:
 [...]
  That's not entirely true, there are minor BC breaks: Let's say Bar is an
  alias for Foo::Bar. now to $r = new ReflectionClass('Bar'); echo
  $r-getName(); and you'll get 'Foo::Bar' as that's the name in the CE,
  same goes for error messages, stack traces, ... (I'Ve seen people
  parsing them...)
 
 Didn't thought of that, thanks for the heads up. In your opinion, would
 that be a show stopper?

Depends ;-)
Main point: There's no such thing as no BC break. So we have to decide
whether that BC break (hoping it's the only one) is less a problem than
having an inconsistent naming scheme. (... wait - isn't PHP famous for
being inconsistent?) The question there is: Where do we want to go
tomorrow? Do we want to namespace internal stuff? All of it? Or do we
still want to own the global namespace and put internal classes there?
As long as that isn't decided it's hard to make a decision about
aliasing.

So I'd say we need the RFC which defines rules for future stuff
(All/non-core parts/nothing in namespaces) and then the consequences
for existing stuff.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] win32 snaps back

2008-07-05 Thread Johannes Schlüter

Hi,

On Sat, 2008-07-05 at 18:33 +0200, Pierre Joye wrote:
 The win32 snaps were broken since the 24th of June. Except the 5.3
 apache2filter and the 5.3 installer snapshots, everything is back
 online.

Thanks for that, while working on the Windows stuff: Do you think you
can find a good way to send notices to the list or at least me (and
Lukas) once the build fails. In past we had enough situations where
snaps were broken for a few days without anybody seeing which makes
finding the cause harder...

When doing that please keep in mind not to spam the list too much so
only send a mail out when it fails for the first time, not every two
hours when the snaps box tries again.

Thanks,
johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()

2008-07-21 Thread Johannes Schlüter

On Mon, 2008-07-21 at 22:06 +0200, Paweł Stradomski wrote:
 W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:
  It also isn't any shorter:
 
 if(str_endswith($path,'.php'))
 
 vs.
 
 if(substr($path,-4)=='.php')
 
 Only if comparing to a static string, but not for this case:
 
 if (substr($path, -strlen($extension)) == $extension)

Then $extension is a CV which isn't that much slower in comparison as a
CONST, so from engine-performance-perspective: no big deal - spend your
time optimizing on other places where it has more effect than the time
you loose on teaching people about all the fancy string functions (where
we already have more than enough)

 Readability would also increase.

too many functions hurt more on readability imo ...

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?

2008-07-25 Thread Johannes Schlüter

On Thu, 2008-07-24 at 20:25 -0400, Gwynne Raskind wrote:
  Yes, I read that.  But the conversion of the repository itself is  
  only half the battle.  There are a bunch of scripts in CVSROOT that  
  need to be ported over to SVN somehow.
 
 My plan was to work on those next.

not only CVSROOT, there are also some vcs-specific script in php-src
(like cvsclean or scripts for snaps building), scripts on the snaps box
to build snaps, on master to generate docs and websites,  which all
have to found, analyzed, rewritten.

So a rather long running project where he repository conversion is one
of the smallest problem (enough big projects did that so if there are
problems there are many places to ask, whereas the whole infrastructure
around has to be analyzed...) :-)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS to SVN Migration

2008-07-25 Thread Johannes Schlüter

On Fri, 2008-07-25 at 10:26 +0200, David Soria Parra wrote:
  However I think we should provide the infrastructure for developers to
  setup a dvcs. I dont know if we want to standardize on a specific one.
  But collaboration on exterimental stuff that requires a dvcs should be
  possible on php.net servers.
 
 Maybe it's just about having the possibilities for developers to share 
 experimental trees on a php.net side so that people from outside can 
 pull from it easily and not to remember a bunch of urls to get the trees 
 of some developers working on interesting patchsets.

Sharing trees can also be done with svn. A repository structure might
look something like that:

root
+ active master tees
| + trunk
| + php 5.3
| \ ...
+ developer trees
| + johannes
| | \ my private play ground
| \ 
\ archive
  + php 5.2
  + php 5.1
  \ 

svn 1.5 should allow merging between these tree's, but all such things
should be discussed on the other, new list :-)

johannes

P.S. I'm a git fan boy but see good reasons against it for PHP


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] towards 5.3 alpha1

2008-07-26 Thread Johannes Schlüter

Hello all,

As some of you may have noticed the 5.3 todo list [1] has been  
reworked a bit. There is now a list for alpha1 and some more items for  
alpha2. As previously announced Lukas and I are allowing low risk  
self contained work to continue until alpha2 on a case by case basis.

However there are even still a few items that did not make it in for  
the alpha1 feature freeze that we have permitted to be worked on over  
the course of this weekend. Or just general bug fixing items we need  
to have done before alpha1 release (planned for July 31st):
1) various string optimization patches from Matt (Scott)
2) various ZE optimization patches from Matt (Dmitry)
3) add tests for fileinfo (note fileinfo is now bundled and enabled by  
   default just as mimemagic was before PHP 5.2) (Derick)
4) add openssl_parse_csr (Pierre)
5) OpenLDAP C API cleanup patch and pat44 LDAP control
   support (Pierre)
6) Zend Signal Handling (Dmitry)
7) add array_replace[_recursive] (diff, phpt) (Johannes)
8) prepare windows build infrastructure (Pierre, Rob, Liz)
9) make parent::/self:: forwarding (Dmitry)
10) make ming compile with libming 0.3 and up (Frank)
11) unix path separators in spl (Marcus)
12) add Christians Reflection patch for closures (Marcus)

@Marcus: Can you handle 11) and 12)?

Let us know if we are missing anything from this list ASAP!

Then a couple questions that need to be answered and quickly resolved:
- undeprecate ticks: as long as we have no replacement for the signal
  handling we shouldn't deprecate the only way to do that.
- drop __toString() from Closures
- Do not include 3xx http codes in the fopen wrapper

Again a general request to the developer and user community at large:
Please concentrate on findingfixing bugs instead of functional changes
(including arginfo and parameter_parsing) and to make sure we have all
changes covered in the wiki [2] so they can be added to release notes
and the documentation. 

Lukas and Johannes

[1] http://wiki.php.net/todo/php53
[2] http://wiki.php.net/doc/scratchpad/upgrade/53



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DOMDocument Extension: Output current nodelist

2008-07-29 Thread Johannes Schlüter

On Wed, 2008-07-30 at 00:23 +0200, Benjamin Eberlei wrote:
 I recognized at work today that DOMDocument has two function saveHTML and
 saveHTMLFile, but only a save function for the unfiltered xml node
 structure to save to a file although libxml provides the functionality to
 export the data to string.


There's save() and saveXML(), where the later does what you're looking
for.

 I created a patch that adds a new method DOMDocument::ouput that does

Why output? ooutput would mean it prints directly to the output
stream.

Two comments to the patch: (although the function already exists..)

Please use diff -u in future, probably even diff -up, that makes the
diff way better to read (see http://php.net/anoncvs.php for tips about
configuring cvs to do that automatically)

And please use braces { } on if statements.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Making PHP upload hooks available through session variables?

2008-07-30 Thread Johannes Schlüter

Hi,

On Wed, 2008-07-30 at 13:46 -0700, Tore B. Krudtaa wrote:
 As most of you probably know Rasmus Lerdorf made som upload hooks 
 available in PHP 5.2 some long time back.
 This was great news for those that wanted more control of uploads 
 and/or wanted to give real time feedback to client about upload 
 progress, and had APC installed as well.
 
 Most PHP installations does not have APC installed, so therefore the 
 upload hooks are not available.
 
 I would like to be able to use the upload hooks without installing 
 the APC.

There's also a package called uploadprogress or something like that in
PECL.

 I would eventually like to be able to use those upload hooks using 
 session variables.

I think that's not possible in a good way as the uploading process would
have to open and parse the session file, update the status, serialize it
and store it again to disk everytime the status changes (aka. every few
bytes received), APC does that using shared memory, uploadprogress using
special files in /tmp, I think.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] New functions: array_replace[_recursive]

2008-07-31 Thread Johannes Schlüter

Matt,

On Tue, 2008-07-22 at 10:52 -0500, Matt Wilmas wrote:
 Adding these two array functions has been on the TODO for a while, 

The patch can quite easily be tricked into an endless recursion of
php_array_replace_recursive() calls which will segfault:

$ php -r '$a = array(); $a[] = $a; $b = array(); $b[] = $b;
array_replace_recursive($a, $b);'
Segmentation fault

Some other cases were covered by PHP's recursion detection:

$ php -r '$a = array(); $a[1] = $a; $b = array(); $b[2] = $b;
array_replace_recursive($a, $b, array($a, $b), array($b, $a));'

Warning: array_replace_recursive(): recursion detected in Command line
code on line 1

Can you try to add a detection for the first case?

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] New functions: array_replace[_recursive]

2008-07-31 Thread Johannes Schlüter

Hi,

On Thu, 2008-07-31 at 11:48 -0500, Matt Wilmas wrote:
 Ugh, I hate that reference/recursion stuff!  I have a hard time following
 what's happening, and am not sure how some of those checks, etc. even work
 in php_array_merge() (which I was working from). :-/  I tried changing a few
 parts, and unfortunately couldn't fix it.  I will look at it further when I
 have some more time, and will of course let you know if it's fixed.  Sorry.
 :-(

I think I found a think: you're iterating over src and src_entry, but
doing the recursion check using Z_ARRVAL_PP(dest_entry)-nApplyCount, I
didn't test it (need food first) but should do that with src_entry.

That's at least where I'd poke around, can you try that, else I'll dig
around there, after having some food :-)

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] New functions: array_replace[_recursive]

2008-07-31 Thread Johannes Schlüter

Matt,

On Thu, 2008-07-31 at 20:06 +0200, Johannes Schlüter wrote:
 On Thu, 2008-07-31 at 11:48 -0500, Matt Wilmas wrote:
  Ugh, I hate that reference/recursion stuff!  I have a hard time following
  what's happening, and am not sure how some of those checks, etc. even work
  in php_array_merge() (which I was working from). :-/  I tried changing a few
  parts, and unfortunately couldn't fix it.  I will look at it further when I
  have some more time, and will of course let you know if it's fixed.  Sorry.
  :-(
 
 I think I found a thing: you're iterating over src and src_entry, but
 doing the recursion check using Z_ARRVAL_PP(dest_entry)-nApplyCount, I
 didn't test it (need food first) but should do that with src_entry.

FYI: that assumption seems to be correct and I committed it including
the fix :-)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/date config.w32 /ext/date/lib parse_iso_intervals.re

Hi,

On Sun, 2008-08-03 at 22:15 +0200, Pierre Joye wrote:
 Hi Derick,
 
 On Sun, Aug 3, 2008 at 6:34 PM, Derick Rethans [EMAIL PROTECTED] wrote:
 
  you're not reading what I said. It does not make one single bit of sense
  that a short function gives problems while an enormously long function
  is fine. This does *NOT* make sense. If you have no idea either, then
  figure it out first before you add silly #pragmas to code.
 
 This code broke the VC6 build, that's a fact. A breakage must be
 fixed, period. I figured out why and fixed it, end of the topic.  Let
 forget the insane amount of warnings in the date code... (top #1 in
 PHP).

Correct PHP is supposed to work on all platforms therefore the code
has to work on Windows, too.

Now there are two questions Derick ask, which I see as valid questions:

a) Why does it break with that function while at least another bigger
one exists. Do we have to expect the other one breaks too the next time
the scan() function is regenerated from re2c for instance?
It feels a bit awkward that a small function is too big for the compiler
while a way bigger one isn't. So finding the exact reason might help in
the future. That's mainly curiosity.

b) In general the build system is not only for putting the stuff in the
compiler but also detecting compiler problems and working around them.
Is it possible to do this work around in the build file? The benefit
would be that it's less likely that a developer breaks it by accident
and we avoid making our code harder to maintain by not cluttering it
with compiler specific stuff (probably the Aix compiler has a problem
with some other stuff, the Sun compiler with other stuff and yet another
compiler somewhere else) Yes one workaround doesn't hurt but let's wait
5, 6, 7 years of further growth of the code base and new compilers with
their issues to be supported... Therefore such changes should be, when
possible, be placed in the build files. Oh and also see the discussion
about a gcc issue we recently discussed on the list.

So as a summary: The nicest code is worthless if we can't compile it on
our platforms, but build fixes should be places where they hurt the
less.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Closures and reflection improvements

Christian,

On Mon, 2008-08-04 at 11:33 +0400, Dmitry Stogov wrote:
  http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch
   
 
  http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch
   
  

without applying and testing the patch:

-   zend_hash_apply_with_arguments(ce-function_table TSRMLS_CC, 
(apply_func_args_t) _addmethod, 3, ce, return_value, filter);
+   zend_hash_apply_with_arguments(ce-function_table TSRMLS_CC, 
(apply_func_args_t) _addmethod, 3, ce, return_value, filter, intern-obj);

that looks a bit strange, probably you want 4 instead of 3 now?

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Alias stream_context_get_default() as stream_context_set_default()

On Mon, 2008-08-04 at 09:49 +0200, Hannes Magnusson wrote:
 On Mon, Aug 4, 2008 at 01:29, Davey Shafik [EMAIL PROTECTED] wrote:
  Hey,
 
  it has come to my attention that stream_context_get_default() 
  is /grossly/ misnamed, considering
[...]
 That doesn't really solve anything as the argument is optional.

Adding a new function which enforces the parameter sounds way better
then a simple alias.

 In
 fact, to me it reads like the default context would be reset to
 nothing.

I hope not ... I'd expect it to return the current default context
unchanged, else that function certainly should be replaced

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] enabling everything by default