Re: [PHP-DEV]

a scaled down and easier to learn/work with version of >SGML. > >Correct me if I'm wrong > >--Andrew > >On Friday 26 April 2002 07:30 pm, Zeev Suraski wrote: > > At 03:18 27/04/2002, Rasmus Lerdorf wrote: > > >It looks like we can. I was assuming the SGML cha

Re: [PHP-DEV] Discourage use of short tags

At 04:41 27/04/2002, Yasuo Ohgaki wrote: > > > Use of short tags is strongly discouraged. It is disabled by default > from PHP 4.3.0. Short tags are not only non-portable, but also non-XML > compliant. > > I object. I don't see an overwhelming reason to disable short tags by default,

Re: [PHP-DEV]

At 18:44 27/04/2002, Stig S. Bakken wrote: >On Sat, 2002-04-27 at 03:30, Zeev Suraski wrote: > > At 03:18 27/04/2002, Rasmus Lerdorf wrote: > > >It looks like we can. I was assuming the SGML characteristics for XML and > > >it looks like I was wrong. A '>'

Re: [PHP-DEV] config.w32.h...registry configuration

At 23:11 01/05/2002, Shane Caraveo wrote: >That would only solve that particular situation, what about multiple >installations of the same version, or seperate configurations for the same >installation? We can have PHP look for php.ini in the directory where php.exe is located. This would all

Re: [PHP-DEV] config.w32.h...registry configuration

x27;s been pointed out that the CWD lookup can be a potential security risk, because it allows people to override php.ini in some shared hosting environment setups, so it's another reason to replace it with the path lookup) Zeev At 23:17 01/05/2002, Zeev Suraski wrote: >At 23:11 01/0

Re: [PHP-DEV] config.w32.h...registry configuration

At 13:36 02/05/2002, [EMAIL PROTECTED] wrote: >Some hosters use this feature to have different settigns for different >customers... Do you know this for a fact, or is this an estimate? Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.p

Re: [PHP-DEV] config.w32.h...registry configuration

At 14:00 02/05/2002, [EMAIL PROTECTED] wrote: >On Thu, 2 May 2002, Zeev Suraski wrote: > > > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote: > > >Some hosters use this feature to have different settigns for different > > >customers... > > > > Do you kn

Re: [PHP-DEV] config.w32.h...registry configuration

We're not necessarily talking about Win32... Zeev At 14:02 02/05/2002, Dan Hardiker wrote: >At the risk of getting toasted out of the water... do any serious hosters >use a Win32 enviroment to host on? (who would utilise this way of setting >different settings for different clients) > >Are there

Re: [PHP-DEV] config.w32.h...registry configuration

At 15:09 02/05/2002, [EMAIL PROTECTED] wrote: > > Ok then, perhaps we should have an .ini setting for it? :) > >So you want to add an .ini setting where the .ini file could be found? >That just doesn't make sense to me :) That was a joke.. > > The only two options I see, in that case are: > > >

Re: [PHP-DEV] Re: Xdebug extension availability

Because it's not efficient enough... ZE2 is going to have these features built-in in a way that would have no performance impact. Zeev At 14:38 02/05/2002, Sebastian Bergmann wrote: >[EMAIL PROTECTED] wrote: > > Yeah, I know... but it doesn't belong in ext/ because it's a > > Zend_extension. PE

Re: [PHP-DEV] config.w32.h...registry configuration

On Thu, 2 May 2002, Shane Caraveo wrote: > #4 is realy needed for systems running virtual servers under IIS. While > you can configure ini in the registry, it's a pain, especially if you > want to give users access to edit their own ini file, or you want > different extensions loaded for diff

RE: [PHP-DEV] A better strlcat()

At 03:58 03/05/2002, Preston L. Bannister wrote: >Heh - there's a question :). > >Looking at the two implementations, which do you think you better >understand (with complete certainty), and which would you be willing >to (say) bet your life on? Are you implying that cryptic pointer arithmetic is

Re: [PHP-DEV] config.w32.h...registry configuration

