[PHP-DEV] Re: curl_multi_info_read patch review
please commit it, looks good. thanks, sterling On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote: Some guys at work created this patch and have been running with it for a while now. Could I get a few more eyeballs on this? http://www.brianfrance.com/software/php/curl_multi_read.patch Quote from our internal bug: The attached patch implements curl_multi_info_read(), as well as fixing some memory leak issues and reference problems in the original source. Should I keep it internal or commit it? Thanks, Brian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: curl_multi_info_read patch review
not having tested it, i don't know. this is certainly a RM question, but if it doesn't break the compile, it does not look like it has the potential to damage previously existing infrastructure. -sterling On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote: PHP_5_1 and head or just head? It could be considered bug fix since curl_multi_info_read was there, but not implemented. Brian On May 2, 2006, at 4:56 PM, Sterling Hughes wrote: please commit it, looks good. thanks, sterling On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote: Some guys at work created this patch and have been running with it for a while now. Could I get a few more eyeballs on this? http://www.brianfrance.com/software/php/curl_multi_read.patch Quote from our internal bug: The attached patch implements curl_multi_info_read(), as well as fixing some memory leak issues and reference problems in the original source. Should I keep it internal or commit it? Thanks, Brian -- 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] Simplexml and xml namespaces
Hm - that shouldn't be.
I think the right solution is that media:title should not show up in
the children of node, unless you are looking at the proper namespace,
ie, you need to use children() to get the children in that namespace.
-Sterling
On 8/18/05, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
I don't really understand how the current xml namespace handling in
simplexml is useful.
test.xml:
rss version=2.0 xmlns:media=http://search.yahoo.com/mrss;
node
titleTitle1/title
titleTitle2/title
media:titleMedia Title/media:title
/node
/rss
$xml = simplexml_load_file('test.xml');
$xml-node ends up containing a title array that looks like this:
[title]=
array(3) {
[0] = string(6) Title1
[1] = string(6) Title2
[2] = string(11) Media Title
}
Of course, I can loop through
$node-children('http://search.yahoo.com/mrss')
and get
[title ]=
object(SimpleXMLElement)#8 (1) {
[0] = string(11) Media Title
}
But how does this really help? I don't see how it is possible to
distinguish the namespaced title vs. the non-namespaced ones. My
suggestion here would be that for namespaced nodes the namespace alias
(or perhaps the actual namespace?) becomes the key in the nodes array.
As in:
[title]=
array(3) {
[0] = string(6) Title1
[1] = string(6) Title2
['media'] = string(11) Media Title
}
So people have a shot at distinguishing media:title from title
Or, alternatively, have a separate arrays:
[title]=
array(2) {
[0] = string(6) Title1
[1] = string(6) Title2
}
[media:title]=string(11) Media Title
The latter is actually what I was (naiively) expecting.
-Rasmus
--
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] Simplexml and xml namespaces
I agree. var_dump() should accurately expose the structure of the simplexml object, if people want to see *everything* they should dump it explicitly (there is a method in the DOM api to do this?) -Sterling On 8/19/05, Rob Richards [EMAIL PROTECTED] wrote: Rasmus Lerdorf wrote: Yeah, I agree actually. My real beef is that simplexml and var_dump() don't place nicely with each other. var_dump() ends up lumping the namespaced elements in with the non-namespaced elements of the same name, but when you iterate through things manually they are not lumped together and the only way to get at the namespaced elements is by checking for them directly with the appropriate children() call. I am fine with having to manually dereference the namespace and keeping things completely separate. I'd just like it to be easier for people to use var_dump() on a simplexml object and not have it confuse the heck out of them by showing them arrays with 2 elements in them which when they iterate only get 1 or if they call count() on it only get 1. It doesnt look difficult to make var_dump respect the namespace set by the initial sxe object for subobjects. If it were to be changed I would also suggest not returning non element type nodes as well. Right now PI, Comments, etc.. get returned by var_dump but these aren't considered sxe properties either. Rob -- 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] curl_init() is bypassing safe_mode open_basedir restrictions
I still consider adding such things wrong
-sterling
On Sat, 30 Oct 2004 15:51:12 +0400, Antony Dovgal [EMAIL PROTECTED] wrote:
On Fri, 29 Oct 2004 16:26:08 +
Curt Zirzow [EMAIL PROTECTED] wrote:
* Thus wrote Antony Dovgal:
On Fri, 29 Oct 2004 01:04:23 -0700
Sterling Hughes [EMAIL PROTECTED] wrote:
no curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.
agree, curl doesn't need to respect safemode, but PHP does.
we're talking about PHP's extension, right ?
One thing I noticed in some testing was the host part in the
file:// url has no meaning so:
curl_init('file://whateveryouwant/etc/group');
yup, I see it now.
I can change the patch to check this too.
Currently I'm waiting for Sterling's response.
It's senseless to add any additional checks if he still considers
that adding such things is wrong.
--
Wbr,
Antony Dovgal aka tony2001
[EMAIL PROTECTED] || [EMAIL PROTECTED]
--
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] Re: Negative string offset support
i hope not. this should be about what's cool for developers, the
speed increase is not a compelling reason.. the debate is does this
make code easier to read/write/maintain? I think it doesn't, and
therefore am against it.
-sterling
On Mon, 1 Nov 2004 03:04:45 +0100, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Wez,
well it would. However 5.1 aims to be a major speed improvement and that's
what the idea is about.
best regards
marcus
Monday, November 1, 2004, 2:29:46 AM, you wrote:
Doesn't substr($a, -1) work ?
--Wez.
On Sun, 31 Oct 2004 17:45:03 -0500, Greg Beaver [EMAIL PROTECTED] wrote:
It would reduce the errors I inevitably get
whenever using a complex feature like substr(). The three choices:
1) substr($a, strlen($a) - 1);
2) $a{strlen($a) - 1}
3) $a{-1}
It's pretty obvious that the 3rd choice lowers the potential for all
kinds of bugs (mistypign, wrong parameter name, incorrect parameter
placement), and is much more readable. For those who already know how
{} works in PHP, it's also obvious what it does at the first look
without any speculation.
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
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] curl_init() is bypassing safe_mode open_basedir restrictions
no curl does not need to respect php's safemode, adding such checks at this level is wrong. people who compile curl, can do so without local file access, and this will solve their problem. On Fri, 29 Oct 2004 10:51:49 +0400, Antony Dovgal [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 12:07:50 -0400 Sean Coates [EMAIL PROTECTED] wrote: Is this legitimate? I took a (very) quick look at bugs, and didn't see it. you can find patches for all branches in attachment. comments are welcome. -- Wbr, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offset support
why not add it with the {} operators then?
-sterling
On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.
Ex. $a = 123; echo $a[-1]; // would print 3
I don't think we should do this for arrays, since -1 and similar are
valid array keys, which means adding this support for arrays would break BC.
Ilia
--
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] Re: Negative string offset support
I think we should not follow this discussion on internals@ and instead
we should have a subcommittee to study whether or not the word need
was appropriate in the context of the substring operator, or whether
in fact, would be nice to have, but might be able to continue living
would've been a more appropriate form of expression.
-Sterling
On Sat, 30 Oct 2004 01:29:46 +0200 (CEST), Derick Rethans
[EMAIL PROTECTED] wrote:
On Fri, 29 Oct 2004, Andi Gutmans wrote:
Yeah, I also thought the word need is a bit strong :) It's more like
syntactic sugar which is nice-to-have
As I just told Ilia on IRC, I think we should not add this (now) for a
couple of reasons:
- Adding new language constructs in mini releases is IMO not the way to
go as it will make it possible impossible to run script that use this
new construct not even parse on PHP 5.0.x servers. Adding normal new
functions does not have this problem of course, as those scripts are
still parsable.
- Substring works just fine, adding this for performance reasons is IMO
invalid.
- People might want to take this even further and request {1,3}, {-3,2}
and the like. (This was expressed in the past when talking about this
stuff)
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
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] Variable fetch optimization
Wez Furlong wrote: I'm a big fan of making the computer do the work on our behalf (that's what it's there for, right?). It shouldn't be a huge problem to write a php script to generate the different executors from a source file. If you're worried about bootstrapping, we can keep the generated files in CVS and/or bundle them pre-generated in the distro. Yeah, actually Dmitry wrote a script that converted the old executor into the new executor, so the script was already there. I think its that Andi doesn't like the concept (I do like the concept btw), not the work involved. Personally, I'd prefer to see the executor generated, so long as the source format is well thought-out. Cause it will allow us to do things like, for example, generating an x86 JIT. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCC/CFLAGS Benchmark for HEAD and PHP_5_0
On Mon, 04 Oct 2004 15:05:04 -0400, Ilia Alshanetsky [EMAIL PROTECTED] wrote: Very interesting numbers, I'd like to second Marcus' request for a 4.3 benchmark. I was somewhat surprised by O2 and O1 being slower then Os, while O3 in some cases may end over optimizing which would it explain it's poor showing. However, it could be that it makes simple situations slower, while more complex operations that are generally more CPU intensive will in fact become faster. If you don't mind, could you please all include data for time make test as it seems to cover a much greater quantity of code. Thies and I found the same thing when we did our patch. It relates to the size of the executor loop that is generated, if you have too much inlining you end up blowing your instruction cache. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strptime patch
they are both in Single UNIX, its pretty reliable in my experience where one is, the other follows. i've only ran into difficulties wrt to what features are available on different OS', do you know a case where strptime isn't avail and strftime is? -sterling On Tue, 28 Sep 2004 08:07:55 +0200 (CEST), Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 27 Sep 2004, Sterling Hughes wrote: Sterling Hughes wrote: i needed strptime() for a project i'm working on, its awful handy when you are making dates with strftime(). any objections to committing the attached patch? I think we need another #ifdef for this for the unlikely situation where strptime is not available and strftime is. Derick -- 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] strptime patch
On Tue, 28 Sep 2004 08:28:39 +0100, Wez Furlong [EMAIL PROTECTED] wrote: *cough* windows *cough* probably doesn't have strptime (not that you'd care ;-)) do we still support that platform? who knew? :-P sometimes i often wonder if Zend integrated the Performance Suite into PHP, if we could drop the windows port and let them sell the only commercial version then I go back to calling windmills names. It's also probably a good idea to add the check for the wierdo unix flavours, just to be safe. yeah, fair enough. its easy to add anyway. assume its in my patch. any other issues? -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_exceptions.c zend_execute.c zend_execute.h zend_execute_API.c zend_opcode.c zend_vm.h zend_vm_handlers.h zend_vm_spec.h
this is actually a relevant discussion for internals... -- Forwarded message -- From: Sterling Hughes [EMAIL PROTECTED] Date: Wed, 8 Sep 2004 23:26:00 -0700 Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_exceptions.c zend_execute.c zend_execute.h zend_execute_API.c zend_opcode.c zend_vm.h zend_vm_handlers.h zend_vm_spec.h To: Andi Gutmans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Added files: /ZendEngine2zend_vm.h zend_vm_handlers.h zend_vm_spec.h Modified files: /ZendEngine2zend_compile.h zend_exceptions.c zend_execute.c zend_execute.h zend_execute_API.c zend_opcode.c Log: - Some architectural changes: a) We specialize opcodes according to op_type fields. Each opcode has to be marked with which op_type's it uses. b) We support different execution methods. Function handlers, switch() and goto dispatching. goto seems to be the fastest but it really depends on the compiler and how well it optimizes. I suggest playing around with optimization flags. - Warning: Things might break so keep us posted on how things are going. (Dmitry, Andi) How could someone like the APC optimizer now hook into this system and add a new instruction without modifying the executor? -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Learning from Python: PEPping the PHP Development Process
Rasmus Lerdorf wrote: On Thu, 26 Aug 2004, Sebastian Bergmann wrote: At last weekend's EuroFoo [1] I attended Marc-Andre Lemburg's talk [2] on the Python development process. I really wish we had a process similar to Python's PEPs [3] [4] for PHP. Having guidelines for issues like adding a new module [5] or deprecating a module [6] not only makes the development consistent but also transparent to our users. It smells a little too processy to me, but I wouldn't mind a system that borrowed some of the ideas. Like a single collection point for feature proposals and a common format for them. We could simply steal PEAR's PEPR infrastructure for this (http://pear.php.net/pepr/pepr-overview.php). It smells a bit too processy anyway you swing it, and maybe I'm missing something, but I don't see any need: I'd like to see a problem before we attempt to fix it. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Unmasking the error handler (was Re: [PHP-CVS] cvs: php-src /ext/dom document.c)
Derick Rethans wrote: On Wed, 25 Aug 2004, Sterling Hughes wrote: That's wrong. You should *never* require an E_WARNING to be sent without being able to silence it, especially not on something so unimportant. It's just as wrong as trying to parse non-wellformed XML. Then don't add the feature. There are things that extensions are allowed to do (throw a warning), and there are things that extensions should not be allowed to do, unmasking the error handler is one such thing. IMNSHO, that is a technical limitation for any extension distributed with PHP. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [TAG: Process Improvement] Re: [PHP-DEV] Learning from Python: PEPping the PHP Development
Rasmus Lerdorf wrote: Just to clarify, I didn't propose taking the PEAR PEPr system verbatim. To be honest, I have never really used it, beyond skimming through things because it is handy that everything is in one place. I don't find our feature/change request category in the bugs database to be all that effective. Things tend to get lost in the noise there. I am not sure it would be effective, but I think it might be worth a try to have a single place for people to propose features and changes and to have an organized record of decisions surrounding these proposals. At the same time I absolutely hate using a web system for discussing things, so such a system should have an email gateway. As in: 1. Submit proposal to web app 2. web app sends it to internals@ or some other relevant list 3. Replies to that email automatically get picked up by the web app 4. Alternatively, you can add comments via the web app which would also get bounced to the relevant mailing list One thing we could do is have a TAG message in our existing lists, when a discussion like this one becomes noteworthy, someone could respond with a subject [TAG: Feature Request] and that would propagate the conversation to the necessary portion of the web app? -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unfulfilled promises... forever experimental extensions... all over again
Both you and roshan are more than welcome, if not encouraged, to stop posting if you find us childish, immature and generally uncool dude. We apologize for our inferiority, we really wish we had something better to do than respond to your mails. -Sterling Here we have a polite, if provocative, email, and two very nasty and rude responses to it. Followed by a polite response from Roshan. If you walk into a room and see an argument where one side is yelling and being rude, and one person is responding calmly and politely, who would you automatically (given no other information) assume is right? Just a thought from an outside observer. Dan On Wed, 25 Aug 2004, Naik, Roshan wrote: snip Roshan's thoughtful and polite email On Wed, 25 Aug 2004 17:42:11 -0700 (PDT), Rasmus Lerdorf [EMAIL PROTECTED] wrote: Wow, that was quite a rant from someone who hasn't contributed a damn thing. Ranting at a bunch of volunteers is utterly useless and counterproductive. If you do that, your words might mean something. On Wed, 25 Aug 2004 18:06:32 -0700, Andi Gutmans [EMAIL PROTECTED] wrote: Thanks for this quite useless and unproductive email. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_execute.c
Andi Gutmans wrote: andiThu Aug 19 16:03:06 2004 EDT Modified files: /ZendEngine2 zend_compile.h zend_execute.c Log: - Stop using garbage. Please let me know if you find any bugs resulting - of this patch (very likely). (Dmitry, Andi) This patch seems to move destruction inline? -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_execute.c
Andi Gutmans wrote: Not exactly because clean_garbage() was also inline. Sure, but it was at the end of the opcode, this moves it into the FREE_OP macro, as opposed to marking (+ sweeping ;) or something else, right? I'm not against that change in any respect, as I mentioned, I'm a big +1, just checking... -Sterling At 01:28 PM 8/19/2004 -0700, Sterling Hughes wrote: Andi Gutmans wrote: andiThu Aug 19 16:03:06 2004 EDT Modified files: /ZendEngine2 zend_compile.h zend_execute.c Log: - Stop using garbage. Please let me know if you find any bugs resulting - of this patch (very likely). (Dmitry, Andi) This patch seems to move destruction inline? -Sterling -- Zend Engine CVS Mailing List (http://cvs.php.net/) 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] Re: [PHP-CVS] cvs: php-src /ext/curl interface.c
yep, that's right. On Fri, 20 Aug 2004 11:06:33 +1000, Dave Barr [EMAIL PROTECTED] wrote: Ilia Alshanetsky wrote: iliaa Thu Aug 19 20:55:56 2004 EDT Modified files: /php-src/ext/curl interface.c Log: Added more missing cURL options. + REGISTER_CURL_CONSTANT(CURL_TIMECOND_IFMODSINCE); + REGISTER_CURL_CONSTANT(CURL_TIMECOND_IFUNMODSINCE); + REGISTER_CURL_CONSTANT(CURL_TIMECOND_LASTMOD); Great, thanks! + case CURL_TIMECOND_IFMODSINCE: + case CURL_TIMECOND_IFUNMODSINCE: + case CURL_TIMECOND_LASTMOD: convert_to_long_ex(zvalue); error = curl_easy_setopt(ch-cp, option, Z_LVAL_PP(zvalue)); break; I don't think the three constants belong here. This switch() is for CURLOPT_'s which these constants are not. These constants are for use with CURLOPT_TIMECONDITION. You would use them as such: curl_setopt($ch, CURLOPT_TIMECONDITION, CURL_TIMECOND_IFMODSINCE); curl_setopt($ch, CURLOPT_TIMECONDITION, CURL_TIMECOND_IFUNMODSINCE); curl_setopt($ch, CURLOPT_TIMECONDITION, CURL_TIMECOND_LASTMOD); Dave -- 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
[PHP-DEV] php.net announcement
http://www.php.net/: Hereby we would like to kindly ask everyone who published an article or howto about installing PHP on Windows to revise those instructions according to our latest guide. These new instructions got distributed with PHP 5.0.1 in both the source code and binary versions, and will continue to be shipped with future versions of PHP. Uhm, Its nice that there are new instructions and all, but should we really be recommending this? What's the reason for this announcement? -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: setcookie() and Max-Age
+1
-Sterling
On Tue, 17 Aug 2004 18:05:12 -0700 (PDT), Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Perhaps it makes more sense to just give it an array there. I agree that
+3600 is not great either as I am sure someone will try to just pass
+3600 without the quotes.
How about this:
setcookie('name',$value,array('Max-Age'=3600, 'Comment'=$comment, 'Path'='/');
So, in this overloaded form you just have 3 arguments and you put all your
args in that 3rd array arg.
RFC 2109 lists all the attributes possible. Version and Comment are the
other two we don't currently have a way to send, so if we address Max-Age
we should also add a way to send those other two. It even says the
version field is required, but that must be a rather relaxed use of the
term, 'required'.
-Rasmus
On Tue, 17 Aug 2004, Andi Gutmans wrote:
I think overloading the type is a good idea. Might even be best to use
something which doesn't resemble a number for instance Max-Age: 3600. We
could just send that out in the header if it's a string (although it might
leave room for typos).
Any other ideas or sexier ways to do the overloading?
Andi
At 04:55 PM 8/17/2004 -0700, Rasmus Lerdorf wrote:
No, I think he is saying use Max-Age if the expire is before Sep. 2001.
ie. if the expire timestamp looks like a small value and not a timestamp,
treat it like a max-age, otherwise if it looks big enough to be a real
unix timestamp, make it a normal absolute expiry.
While that is an idea that will probably work, it seems messy to me. Code
with hardcoded expiries in the past that previously wouldn't cause any
cookies to be sent will now suddenly start sending cookies.
I think I would rather see a separate function, or perhaps overload it by
type instead. As in, SetCookie(foo,bar,+3600);
The fact that it is a string that start with a + indicates a Max-Age
instead of an integer timestamp. This way the separation is clear.
-Rasmus
On Tue, 17 Aug 2004, Andi Gutmans wrote:
If I understand correctly, what you're saying is that we should always use
Max-Age and just do the conversion ourselves?
Andi
At 01:46 AM 8/18/2004 +0200, Christian Schneider wrote:
Andi Gutmans wrote:
Not sure if an how this could be added to setcookie() because of the
already rich amount of parameters it accepts. Would it make sense to have
something like setcookie_max_age() or something similar?
I think we should overload the expire parameter. Somewhat ugly but
transforms the function into what it really should look like. Adding
another parameter or even function complicates the life of everyone in the
future and since a IMHO doable way exists I'd say we should keep it
simple.
Proposal: expire 10 (Sun Sep 9 01:46:40 2001) uses Max-Age and
allows up to 31 years of Max-Age. If properly documented this should be ok
IMHO.
If people are afraid that someone hardcoded something before Sun Sep 9
2001 in their source code then we could lower it to 1 (Sat Mar 3
09:46:40 1973, 3.1 years) but I'd prefer the previous value.
My .02$,
- Chris
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sorting Bug / Wrong behavior?
i don't think sort() should be changed - this is how php works, for
better or sometimes worse, changing it any other way would break BC,
and it doesn't make much sense.
-Sterling
On Fri, 30 Jul 2004 15:39:19 -0700, Andi Gutmans [EMAIL PROTECTED] wrote:
How would you expect the sort function to behave on the following:
array(true, false, 0, 1)?
It is a different way of looking at the same problem and you are likely to
hit this anytime you start comparing/sorting different data types.
In general, I don't think it makes very much sense to fix the comparison
operator for these special cases.
PHP has always done this kind of type juggling and you would be changing a
lot of its behavior.
I suggest that when you do try and sort an array with different kind of
data you define your own sorting callback function.
Making special cases for each such case in the compare function will not
only change behavior but it will slow down the already too big for my
taste compare function.
I know it's not the answer John was hoping for (I promised him to look into
it more deeply when I'm back from OSCON) but after doing so and thinking
about it, I think we'd be going in a direction which wouldn't be good.
I have a feeling this might also not give you the expected behavior for
something like array(0, -1) but I haven't actually ran it.
Andi
At 09:45 PM 7/27/2004 +0200, Marcus Boerger wrote:
Hello John,
Tuesday, July 27, 2004, 9:48:28 PM, you wrote:
Consider the following:
?php $a = array('a', 'b', 'c', 'a'=0, 'b'=1, 'c'=2);
sort($a);
print_r($a);
?
This produces a bogus output:
Array
(
[0] = a
[1] = b
[2] = 0
[3] = c
[4] = 1
[5] = 2
)
Notice how 0 and c are switched incorrectly. Attached is a patch to
zend_operators.c that fixes it.
The current order simply makes no sense at all.´The following though would:
0 a b c 1 2 // zero dirst, then strings then numbers
a b c 0 1 2 // strings first, then numbers
0 1 2 a b c // numbers first, then strings
and btw, john you forgot the patch, it is attached here.
The one provided does the 2nd which means we only ensured
0 is treated un the same way other numbers are.
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sorting Bug / Wrong behavior?
no argument there, having a few more reasonable sort options/methods makes sense to me, so long as they offer new functionality (as opposed to fixing an inconsistency) and don't affect the default behaviour... -sterling On Tue, 10 Aug 2004 12:59:09 -0700 (PDT), Rasmus Lerdorf [EMAIL PROTECTED] wrote: On Tue, 10 Aug 2004, Sterling Hughes wrote: i don't think sort() should be changed - this is how php works, for better or sometimes worse, changing it any other way would break BC, and it doesn't make much sense. I agree that we should keep the generic sort function the same. Might be nice to add some more sort flags though. It's somewhat annoying that the sort_string sort option doesn't use strcoll, for example, so you have to use a usort to get proper string sorting in most languages. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the difference between MySql and Microsoft SQL?
one thing is the same about both of them - neither of them is relevant to this list. Please stop posting to this list, it is not the appropriate place for any of your questions. -sterling On Wed, 4 Aug 2004 23:00:21 -0400, nsangineto [EMAIL PROTECTED] wrote: What is the difference between MySql and Microsoft SQL? -- Best regards, Nicholas Sangineto www.scctechnologies.com Ergonomic Web Site Designer - Security IT www.finalbookofdaniel.com Daniel Prophet www.godsgateways.com Web Database and Gateways about the Spirituality and Mt-Shasta. www.twth.org Way to Hapiness Booklet Reseller -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
It can't be doable because it makes writing an optimizer impossible. -sterling On Tue, 3 Aug 2004 11:54:28 -0700, Sara Golemon [EMAIL PROTECTED] wrote: If you really, really, really wanted to do such a thing, you could still do: eval(goto foo$bar;); to get the same effect, right? Hmm, depends on how it's implemented. It will most likely not work I guess. Nope... eval()'d code is in a separate op_array from the code it's eval()'d from. While it has the same variable scope it does not have the same label pool. Building in that kind of support is theoretically doable (and you'd get support for cross-file gotos in the process), but it complicates the execution flow somethin' fierce. -- 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] SimpleXML returning attributes as objects instead of strings
iterators...
On Mon, 02 Aug 2004 16:53:49 -0400, David Sklar [EMAIL PROTECTED] wrote:
SimpleXML returns attribute values as SimpleXMLElement objects instead
of strings. E.g, given this:
$sxe = simplexml_load_string('octopus arms=eight legs=Doc
Ock/octopus');
$sxe['arms'] and $sxe['legs'] are SimpleXMLElement objects.
This mostly works OK, but causes problems when using empty() to test if
an attribute has a value. empty($sxe['arms']) is false, but so is
empty($sxe['legs']).
An easy workaround is to use strlen() instead of empty(), I suppose
(except if an attribute value is 0), but I am wondering why SimpleXML
works this way.
Thanks,
David
--
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] Lamenting PHP's streaming support...
php-general@ can answer your question... -sterling On Sun, 01 Aug 2004 16:28:18 -0400, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi everyone, I'm trying to write some serious parsing applications in PHP. I find myself frequently lamenting the 4GL-like support for buffered streams. I'd rather a full fledged streaming API with stream handles (or objects) like you get in mature 3GL languages like C and Java. I'm making do with the single character-stream buffer available to me in the output buffer. I wrap this stream in classes that emulate distinct character streams by saving the current output buffer, clearing the output buffer for the new virtual stream, and then restoring the original output buffer when the virtual stream is closed. This works, but it costs in overhead and requires repeatedly creating string objects to store old buffers and then rewriting those objects back to the output buffer. This is less than ideal from both a performance standpoint and a complexity standpoint (and an increased potential for wierd errors). I'm not too concerned about the performance issues of these virtual buffers because I can architect the application so that it minimizes these switches. However, I find myself (so far) unable to architect around another serious performance issue. I'm having to create a new string for each character sequence that I write to the output buffer. I'd rather just copy the substring of the document being parsed directly to the output buffer. Object creation is an expensive activity when thousands of objects needed to be created for a single page hit. All I need to deal with this problem is a new PHP function: ob_write($string, $start, $length) This would write the characters in substr($string, $start, $length) to the output buffer without creating an intermediate string object. Is there anything on the horizon that would give me the kind of streaming support I'm looking for? Thanks for your help! ~joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- ..II.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO operator
i'm just piping up that i'm a strong +1 on goto, its immensely useful
for code generators, like for example a gui application that wanted to
generate some type of php code.
also, when you start quoting djikstra in a php context, you've lost.
goto is fine, fight the power!
-sterling
On Sat, 31 Jul 2004 17:44:07 -0700, Sara Golemon [EMAIL PROTECTED] wrote:
How does the GOTO implementation handle this
script1.php
?php
do_some_stuff();
include script2.php;
label:
echo Hello
?
script2.php:
?php
declare_some_funcs();
some code ...
if (some_cond) {
goto label;
}
other code
?
Included files are actually separate execution scopes (even though they're
shared data scope). So the implementation referenced originally would raise
an error saing that 'label' is an undefined label.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
..II..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
dooalocaaa, damnit On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans [EMAIL PROTECTED] wrote: At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote: On July 23, 2004 12:40 pm, you wrote: At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: On July 23, 2004 11:42 am, Andi Gutmans wrote: Why do we need one extra byte? We do not. Anyway, the question is if we should return to alloca() or not. I am slightly in favor but don't feel very strongly about it. Perhaps we could try a combination of the two, to ensure that no script is terminated due to a PHP crash if allocating on the stack fails. By default we can use alloca() if that fails to allocate the memory, we could use emalloc() and set a flag free code indicating which free function should be used. I'm hesitant to slow down the general case (even if it's just an additional if()) statement. I'd revert to alloca() and we can always add a --paranoid-stack-allocation directive to configure to use emalloc() :) The problem is that that this causes certain large script to just crash, without any meaningful information. Is the cost of 2 if()s really that pefromance prohibitive? No it's not. But 2 and 2 and 2 is :) I guess we can go with the if()'s for now Argh... Want to write a patch? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- ..II.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [php 4.3.5] Determining Memory Usage by Variable
would be a good addition to xdebug, it couldn't be variable based, but it could be data based. On Thu, 22 Jul 2004 08:55:00 -0700, Bruce Bailey [EMAIL PROTECTED] wrote: Is there a way to determine how much memory a particular variable is using (either in php or in an extension)? It might be nice to check all variables in the php process (perhaps scanning the interpreter's symbol table). Thanks in advance, Bruce _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ -- 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: Re: Re: [PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_language_parser.y zend_language_scanner.l
i'll do it sometime, but no, this patch should be reverted (.) the performance increase is neglible - its a *bad* optimization. -sterling On Mon, 19 Jul 2004 22:59:14 +0200 (CEST), Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 16 Jul 2004, Sterling Hughes wrote: not only that but those people who want this performance boost can use apc. i'll give george a patch that solves this if no one else steps up. Do that before we revert it then, ok? :) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_language_parser.y zend_language_scanner.l
woops, discussion should be on [EMAIL PROTECTED]
-- Forwarded message --
From: Sterling Hughes [EMAIL PROTECTED]
Date: Fri, 16 Jul 2004 00:11:53 -0700
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 /
zend_language_parser.y zend_language_scanner.l
To: Marcus Boerger [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
this breaks bc - it should at least be discussed
-sterling
On Fri, 16 Jul 2004 06:50:58 -, Marcus Boerger [EMAIL PROTECTED] wrote:
helly Fri Jul 16 02:50:58 2004 EDT
Modified files:
/ZendEngine2zend_language_parser.y zend_language_scanner.l
Log:
- Speed up by making null/false/true reserved word which allows to drop
an opcode (FETCH_CONSTANT) for every usage.
http://cvs.php.net/diff.php/ZendEngine2/zend_language_parser.y?r1=1.144r2=1.145ty=u
Index: ZendEngine2/zend_language_parser.y
diff -u ZendEngine2/zend_language_parser.y:1.144
ZendEngine2/zend_language_parser.y:1.145
--- ZendEngine2/zend_language_parser.y:1.144Tue Apr 20 10:14:55 2004
+++ ZendEngine2/zend_language_parser.y Fri Jul 16 02:50:57 2004
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: zend_language_parser.y,v 1.144 2004/04/20 14:14:55 andi Exp $ */
+/* $Id: zend_language_parser.y,v 1.145 2004/07/16 06:50:57 helly Exp $ */
/*
* LALR shift/reduce conflicts and how they are resolved:
@@ -142,6 +142,9 @@
%token T_DOLLAR_OPEN_CURLY_BRACES
%token T_CURLY_OPEN
%token T_PAAMAYIM_NEKUDOTAYIM
+%token T_NULL
+%token T_FALSE
+%token T_TRUE
%% /* Rules */
@@ -675,6 +678,9 @@
| T_CLASS_C { $$ = $1; }
| T_METHOD_C { $$ = $1; }
| T_FUNC_C{ $$ = $1; }
+ | T_NULL { $$ = $1; }
+ | T_FALSE { $$ = $1; }
+ | T_TRUE { $$ = $1; }
;
http://cvs.php.net/diff.php/ZendEngine2/zend_language_scanner.l?r1=1.111r2=1.112ty=u
Index: ZendEngine2/zend_language_scanner.l
diff -u ZendEngine2/zend_language_scanner.l:1.111
ZendEngine2/zend_language_scanner.l:1.112
--- ZendEngine2/zend_language_scanner.l:1.111 Mon Jun 14 15:09:42 2004
+++ ZendEngine2/zend_language_scanner.l Fri Jul 16 02:50:57 2004
@@ -19,7 +19,7 @@
+--+
*/
-/* $Id: zend_language_scanner.l,v 1.111 2004/06/14 19:09:42 helly Exp $ */
+/* $Id: zend_language_scanner.l,v 1.112 2004/07/16 06:50:57 helly Exp $ */
#define yyleng SCNG(yy_leng)
#define yytext SCNG(yy_text)
@@ -57,6 +57,7 @@
#include zend_constants.h
#include zend_variables.h
#include zend_operators.h
+#include zend_API.h
#ifdef HAVE_STDARG_H
# include stdarg.h
@@ -1301,6 +1302,21 @@
zendlval-value.str.val = estrndup(filename, zendlval-value.str.len);
zendlval-type = IS_STRING;
return T_FILE;
+}
+
+ST_IN_SCRIPTINGNULL {
+ ZVAL_NULL(zendlval);
+ return T_NULL;
+}
+
+ST_IN_SCRIPTINGFALSE {
+ ZVAL_FALSE(zendlval);
+ return T_FALSE;
+}
+
+ST_IN_SCRIPTINGTRUE {
+ ZVAL_TRUE(zendlval);
+ return T_TRUE;
}
INITIAL(([^]|[^?%s]){1,400})|s| {
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
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: Re: [PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_language_parser.y zend_language_scanner.l
?php
function null() {
}
null();
?
?php
class connected {
function true() {
}
}
if (connected::true()) {
echo bar;
}
?
On Fri, 16 Jul 2004 09:26:33 +0200, dharana [EMAIL PROTECTED] wrote:
Excuse my ignorance, but why does this breaks compatibility?
Sterling Hughes wrote:
woops, discussion should be on [EMAIL PROTECTED]
-- Forwarded message --
From: Sterling Hughes [EMAIL PROTECTED]
Date: Fri, 16 Jul 2004 00:11:53 -0700
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 /
zend_language_parser.y zend_language_scanner.l
To: Marcus Boerger [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
this breaks bc - it should at least be discussed
-sterling
On Fri, 16 Jul 2004 06:50:58 -, Marcus Boerger [EMAIL PROTECTED] wrote:
helly Fri Jul 16 02:50:58 2004 EDT
Modified files:
/ZendEngine2zend_language_parser.y zend_language_scanner.l
Log:
- Speed up by making null/false/true reserved word which allows to drop
an opcode (FETCH_CONSTANT) for every usage.
http://cvs.php.net/diff.php/ZendEngine2/zend_language_parser.y?r1=1.144r2=1.145ty=u
Index: ZendEngine2/zend_language_parser.y
diff -u ZendEngine2/zend_language_parser.y:1.144
ZendEngine2/zend_language_parser.y:1.145
--- ZendEngine2/zend_language_parser.y:1.144Tue Apr 20 10:14:55 2004
+++ ZendEngine2/zend_language_parser.y Fri Jul 16 02:50:57 2004
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: zend_language_parser.y,v 1.144 2004/04/20 14:14:55 andi Exp $ */
+/* $Id: zend_language_parser.y,v 1.145 2004/07/16 06:50:57 helly Exp
$ */
/*
* LALR shift/reduce conflicts and how they are resolved:
@@ -142,6 +142,9 @@
%token T_DOLLAR_OPEN_CURLY_BRACES
%token T_CURLY_OPEN
%token T_PAAMAYIM_NEKUDOTAYIM
+%token T_NULL
+%token T_FALSE
+%token T_TRUE
%% /* Rules */
@@ -675,6 +678,9 @@
| T_CLASS_C { $$
= $1; }
| T_METHOD_C { $$
= $1; }
| T_FUNC_C{ $$
= $1; }
+ | T_NULL { $$
= $1; }
+ | T_FALSE { $$
= $1; }
+ | T_TRUE { $$
= $1; }
;
http://cvs.php.net/diff.php/ZendEngine2/zend_language_scanner.l?r1=1.111r2=1.112ty=u
Index: ZendEngine2/zend_language_scanner.l
diff -u ZendEngine2/zend_language_scanner.l:1.111
ZendEngine2/zend_language_scanner.l:1.112
--- ZendEngine2/zend_language_scanner.l:1.111 Mon Jun 14 15:09:42 2004
+++ ZendEngine2/zend_language_scanner.l Fri Jul 16 02:50:57 2004
@@ -19,7 +19,7 @@
+--+
*/
-/* $Id: zend_language_scanner.l,v 1.111 2004/06/14 19:09:42 helly
Exp $ */
+/* $Id: zend_language_scanner.l,v 1.112 2004/07/16 06:50:57 helly
Exp $ */
#define yyleng SCNG(yy_leng)
#define yytext SCNG(yy_text)
@@ -57,6 +57,7 @@
#include zend_constants.h
#include zend_variables.h
#include zend_operators.h
+#include zend_API.h
#ifdef HAVE_STDARG_H
# include stdarg.h
@@ -1301,6 +1302,21 @@
zendlval-value.str.val = estrndup(filename,
zendlval-value.str.len);
zendlval-type = IS_STRING;
return T_FILE;
+}
+
+ST_IN_SCRIPTINGNULL {
+ ZVAL_NULL(zendlval);
+ return T_NULL;
+}
+
+ST_IN_SCRIPTINGFALSE {
+ ZVAL_FALSE(zendlval);
+ return T_FALSE;
+}
+
+ST_IN_SCRIPTINGTRUE {
+ ZVAL_TRUE(zendlval);
+ return T_TRUE;
}
INITIAL(([^]|[^?%s]){1,400})|s| {
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Juan Alonso
This message represents the official view of the voices in my head
--
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: Re: [PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_language_parser.y zend_language_scanner.l
I would have been +0 for 5, I'm -1 for 5.1. FETCH_CONSTANT is not a terribly expensive operation (as opposed to registering constants with define()), and something like this is *easy* to optimize in a compiler cache/optimizer. End of the day, we shouldn't break BC in any way during a point release (or at all) unless its necessary/important, this does meet that criteria. -Sterling On Fri, 16 Jul 2004 08:20:43 -0700, Andi Gutmans [EMAIL PROTECTED] wrote: I don't think it's critical to include this patch, but I do think it'd be a good thing. Do you really think it'll break BC for many applications? How many people have functions that use null(), false(), true()? Andi At 08:17 AM 7/16/2004 -0700, Sterling Hughes wrote: oh, i didn't notice it at all, which i'll buy is probably my fault. :) This seems like its a bad optimization. I believing in breaking BC in some cases when its absolutely necessary, but an optimization like this one could easily happen at the level of an optimizer, like APC or Zend's product. Why are we breaking BC for this? -sterling On Fri, 16 Jul 2004 09:55:57 +0200, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Sterling, it was on internals and in TODO-5.1. Maybe not many people noticed it between discussing typehints and ifsetor. marcus Friday, July 16, 2004, 9:12:28 AM, you wrote: woops, discussion should be on [EMAIL PROTECTED] -- Forwarded message -- From: Sterling Hughes [EMAIL PROTECTED] Date: Fri, 16 Jul 2004 00:11:53 -0700 Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_language_parser.y zend_language_scanner.l To: Marcus Boerger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] this breaks bc - it should at least be discussed -sterling On Fri, 16 Jul 2004 06:50:58 -, Marcus Boerger [EMAIL PROTECTED] wrote: helly Fri Jul 16 02:50:58 2004 EDT Modified files: /ZendEngine2zend_language_parser.y zend_language_scanner.l Log: - Speed up by making null/false/true reserved word which allows to drop an opcode (FETCH_CONSTANT) for every usage. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Clarification needed
it wasn't ported because i don't want people using it anymore, they should be using ext/xsl, period. -sterling On Fri, 16 Jul 2004 11:18:46 +0200, Christian Stocker [EMAIL PROTECTED] wrote: On 16.7.2004 11:15 Uhr, Kamesh Jayachandran wrote: Hi, I have seen that in php5.0/ext/xslt directory does not have any source except the test scripts whereas in php-4.3.8 I could find the files. In php5.0 there is one extra directory under ext by name xsl which does not exist in PHP4.3.8 ext/xslt is based on sablotron ext/xsl is based on libxslt and the new libxml2 support in PHP 5.0 The API is incompatible, so we made an extension with a new name. The inner workings are also quite different. It seems that noone ported ext/xslt (the sablotron one) to PHP 5 until now. And it's in PECL now. chregu Why is this change? Can someone clarify me on this? With regards Kamesh Jayachandran -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- 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] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute.c
can we put that in the release notes - php is like 50% more stable,
it takes 20 seconds not 10 to crash it?
-sterling
On Fri, 16 Jul 2004 12:15:46 -0400, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
hey ilia,
here's another one of my meaningess, synthetic benchmarks (this is how
the CreatorsOfPHP(tm) would call them)
ackermann(8) (source on request - highly recursive)
Recursive functions in PHP are inherently dangerous as without proper limits
they will rather quickly ~5671 iterations with a basic function a() { a(); }
(PHP 4/5).
By comparison the same code only takes 2897 iterations before the patch. While
the patch does not solve this crash it reduces it's chances by nearly 50%
(unexpected benefit).
More over the crash problem that the patch solves is not theoretical that I
made up because I have nothing better to do. We have at least 2 confirmed bug
reports by different people and surely there are others who came across this
issue and didn't report it.
Yes, you are correct, with a dedicated benchmark specifically designed to
exploit the allocation routine change there is a performance drop, but
surely stability is more important then speed. If that is not that case,
there are a whole lot of optimizations we can perform, but that'd mean users
will need to write their code extra carefully :-), which as we know is not
going to happen.
Ilia
--
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: Re: [PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_language_parser.y zend_language_scanner.l
not only that but those people who want this performance boost can use
apc. i'll give george a patch that solves this if no one else steps
up.
-sterling
On Fri, 16 Jul 2004 10:20:08 -0700, Andi Gutmans [EMAIL PROTECTED] wrote:
Nah, I dread the INI word. It makes applications less portable.
I prefer rolling back than doing this.
Andi
At 10:09 AM 7/16/2004 -0700, Sara Golemon wrote:
Andi Gutmans [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I don't think it's critical to include this patch, but I do think it'd be
a
good thing.
Do you really think it'll break BC for many applications? How many people
have functions that use null(), false(), true()?
I know people hate the dreaded ini option word. But how about one for
this? That'd let the optimization work for the 99% of scripts that don't
need to implement null(), true(), and false(), and allow those rare few to
simply disable it for BC.
# Note: I'm no lexx expert, this syntax may not even make sense
ST_IN_SCRIPTINGTRUE {
if (CG(fast_constants)) {
ZVAL_TRUE(zendlval);
return T_TRUE;
} else {
yymore();
}
}
-Sara
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] New construct discussion Summary (was: what happened to that new isset() like language construct)
On Sun, 11 Jul 2004 09:43:51 -0700 (PDT), Rasmus Lerdorf [EMAIL PROTECTED] wrote: On Sun, 11 Jul 2004, Marcus Boerger wrote: $a = ifsetor($_GET['index'], $default); ifsetor() sounds a bit cumbersome to me. Some other suggestions: $a = is($_GET['index'], $default); $a = isor($_GET['index'], $default); $a = valid($_GET['index'], $default); I don't like valid, because that implies checks that aren't there (some sort of sanitizing). $a = value($_GET['index'], $default); all of the other ones sound good - i like value() the best. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory manager
yes!!! i currently don't have a 32 bit linux box available to me (i'm remote in ca for all of august), however, if someone gives me shell on one, i'll bang around on it with valgrind. -sterling On Mon, 5 Jul 2004 11:13:12 -0700 (Pacific Standard Time), Rasmus Lerdorf [EMAIL PROTECTED] wrote: I'd like to see a few people who know their way around Valgrind give this thing a workout before any release. I am planning on doing that as well this week, but the more codepaths tested, the better. -Rasmus On Mon, 5 Jul 2004, Andi Gutmans wrote: Hi, Although I'm pretty sure I fixed the problem of the memory manager (in zend_alloc.c), I agree with Sterling that it's probably best to disable it for 5.0.0. I don't think that my fix will get enough testing until then for me to feel comfortable with including it. As I'd like to roll 5.0.0 by the end of the week, can developers please speak up if they have anything critical they are working on? Please also run latest head just to make sure that the malloc()/free() MM still works :) Andi -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] fix for curl bug
commit or don't, fixed for a client, that code is just stupid bogus. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fix for curl bug
committed to head and branch. On Wed, 30 Jun 2004 23:43:05 -0700, Andi Gutmans [EMAIL PROTECTED] wrote: Sure if it's a fix I think it should go in. At 11:25 PM 6/30/2004 -0700, Sterling Hughes wrote: commit or don't, fixed for a client, that code is just stupid bogus. -sterling -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fix for bug #28325
this would still not suffice for a proper serialization, overloaded objects should have serialize and unserialize handlers something for 5.1 methinks. -sterling On Thu, 1 Jul 2004 16:03:09 +0900, Moriyoshi Koizumi [EMAIL PROTECTED] wrote: On 2004/07/01, at 14:25, Andi Gutmans wrote: Hi Moriyoshi, The object handle is not a unique identifier. Different object types (e.g. PHP objects, SimpleXML objects) can have the same object handle. The real unique identifier is object handle + object handlers array or more useful in your case, possibly class name and object handle. Thanks for the advice. So, will object handle + the VM address to the class entry suffice either? Moriyoshi -- 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] Upgrading www.php.net to PHP 5.0
yep, this is what I found too, and have been saying for nearly a year: http://www.edwardbear.org/blog/archives/000129.html#000129 maybe one of these days we'll give up on the ZEND_MM, which doesn't by us much anyway and has leaked since well before and after beta 1. Ok, that's my annoying I told you so for the month, back to lurking :) -sterling On Mon, 28 Jun 2004 13:07:38 +0200 (CEST), Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 28 Jun 2004, Zeev Suraski wrote: Edin, Can you try disabling ZEND_MM and see if the problem persists? (it's in Zend/zend_mm.h, #undef ZEND_MM). Will do. Derick -- 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] Upgrading www.php.net to PHP 5.0
well, disabling ZEND_MM does *fix* the/a leak. It was disabled when we released beta 1 and has been subsequently re-enabled. As for checking my facts and helping to debug the problem, I'm the one who found the leak and who found the fix (a change which prevents the problem from occuring) nearly a year ago. I stopped debugging it around the time I got tired of doing real work on PHP, but your point is taken, as I've told qa people a thousand times, its easy to always be right when you haven't written any code. -sterling On Mon, 28 Jun 2004 08:50:15 -0700, Andi Gutmans [EMAIL PROTECTED] wrote: Sterling, As far as I can tell, it's not ZEND_MM which is leaking, but after I fixed a bug in zend_alloc.c, these problems started happening. We are using the same zend_alloc.c code for ZEND_MM and allocator on Win32, so in any case, this problem needs to be fixed. It might be that it happens when ZEND_MM is enabled but it doesn't mean that the fault is in ZEND_MM. Check your facts first or even better, why don't you help debug the problem? Andi At 08:46 AM 6/28/2004 -0700, Sterling Hughes wrote: yep, this is what I found too, and have been saying for nearly a year: http://www.edwardbear.org/blog/archives/000129.html#000129 maybe one of these days we'll give up on the ZEND_MM, which doesn't by us much anyway and has leaked since well before and after beta 1. Ok, that's my annoying I told you so for the month, back to lurking :) -sterling On Mon, 28 Jun 2004 13:07:38 +0200 (CEST), Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 28 Jun 2004, Zeev Suraski wrote: Edin, Can you try disabling ZEND_MM and see if the problem persists? (it's in Zend/zend_mm.h, #undef ZEND_MM). Will do. Derick -- 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 -- 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: Re: [PHP-DEV] The open letter to Derick Rethans derick@php.net
% telnet www.php.net 80 Trying 64.246.30.37... Connected to php.net. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 301 Moved Permanently Date: Fri, 18 Jun 2004 18:13:45 GMT Server: Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a PHP/4.3.3-dev Location: http://www.php.net/ Connection: close Content-Type: text/html; charset=iso-8859-1 -- % telnet www.zend.com 80 Trying 209.61.191.11... Connected to www.zend.com. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 18 Jun 2004 18:14:38 GMT Server: Apache/1.3.27 (Unix) PHP/4.3.7 mod_macro/1.1.1 mod_ssl/2.8.12 OpenSSL/0. 9.6b Set-Cookie: SaneID=68.120.96.254-1087582479359; path=/; expires=Fri, 18-Jun-09 2 1:14:39 GMT X-Powered-By: PHP/4.3.7 Set-Cookie: Zend_Session_DB=4a6d867cea6c870397399eb97c44a415; expires=Mon, 21-Ju n-2004 18:14:39 GMT; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: Zend_In=deleted; expires=Thu, 19-Jun-2003 18:14:38 GMT; path=/ Connection: close Content-Type: text/html -- Perhaps we should try running php.net and zend.com on php5 before we release? if we're not even eating our own dogfood yet, it seems premature to release. -sterling On Fri, 18 Jun 2004 20:07:30 +0200, Andi Gutmans [EMAIL PROTECTED] wrote: Don't think that's a good idea. I suggest to wait for another 2 weeks or so, then release 5.0.0 and create a 5_0 branch for bug fix releases and 5_1 for bigger changes. BTW, Zeev suggested 4th of July for a release date. I think that's nice timing. Anyone object? (maybe the French? :) Andi At 06:24 PM 6/18/2004 +0200, Sebastian Bergmann wrote: Marcus Boerger wrote: Even i am holding back tons of patches right now to not disturb release process further :-) Why not branch PHP 5.0 now and continue development in HEAD as PHP 5.1? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: Re: [PHP-DEV] The open letter to Derick Rethans derick@php.net
On Fri, 18 Jun 2004 21:04:36 +0200, Andi Gutmans [EMAIL PROTECTED] wrote: I don't think having php.net run PHP 5 is a pre-requisite for a release. What high traffic site is PHP5 RCx powering at the moment? Where is PHP5 being stress tested? How many people have deployed it for non-academic purposes? Running php.net on PHP5 isn't about making php.net run better, its about making PHP5 run better. In the PHP4 days, as you remember, we were running PHP4 on php.net since beta 1, why have we not switched to php5 since beta 1? I understand that deployment must come after the release for the majority of sites out there, but that is all the more reason that we should take every opportunity we have to test it in a real world circumstance before releasing it onto the public. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alloca() problem
So, oddly enough while responding to this, gmail is showing me Zend advertisements - just thought you should know you are getting your money's worth :) I'll buy that alloca() is harmless in the places the executor uses it (*), php segvs on highly recursive functions, worrying about overly long function names won't keep anyone up at night. But the real issue is the other areas ilia mentions, where it just isn't worth it. -Sterling (*) Although I think its a bottom drawer optimization that something like the Zend optimizer invalidates. On Wed, 16 Jun 2004 01:10:16 +0300, Andi Gutmans [EMAIL PROTECTED] wrote: Ilia, alloca() is very important for the executor loop and functions which where performance is very important (mainly the Zend Engine). I don't see any convincing reason not to use it in the way it is being used today. If there are any specific places you find problematic and want to discuss let me know. Andi At 12:10 PM 6/14/2004 -0400, Ilia Alshanetsky wrote: Virtually all current uses involve some form of user input, which means that the user can exploit the problem. When bar[2048] is used to create a buffer of a certain known size that never change, with alloca a buffer of undermined size is created in most cases. The only 'safe' way to use the function would be to put it inside a wrapper that would check the size against some preset limit and based on that determine if alloca or emalloc should be used. The length would also need to be stored to allow the free wrapper to determine if efree() is needed. These safety checks may offset the miniscule speed advantage gained by using alloca anyway, especially when the length is being calculated inside alloca call. Ilia -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC3
Wolfgang Drews wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi Andi, This is indeed very strange. I made some fixes to the memory manager a few days ago. Have you tried a version since then? before writing to this list, i've download the latest CVS-Snap Win-Built from snaps.php.net. Problem still existed, so i decided to tell you (Build Date Jun 1 2004 12:13:54). can we drop this ts memory manager, its been causing leaks for quite a while and, from my understanding, only speeds up the threaded case. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] libxml - Move Callback Reg to Request Init
Rob Richards wrote: From: Andi Gutmans zend_is_executing() might work, but that is only if this method can only be called during script execution (which I'm not sure of). I'm also not sure if this is reset to 0 at the end of each request but that should be easy to fix. Yup, this method should only be called during a request. I tested it out with mod_xslt and it seemed to work correctly. mod_xslt would safely exit from the function ignoring our streams handler. It seems to reset to 0 after a php script hits it, as a subsequent calls to the mod_xslt handler continuted to function correctly. The only question I have is will there be any problems if run in threaded mode as TSRMLS_FETCH() needs to be called. Well, the threaded case is very much a who cares scenario. Crash once every hundred requests, crash once every thousand - add them up and it might be real money some day. Serially, if someone wants to share a shared library between two separate third party software products in a threaded environment - i'll keep them in my nightly prayers. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix pcre global variable abuse
i'm pretty sure it does, it has a compiled regex cache that uses it, i think. -sterling On Apr 23, 2004, at 7:11 AM, Andi Gutmans wrote: At 10:05 AM 4/23/2004 -0400, Ilia Alshanetsky wrote: On April 23, 2004 10:01 am, Andi Gutmans wrote: I think changing back to malloc/free on RSHUTDOWN is a better solution. After all, we use our memory manager to prevent memory leaks and I think this is one of PHP's most important features. I don't trust third party extensions :) The php_pcre_(free|malloc) use persistent allocation routines with the persistent flag set. Iif I am reading the code correctly, this is nothing more then a wrapper around malloc() free() without any sort of ZE memory management. If that is indeed the case, it would seem that Joe's solution would be better, since besides fixing the problem it eliminates pointless wrapper. I was sure it was using emalloc/efree. Is there any good reason it isn't? Does PCRE require persistent memory? If it does, then I agree with you that malloc/free is the right way to go. Andi -- 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] xmlSetGenericErrorFunc Abuse
On Apr 22, 2004, at 5:09 AM, Rob Richards wrote: From: Sterling Hughes Err, read back in the message. Specifically about should reset the generic error handler. If it doesn't reset it, that's a separate issue. It has *nothing* todo with the mysql issue (which was symbol conflicts due to two libraries being compiled into the same server). A process can not execute two code paths at the same time, therefore you cannot have such corruption in a prefork model. Sterling, I also thought this might be in issue when I brought it up many moons ago as I have no idea of the isolation in apache. I just ran a debug session using apache 2.0.45 prefork under linux. MINIT is only called on server startup and MSHUTDOWN is only called on server shutdown. Since the error handling is set/unset in this spots, it gets changed to our internal handling when apache first starts up and isn't reset between requests. Only when apache shuts down is it reset. Now either the apache 2 sapi is wrong in this regard or the error handling really needs to be re-worked. Here are a couple options I can think of: Putting it in the RINIT/RSHUTDOWN should fix it (cant say about threaded servers and threaded libxml as there was an issue with the per thread error handing in libxml up to at least 2.5.11 - threaded libxml builds needed xmlThrDefSetGenericErrorFunc to be set in the main thread which would have to happen in MINIT (or the error handling needs to be set on every request) - had only played around with this on windows though so not sure if it affects non threaded web servers as well), not sure if this is ideal since it would need to be run on every request wether using libxml or not. Right, this wouldn't fix the threaded case. If libxml error messages are only needed during loading of xml and possibly some other spots where we have a context (such as SAX and possibly validating, etc.. - havent looked at that), the custom error functions can be attached directly to the context. Origionally I moved those custom error functions to the libxml extension (as they used to only be used in dom in th is manner) so that this could be the case, but ended up with just setting the global error handler instead. For all other errors when dealing with operations on the tree, would have to deal with errors through the extensions alone. My suggestion is to pull the 2 calls to xmlSetGenericErrorFunc from libxml.c right now so that is resolved prior to RC2 going out the door (if possible). Then just have to decide wether this should be worked on and implemented prior to the 5.0 release or put on the list for 5.1. Feel free to tell me if I am way off base here as I really have no idea of the interaction between modules in apache :) I think you are off base in removing them. We need them to hook into PHP's error handling system. I think setting/resetting in RINIT instead of MINIT is a good place to start and see if that fixes the problem. I personally could care less about the threaded case (i hope PHP stops using this TSRM stuff and just recommends FastCGI), although someone here who cares more may have opinions about that. I guess we could add an #ifdef TSRM to the system, and not set the generic error handler - if someone cares enough about the threaddites. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse
On Apr 21, 2004, at 2:36 PM, Paul Querna wrote: The libxml2 Extension in PHP5 uses xmlSetGenericErrorFunc(NULL, php_libxml_error_handler); This globally(inside the process) sets the libxml2 error hander to PHP's own function. Why is this bad? It clobbers the processing done by anything else that uses libxml2 in the same process as PHP. For a simple example, I use mod_transform ( http://svn.outoforder.cc/svn/mod_transform ) with Apache 2 as a filter to process XML documents w/ XSLT into HTML. If there are _any_ errors in the transformation PHP attempts to take care of them. This causes Apache to crash because this is not even a PHP request and very quickly the Error Handler will crash when it tries to get a server context. This is not an issue isolated to Apache 2. It could happen in Apache 1.3 if any other module used libxml2. Nope - it couldn't. We reset (or we should) the error handler after we are done executing. In processes, only one thing executes at a time, and when PHP is executing we want to override this error handler. The proper way for PHP to handle this is to not set a Generic Error function, but rather check the return values of libxml2 functions. Nope. This is not like the local-mysql vs system-mysql problem that used to be more common. PHP is initializing libxml2 as if it was the only user, which is not always the case. Its actually quite different than that problem. This is a problem for people who use threads. People who use threads for serving dynamic webpages with PHP should be castrated and then shot (well, at least castrated, we don't want this problem proliferating.) The solution here is either to use a global context of our own, if libxml2 allows us to do so, use a mutex, or just laugh very hard and very loud when people tell us they have a problem using php in threaded environments. On that note bwahhhahahahhahahaha. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse
On Apr 21, 2004, at 6:16 PM, Paul Querna wrote: On Wed, 2004-04-21 at 18:50, Sterling Hughes wrote: Its actually quite different than that problem. This is a problem for people who use threads. I am afraid that you are completely wrong. httpd -V: Server version: Apache/2.1.0-dev Server built: Feb 15 2004 14:26:54 Server's Module Magic Number: 20030821:3 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses disabled) -D APR_USE_FLOCK_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/home/httpd/local -D SUEXEC_BIN=/home/httpd/local/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf Yes. That is correct, I am using the PREFORK MPM, which is not multi-threaded. If I was using the worker MPM, i wouldn't even bother submitting this because I know the PHP-Devs do not care about thread safety. and here is an example backtrace of this happening: #0 php_apache_sapi_send_headers (sapi_headers=0x2857ce98) at /usr/home/httpd/src/php-src/sapi/apache2handler/sapi_apache2.c:140 #1 0x28472714 in sapi_send_headers () at /usr/home/httpd/src/php-src/main/SAPI.c:747 #2 0x284230de in php_header () at /usr/home/httpd/src/php-src/ext/standard/head.c:60 #3 0x28478f50 in php_ub_body_write ( str=0x8143154 br /\nbWarning/b: I/O warning : failed to load external entity \docbooka/xsl/html/docbook.xsl\ in bUnknown/b on line b0/bbr /\n, str_length=142) at /usr/home/httpd/src/php-src/main/output.c:704 #4 0x28477fa9 in php_body_write ( str=0x8143154 br /\nbWarning/b: I/O warning : failed to load external entity \docbooka/xsl/html/docbook.xsl\ in bUnknown/b on line b0/bbr /\n, str_length=142) at /usr/home/httpd/src/php-src/main/output.c:119 #5 0x2846b6e2 in php_printf (format=0x28502600 %sbr /\nb%s/b: %s in b%s/b on line b%d/bbr /\n%s) at /usr/home/httpd/src/php-src/main/main.c:400 #6 0x2846c05e in php_error_cb (type=2, error_filename=0x284fba9c Unknown, error_lineno=0, format=0x2850223d %s, args=0xbfbfe604 ô0\024\b\n) at /usr/home/httpd/src/php-src/main/main.c:736 #7 0x2849f356 in zend_error (type=2, format=0x2850223d %s) at /usr/home/httpd/src/php-src/Zend/zend.c:930 #8 0x2835fec4 in php_libxml_internal_error_handler (error_type=0, ctx=0x0, msg=0x0, ap=0xbfbfe654 ) at /usr/home/httpd/src/php-src/ext/libxml/libxml.c:351 #9 0x2835ffb0 in php_libxml_error_handler (ctx=0x0, msg=0x287339fb %s) at /usr/home/httpd/src/php-src/ext/libxml/libxml.c:377 #10 0x286a48ab in xmlReportError (err=0x826b580, ctxt=0x826b400, str=0x8269300 failed to load external entity \docbooka/xsl/html/docbook.xsl\\n, channel=0x2835ff98 php_libxml_error_handler, data=0x0) at error.c:381 #11 0x286a4d4b in __xmlRaiseError (schannel=0, channel=0x286a4f3e xmlParserWarning, data=0x826b400, ctx=0x826b400, nod=0x0, domain=8, code=1549, level=XML_ERR_WARNING, file=0x0, line=0, str1=0x8249a20 docbooka/xsl/html/docbook.xsl, str2=0x0, str3=0x0, int1=0, int2=0, msg=0x28724b40 failed to load external entity \%s\\n) at error.c:573 #12 0x286c2b88 in __xmlLoaderErr (ctx=0x2857ce40, msg=0x28724b40 failed to load external entity \%s\\n, filename=0x8249a20 docbooka/xsl/html/docbook.xsl) at xmlIO.c:426 #13 0x286a69f2 in xmlNewInputFromFile (ctxt=0x826b400, filename=0x8249a20 docbooka/xsl/html/docbook.xsl) at parserInternals.c:1465 #14 0x286c4eed in xmlDefaultExternalEntityLoader (URL=0x82499e0 docbooka/xsl/html/docbook.xsl, ID=0x0, ctxt=0x826b400) at xmlIO.c:3176 #15 0x286c4f91 in xmlLoadExternalEntity (URL=0x8249a20 docbooka/xsl/html/docbook.xsl, ID=0x0, ctxt=0x826b400) at xmlIO.c:3233 #16 0x286b6f60 in xmlCreateURLParserCtxt (filename=0x826d300 docbooka/xsl/html/docbook.xsl, options=16398) at parser.c:11039 #17 0x286b7dfe in xmlReadFile (filename=0x826d300 docbooka/xsl/html/docbook.xsl, encoding=0x0, options=136754176) at parser.c:12093 #18 0x2899ac0e in xsltParseStylesheetFile (filename=0x826d300 docbooka/xsl/html/docbook.xsl) at xslt.c:2129 #19 0x2899b110 in xsltLoadStylesheetPI (doc=0x824ca00) at xslt.c:2357 #20 0x28a043ad in transform_run (f=0x8257f60, doc=0x826d300) at mod_transform.c:182 #21 0x28a044d2 in transform_filter (f=0x8257f60, bb=0x825a120) at mod_transform.c:249 #22 0x0806d8db in ap_pass_brigade (next=0x2857ce40, bb=0x2857ce40) at util_filter.c:511 #23 0x0807412b in default_handler (r=0x8256050) at core.c:3513 #24 0x080630be in ap_run_handler (r=0x8256050) at config.c:151 #25 0x08063582 in ap_invoke_handler (r=0x8256050) at config.c:358 #26 0x08060a03 in ap_process_request (r=0x8256050) at http_request.c:246 #27 0x0805c639 in ap_process_http_connection (c=0x8250128
RE: [PHP-DEV] Interface inheritance
I agree. Interfaces are useless if you can't guarantee that a class actually implements them. Violating an interface is violating a contract and it should be an compile error - indeed, when coding I mostly rely on not properly implementing interfaces to be a compile error. -Sterling -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 1:49 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Interface inheritance All, Yesterday, someone complained that classes that implement interfaces succeed in doing so even when they don't satisfy the prototypes. While this does cause an E_STRICT message to be emitted, it would go unnoticed in most cases, as E_STRICT is off by default, in some cases - even when people think it's on. I believe that this behavior is wrong. I believe that classes should not be allowed to say they implement an interface X, unless they actually implement all of the methods in that interface with methods that are compatible with its prototypes. Reasoning: - Interfaces (and for that matter, abstract classes) are a new feature in PHP 5, used solely to enforce implementing classes to abide to the prototypes. There's no issue of downwards compatibility, and there's no other use case. - Without this, the whole mechanism of class type hints is rendered useless. With it, it gives users the full power of class type hints (and instanceof, for that matter) - because they always have the option of adding an interface for their base classes. Suggested behavior: Any method that implements (directly or indirectly) an interface method or an abstract method, will have implementation checks fully enforced, with an E_COMPILE_ERROR emitted in case of an error. Behavior for methods that override regular parent methods, that do not have interface/abstract prototypes, will not change (E_STRICT message). Comments welcome - we'd like to sort this out before RC2... Zeev -- 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] Re: [RFC] ifsetor operator
How about,
if (isset($b)) {
$a = $b;
} else {
$a = 10;
}
Or is that a bit too revolutionary? :)
The problems with these operators is that the logic you want here is rarely
simple, and when you need to refactor, you need to change your construct
back to if{}else{} often introducing bugs. I see no reason to save ~ 10
keystrokes at the cost of readability.
-Sterling
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Friday, April 16, 2004 3:29 PM
To: Andi Gutmans
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Re: [RFC] ifsetor operator
Hello Andi,
Saturday, April 17, 2004, 12:17:49 AM, you wrote:
I don't want to spoil the party but:
a) I don't think we should add a new reserved word for this. I will try
and
think of an alternative which uses the existing vocabulary.
b) I would not want to add this before releasing PHP 5.0.0. I think we
should add it afterwards. We are not talking about a trivial patch here
and
I believe that we should be in a deep feature freeze especially when it
comes to the core.
c) As this is a new feature and people have done without it up to now, I
see no reason not to think of a good solution and wait with its
implementation.
I've already talked to Marcus about this in the past and he agreed not to
make anymore such patches. It's not the first time where such harmless
engine changes were discovered to have more widespread effects.
yes we should wait until after 5.0. I never meant this to be commited
to 5.0. But having the patch at hand gives the people to play with it.
And i guess enough people know how to change the keyword. Having said
this i hope we reach a consensus on either a good name or a new
operator.
marcus
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
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] Exceptions and Errors
The way to avoid exceptions in ctors is using empty exceptions and issuing E_WARNINGs or E_ERRORs from every method when the instance wansn't initialized already. If you think twise this is worse and also comes along with a speed penalty from the additional checks. Anyway if you don't want to deal with exceptions in ctors then you probably might not want to deal with oo at all. What marcus said. Also, I want the record to state that I'm not anti-exceptions. Neither, I guess is marcus. Both of us just prefer people use them appropriately, within well known mappings and usage cases for exceptions. Objects that have logic in a constructor throw exceptions - that's how it works. Same thing for overloads. These are not revolutionary concepts, but pretty standard OO paradigms. In the same vein, many things that aren't exceptions are handled by E_WARNING and E_ERROR. If someone who understands exceptions wants to use them in an acceptable (and by this, I mean a manner that won't make someone with experience with OO paradigms go what *is* he or she smoking?), then they should be free to do so in standard PHP extensions (imho). But as for converting such things, please, let's leave well-enough alone. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 14, 2004, at 10:36 PM, Thies C.Arntzen wrote: Am 14.04.2004 um 21:53 schrieb Marcus Boerger: Personally I'd much prefer a way of returning a value from a constructor, i.e. to be able to 'return null;' or a similar language construct so I could do 'if ($db = new SQLiteDatabase)' It would also mean that I would run into a 'calling method on a non-object' error if I don't check it (which is fine). In no language i know (c++, delphi, java as the popular ones) a ctor can return a value especially not it's own value. The problem is that when the ctor is called the object is already created. For most languages that means some memory has been allocated and for php overloaded objects like the SQLite class it also means that the memory has been initialized. Now in PHP 4 there was the ugly trick of setting $this=NULL. i'm sure ZE2 can be tricked to support return NULL from a constructor so that: $a = new bla(); if (! $a) ... if ctors are the only place that *cannot* life without exceptions it would be well worth *fixing* (yes, i said fix), as adding understanding exceptions to the list of pre-requisites for learning/using php would just be a poor decision looking at what made php as popular as it is today. the solution there would not be to fix ctor, but instead to use a factory, and have constructors without logic. the other case where one can't live without exceptions is when using overloads (solution: don't use overloads when you care about signaling error conditions). couldn't agree more btw, i think exceptions are cool, and certainly have their usages, but after reading the comments on this thread, i think we are about to hand out cocaine to children. hopefully one hit is enough ;-) either way its rc2, not much can be done now... -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 3:45 AM, Andi Gutmans wrote: At 12:41 PM 4/12/2004 +0200, Derick Rethans wrote: On Sun, 11 Apr 2004, John Coggeshall wrote: As a matter of consistency, I would like to suggest that for those extensions which have a OO/procedural syntax that the non-fatal errors generated by those extensions be thrown as Exceptions when called from an OO syntax. I have already committed such a change to Tidy, and I can't see any serious reason why such a change can't be implemented for internal classes. Feedback welcome. I think it's a stupid idea (actually OO is a stupid idea but that's something for another dicussion ;-): 1. In order to silently ignore failed queries you still have to put a stupid try..except block around it. 2. KISS: PHP is supposed to be SIMPLE; with all thos advanced OO stuff writing scripts for PHP starts becoming less and less easy. Sure, they are already using OO but that's just a notation. Some extensions are only OO, like DOM, but that doesn't mean that every Joe Average has any idea on what exceptions are. Please, kepe things simple. Don't force people. Derick, The fact that you have something personal against OOP doesn't mean it's not good. I think that functional context should continue to work as usual, but there's a big advantage to be able to catch problems with try/catch and not have to if() each internal function call separately (which you probably don't do :) I don't see a problem with OOP extensions throwing exceptions. I like OO (*), and I think warnings (non-fatal errors) as exceptions are a stupid idea. Does that count? ;-) Exceptions in languages like Java are used explicitly to catch fatal errors, not to catch basic errors. Converting warnings to exceptions would change the meaning of a warning from something which is nice for development, or logging purposes, but handled by your control flow, into an unrecoverable error. Errors as exceptions are a different story. I don't think that's a bad idea at all. But leave good alone, warnings shouldn't be exceptions. -Sterling (*) Though my like is most definitely due to stockholm syndrome, and excessive brainrape. Nonetheless. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 8:50 AM, George Schlossnagle wrote:
On Apr 12, 2004, at 11:42 AM, Sterling Hughes wrote:
I like OO (*), and I think warnings (non-fatal errors) as exceptions
are a stupid idea. Does that count? ;-)
Exceptions in languages like Java are used explicitly to catch fatal
errors, not to catch basic errors.
If 'languages like Java' means languages designed for OO, then this is
not true. Python throws exceptions for almost everything (KeyError,
for example). Even Java throws exceptions (java.sql.Exception) for
things like failed database connections which are warnings in PHP.
Languages like Java doesn't mean languages designed for OO, but
languages closely adhering to the OO model that PHP uses, Java being
the language that can most easily be called the parent of our current
model - although I do keep Python in this context even after your
KeyError example. The triviality of an exception doesn't make
exceptions themselves less severe. Whether or not a KeyError is
warranted as an E_ERROR, doesn't in fact change that a KeyError will
bump you firmly out of your control flow branch, and make you handle an
error condition. In PHP, E_WARNINGs may be misused (that's a
discussion for another time, i think); but the fact remains, they do
not end your current control flow branch. Changing E_WARNING's to
errors catchable by try{}catch{} will not only break BC, but will not
make sense for a large number of warnings currently thrown for PHP and
lead to the same inconsistencies.
John has gone ahead and committed a perfect example of where exceptions
just mess things up. In the tidy extension if you try and set an
unknown configuration option it throws an exception. This is not by
any stretch of the imagination an unrecoverable error, but rather a
simple failure. Yet, if you use tidy in a script, and it is not within
a try {} catch {} block your script execution will be terminated
because the configuration option could not be resolved. This is much
less than desirable and probably confusing for someone who doesn't
understand what an exception or why he should care.
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code i
have found this the opposite, however, even conceding that, PHP should
never do this. We have the concept of warnings, in our world an error
of this type does *not* terminate script execution. There are even
less severe usages of warnings throughout the PHP source code, and
there is no reason to convert them to exceptions. And if you don't,
you still have the same inconsistencies.
Java and Python both use a mix of philosophies, and indeed there is no
complete consensus. However, in my experience and the books that I've
read on the subject, the general thought is:
a) throw specific exceptions, not just a tidy_exception. PHP would
need to add a library of built-in exceptions to make this even remotely
useful. this is not feasible to do at RC1.6667
b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these cases
exceptions are used in leu of a better solution. This brings us back
to KeyError - KeyError is only thrown when overloading is used:
names = [barney, fred, wilma]
print names[betty] # throws an exception
print names.get(betty) # returns None
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try and
set an unknown configuration option it throws an exception. This is
not by any stretch of the imagination an unrecoverable error, but
rather a simple failure. Yet, if you use tidy in a script, and it is
not within a try {} catch {} block your script execution will be
terminated because the configuration option could not be resolved.
This is much less than desirable and probably confusing for someone
who doesn't understand what an exception or why he should care.
I don't have a strong feeling about this either way, but to play
devils advocate: You requested an option be set. That option could
not be set because it is impossible to set a non-existent option. How
do you know how someone wants to handle that error?
I assume they don't want their script to stop executing, their
transactions to be rolled back and a nasty error page shown :
Uncaught exception, could not set tabsize to 2 spaces
That could just be my crazy assumption though.
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code
i have found this the opposite, however, even conceding that, PHP
should never do this. We have the concept of warnings, in our world
an error of this type does *not* terminate script execution. There
are even less severe usages of warnings throughout the PHP source
code, and there is no reason to convert them to exceptions. And if
you don't, you still have the same inconsistencies.
The discussion was on OO code throwing exceptions. Given that there
is very little OO core code in php4, I don't see a widespread
conversion happening.
No, this discussion was on having exceptions thrown instead of
E_WARNINGs inside OO code. I'm pointing out that the two paradigms
don't map, and in other languages for many of the common errors given
by E_WARNINGs (but not all) simply wouldn't propagate as Exceptions.
Many cases it would, but in order for this idea to work, it needs to
map for the most part, which it doesn't.
Java and Python both use a mix of philosophies, and indeed there is
no complete consensus. However, in my experience and the books that
I've read on the subject, the general thought is:
a) throw specific exceptions, not just a tidy_exception. PHP would
need to add a library of built-in exceptions to make this even
remotely useful. this is not feasible to do at RC1.6667
But the beauty of OO Code is that all the tidy exceptions should
derive from TidyException. So life can continue as before, with no BC
break.
b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these
cases exceptions are used in leu of a better solution. This brings
us back to KeyError - KeyError is only thrown when overloading is
used:
names = [barney, fred, wilma]
print names[betty] # throws an exception
print names.get(betty) # returns None
You'll have a hard time defending Python as being restrained in it's
use of exceptions for warnings. It's a rather exception-happy
langugae and throws exceptions for the equivalent of most PHP
E_NOTICEs.
I haven't noticed that, and I've written quite a bit python code. It
does throw exceptions, no argument, but it depends largely on what you
are doing. The above example you've given is a place where an
exception is not out of place (although I don't particularly like one
being thrown), because you are using an overload. Different paradigm
than PHP arrays imho.
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
The key point that you're missing in all this is that _you_ don't know
what's a serious error and what's not. Only the developer knows. For
instance, the python smtplib can throw any number of exceptions based
on bad connect data or bad command responses. Is this a 'serious'
error? It depends. If sending a mail is an inconsequential part of
the app, maybe it's just an informational warning. It's also easy to
imagine it being a very critical, non-recoverable error. The severity
of the error lies entirely in the purview of the receiver.
Nothing sums this up for me better than KeyError, which is almost
never fatal in my applications but which constantly bites me in the
ass. Obviously your experiences may differ, which is really the whole
point.
Well, you can use get() now and be happy. :)
I'm not saying that exceptions should never be used. But, John
suggested As a matter of consistency, I would like to suggest that for
those extensions which have a OO/procedural syntax
Re: [PHP-DEV] Exceptions and Errors
On Apr 12, 2004, at 11:35 AM, George Schlossnagle wrote:
On Apr 12, 2004, at 2:14 PM, Sterling Hughes wrote:
John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try
and set an unknown configuration option it throws an exception.
This is not by any stretch of the imagination an unrecoverable
error, but rather a simple failure. Yet, if you use tidy in a
script, and it is not within a try {} catch {} block your script
execution will be terminated because the configuration option could
not be resolved. This is much less than desirable and probably
confusing for someone who doesn't understand what an exception or
why he should care.
I don't have a strong feeling about this either way, but to play
devils advocate: You requested an option be set. That option could
not be set because it is impossible to set a non-existent option.
How do you know how someone wants to handle that error?
I assume they don't want their script to stop executing, their
transactions to be rolled back and a nasty error page shown :
Uncaught exception, could not set tabsize to 2 spaces
That could just be my crazy assumption though.
It is. It's a hardocded portion of their app, and they made a
mistake. They may not care, but it's also possible that they do.
Assuming that they don't care enough to fix it seems equally crazy to
me.
Could be a version mismatch with tidy, and a newer library. They
develop there code, the option exists, and then someone with an older
version of the library doesn't have that. Whether or not i have 4
spaces or 2 in my output is rather inconsequential. Now you deploy
somewhere else and this explodes somewhere within a function and bumps
the script out of a critical execution context and refuses to work.
You might argue that python or java would throw an exception in
this case. For the majority of the java standard library and
python code i have found this the opposite, however, even conceding
that, PHP should never do this. We have the concept of warnings,
in our world an error of this type does *not* terminate script
execution. There are even less severe usages of warnings
throughout the PHP source code, and there is no reason to convert
them to exceptions. And if you don't, you still have the same
inconsistencies.
The discussion was on OO code throwing exceptions. Given that there
is very little OO core code in php4, I don't see a widespread
conversion happening.
No, this discussion was on having exceptions thrown instead of
E_WARNINGs inside OO code.
Rewind to the beginning of the discussion, the scope is not as broad
as you claim.
I did. fast-forward to the end of this message, that's exactly the
point john brought up.
The key point that you're missing in all this is that _you_ don't
know what's a serious error and what's not. Only the developer
knows. For instance, the python smtplib can throw any number of
exceptions based on bad connect data or bad command responses. Is
this a 'serious' error? It depends. If sending a mail is an
inconsequential part of the app, maybe it's just an informational
warning. It's also easy to imagine it being a very critical,
non-recoverable error. The severity of the error lies entirely in
the purview of the receiver.
Nothing sums this up for me better than KeyError, which is almost
never fatal in my applications but which constantly bites me in the
ass. Obviously your experiences may differ, which is really the
whole point.
Well, you can use get() now and be happy. :)
I could, I could also catch my exceptions. There are plenty of other
exceptions (casting errors, etc) that will irk me whenever I use
Python.
I've probably written a considerably large amount of python and I
haven't run into this rampant exception problem you talk about. Could
also be the reason why I like Python more than you... ;) It makes
sense that overloads would cause exceptions, as it does with type
casting exceptions - remember, python is a strongly typed language,
that type schiznizzle is important to them.
I'm not saying that exceptions should never be used. But, John
suggested As a matter of consistency, I would like to suggest that
for those extensions which have a OO/procedural syntax that the
non-fatal errors
generated by those extensions be thrown as Exceptions when called
from an OO syntax.
I'm undecided on whether it's advisable to throw E_WARNINGs as
exceptions. I think that all but engine-consistency-affecting
E_ERRORs should be exceptions, but that's a different discussion.
I would probably agree with you on E_ERRORs.
Either i'm missing the point or we are agreeing this shouldn't be so.
You were saying that not doing this was consistent with other
languages. I was saying that it was not.
Ok, then we disagree. I think its entirely inconsistent because the
two systems don't map to each other, and you get plenty
Re: [PHP-DEV] Segfault in HEAD
php5 shouldn't crash _at all_ within an infinite loop because we aren't
in one big execution loop.
-sterling
On Mar 30, 2004, at 11:27 PM, Derick Rethans wrote:
On Wed, 31 Mar 2004, Antony Dovgal wrote:
Hi all!
This small script:
?
class test {
var $a = false;
var $x = false;
function getA() {
if (!$this-x) { // yep, I know, it's infinite loop
PHP always crashes on infinite loops as you might be aware off. You'll
have to live with it.
regards,
Derick
--
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] Studlycaps and MySQLi
i'm with georg. then again, i never quite agreed with all your base is belonging to studlycaps, its a nice guideline for future code, but i don't see the the necessity of breaking old stuff, even if it hasn't been released yet, its been in the tree for well over a year. -sterling On Mar 23, 2004, at 2:58 AM, Georg Richter wrote: I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, beside changing c-code it's - changing documentation (english, german, spain and french) - changing all samples - changing testcases (incl. ~300 testscripts on my machine) - changing ~200 slides - changing 2 articles and 2 authors told me they don't have a chance to change it anymore in their books, they will be printed these days. you think it's not too much trouble? Georg -- 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] Studlycaps and MySQLi
On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote: --- Georg Richter [EMAIL PROTECTED] wrote: Sure, your book isn't ready yet. Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and attacking scripts is terrorism, thus georg's violation of a never agreed upon standard is in support of terrorism. thus php supports terrorism - i always thought that elephant was for smuggling nuclear material. wmd. all that because MySQLi's naming conventions violate the pleasure of some people on the list. Georg made his decision on this, and there are enough developers against it to backup his decision - can we please find another dead horse to beat? ;-) -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SimpleXML brokenness
ps issue there are no other basic issues. They are all bug fixes. Ok, if you are sure of that fine. But lets doublecheck with the authors of the main new components (sqlite, mysqli, simplexml) first and make sure they are all in sync. For example, Derek Ford's simplexml-related message to internals last week(*) worries me somewhat. He passed on what looks to be some basic brokeness in the extension which nobody has addressed so far. (*) http://news.php.net/article.php?group=php.internalsarticle=8660 The first one is a valid bug, the rest are just him not understanding how simpleXML handles namespaces (nor how xpath handles them for that matter), and should at some point be fixed. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 1:17 PM, Andi Gutmans wrote: At 11:12 AM 3/23/2004 -0800, Sterling Hughes wrote: On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote: --- Georg Richter [EMAIL PROTECTED] wrote: Sure, your book isn't ready yet. Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and attacking scripts is terrorism, thus georg's violation of a never agreed upon standard is in support of terrorism. thus php supports terrorism - i always thought that elephant was for smuggling nuclear material. wmd. all that because MySQLi's naming conventions violate the pleasure of some people on the list. Georg made his decision on this, and there are enough developers against it to backup his decision - can we please find another dead horse to beat? ;-) Sterling. We did come to a decision on this mailing list. In case you were asleep, well read the archives. I didn't say there was no decision - I said there was no agreement. And no, I don't think we should make decisions about PHP based on books. Zeev's book with PHP 5 support came out a few months ago and we broke half the things which he wrote about it. He'll need to create a new edition and I don't remember him even once complaining about it, because he did what was best for PHP. Well, if I honestly believed there were a practical advantage to this, I might feel differently. The changes that obsoleted Zeev's book prematurely were rather big and necessary, this is small and is for consistency. The fact is that consistency is important for PHP, wether it is studlyCaps or underscores. We just happened to have decided on studlyCaps, if you don't like it then you had your chance to voice this when it was discuss on [EMAIL PROTECTED] We can't continue to open issues every month or two. I agree. But given that its a rather weak argument either way (*), we should respect the extension maintainer's wishes. Georg spent a lot of time writing this extension, and he's expressed his wishes that the extension's OO API remain the same, and provided a valid technical reason, whether people agree with it or not. -Sterling (*) Ie, you have no practical advantage besides consistency. As you know, PHP will never be a consistent language, neither in approach nor in API. That doesn't mean imho one should add more inconsistency lightly, but it s not like MySQLi is violating the pristine mathematical equation that makes up the PHP programming language with dirty thoughts of underscores. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] curl-multi-info-read not functioning
curl_multi_info_read() is currently not working. I am planning on getting it working before php5, andi allowing (*), although I don't have any specific timeframe. You can use $still_running returned from curl_multi_exec (or perform, i can't remember what i called the php version) to spawn new connections if you like... -Sterling (*) It shouldn't hold up the release, but I think it should be allowed as a bug fix, since its currently there, just not implemented, and its important to the multi interface. On Mar 17, 2004, at 12:11 AM, [EMAIL PROTECTED] wrote: Hello! I am writing a php-cgi server, using curl-multi. It needs to start a bunch of curl 'threads', and steadily process the results of finished 'threads' and start new ones in their place. It seems to be working other than curl_multi_info_read() - this function does not return any data so I cannot see which curl threads have finished and are ready for processing. Looking at the curl.haxx.se curl-lib docs, it doesn't look too complicated (I'm not a C programmer though!) to implement, seeing as everything else is working. Perhaps I have missed something entirely. I assume it is the same problem as mentioned here:? http://marc.theaimsgroup.com/?l=php-devm=104791992407964w=2 Thank you in advance for any help or suggestions you can offer, or perhaps even an ETA on when this function might be finished so I can either wait, or skin the cat another way. Warm regards, Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML Casting to String
On Feb 29, 2004, at 12:03 PM, Andi Gutmans wrote:
I think there isn't a problem with echo as it will call the string
handler. However, in other cases it might be problematic.
Maybe a solution is to implement an equals function so that people
would do:
if ($doc-name-equals(Hello)) ?
I don't think we can support auto-string conversion transparently
everywhere in the engine. print and echo are special cases and we also
supported make_printable_zval() in PHP 4.
Well, the comparison operator should be overloaded if one of the
objects is an overloaded object imho.
My concern lies more with functions like utf8_encode() not properly
getting the contents of the XML string - but I haven't looked into it
too much - I'll try and get some hacking done on the cruise.
-Sterling
Andi
At 17:58 27/02/2004 -0500, Sterling Hughes wrote:
BP_VAR_R just tells the engine not to through a warning when the
property doesn't exist. The problem is that we need to handle cases
like:
$doc = simplexml_load_string('rootname attr=foobar/name');
echo $doc-name[attr];
echo $doc-name;
Both would be covered by BP_VAR_R AFAIR. What if the string is empty
and they want a subnode, ie:
?php
$a = $b-foo;
echo $a-john;
?
-Sterling
On Feb 27, 2004, at 5:33 PM, Andi Gutmans wrote:
Basically SimpleXML should know if the property is being fetched for
read or not (type is passed such as BP_VAR_R or BP_VAR_W). If the
case is BP_VAR_R (read access) then SimpleXML should return the
value and not an object.
There might be some places in the engine which aren't covered but
it's best for the SimpleXML authors to check this out first because
in general it should work.
At 13:37 27/02/2004 -0500, Adam Maccabee Trachtenberg wrote:
I know we discussed this already, but after seeing a couple of bug
reports about SimpleXML, I'm worried our decision only makes sense
to
us and not to regular users. :)
Specifically, since elements and attibutes look like strings, people
expect them to act like strings. But since they're not objects
instead
of strings, they're completely buffled as how to handle them.
Here are two examples that have come through the bug report system
in
the last day:
$sxe = simplexml_load_string('root a=123 /');
if ($sxe['a'] == '123') {
// do something
}
And:
$xml = simplexml_load_string(/* some valid XML string that I'm not
going to cut and paste here */);
foreach($xml-user as $user){
if (utf8_decode($user-login) == $login
utf8_decode($user-password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
In the first example, we're comparing an object with a string. Even
though $sxe['a']-__toString() == 'a', the comparison fails. (Well,
you
can't actually do that, but you know what I mean.)
In the second example, utf8_decode() expects a string and not an
object and we again we don't autoconvert.
The problems can be solved by explicitly casting the object to a
string, but since you rarely need to cast elsewhere in PHP, I don't
think anyone thinks of it as a necessary step.
Originally, I proposed that PHP autoconvert an object to a string
whenever the object has a __toString() and it's necessary to treat
the
variable as a string. In the first example, since we're comparing an
object to a string, we would cast down the object to enable the
comparison. This would work just like 1 == '1'. In the second case,
since the function expects a string, we'd also do the cast.
However, Andi (and others) raised some valid issues about edge cases
and other potential engine problems.
Is there anything we can do to help out people so that SimpleXML
works
as they expect, but doesn't have the potential to unleash hell on
PHP
and the bug system?
Maybe it makes sense to have SimpleXML leaf nodes return as strings
instead of SimpleXML objects? Or does this merely substitute one set
of problems for another? (E.g. this breaks iteratation, what happens
when there's multiple leaves, etc.)
I don't know what the right answer is, but I feel that the current
solution isn't perfect. It may end up to be the best possible
method,
but I'm not yet convinced it is.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML Casting to String
On Feb 29, 2004, at 12:31 PM, Andi Gutmans wrote: At 12:20 29/02/2004 -0500, Sterling Hughes wrote: On Feb 29, 2004, at 12:03 PM, Andi Gutmans wrote: I think there isn't a problem with echo as it will call the string handler. However, in other cases it might be problematic. Maybe a solution is to implement an equals function so that people would do: if ($doc-name-equals(Hello)) ? I don't think we can support auto-string conversion transparently everywhere in the engine. print and echo are special cases and we also supported make_printable_zval() in PHP 4. Well, the comparison operator should be overloaded if one of the objects is an overloaded object imho. The problem is that user-land overloading can't be supported. C extensions might be able to be supported but I don't think it's a good idea to start hacking this into PHP. It wouldn't end at the comparison operator but people would want it to work everywhere. I don't want user overloading - I've been consistently against that for objects of all types. I want it internally cause its important to be able to overload all operations for something like SimpleXML to properly work. The same applies to ext/mono (has the same issues as java, but even more due to field and property distinctions.) My concern lies more with functions like utf8_encode() not properly getting the contents of the XML string - but I haven't looked into it too much - I'll try and get some hacking done on the cruise. The way to do it today is to do a cast to (string) although I admit it's not a beautiful solution. Right - what I don't understand is that why doesn't convert_to_string_ex() handle this? -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML Casting to String
BP_VAR_R just tells the engine not to through a warning when the
property doesn't exist. The problem is that we need to handle cases
like:
$doc = simplexml_load_string('rootname attr=foobar/name');
echo $doc-name[attr];
echo $doc-name;
Both would be covered by BP_VAR_R AFAIR. What if the string is empty
and they want a subnode, ie:
?php
$a = $b-foo;
echo $a-john;
?
-Sterling
On Feb 27, 2004, at 5:33 PM, Andi Gutmans wrote:
Basically SimpleXML should know if the property is being fetched for
read or not (type is passed such as BP_VAR_R or BP_VAR_W). If the case
is BP_VAR_R (read access) then SimpleXML should return the value and
not an object.
There might be some places in the engine which aren't covered but it's
best for the SimpleXML authors to check this out first because in
general it should work.
At 13:37 27/02/2004 -0500, Adam Maccabee Trachtenberg wrote:
I know we discussed this already, but after seeing a couple of bug
reports about SimpleXML, I'm worried our decision only makes sense to
us and not to regular users. :)
Specifically, since elements and attibutes look like strings, people
expect them to act like strings. But since they're not objects instead
of strings, they're completely buffled as how to handle them.
Here are two examples that have come through the bug report system in
the last day:
$sxe = simplexml_load_string('root a=123 /');
if ($sxe['a'] == '123') {
// do something
}
And:
$xml = simplexml_load_string(/* some valid XML string that I'm not
going to cut and paste here */);
foreach($xml-user as $user){
if (utf8_decode($user-login) == $login
utf8_decode($user-password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
In the first example, we're comparing an object with a string. Even
though $sxe['a']-__toString() == 'a', the comparison fails. (Well,
you
can't actually do that, but you know what I mean.)
In the second example, utf8_decode() expects a string and not an
object and we again we don't autoconvert.
The problems can be solved by explicitly casting the object to a
string, but since you rarely need to cast elsewhere in PHP, I don't
think anyone thinks of it as a necessary step.
Originally, I proposed that PHP autoconvert an object to a string
whenever the object has a __toString() and it's necessary to treat the
variable as a string. In the first example, since we're comparing an
object to a string, we would cast down the object to enable the
comparison. This would work just like 1 == '1'. In the second case,
since the function expects a string, we'd also do the cast.
However, Andi (and others) raised some valid issues about edge cases
and other potential engine problems.
Is there anything we can do to help out people so that SimpleXML works
as they expect, but doesn't have the potential to unleash hell on PHP
and the bug system?
Maybe it makes sense to have SimpleXML leaf nodes return as strings
instead of SimpleXML objects? Or does this merely substitute one set
of problems for another? (E.g. this breaks iteratation, what happens
when there's multiple leaves, etc.)
I don't know what the right answer is, but I feel that the current
solution isn't perfect. It may end up to be the best possible method,
but I'm not yet convinced it is.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_operators.c
George Schlossnagle wrote: On Feb 22, 2004, at 5:15 PM, Derick Rethans wrote: On Sun, 22 Feb 2004 [EMAIL PROTECTED] wrote: It's generating an idivl, which gives you an exception if the (signed) result is too large (a.k.a. integer overflow). Did you notice your compiler warning this decimal constant is unsigned only in ISO C90? ;) Yes I did +2147483648 is: 1000 . -2147483648 is too large to be represented by a signed integer (as it would be ~(+2147483648) + 1, No, -2147483648 is the lower bound and 2147483647 is the upper bound for signed integers. -2147483648 = 1000 2147483647 = 0111 it still doesn't explain the FPE here. What does explain it is that -2147483648 / -1 = 2147483648 which is too large. Doesn't the rval in modulus need to be unsigned? No, it's implementation-defined though if one of the operands is negative, IIRC. no, -22 % 7. They truncate towards 0. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_operators.c
At 00:23 23/02/2004 +0100, Edin Kadribasic wrote: On Sunday, Feb 22, 2004, at 23:57 Europe/Copenhagen, Andi Gutmans wrote: Can someone check this on a non-intel CPU with a 32bit int? gcc 3.3 produces the same warning (this decimal constant is unsigned only in ISO C90) on PowerPC G4. The code produces no floating point exceptions though. c at the end of the execution is -2147483648. G4 is 64bit right? G5 is. G4 is 32 bit afaik. -Sterling Andi -- 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] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote: Andi's point, I believe, is that otherwise we'll need to add a finally keyword to make sure some random extension doesn't throw some random undocumented exception that you could miss. And I agree with him. It just seems to make everything more clean. And my point is that I may want to create an exception (sterling's 'InternalException', for example), that I do not want you catching unless you specifically check for it. Moving this discussion to [EMAIL PROTECTED] Right. Exception heirarchies are nice and all, but sometimes you want exceptions to leak through, or be explicitly caught. In-fact, I've never encountered a case where this isn't what I want, maybe in a small 20 line example, but in large scripts I've almost always designed for leakage. I contend that what you want in this case is a Throwable interface or none at all. Java provides just this differentiation btw. -Sterling -- Reductionists like to take things apart. The rest of us are just trying to get it together. - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
The reasoning is that it allows users to do a catch-all (which otherwise
we'd add to the language syntax). It also adds cleanliness to the Exception
hierarchy and allows PHP code to interact with PHP code which isn't written
by the developer knowing that there's a common interface (such as
getMessage()) which the exception always adheres to. That improves the
ability of exception handling especially debugging and logging
significantly.
That second part is a Throwable interface, not a base class (and
Exception isn't even an ABC.)
i.e.
try {
...// Main code which calls PEAR, SOAP, Smart, external stuff and
so on
} catch (Exception $e) {
print Damn something is really wrong here\n;
print $e-getMessage();
}
I get the concept, that's the reason Exception was added. But its meant
to be a voluntary thing (I believe this has been discussed before btw),
a standard class that gives users something to build upon, should they
want to. I think an all-your-base-is-belonging-to-Exception is the
wrong way to go. If you really want a catch-all or some type of
consistency the way to go is either a Throwable interface (which makes
it more of a pain to write exceptions) or the generic:
catch ($e) {
}
syntax.
_Sterling
--
Reductionists like to take things apart. The rest of us are
just trying to get it together.
- Larry Wall, Programming Perl, 3rd Edition
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC1
Hey, (a) Failure return value of FETCH_RESOURCE and the default return value - should we change it to be FALSE? Today it's NULL, which is inconsistent with most of the functions in PHP which return FALSE on failure. The downside is that changing it may break scripts that check the return value with === or !== Should be NULL, not a boolean FALSE, IMNHO (*). False indicates the given operation was not succesful but everything supplied was in valid boundaries. At least that's how I see it, but PHP is across the board inconsistent in this area, so I see no reason to break BC. (b) Default inclusion of the SOAP extension +1 -Sterling (*) In My Never Humble Opinion -- Reductionists like to take things apart. The rest of us are just trying to get it together. - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC1
http://marc.theaimsgroup.com/?l=php-devm=107367078904900w=2 The main problem with a too early beta/rc release is we (well you ;) ) have to be sure that the ZE2 apis works the way it should. And not only from the php side. For the good all php extensions that are not bundled with the php releases (and I'm not thinking only about pecl :) ). Yeah we looked at it today. It seems to be a bit of a problem. The correct way of doing this is to nuke get_properties() and only use set/get overloading handlers. However, it would mean that extension writers who want foreach() to work would have to implement iterator interface. I'm not quite sure how to go on this one. IMO get_properties() should not be used with non-PHP objects. how would one handle var_dump($obj) then? -sterling Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reductionists like to take things apart. The rest of us are just trying to get it together. - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warnings in include files suddenly treated as fatal
+ zend_file_handle file_handle;
+ zend_bool can_open =
zend_stream_open(inc_filename-value.str.val, file_handle TSRMLS_CC);
+ zend_file_handle_dtor(file_handle);
+
wouldn't a stat be better suited here?
-sterling
+ /* file open succeeded but still no op-array,
likely parse error */
+ if (can_open == SUCCESS) {
+fatal_error:
+ zend_error(E_ERROR, Parse error
inside included file.);
+ }
+ }
}
break;
case ZEND_EVAL: {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Reductionists like to take things apart. The rest of us are
just trying to get it together.
- Larry Wall, Programming Perl, 3rd Edition
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dollars and sense.
Andrei Zmievski wrote: On Tue, 27 Jan 2004, Christian Schneider wrote: Why do you say this? I prefer foo $bar blah. Because it's faster. Ok, that's interesting but irrelevant for most of my code. Readability is a higher priority in most cases. Thanks for pointing this out, If you use a compiler cache like apc, this performance hit will be totally removed as the optimizer compiles both representations into the same format. -sterling -- Reductionists like to take things apart. The rest of us are just trying to get it together. - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString() with strval() and settype()
Adam Maccabee Trachtenberg wrote: Anyone else care to chime in here? If we're really moving to RC1, I So to summarize that'd be echo, print, (string), strval() and settype() using __toString(), right? Sounds +1 to me. settype() is a tricky one - i think it should fail for objects, as it could cause destruction of the underlying object, as we don't have magic (in the perl internals meaning of the world). -sterling -- Reductionists like to take things apart. The rest of us are just trying to get it together. - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: Moving Forward
Hello Adam, Thanks for moving backward. Since iterating is now worthless i am all for removing it completley. I mean it isn't even in the spirit of the extension. I will sleep over this tonight and probably remove the work of another full week too. Just because it is too complex and doesn't fit in the current scheme of SimpleXMl. Marcus - why remove iterators? Just because we remove their user level API's, I see no reason to remove the internal implementations? -Sterling -- Reductionists like to take things apart. The rest of us are just trying to get it together. - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Leak Script
Looks like a circular reference to me. It's supposed to leak :)
Yep - but shouldn't object destruction be forced before the memory
manager cleans it up. The example could rather be put as:
?php
class InstanceContainer {
public $value;
function __construct() {
$this-value = new GenericObject($this);
}
function __destruct() {
print Called\n;
}
}
class GenericObject {
public $internal;
function __construct($instance) {
$this-internal = $instance;
}
}
$o = new InstanceContainer();
?
As you can predict, __destruct() won't be called. Shouldn't objects be
unmercifully cleaned up before we rely on the memory manager to burn the leftovers?
-Sterling
Andi
At 06:42 PM 1/13/2004 -0500, Sterling Hughes wrote:
Hey,
The attached script gives 10 leaks when PHP5 is compiled with
--enable-debug. These problems are also related to Bug #26765, I'll be
taking a look at it, unless someone knows the cause already.
The leaks caused when running it are:
/home/sterling/work/php/php-src/Zend/zend_execute.c(2840) : Freeing
0x40162A30 (16 bytes), script=t.php
/home/sterling/work/php/php-src/Zend/zend_hash.c(236) : Freeing
0x401629CC (44 bytes), script=t.php
Last leak repeated 1 time
/home/sterling/work/php/php-src/Zend/zend_execute.c(3094) : Freeing
0x40162968 (44 bytes), script=t.php
/home/sterling/work/php/php-src/Zend/zend_API.c(720) : Actual location
(location was relayed)
Last leak repeated 1 time
/home/sterling/work/php/php-src/Zend/zend_objects.c(88) : Freeing
0x40162924 (12 bytes), script=t.php
Last leak repeated 1 time
/home/sterling/work/php/php-src/Zend/zend_execute.c(3093) : Freeing
0x401628E0 (16 bytes), script=t.php
/home/sterling/work/php/php-src/Zend/zend_API.c(721) : Freeing
0x4016272C (32 bytes), script=t.php
/home/sterling/work/php/php-src/Zend/zend_hash.c(157) : Actual location
(location was relayed)
Last leak repeated 1 time
=== Total 10 memory leaks detected ===
-Sterling
--
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] SimpleXML: Moving Forward
From: Adam Maccabee Trachtenberg
1) SimpleXML creates PHP data structures from XML documents. It only
handles XML elements, attributes, and text nodes. The syntax for
accessing the text node children of an element is akin to object
properties ($foo-bar); the syntax of accessing attributes is akin
to array elements ($foo['bar']).
This goes back to my question on what is the goal of SimpleXML?
Is it supposed to be an easy api to be able to access any xml document or
only not complex ones?
Attributes are handled associative arrays, so given an element with 2
attributes with the same name, but in different namespaces, it wont work:
foo a:bar=x b:bar=y
Attributes should be ns qualified within the array:
$node-foo['a:bar']
This would respect namespaces registered by register_ns()
xpath wont help here either as xsearch returns an array of sxe objects with
the attribute nodes (which causes some additional problems).
Its fine if this would have to be handled in dom, but to me the question
really has never been fully answered.
See also example under the xpath comments for elements containing mixed text
and element nodes.
4) XPath and validation functions will be available in SimpleXML, but
we will not try to code generic extensions that work with both
SimpleXML and DOM if for no other reason than this is not
guaranteed to be simple. (e.g. SimpleXML must remove from XPath
results nodes that aren't elements, attributes, and text nodes.)
I've decided (unless some more people pipe up support for removing
children() and attributes() its current 2-3 against) to leave children()
and attributes(), but remove the other methods. Things like schema
validation and xpath queries will become procedural.
return types need to be standardized. attributes or getAttributes returns
name/value array, while the current xsearch will return array of a sxe
objects of the attribute node (which stated before is bad in the current
state of simplexml).
xsearch will become a procedure, simplexml_query($node, 'expression', $matches);
Also, consider the following (an element contains a mix of text and element
nodes):
$foo = simplexml_load_string('fooabfoo2test/foo2cd/foo');
$ns = $foo-xsearch('child::text()');
foreach ($ns as $node) {
print Node Value: .$node.\n;
}
Output:
Node Value: abcd
Node Value: abcd
One would expect:
Node Value: ab
Node Value: cd
Is the output correct, should something like this not be handled via
simpleXML, or is the xsearch incorrect when it returns the parent of a text
node?
Yep, this is the intended behaviour of simplexml. The
simplexml_save_string() function will allow you to get the entire node
contents (including tags). As for processing text childs separately,
use DOM. It can interpret the same results of an XPath query in the
manner you desire.
Your initial point concerning what SimpleXML is was a good start, but it
still doesn't define the boundaries of what it is meant to handle. When do
you tell someone that what they are doing should not be done in SimpleXML?
This is where I get lost with the API as I don't really know its intended
limitations.
Well, this is the purpose in finalizing the underlying API. The answer
to that question is simple, if it doesn't do what you want, then
SimpleXML is not what you want. This is part of the reason I want to
finalize on no methods. If you need methods, use DOM, the two are
totally interoperable, requiring zero document copies to work with both.
You can process a DOM object then load it into simplexml for the final
processing. Conversely you can take a simplexml object and load it into
DOM for complex processing.
I'm certainly stopping the API at children() and attributes(),
regardless, as anything else is just silly, and it seems that only
people felt strongly about these two functions. (*)
Schema validation and XPath searching will become functions in
SimpleXML space.
-Sterling
(*) Btw, getChildren() is currently broken from a userspace perspective
as it is mainly implemented for the SPL recursive iterator. This will
have to change, simplexml will not add userspace APIs for other
extensions.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] fix for bug #26696
Hey,
I've attached a fix for an engine level crash in switch() when it is
used with string offsets. This eliminates a double-free and valgrind
reports that no new leaks have been introduced.
-Sterling
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.582
diff -u -r1.582 zend_execute.c
--- zend_execute.c 8 Jan 2004 17:31:47 - 1.582
+++ zend_execute.c 13 Jan 2004 19:58:18 -
@@ -194,13 +194,7 @@
{
switch (opline-op1.op_type) {
case IS_VAR:
- if (!T(opline-op1.u.var).var.ptr_ptr) {
- temp_variable *T = T(opline-op1.u.var);
- /* perform the equivalent of equivalent of a
-* quick silent get_zval_ptr, and FREE_OP
-*/
- PZVAL_UNLOCK(T-var.str_offset.str);
- } else {
+ if (T(opline-op1.u.var).var.ptr_ptr) {
zval_ptr_dtor(T(opline-op1.u.var).var.ptr);
if (opline-extended_value) { /* foreach() free */
zval_ptr_dtor(T(opline-op1.u.var).var.ptr);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fix for bug #26696
Are you sure this is OK? It seems strange that string offsets don't need
any unlocking. It might mean we have a problem someplace else and that
you're fixing the cause and not the source of the problem (although I
haven't had time to dig deep).
In general, consider the following code:
$a = Foo;
switch ($a[0]) {
case 'b':
break;
case 'c':
break;
case 'F':
break;
}
Are you sure this doesn't leak now? I don't have time to look at it now,
but if you are absolutely convinced the patch makes sense I'll try and step
through it with a debugger as soon as I have some free time.
No, I was wrong. I hate the memory manager, it cleans up my leaks for
me - makes it impossible to rely on valgrind. ;) Anyway to turn that off?
I'm playing around some more now.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fix for bug #26696
Ok, attached is a diff that properly fixes the problem.
-Sterling
At 04:06 PM 1/13/2004 -0500, Sterling Hughes wrote:
Are you sure this is OK? It seems strange that string offsets don't need
any unlocking. It might mean we have a problem someplace else and that
you're fixing the cause and not the source of the problem (although I
haven't had time to dig deep).
In general, consider the following code:
$a = Foo;
switch ($a[0]) {
case 'b':
break;
case 'c':
break;
case 'F':
break;
}
Are you sure this doesn't leak now? I don't have time to look at it now,
but if you are absolutely convinced the patch makes sense I'll try and
step
through it with a debugger as soon as I have some free time.
No, I was wrong. I hate the memory manager, it cleans up my leaks for
me - makes it impossible to rely on valgrind. ;) Anyway to turn that off?
If you're running in --enable-debug it should be telling you about the
leaks.
I'm playing around some more now.
OK thanks.
Andi
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.583
diff -u -r1.583 zend_execute.c
--- zend_execute.c 9 Jan 2004 13:52:19 - 1.583
+++ zend_execute.c 13 Jan 2004 22:24:18 -
@@ -195,11 +195,10 @@
switch (opline-op1.op_type) {
case IS_VAR:
if (!T(opline-op1.u.var).var.ptr_ptr) {
- temp_variable *T = T(opline-op1.u.var);
/* perform the equivalent of equivalent of a
* quick silent get_zval_ptr, and FREE_OP
*/
- PZVAL_UNLOCK(T-var.str_offset.str);
+ PZVAL_UNLOCK(*Ts-var.ptr_ptr);
} else {
zval_ptr_dtor(T(opline-op1.u.var).var.ptr);
if (opline-extended_value) { /* foreach() free */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
The idea of simplexml is to return the nodes of *that particular node*,
not all of the subsequent nodes, therefore (as mentioned before), the
current behaviour is correct.
The current behaviour of to_xml_string() is however, wrong. It should
return the xml content from the current node as adam points out. The
current behaviour of to_xml_file() is appropriate, but inconsistent
(as adam's patch points out). to_xml_string() and to_xml_file() are
both rather confusing names as well.
My thoughts on this are as follows, some are directly related to the topic,
some are related to simplexml's original design and current functionality.
SimpleXML was originally designed to provide a direct mapping between a
XML document and a data structure, through access to the properties and
attributes and *only* the properties and attributes.
Much of the current code in SimpleXML is due to immaturities in either
Zend or the LibXML interface at the time I was writing SimpleXML. I wanted
to have cool things to show at conferences, plus other people wanted to see
what was possible with simplexml, so features started to creep in. xsearch()
and schema validation were the first added, then came other methods like
hasChildren() and getChildren() (when a simple xpath query /child::node() can
tell you this)
Most of simplexml's methods are either redundant, or redundant based
upon redundancy (hasChildren(), getChildren(), attributes(), count()).
Each of these methods are actually a very simple, very optimized xpath
expression.
I know its late in the process, but its also the last chance for an API
change, or rather adjustment, the change was always meant to happen, I
just got a bit too busy to do it. So here are my thoughts on an API:
1) Remove all methods from simplexml. They were never supposed to be
permanent parts of the API.
2) Add three new functions:
simplexml_register_ns(simplexml_element $e, string name, string value)
simplexml_save_file(simplexml_element $e, string filename)
simplexml_save_string(simplexml_element $e, string $data)
The last two functions will work as Adam mentions, saving from the current
node. The copy of the data can be omitted, since libxml2 should be
using our memory management functions.
3) For the next version of PHP, PHP5.1 add a new xpath extension which
provides a generic query interface to XML objects. This would be
something like:
if (xpath_query('/child::node()', $node, $results)) {
}
As xpath is very much akin to regular expressions for XML. This is a
more elegant solution than the current DOM api for XML which would
require a casting into a dom object, then a domxpath object, then a
simplexml object. (*)
I realize this is a rather drastic change so late in the game.
But this was the original intent of the extension, and indeed is more consistent
than the current solution. I also think that the current direction with
these helper methods is wrong. They don't help, they just muddy the
waters up.
As a further note. SimpleXML is not currently ready for production
usage, I've been going through it over the past couple of days, and it
needs some work (especially since some bugs in Zend currently make
things impossible). I'm loth to do a deep grotting of the extension
(even though its easier now that we have a test suite), but quite a bit can be won
in terms of consistency and stability (code path) - I think this should
be a part of that work, and I would be willing to make the necessary
changes.
Anyhow, these are my thoughts on the matter.
-Sterling
(*) The DOM api could be left for PHP5.0, but shouldn't be the only
option. The xpath extension would actually be quite trivial, and could be
done quickly. Most of the code is already in DOM and SimpleXML, it would just
be moving it to a separate extension.
The patch you propose is exactly the type of functionality that I was
hoping to find.
Thank you,
Blake Schwendiman
-Original Message-
From: Adam Maccabee Trachtenberg [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 11, 2004 11:54 PM
To: Andi Gutmans
Cc: Marcus Boerger; Blake Schwendiman; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] SimpleXML and Default Cast To String
On Thu, 8 Jan 2004, Andi Gutmans wrote:
At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
So i'd say let us add a method for returning the complete content.
Adam
could you do that?
That wouldn't be too difficult (although I am busy for the next day
or
two). However, as much as I loathe toggles, I'm wondering if it
wouldn't be better to make this an object-wide setting. My thought
are
that on an object-by-object basis, you either always want tags or
never want them.
[snip]
I'd keep things the way they are today.
I've spent a little time looking at the code and I realize I
misunderstood what was going on. Right now, given this XML:
foo
AbB/bC
/foo
Doing a print $xml; prints AC.
Re: [PHP-DEV] How to add new functions to SimpleXML extention
Funny, i writing a response to adam's message while this got to the
mailing list. Take a look at my response to adam, as it covers this
patch as well.
-Sterling
Hi!
I'm just playing with simplexml and wonder if two new functions of the
simplexml_element object would be usefull: getName() and getParent(). I'm
interesting in adding them to the extention, if possible. What should I do
for this? (I also think that it may be in FAQ, but I did not find that info
with my search skills).
Basically, this is my first experiment with PHP Extensions. I may be wrong
with my code, but tests pass is ok
---
Thank you for time,
Alexander Netkachev
http://devlink.narod.ru/
Code for getName function:
/* {{{ getName()
*/
SXE_METHOD(getName)
{
char *name;
xmlNodePtr node; // current node
php_sxe_object *sxe = php_sxe_fetch_object(getThis() TSRMLS_CC);
GET_NODE(sxe, node);
if (node (name = (char *)(node-name))) {
RETURN_STRING(name, 1);
}
RETURN_EMPTY_STRING();
}
/* }}} */
/* {{{ getParent()
*/
SXE_METHOD(getParent)
{
xmlNodePtr node; // current node
xmlNodePtr pNode; // node-parent
php_sxe_object *sxe = php_sxe_fetch_object(getThis() TSRMLS_CC);
GET_NODE(sxe, node);
if (node (pNode = node-parent)) {
_node_as_zval(sxe, pNode, return_value TSRMLS_CC);
return;
}
RETURN_NULL();
}
/* }}} */
File: ext/simplexml/tests/019.phpt
--TEST--
SimpleXML: Test getParent() and getName() functions
--SKIPIF--
?php if (!extension_loaded(simplexml)) print skip; ?
--FILE--
?php
$doc = simplexml_load_string('htmlbody/body/html');
var_dump(trim($doc-body-getParent()-getName()));
echo '--done--';
?
--EXPECT--
string(4) html
--done--
--
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] SimpleXML and Default Cast To String
Much of the current code in SimpleXML is due to immaturities in either
Zend or the LibXML interface at the time I was writing SimpleXML. I wanted
to have cool things to show at conferences, plus other people wanted to see
what was possible with simplexml, so features started to creep in. xsearch()
and schema validation were the first added, then came other methods like
hasChildren() and getChildren() (when a simple xpath query /child::node() can
tell you this)
Most of simplexml's methods are either redundant, or redundant based
upon redundancy (hasChildren(), getChildren(), attributes(), count()).
Each of these methods are actually a very simple, very optimized xpath
expression.
The only SimpleXML methods (besides the ones for getting data in and
out of the object) I care about are xquery and validation. I've never
used (or really even known about) the other ones and don't see a need
for them.
Ahh, i missed validation. See notes below.
I know its late in the process, but its also the last chance for an API
change, or rather adjustment, the change was always meant to happen, I
just got a bit too busy to do it. So here are my thoughts on an API:
1) Remove all methods from simplexml. They were never supposed to be
permanent parts of the API.
2) Add three new functions:
simplexml_register_ns(simplexml_element $e, string name, string value)
simplexml_save_file(simplexml_element $e, string filename)
simplexml_save_string(simplexml_element $e, string $data)
simplexml_save_dom(simplexml_element $e, domDocument $dom)
dom has a function to do this.
The last two functions will work as Adam mentions, saving from the current
node. The copy of the data can be omitted, since libxml2 should be
using our memory management functions.
I prefer it when functions that create strings and objects return
them, so I vote for:
string simplexml_save_string(simplexml_element $e)
I want to be able to do:
if ($data = simplexml_save_string($e)) {
print $data;
}
The preg() functions have an API like yours and I hate it. They always
require an extra step to extract the data from the $results array.
Yeah, I had it the other way for consistency but would be willing to
yield to popular opinion. ;)
3) For the next version of PHP, PHP5.1 add a new xpath extension which
provides a generic query interface to XML objects. This would be
something like:
if (xpath_query('/child::node()', $node, $results)) {
}
As xpath is very much akin to regular expressions for XML. This is a
more elegant solution than the current DOM api for XML which would
require a casting into a dom object, then a domxpath object, then a
simplexml object. (*)
If you're going to blow things up, I would much prefer that you
somehow manage to get this into PHP 5.0. Right now, AFAIK, xsearch()
is the only way to do any XML Namespace querying and casting things
through that chain of objects causes me to barf more than even XML
Namespaces. :)
And, as you say below, this code already exists in xsearch(), it's
just a matter of figuring out where to put it. Why not just do:
array simplexml_xpath_query(simplexml_element $e, string $xpath)
This allows for:
foreach(simplexml_xpath_query($node, '//foo') as $foo) {
print $foo;
}
DOM is explicitly an OO API. You seem to want SimpleXML to be
procedural. (I must admit here that I actually like the SimpleXML OO
API.)
Therefore, I think it makes sense for domXPath to continue to be an OO
solution for DOM and just build in an procedural XPath function into
the SimpleXML extension.
Well, that's certainly an option. Whilst I prefer to have standard
api's for this across PHP, I'm not terribly adamant about this
particular issue. The main idea would be to have a standard schema
interface and a standard xpath interface that would work perfectly with
both DOM and SimpleXML objects, in fact the two would be interchangeable
because they are both libxml objects underneath. I think that would be
sexy, but I'm willing to give it up.
The problem with simplexml_xpath_query returning an array is that how do
you signify failure and an empty set. In order for you to have code
that uses foreach() it would need to return an empty set on failure in
order to avoid warnings. The reason that there is an extra argument (as
with PCRE) is for the failure condition.
I realize this is a rather drastic change so late in the game.
But this was the original intent of the extension, and indeed is more consistent
than the current solution. I also think that the current direction with
these helper methods is wrong. They don't help, they just muddy the
waters up.
As a further note. SimpleXML is not currently ready for production
usage, I've been going through it over the past couple of days, and it
needs some work (especially
Re: [PHP-DEV] SimpleXML and Default Cast To String
In theory, I like the idea of a unified set of XML helper extensions, but DOM's so big and ugly that I don't know if it plays well with others in the sandbox. We are not consistent! Not in any way. DOM uses studlyCaps and SimpleXML uses underscores for its method names. Speaking of consistency we should probably discuss whether we want to change all methods of SimpleXML to studlyCaps (we cannot hcnage the DOM method names). Until RC1 i guess we can do such changes if we all agree and see it to be important. Haven't you been reading the thread - there are no more methods! :) -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
My thoughts on this are as follows, some are directly related to the
topic,
some are related to simplexml's original design and current functionality.
SimpleXML was originally designed to provide a direct mapping between a
XML document and a data structure, through access to the properties and
attributes and *only* the properties and attributes.
What's the ultimate goal for simpleXML? I have been hesitant from ever
touching this extension as what I thought it was intended to do, seems
simplistic to where it acutally (is going/went?). Correct me if I'm wrong,
but when it started I thought simpleXML's intent was to handle XML
structures containing only elements and attributes (or at least ignoring
everything else). The structure could never contain an element which had an
attribute named the same as one of its child elements (otherwise you would
need to be adding functionality as well to distinguish when you work with
the attribute or element). Also, elements would contain either text or
children elements but not both.
Now that Zend can differentiate between array accessors and property accesses,
attributes and nodes should be separated.
As for the second, yes, that's true, although xpath expressions could
achieve this.
Not sure about how adding one of these types was to be handled as you would
need a way to determine wether you are adding an element or an attribute.
As I said, this may be a simplistic view, but as it evolved, I just dont
understand the concept behind simpleXML anymore.
3) For the next version of PHP, PHP5.1 add a new xpath extension which
provides a generic query interface to XML objects. This would be
something like:
if (xpath_query('/child::node()', $node, $results)) {
}
As xpath is very much akin to regular expressions for XML. This is a
more elegant solution than the current DOM api for XML which would
require a casting into a dom object, then a domxpath object, then a
simplexml object. (*)
There is a problem here however as simpleXML can only handle Element,
Attribute and Text nodes, so if any other node type is returned in the
nodelist there will be problems. simpleXML will need a custom xpath handler
to insure that the returned nodes are of type element or attribute.
The dom api for xpath also wasnt meant as the end all solution either. It
was a quick implementation to at least support querying nodes in the
document, but thats about all it does. The majority of XPath functionality
wasnt touched.
I do agree with the comment that DOM is big and clunky. In reality, I have
only ever had to use a handful of its functions and the only reason it got
done is that people using domxml wanted a compliant implementation that
implemented the functionality correctly and I had time to kill. Personally I
would like a simpleXML/DOM hybrid extension which took some of the best
features of each, so would offer the ease of use of simpleXML, some of the
more advanced features/methods in dom, yet noy have all the dom api baggage.
Well, this can be added with userspace handlers as I mentioned to
Marcus. The real trick to XML manipulation is Xpath, not adding a bunch
of broken methods. If people want to do that, they can load a simplexml
object into DOM, and use the two together. ;)
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
At 04:33 PM 1/12/2004 -0500, Sterling Hughes wrote:
In theory, I like the idea of a unified set of XML helper extensions,
but DOM's so big and ugly that I don't know if it plays well with
others in the sandbox.
We are not consistent! Not in any way. DOM uses studlyCaps and SimpleXML
uses underscores for its method names. Speaking of consistency we should
probably discuss whether we want to change all methods of SimpleXML to
studlyCaps (we cannot hcnage the DOM method names). Until RC1 i guess we
can do such changes if we all agree and see it to be important.
Haven't you been reading the thread - there are no more methods! :)
Sterling,
I actually think it's nice and easy to have some of SimpleXML's methods.
Maybe there is some redundancy and it might be an OK idea to make sure we
got them right, but I definitely think we should keep them.
Sure, but you're not an XML guy either. :) XML is a really nasty pit
when it comes to processing. Things that seem simple are crazy hard,
things that seem hard become crazy simple.
Where do you draw the line, how do you implement these methods
coherently. Does getChildren() get the immediate children or *all*
descendants. This is actually an important question, depending on how
you want to process an XML document. How does getting the text of a
method work? How do you combine nodes split up by XML tags?
DOM is evil, but it's in very many ways a necessary evil, if you want to
do programatical searching and manipulation of XML documents. This is a
very bad path for SimpleXML to go down. This is why I say XPath and
XQuery (in the future) are the solution. This was also the original
point of SimpleXML.
Also, it's great you've finally woken up, but it's a bit late in the game
to be doing so. We are in a feature freeze now so that we can get RC1 out
of the door hopefully by the end of the month, and it just doesn't make
sense to redesign the whole thing now.
Well, its not a feature freeze, and this doesn't require a full
redesign. As you know removing methods from a class entry is not at all
hard. Neither is changing two methods into functions. Much more
grotting of the internals could be done in the future, but the entire set of
userspace changes (which are important for 5.0) can be done without any terribly
invasive changes.
A lot of people have done some great work on your initial idea, including
the write support which I think was a must. What we have today is extremely
useable and I think if there are any important last minute
fixes/improvements that need to be made we should go ahead with them, but
they should be made after consulting w/ people and I definitely wouldn't
want to see something drastic such as removing methods. I think the fact
that you have the methods defined on the SimpleXML objects is great. That's
the essence of OOP and if you like it or not, SimpleXML is an OOP extension.
I am consulting with people, thus the thread. Had I not been consulting
with people, I could have easily made the changes already.
The core of SimpleXML uses objects, because that's the only way (tm).
SimpleXML is not an OOP extension. Look how you get a simplexml object,
it's all procedural (for a reason). You don't do:
$obj = new SimpleXML();
$obj-loadFile('filename');
But rather:
$obj = simplexml_load_file('filename');
So after all this ranting what I really think we should be discussing is if
there are any *crucial* things which need changing or fixing without
redesigning the whole thing.
It was never redesigned. People added work while i was sleeping
(since I woke up after all), this work happens to be contrary to the
point of the extension. That's why I'm writing in disagreement.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
Well, this can be added with userspace handlers as I mentioned to Marcus. The real trick to XML manipulation is Xpath, not adding a bunch of broken methods. If people want to do that, they can load a simplexml object into DOM, and use the two together. ;) XPath cant be the answer to everything. Although it would work, XPath is sure. but it can solve most of the simple problems quite efficiently, like getting immediate children. slow. I dont have them handy, but benchmarking was done for libxml on XPath querying and simplly walking the tree and manuallly performing tests. As the size of the document increased, the time to perform the XPath query went up by drastically comapred to manual processing. This is a good reason to use many of the dom methods over xpath as they are much faster. If speed isnt an issue then its a real moot point. Sure, I'm not dissing DOM (well, slightly, but still)... As I wrote to Andi, DOM is evil, but its a necessary evil. Don't get me wrong, I agree that simpleXML should be simple without alot of those methods (as a majority of the people using xml dont and most likely never will use them). And XPath is the answer for them when they need a little more juice. I can live with the interop between simpleXML and dom I guess, but see I wasnt the only one who was mentioning a happy medium between the 2 :) Perhaps. But that happy medium can be achieved in userspace, or another extension. SimpleXML's utility methods are now nowhere near the type of support I'm guessing you want, they are (imho) rather silly replacement for basic xpath. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
At 05:13 PM 1/12/2004 -0500, Sterling Hughes wrote:
I actually think it's nice and easy to have some of SimpleXML's methods.
Maybe there is some redundancy and it might be an OK idea to make sure we
got them right, but I definitely think we should keep them.
Sure, but you're not an XML guy either. :) XML is a really nasty pit
when it comes to processing. Things that seem simple are crazy hard,
things that seem hard become crazy simple.
Where do you draw the line, how do you implement these methods
coherently. Does getChildren() get the immediate children or *all*
descendants. This is actually an important question, depending on how
you want to process an XML document. How does getting the text of a
method work? How do you combine nodes split up by XML tags?
DOM is evil, but it's in very many ways a necessary evil, if you want to
do programatical searching and manipulation of XML documents. This is a
very bad path for SimpleXML to go down. This is why I say XPath and
XQuery (in the future) are the solution. This was also the original
point of SimpleXML.
I didn't say we should support everything (that would stop it from being
simple). I'm just saying have some useful methods such as schema validation
is nice. You were saying all methods should be nuked.
Right. Schema Validation is a great example. Perhaps it can be added as
a function, but here is where it gets tricky.
When I do a Schema validation on a simplexml_element, on what element
does the validation happen? Schema validation happens on the root
document, should it happen on the subnode that i call validate on? This
can be solved with a procedural approach (requiring that you pass the
root element), but can't easily be enforced with methods (unless you
throw an exception in every node except the root, which is kinda
counterproductive.)
Also, it's great you've finally woken up, but it's a bit late in the game
to be doing so. We are in a feature freeze now so that we can get RC1 out
of the door hopefully by the end of the month, and it just doesn't make
sense to redesign the whole thing now.
Well, its not a feature freeze, and this doesn't require a full
redesign. As you know removing methods from a class entry is not at all
hard. Neither is changing two methods into functions. Much more
grotting of the internals could be done in the future, but the entire set
of
userspace changes (which are important for 5.0) can be done without any
terribly
invasive changes.
I don't mind getting some cosmetic changes into RC1. However, I still think
that not all methods should be made functions.
Well, which should remain?
A lot of people have done some great work on your initial idea, including
the write support which I think was a must. What we have today is
extremely
useable and I think if there are any important last minute
fixes/improvements that need to be made we should go ahead with them, but
they should be made after consulting w/ people and I definitely wouldn't
want to see something drastic such as removing methods. I think the fact
that you have the methods defined on the SimpleXML objects is great.
That's
the essence of OOP and if you like it or not, SimpleXML is an OOP
extension.
I am consulting with people, thus the thread. Had I not been consulting
with people, I could have easily made the changes already.
The core of SimpleXML uses objects, because that's the only way (tm).
SimpleXML is not an OOP extension. Look how you get a simplexml object,
it's all procedural (for a reason). You don't do:
$obj = new SimpleXML();
$obj-loadFile('filename');
But rather:
$obj = simplexml_load_file('filename');
Yeah but then you do $obj-foo-bar-barbara.
Sure. But I use php_error(E_WARNING) not exceptions. We can certainly
discuss how it is and isn't pure OO, and what that means. OO people are
still arguing that... In fact I read a paper on OO the other day that
said instantiable class should have no external methods (which is
bollocks).
At the end of the day its what works best for the API. And in the case
of SimpleXML which has a rather messed up structure, something like a
array/balanced tree hybrid, most utility methods make better sense as
functions. And access methods shouldn't exist, its not the point of
simplexml.
So after all this ranting what I really think we should be discussing
is if
there are any *crucial* things which need changing or fixing without
redesigning the whole thing.
It was never redesigned. People added work while i was sleeping
(since I woke up after all), this work happens to be contrary to the
point of the extension. That's why I'm writing in disagreement.
I think the people who continued your work have done a good job in keeping
things simple. And I don't think the point of the extension has been lost.
By the way, did you following problem:
Due to engine problems
Re: [PHP-DEV] SimpleXML and Default Cast To String
On Jan 12, 2004, at 5:35 PM, Sterling Hughes wrote:
Well, this can be added with userspace handlers as I mentioned to
Marcus. The real trick to XML manipulation is Xpath, not adding a
bunch
of broken methods. If people want to do that, they can load a
simplexml
object into DOM, and use the two together. ;)
XPath cant be the answer to everything. Although it would work, XPath
is
sure. but it can solve most of the simple problems quite efficiently,
like getting immediate children.
Seems to take a good bit of the Simple out of SimpleXML, IMHO.
So is generically processing child elements. Besides, if there is one
technology worth learning when it comes to processing XML its Xpath.
Its XML's SQL/regular expressions, draw what analogies to string processing
that you will, but I don't see:
$results = simplexml_query($element, '/child::node()');
foreach ($results as $result) {
echo $result;
}
Signifigantly more complex then:
$results = $element-getChildren();
foreach ($results as $result) {
echo $result;
}
And it comes with the advantage of being a *signifigantly* more
powerful abstraction.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
Sure. But I use php_error(E_WARNING) not exceptions. We can certainly discuss how it is and isn't pure OO, and what that means. OO people are still arguing that... In fact I read a paper on OO the other day that said instantiable class should have no external methods (which is bollocks). At the end of the day its what works best for the API. And in the case of SimpleXML which has a rather messed up structure, something like a array/balanced tree hybrid, most utility methods make better sense as unbalanced. pah. -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
On Mon, 12 Jan 2004, Sterling Hughes wrote: What's the ultimate goal for simpleXML? I have been hesitant from ever touching this extension as what I thought it was intended to do, seems simplistic to where it acutally (is going/went?). Correct me if I'm wrong, but when it started I thought simpleXML's intent was to handle XML structures containing only elements and attributes (or at least ignoring everything else). The structure could never contain an element which had an attribute named the same as one of its child elements (otherwise you would need to be adding functionality as well to distinguish when you work with the attribute or element). Also, elements would contain either text or children elements but not both. Now that Zend can differentiate between array accessors and property accesses, attributes and nodes should be separated. I might be crazy, but they already are. This was changed months ago. I am the only one who actually uses SimpleXML? :) :) I know the code was in there, i didn't know it forcibly separated it. It seems it does. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML and Default Cast To String
On Mon, 12 Jan 2004, Sterling Hughes wrote:
Its XML's SQL/regular expressions, draw what analogies to string processing
that you will, but I don't see:
$results = simplexml_query($element, '/child::node()');
foreach ($results as $result) {
echo $result;
}
Signifigantly more complex then:
$results = $element-getChildren();
foreach ($results as $result) {
echo $result;
}
I do see it that way. The first one forces the user to learn a new
(significantly complex) language to perform simple operations, even if
it provides a more powerful abstraction.
I'm not arguing whether or not getChildren() is easier. Of course it
is. I'm arguing that getChildren() is not within the spirit of the
simplexml extension, which is explicitly designed to be without accessor
methods. I further, because of the availability of XPath don't see the
need to have such an accessor. Perhaps I would reconsider if this were
a particularly hard problem to solve without internal functions, but
when its so simple, I don't see the point.
There are plenty of other utility API's the extension could have that
will help in using it. getElementsByTagName() is a great function to
have - its simple *and* more efficient than Xpath, why isn't it there?
Because that's not what this extension is about. Its not about an
easy API for XML, or an efficient API for XML. Although it is
signifigantly easier and more efficient. It's a *simple*, uncluttered
API for XML.
SimpleXML is *not* supposed to reinvent DOM. It is supposed to be a
data structure view of XML that can easily be integrated with other
future components (such as XmlReader and XmlWriter API's).
I can accept getChildren() and getAttributes() (or better, just
children() and attributes()) as methods on objects, but I'm not happy
with them at all. These two methods were considered for inclusion in
my original thoughts on simplexml, and I decided against them for the
reasons I've mentioned above. Anyhow, shall we put it to a vote on
these two methods and move on?
I'm -1 on having them.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] internal API documentation
George Schlossnagle's upcoming book (Advanced PHP), will have 3 chapters
entirely devoted to PHP Internals and the Zend API; I highly recommend
it.
-Sterling
-Original Message-
From: david [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 5:39 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] internal API documentation
does anyone know where i can find documentation for PHP's internal API?
functions/macros like:
zend_hash_next_index_insert
zend_register_functions
zend_make_printable_zval
...etc
i am writing a PHP extension and i have a few questions on a few APIs
where
i need to understand what they really do without looking at the actual
PHP
source, if possible.
david
--
sub'_{print@_ ;* \ = * __ ,\ \}
sub'__{print@_ ;* \ = * ___ ,\ \}
sub'___{print@_ ;* \ = * ,\ \}
sub'{print@_,\n}{_+Just}(another)-(Perl)-(Hacker)
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
