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