> > php-apache-4.2.1.ini > php-apache.ini > php.ini > > ? > > This way it's even more less pain to have different versions > installed. > > - Markus > >On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote : &g

RE: [PHP-DEV] A better strlcat()

To make it clear, this *WAS* a joke :) At 04:36 03/05/2002, Zeev Suraski wrote: >At 03:58 03/05/2002, Preston L. Bannister wrote: >>Heh - there's a question :). >> >>Looking at the two implementations, which do you think you better >>understand (with complete ce

RE: [PHP-DEV] config.w32.h...registry configuration

At 07:51 03/05/2002, Stig S. Bakken wrote: >Edin and I were discussing ini files on IRC last night and the same idea >came up. With the exact same syntax too, actually. This is divine >proof that the include_ini is good and must be implemented. :-) > >Seriously, being able to include other ini f

Re: [PHP-DEV] PHP 4.3 charter and release plan

At 08:17 03/05/2002, Stig S. Bakken wrote: >Does this organization of the 4.3 release sound reasonable? Yep. Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] resource problem, advice wanted

At 12:02 01/05/2002, Stig Venaas wrote: >This is a bit involved, I'll try to explain. I'm trying to fix a >problem in the LDAP extension, but not sure how best to do it. > >The issue is that code like > >$e = ldap_first_entry($ds, ldap_read($ds,$dn,"objectClass=*")); >$a = ldap_get_attributes($ds,

Re: [PHP-DEV] config.w32.h...registry configuration

At 17:24 03/05/2002, Jim Winstead wrote: >Zeev Suraski <[EMAIL PROTECTED]> wrote: > > We could add it. I just hope people wouldn't start demanding control > > structures in there to start selectively loading other files... > >let's just hope that by the

Re: [PHP-DEV] RFI: Request for Interfaces

One thing that I'm personally don't really understand, is what kind of support this needs from the infrastructure. As far as I can tell, we could define php_database_interface (example), with the necessary callbacks, and use it directly in all pieces of code that require/support it. I don't e

Re: [PHP-DEV] RFI: Request for Interfaces

At 03:04 04/05/2002, Zeev Suraski wrote: >One thing that I'm personally don't really understand reread entire paragraph after rewriting parts of it -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFI: Request for Interfaces

At 12:12 07/05/2002, Wez Furlong wrote: >On 04/05/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote: > > One thing that I'm personally don't really understand, is what kind of > > support this needs from the infrastructure. As far as I can tell, we > coul

[PHP-DEV] Any idea why we have two html_puts()'s?

We currently have two html_puts()'s - the old zend_html_puts(), and a relatively new php_html_puts(). Was there any good reason for adding php_html_puts()? It duplicates the same logic of both zend_html_putc() and zend_html_puts(). Zeev -- PHP Development Mailing List

Re: [PHP-DEV] Safe Mode

At 20:17 11/05/2002, Rasmus Lerdorf wrote: > > Ideally every ISP would use it and each virtual host would have such a > > directory. In reality I've set to see a SINGLE ISP that has used that > option. > > In fact I didn't know about it myself until you told me about on IRC. > >Well, it is well d

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

Hmm, then it could be fixed, but we shouldn't introduce a new implementation. Assuming you refer to the large number of output calls, they can be saved using output buffering - implementing localized buffering in every place is not a good way to go by. I'm not sure output buffering was already

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 17:43 12/05/2002, Sascha Schumann wrote: > I've just noticed that you have kicked out the premier > implementation of the same functionality in favor of the dog > slow old one. I almost missed those idyllic descriptions :) > Note that relying on output buffering alone is infer

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 17:58 12/05/2002, Sascha Schumann wrote: > > What inherent flaws? So far, the only difference between them that I could > > spot was that php_html_puts() was buggy, and did not convert series of > > spaces into  's. Otherwise, the only difference was the use of > > buffering. I may have miss

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 18:24 12/05/2002, Sascha Schumann wrote: > - it is buffering as you already noted without having to rely > on the huge output-buffering infrastructure. I have not > benchmarked it, but I do assume that it is noticably slower > than php_html_puts. > > - it is faster du

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

I'd *really* like to avoid having two copies of the same code, though. Please remove the duplicated implementation... Zeev At 18:24 12/05/2002, Sascha Schumann wrote: > > What I'm pointing out is that there are no 'inherent flaws' in the 'dog > > slow' implementation that we already had for a

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 18:34 12/05/2002, Sascha Schumann wrote: > I favor php_html_puts also due to maintability reasons. > Please consider this part of code from zend_html_puts: > > && !(((ptr+1)>=end) || (*(ptr+1)==' ')) /* next is not a space */ > && !((ptr==s) || (*(ptr-1)==' ')))

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 19:00 12/05/2002, Sascha Schumann wrote: > > Again, I fail to understand the logic behind it. I'll change the space > > handling code to your method (which is indeed nicer); Why on earth would > > we need to have a stupid HTML printout function as a function pointer? > > If you would also

