[PHP] Re: [PHP-DEV] PHP Extensions & Pass-By-Reference
Hello Chris, you need to define that signature of your functions by supplying ZEND_ARG_INFO's to them. look at ZEND_API.h file for those macros. marcus Friday, February 25, 2005, 2:22:39 AM, you wrote: > I have a PHP_FUNCTION() defined in my PHP extension. How am I suppose to > pass variables by reference to my function without enabling call-time pass > by reference in the PHP.INI file? > Thanks -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-DEV] PHP 4.4.8RC1
Hello Derick, to stick with our announced plan, can we release this in 2007? marcus Thursday, December 20, 2007, 1:43:18 PM, you wrote: > Hello! > I packed PHP 4.4.8RC1 today, which you can find here: > http://downloads.php.net/derick/ > Please test it carefully, and report any bugs in the bug system, but > only if you have a short reproducable test case. > If everything goes well, we can release it somewhere in the first week > of 2008. > regards, > Derick > -- > Derick Rethans > http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org Best regards, Marcus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
Hello everyone, sorry for the crosspost. But recent discussions about: '[RFC] Replace the flex-based scanner with an re2c [1] based lexer' revealed one big issue. During the development of said RFC we dropped --enable-multibyte-support and interaction between engine and ext/mbstring using declare(encoding=..). Now neither of the two is documented anywhere, nor does any of the core developers happen to know how it works, what it is supposed to do or how to test it. Since we do not want to drop this feature we need some test code, best in the form of .PHPTs. You can find information on how to write tests here: http://qa.php.net/write-test.php and http://talks.somabo.de/200703_montreal_need_for_testing.pdf If you are interested in this further you are of course also more than welcome to help in any other form. Apart from the proposal below, there is also my blog entry to help you getting started: http://blog.somabo.de/2008/02/php-on-re2c.html thanks marcus Sunday, March 2, 2008, 11:21:34 PM, you wrote: > RFC: REPLACE THE FLEX-BASED SCANNER WITH AN RE2C [1] BASED LEXER > Situation: > The current flex-based lexer depends on an outdated and unsupported flex > version. Alternatives include either updating to a newer version of flex or > using re2c, which we already use for a variety of things (serializing, pdo sql > scanning, date/time parsing). While moving towards a newer flex version would > be much easier, switching to re2c promises a much faster lexer. Actually, > without any specific re2c optimizations we already get around a 20% scanner > performance increase. Running the tests gets an overall speedup of 2%. It is > arguable whether this is enough, but re2c has more advantages. First of all, > re2c allows one to scan any type of input (ASCII, UTF-8, UTF-16, UTF-32). > Secondly, it allows for better integration with Lemon [2], which would be the > next step. And thirdly we can switch to a reentrant scanner. > Current state: > Flex has been fully replaced by re2c in Zend. We have also switched to an > mmap-based lexer approach for now. However, we had to drop multibyte support > as well as the encoding declare. The current state can be checked out from > Scott's subversion repository [3] and you can follow the development on his > Trac setup [4]. When you want to build php with re2c, then you need to grab > re2c from its sourceforge subversion repository [5]. You can also check out > the changes in a patch created Sunday 2nd March against a PHP checkout from > 14th February [6]. > Further steps: > Commit this to PHP 5.3. Synch to HEAD. Add pecl/intl to 5.3. Discuss/recreate > multibyte support with libintl. > Future steps: > Replace bison with lemon in PHP 5.4 or HEAD. > Time Frame: > 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. > Marcus Boerger > Nuno Lopes > Scott MacVicar > [1] http://re2c.org/ > [2] http://www.hwaci.com/sw/lemon/ > [3] svn://whisky.macvicar.net/php-re2c > [4] http://trac.macvicar.net/php-re2c/ > [5] https://re2c.svn.sourceforge.net/svnroot/re2c/trunk/re2c > [6] http://php.net/~helly/php-re2c-20080302.diff.txt -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: SimpleXML is creating nodes when it shouldn't...
Hello D.,
Friday, May 12, 2006, 5:29:42 AM, you wrote:
> I've recently upgraded to PHP 5.1.4 from 5.1.2 and noticed that in 5.1.3
> there were changes made to SimpleXML. Now, when I touch an element
> which didn't used to exist, instead of acting like it didn't exist, it
> creates it! That's horrible!
> Well, this used to work:
> $xmlstr = "1";
> $xml = simplexml_load_string($xmlstr);
> print_r($xml);
> foreach ($xml->nonexist as $nonexist) {
> // do nothing
> }
> print_r($xml);
?>>
> But now, the output of the print_r is different when I do it the second
> time because the foreach statement created nodes:
> SimpleXMLElement Object
> (
> [item] => 1
> )
> SimpleXMLElement Object
> (
> [item] => 1
> [nonexist] => SimpleXMLElement Object
> (
> )
> )
> I think that's a bug and not a feature. Why was this changed?
It is called write support. I think we are going to add a flag
so that one can specify whether write support is enabled or not.
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: SimpleXML is creating nodes when it shouldn't...
Hello D.,
SimpleXML was never ever designed to have methods. If you prefer methods
then you probably might be better with xmlReader or Dom. Either way i *may*
do something about it. Right now it perfectly fits my needs :-)
best regards
marcus
Friday, May 12, 2006, 5:42:23 PM, you wrote:
> Marcus Boerger wrote:
>>> I think that's a bug and not a feature. Why was this changed?
>>>
>> It is called write support. I think we are going to add a flag
>> so that one can specify whether write support is enabled or not.
>>
> Creating data without using '=' assignment or calling a function is
> scary and somewhat 'magical' behavior. When I 'read' from a SimpleXML
> node and cast that read into an array context, I NEVER expect to
> actually create an array on the object I am reading from. If I do a SET
> (__set), I'd be ok with the magical behavior:
> $xmlstr = "1";
> $xml = simplexml_load_string($xmlstr);
> $xml->nonexist = array();
> But if I'm doing a GET, changing the structure of the object is very bad:
> foreach ($xml->nonexist2 as $nonexist2) {
> }
> Adding a flag is fine and all, but I definitely don't want that flag to
> be inside an INI file. We don't need yet another flag which causes the
> language to behave differently under different circumstances. Can't you
> distinguish between __get and __set on the object and handle it
> differently that way? If not, the flag needs to somehow be set in code
> and not in an INI file with the default behavior to be NO, do not enable
> write support. This is a bad break in BC from such a minor version upgrade
> of 5.1.2 to 5.1.4.
> Dante
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-DEV] Re: [PHP] Exceptions: function x throws Exception
Hello Jochem,
lookup the archieves. We have long ago decided agains that.
marcus
Friday, August 5, 2005, 2:26:04 PM, you wrote:
> Dear Internals,
> class FooBar { public function foo() throws Exception {} }
> function fooFoo() throws Exception {}
> this came up on php-generals and I wondered if anyone had time/cared
> to comment if it (as it does to me) seems like a good idea and/or whether it
> is
> technically feasable. My thinking was that one could then use the reflection
> API
> to determine whether functions/methods are capable of throwing exceptions and
> or
> what kind - might be quite handy when using third party apps/classes
> (PEAR springs to mind.)
> thanks and regards,
> Jochem
>
> Torgny Bjers wrote:
>> Norbert Wenzel wrote:
>>
>>>If there is a class with a function, that might throw exceptions and
>>>does NOT catch them, may I write that like in Java?
>>>
>>>class FooClass {
>>>
>>>public function foo() throws Exception {
> think about this, especially in terms of the Reflection API, it sounds
> like a really good idea (at least to me)
>>>
>>>}
>>>
>>>}
>>>
>>>Or is there another possibility to tell a function throws an exception
>>>and to force the caller to handle that exception?
>>>
>>>thanks in advance,
>>>
>>>Norbert
>>>
>>
>>
>> Hello Norbert,
>>
>> The Java way doesn't work here. The best approach would be to simply run
>> a try/catch/finally around the call to your function/method, and inside
>> the function itself you do the following:
>>
>> if (...) { throw new Exception("My message."); } }
>>
> indeed - bottom line is you have to know that a function/method/extension may
> throw. mostly you do know because:
> 1. you wrote the code,
> 2. or it's documented in the extension manual pages
> 3. and/ro you hit an unacaught exception whilst developing.
> my approach to cover any oversights is to wrap every thing in a main
> try/catch block
> just in case - keeping in mind that the idea is that this 'main' catch block
> is never run
> is al goes well.
>> Regards,
>> Torgny
>>
Best regards,
Marcus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