Fwd: Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

I messed up on the test, I left output buffering enabled for tests 2 and 3. So you can see that using output buffering on top of the global output buffering (whether specialized or not) slows you down by about 30%. However, to be fair, the numbers w/o global output buffering enabled: Speciali

Re: [PHP-DEV] Segfault in current HEAD

This trace isn't meaningful... At 20:36 12/05/2002, Sebastian Bergmann wrote: > Can't tell how to reproduce this, it occurs when working with Harald's > form validation system, which is built on top of PEAR::XML_Transformer: > >NTDLL! 778cb892() >NTDLL! 778cb733() >shutdown_memory_manager(int

Re: [PHP-DEV] Segfault in current HEAD

At 21:33 12/05/2002, Sebastian Bergmann wrote: >Zeev Suraski wrote: > > This trace isn't meaningful... > > I know. How would I produce a more useful one? It's probably not possible - the best thing to do is to try to cut down the script to the smallest one that sti

Re: [PHP-DEV] Re: Bug #17168: error_log can be used to bypass safe_mode

We can check it at the ini handler level. We can either forbid modifying error_log from userspace (denying PHP_INI_USER), deny it only in safe mode, or even apply the safe mode restriction at that level. At 00:25 13/05/2002, Rasmus Lerdorf wrote: >Not quite sure how to fix this one. It's not

Re: [PHP-DEV] Safe Mode

Jason, He has a point in the sense that it's trivially easy to starve a PHP based web server from within, safe mode enabled or not. What you describe as the automated way in which the web server will overcome this attack is not realistic - pretty quickly, the web server would hit the maximum

Re: [PHP-DEV] Safe Mode

At 11:42 13/05/2002, veins wrote: > > He has a point in the sense that it's trivially easy to starve a PHP based > > web server from within, safe mode enabled or not. What you describe as >the > > automated way in which the web server will overcome this attack is not > > realistic - pretty quickl

Re: [PHP-DEV] Profiling PHP

We already tried our best to optimize most of the functions that show up in profiling. Not surprisingly, they are mostly the infrastructure functions... What profiler are you using? If it's under Linux, chances are it's *extremely* inaccurate. Profiling under Linux is horrible. Zeev At 17:

Re: [PHP-DEV] Profiling PHP

exact numbers, but the functions are more or less the same). Zeev At 18:43 13/05/2002, Rasmus Lerdorf wrote: >I did specify the profiler on line 4 of the message. And it is a pretty >good one actually. > >On Mon, 13 May 2002, Zeev Suraski wrote: > > > We already tried our be

Re: [PHP-DEV] Profiling PHP

At 23:59 13/05/2002, Stig S. Bakken wrote: >Seeing that the single most time-consuming function is zend_parse, it >would be interesting to see where the bottleneck moves when using >ZendAccelerator or another caching product. Did you try that setup with >NuMega's profiler? It still stays in the

Re: [PHP-DEV] Probably a simple answer...

zval strings must be NULL terminated, even if they contain binary data. The str.val.len property represents the length of the string w/o the terminating NULL. Zeev At 16:39 14/05/2002, Robert Cummings wrote: >brad lafountain wrote: > > > > Well i do believe that the zval string SHOULD be null

Re: [PHP-DEV] Safe Mode

At 04:38 PM 5/13/2002, Jason T. Greene wrote: > > I do, for two simple reasons: > > - Misperception about what it's supposed to do - it does NOT secure your > > environment, people expect it to. That's a 'marketing' issue, but we > > should realize that these kinds of issues are at least as imp

Re: [PHP-DEV] Command line compilation under win32

php4' directory will be used rem 3) "cvsup", which is like "cvs", except the CVS repository remwill be updated first rem rem Author: Zeev Suraski <[EMAIL PROTECTED]> rem Defaults set configuration=Release_TS set build_type=/rebuild if "%1" == "

Re: [PHP-DEV] Garbage Collection!

At 08:53 PM 5/17/2002, Robert Cummings wrote: >Let's say I do: > > zval *newVar; > MAKE_STD_ZVAL( newVar ); > ZEND_SET_SYMBOL( &EG(symbol_table), "varKey", newVar ); > >and then I do: > > MAKE_STD_ZVAL( newVar ); > ZEND_SET_SYMBOL( &EG(symbol_table), "varKey", newVar ); > >This

Re: [PHP-DEV] Garbage Collection!

At 09:04 PM 5/17/2002, Robert Cummings wrote: >To be honest I'm passing the return_value into my recursion Not sure what you mean by that - return_value is handled by the engine as soon as you return from your function implementation, if that's what you're asking. If you're using it internally

Re: [PHP-DEV] Garbage Collection!

If you're adding elements to a hash you created using array_init(), and you're using the standard macros (which apparently you are) - then yes, the engine will take care of garbage collection for you. At 09:27 PM 5/17/2002, Robert Cummings wrote: >Zeev Suraski wrote: > > &

Re: [PHP-DEV] zend_op_array question

EX(function_state).function is supposed to be a pointer to the op_array that you passed to execute(). Any chance the op_array is somehow deleted by mistake? Did you try looking at EX(function_state) and EX(function_state).function to understand why it's dying? At 03:02 PM 5/19/2002, Wez Furlo

Re: [PHP-DEV] Crasher in 4.2.1 - debugging advice needed

Wild guess, but did you load an extension using dl() in the file that crashed? Zeev At 15:23 21/05/2002, Dave Brotherstone wrote: >Hi, > I've got a particular script that seg-faults when certain parts of it run >(tested with 4.1.0 and 4.2.1, both CGI and Apache module). > >I've done a back tra

Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL

At 00:08 24/05/2002, Rasmus Lerdorf wrote: >I really don't like the term Web Services. SOAP is an RPC mechanism and >has nothing to do with the web despite what M$ would like to have you >think. I think that's kind of like saying HTML has nothing to do with the web, but anyway, perception is ev

RE: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL

I think, by the way, that this could be a good time to drop the php- prefix from new mailing list names. Do we really need to point out that it's PHP related, when the domain is lists.php.net? :) Zeev At 00:20 24/05/2002, Lukas Smith wrote: >Shane also did not like the term and I can see wher

Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL

At 01:39 24/05/2002, Rasmus Lerdorf wrote: >Well, HTML is an intrical part of the Web and I don't see how that can be >compared to SOAP at all. In order for SOAP to be part of the Web it needs >to conform to the HTTP protocol and to the concepts that defines the Web. >It doesn't do that at all to

Re: [PHP-DEV] PECL

As I told Stig yesterday, I think the main problem with PECL right now is that when an extension is moved to PECL, its author gets the feeling as if it was banished to Siberia, and that has to be changed. I think that the moving of extensions to PECL was supposed to address the problem of sync

Re: [PHP-DEV] bundling libxml2 / bundling locations

At 07:16 PM 5/30/2002, Stig S. Bakken wrote: >On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote: > > On Thu, 30 May 2002, brad lafountain wrote: > > > > > The 2M size has alot of stuff that we wouldn't need. Im sure we can > get it > > > down to under 500K. > > > > I still think 500kb is too

Re: [PHP-DEV] bundling libxml2 / bundling locations

At 07:08 PM 5/30/2002, [EMAIL PROTECTED] wrote: >On Thu, 30 May 2002, brad lafountain wrote: > > > The 2M size has alot of stuff that we wouldn't need. Im sure we can get it > > down to under 500K. > >I still think 500kb is too much for something the most ppl already have >installed. How do you

Re: [PHP-DEV] bundling libxml2 / bundling locations

At 11:39 PM 5/30/2002, Dan Kalowsky wrote: >On Thu, 30 May 2002, brad lafountain wrote: > > > I personally will take responsiblity for bundling and upgrading it. > >As Rasmus stated earlier the reason the MySQL stuff is bundled is due to >an assurance from the MySQL developers to keep it updated.

Re: [PHP-DEV] libxml bundling

Just an overall reply to a point you're making - yes, making the user download and build something if he wants to use XML is really a con, in my opinion. Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] libxml bundling

At 11:19 PM 5/31/2002, Andi Gutmans wrote: >At 13:12 31/05/2002 -0700, brad lafountain wrote: >>Ok, >> >> I think we are split in two about what to do here. Ill try and list the >>different ideas that have been proposed. >> >>1) don't include at all >> pros: >>No need to worry about auto ins

Re: [PHP-DEV] libxml bundling

Guys, Unless somebody strongly objects, I suggest we drop the discussion about how horrible it would be to import libxml2 into our CVS. I believe it's well established that it's a Bad Thing to do, there's no point hashing it. I believe the question on the table is whether libxml2 is important

Re: [PHP-DEV] libxml bundling

Did you conduct a survey about that? I believe there's at least one company that effectively proved that the opposite is true, there are probably many others. I don't see a problem in having core technologies enabled by default. Purists can turn them off, but there are a hell of a lot more a

Re: [PHP-DEV] libxml bundling

At 12:45 PM 6/1/2002, Christian Stocker wrote: > > I believe that bundling at the makedist level makes the most sense, > because: > > (a) Synchronization is trivial > > (b) We get to choose what libxml we use, so our libxml-dependent code > > doesn't have to support the zillion different libxml's

Re: [PHP-DEV] libxml bundling

At 02:23 PM 6/1/2002, Christian Stocker wrote: > > If not - I see no problem in always using the bundled library, > > regardless of what's already installed - on the contrary, I see a fairly > > big advantage. > >I see really no advantage in this approach (more memory needed for >example, maybe sy

Re: [PHP-DEV] libxml bundling

At 05:05 PM 6/1/2002, Sebastian Bergmann wrote: >Marko Karppinen wrote: > > It seems to me that PHP is increasingly being modeled for a largely > > imaginary audience of purists. I say imaginary because I just can't > > see how droves of purists would've become involved with PHP in the > > first p

[PHP-DEV] PHP's vision (was: libxml bundling)

At 07:12 PM 6/1/2002, Björn Schotte wrote: >* Sebastian Bergmann wrote: > > I don't want to see changes (like those you mention later in your > > posting) in PHP to attract new users, but more to bind people that > > already use PHP, but are about to "outgrow" it. > > > > If you (and other

Re: [PHP-DEV] libxml bundling

Why not have a --bare (or equivalent) switch of that kind, to disable literally EVERYTHING that's not mandatory? I believe the issue is that for every 'purist' that cares about bloat, it's safe to say there's more than one user (*) that prefers stuff to 'just work', and not mess with additio

Re: [PHP-DEV] PHP's vision (was: libxml bundling)

I agree with every word. Zeev At 12:25 AM 6/2/2002, Shane Caraveo wrote: >I think PHP can be both powerful and easy to use, and I think I have an >example of that in my own experience. I've got code I wrote on PHP 2 >years ago, that has gone through a couple face lifts and modifications to >

Re: [PHP-DEV] PHP's vision

At 05:21 PM 6/2/2002, Sebastian Bergmann wrote: >Jani Taskinen wrote: > > I'm not that familiar with Java..so it would be nice to hear > > what Java offers that PHP doesn't? > > Private members and methods, interfaces, Application Servers, Beans, > Enterprise Beans. Seriously, Sebastian, if t

Re: [PHP-DEV] PHP's vision

At 09:13 PM 6/2/2002, Sebastian Bergmann wrote: >Andi Gutmans wrote: > > Are you aware how complex and expensive it is to create a Java > > application server solution? > > Probably not. But I know that Derick et al. are doing a good job adding > Application Server-like functionality to the "P

Re: [PHP-DEV] PHP's vision

At 09:23 PM 6/2/2002, Björn Schotte wrote: >* Jani Taskinen wrote: > > Could you explain in more detail what exactly these needs > > would be? > >As Sebastian mentioned (sorry I couldn't reply earlier, >we are currently moving PHP-Center/PHP-Conference to a >new machine) things like Applic

Re: [PHP-DEV] PHP's vision

At 12:13 AM 6/3/2002, Sebastian Bergmann wrote: > But, as I said before, I don't understand why simplicity should mean in > its consequence that software designs you find these days in the Java > World cannot be done with PHP. The essence (in one sentence) of what I > would like to see: >

Re: [PHP-DEV] PHP's vision

At 09:48 AM 6/3/2002, Björn Schotte wrote: > > >more complexity to the language itself. > > Why would making PHP more complex be a good thing? > >Because not every web designer and semi-programmer could >then work with PHP - this lacks the image of PHP. ("PHP >ist only good for guestbooks and

Re: [PHP-DEV] PHP's vision

John, Whether we end up having private methods or not, it's way beyond their scope to address the issue of security, and protecting data from someone who has access to their code. It's always possible to work around that level of 'security', whether it's in C++, Java or any other language.

Re: [PHP-DEV] PHP's vision (was: libxml bundling)

At 12:28 PM 6/3/2002, Kristian Koehntopp wrote: >I think that PHP should be only as "newbie hostile" as security >dictates (register_globals off and similar stuff). It should be >as convenient and easy to use as possible. > >It should also provide hooks and means to reconfigure it >manually for th

Re: [PHP-DEV] PHP's vision

At 04:28 PM 6/3/2002, [EMAIL PROTECTED] wrote: > >> I am curious, besides some language quarks, like multidimentional > >> arrays, what sorts of things can you do in Java which can not be done > >> in PHP? > > > > I'm actually curious about the multidimensional arrays point. Exactly > > what do y

RE: [PHP-DEV] PHP's vision

At 06:03 PM 6/3/2002, Lukas Smith wrote: >(I wonder why none of them read this >list and said that they want to make PHP Enterprise ready ...) You're kidding, right? (it doesn't mean that that's what we're going to do). Zeev -- PHP Development Mailing List To unsubscrib

Re: [PHP-DEV] PHP's vision

At 06:43 PM 6/3/2002, Sebastian Bergmann wrote: >Zeev Suraski wrote: > > Amen to that! > > Why does Kristian recieve an "Amen to that!" for saying the same things > I did? :-) Hmm, because he's bigger? :) Zeev -- PHP Development Mailing List <http:/

Re: [PHP-DEV] PHP's vision

At 12:34 PM 6/4/2002, Sebastian Bergmann wrote: >Kristian Koehntopp wrote: > > "Peace through superior firepower"? That's a trademarked american > > concept at the moment, I think. > > Pax Americana replaced Pax Romana a while ago :) 'cept there's no pax... -- PHP Development Mailing List

[PHP-DEV] Re: [Zend Engine 2] PHP in the future

At 07:01 PM 6/6/2002, brad lafountain wrote: >Please don't reply to this email saying Use Java... Because php is different >than java and always will be even with these new features. Brad, I beg you, there's nothing anybody can say on this list that would lead this to closure. Nothing. I belie

Re: [PHP-DEV] Performance of Apache 2.0 Filter

At 07:00 PM 6/6/2002, Sebastian Bergmann wrote: > A user posted [1] a "benchmark" today in the German PHP Newsgroup [2] > stating that Apache 2.0 and PHP (current HEAD) are about 20% slower > than Apache 1.3. > > Are there any official benchmarks out there? I can't quite believe > this..

[PHP-DEV] Re: [Zend Engine 2] PHP in the future

At 08:26 PM 6/6/2002, brad lafountain wrote: >--- Zeev Suraski <[EMAIL PROTECTED]> wrote: > > At 07:01 PM 6/6/2002, brad lafountain wrote: > > >Please don't reply to this email saying Use Java... Because php is > different > > >than java and al

Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future

Aggregation sometimes involves delegation. The 'parent' object delegates requests to the right aggregated objects (in other cases, the 'parent' object returns its aggregated objects and you use them directly). Zeev At 10:43 PM 6/6/2002, Sebastian Bergmann wrote: >Andi Gutmans wrote: > > The t

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future

Code reusability is a psychological issue. You can reuse code in PHP 4, and it'll be even better in 5 - PEAR is a clear demonstration of this. Whether people actually end up reusing code depends on the way they code, very little does it depend on the language. Zeev At 05:27 PM 6/7/2002, Jas

RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future

At 05:46 PM 6/7/2002, Joseph Tate wrote: >How much of C has been reused, and reused and reused again? There is no oo >in stdlib. Exactly. C is one of the easiest languages for code reuse, but it totally depends on your programming habits and skill. As a matter of fact, I find Java to be one

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future

At 06:14 PM 6/7/2002, Jason T. Greene wrote: >True, I hear it is even possible to reuse code in COBOL : ) > >I believe that the ease of maintenance depends purely on the language. >i.e. using a strictly procedural language for a large framework can be >quite messy. Have you ever seen large librari

[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php

There are two reasons we repeat the 'PHP is not Java mantra': (a) Many of those requesting these changes actually DO want to see PHP as a Java with PHPish syntax. (b) Java is (so far) the best implemented OO language out there that's actually being used. It symbolizes the extreme OO world, if

Re: [PHP-DEV] Zend Engine expert wanted!!!!

Brian, We're on the job. I generally think you're right, we have to do some more thinking but chances are we will change the shutdown order to be reversed. Sorry for not ack'ing earlier. Zeev At 09:44 PM 6/7/2002, Brian France wrote: >Zend Engine unloading extension in the wrong order! (Re-

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

PHP has its own buffering mechanism which can take care of this. Try output_buffering = 4096 in your php.ini. Zeev At 08:33 PM 6/8/2002, Brian Pane wrote: >Looking at some more syscall call traces, I'm seeing that >the flush buckets used by php_apache_sapi_ub_write() are >causing very small pa

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

At 12:55 AM 6/9/2002, Brian Pane wrote: >I just looked through zend_alloc.c. It looks like the HeapCreate only >happens once, at startup--did I get that right? It's called on the per-thread startup (start_memory_manager(), which is called from alloc_globals_ctor(), which is the per-thread alloc

Re: [PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

At 02:57 AM 6/9/2002, Brian Pane wrote: >In the httpd, we've done two things to minimize the fragmentation: > * Memory for these heaps is almost always allocated in chunks of >a fixed size, 8KB. Hmm, but doesn't that mean that the largest contiguous block this heap will be able to provide i

Re: [PHP-DEV] REPOST: Class Autoloading [PATCH]

I believe this has been discussed in the past and not ack'd, please read the php-dev archives... Zeev At 10:19 PM 6/9/2002, Ivan Ristic wrote: >Several days ago I posted a simple patch to the Zend Engine, >to support automatic class loading. The code is almost completely >copied from the existi

Re: [PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

At 09:03 AM 6/10/2002, Sander Striker wrote: >Why is PHP even using its own memory allocation scheme? It would be much >easier to just use pools and point out where it doesn't work for you. Because we don't want it depend on any underlying services which aren't available in all servers. We can

Re: [PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

At 07:29 PM 6/10/2002, Aaron Bannert wrote: >On Mon, Jun 10, 2002 at 11:46:46AM +0300, Zeev Suraski wrote: > > What we need for efficient thread-safe operation is a mechanism like the > > Win32 heaps - mutexless heaps, that provide malloc and free services on a > > (prefe

Re: [PHP-DEV] Memory Leaks /w nested classes

If they end up in a circular reference (in this particular case they do, they usually don't) then you're leaking memory. Zeev At 12:10 AM 6/11/2002, brad lafountain wrote: >I use parent members all the time.. w/zend1 > > - Brad >--- Markus Fischer <[EMAIL PROTECTED]> wrote: > > Hi, > > > >

Re: [PHP-DEV] Streamy PHP parser input?

There should be a way of doing that within the framework of flex by redefining YY_INPUT and hacking around flex. You can, by the way, provide a char * string, that already works today (look at zend_eval_string() or zend_prepare_string_for_scanning()). Zeev At 12:23 AM 6/11/2002, Justin Erenkr

Re: [PHP-DEV] Streamy PHP parser input?

At 02:29 AM 6/11/2002, Aaron Bannert wrote: >On Tue, Jun 11, 2002 at 12:38:44AM +0300, Zeev Suraski wrote: > > There should be a way of doing that within the framework of flex by > > redefining YY_INPUT and hacking around flex. > >I'd love to see this built in to SAP

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] RE:[PHP-DEV] oo != php

At 10:19 AM 6/11/2002, Sebastian Bergmann wrote: >Alex Black wrote: > >> class foo aggregates bar { > >> } > > > > I think that is a nice solution. > > It's not, because it's static. Multiple iheritance is flawed, because > it's static. That's hardly considered a flaw almost anywhere, even in

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [ZendEngine 2] RE:[PHP-DEV] oo != php

At 11:23 AM 6/11/2002, Sebastian Bergmann wrote: > This way, an object of Foo can dynamically change behaviour in a very > elegant way. I'm well aware of the strategy design pattern, but it existed before 'Lava' (I use it in Java all the time)... You can just as easily do this by creating

Re: [PHP-DEV] sapi_header_op

At 02:44 PM 6/30/2002, Sascha Schumann wrote: >typedef struct { > char *line; /* If you allocated this, you need to free it yourself */ > uint line_len; > long response_code; /* long due to zend_parse_parameters compatibility */ >} sapi_header_line; > >typedef enum { /

Re: [PHP-DEV] sapi_header_op

Thanks for the clarifications. IMHO the advantage does not outweigh the disadvantages (slower, more cumbersome to use, will require everyone to implement two interfaces), so personally, I'm -1. Zeev At 06:30 PM 6/30/2002, Sascha Schumann wrote: > > How is it better than add_header_ex()? > >

Re: [PHP-DEV] sapi_header_op

At 06:54 PM 6/30/2002, Sascha Schumann wrote: >On Sun, 30 Jun 2002, Zeev Suraski wrote: > > > Thanks for the clarifications. IMHO the advantage does not outweigh the > > disadvantages (slower, more cumbersome to use, will require everyone to > > implement two interfaces

Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

Are you sure they're equivalent to symlinks? They only work with directories as far as I know, which renders them significantly less useful than UNIX symlinks. Zeev At 05:26 PM 7/6/2002, Timo Weingärtner wrote: >NTFS supports directory junctions which are equivalent to unix symlinks. >I found

Re: Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

Apache 2.x recognizes junctions >under NT (Options FollowSymlinks). It would be nice to have the code >included in PHP. > >Thanks in advance, Timo Weingärtner > >-Original Message- >From: Zeev Suraski [mailto:[EMAIL PROTECTED]] >Sent: Samstag, 6. Juli 2002 16:55 >T

<    5   6   7   8   9   10   11   12   13   14   >