Re: [PHP-DEV] [PATCH] .phps support for Apache 2

2002-10-06 Thread Andi Gutmans

ctx->r->handler[strlen("application/x-httpd-php")]

Is this actually the way it's supposed to work? (based on the length)? 
Unless there's something I'm missing I'd prefer to see an strcmp() here. It 
might be a bit slower but it's definitely more robust for future changes.

Andi

At 12:06 PM 10/4/2002 -0400, Ilia A. wrote:
>The attached patch adds .phps file support for Apache 2, allowing Apache 2
>users to show prettified source of their scripts, just like their Apache 1
>counterparts can.
>
>It is a fairly simple patch, that adds just 2 cmp overhead for this
>functionality, so its not too bad imho.
>Please review the patch and let me know if there are any objections to it's
>addition.
>
>Ilia
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] ini_set("register_globals", 1);

2002-10-06 Thread Andi Gutmans

I don't think this is a good idea because some code which runs before the 
script runs depends on this.
It doesn't make sense to make such a hack just for the tests, just to get 
some session code to run differently.

Andi

At 09:01 AM 10/3/2002 +0200, Sascha Schumann wrote:
> The session test scripts need to set register_globals -- does
> anyone see a problem with making that option setable in the
> script?
>
> - Sascha
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c php_pgsql.h

2002-10-06 Thread Andi Gutmans

It doesn't really make sense to me to add an alias to MySQL if it's not needed.
The less aliases we have in PHP the better IMO.

Andi

At 11:04 AM 10/3/2002 +0900, Yasuo Ohgaki wrote:
>Ok. I'll add alias to mysql and rename pgsql function.
>
>--
>Yasuo Ohgaki
>
>Derick Rethans wrote:
>>On Wed, 2 Oct 2002, Marcus Börger wrote:
>>
>>>At 13:41 02.10.2002, Dan Kalowsky wrote:
>>>
On Wednesday, October 2, 2002, at 12:10 AM, Yasuo Ohgaki wrote:

>I don't mind to have alias like pg_result_seek() or
>have only pg_result_seek().

I would rather see it named pg_result_seek as it is more consistent 
with what this function accomplishes.  It also opens the door for ODBC 
to follow in these steps a bit more.
>>>
>>>
>>>So why not add an alias for the mysql function and use the
>>>preferred name?
>>
>>Sounds good to me
>>Derick
>>--
>>---
>>  Derick 
>> Rethans   http://derickrethans.nl/  JDI 
>> Media Solutions
>>--[ if you hold a unix shell to your ear, do you hear the c? ]-
>>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Feature request -- feedback welcomed.

2002-10-06 Thread Andi Gutmans

You already have "public" which you can use instead of "var".
I think method would look very nice but I don't think it's worth creating 
another reserved word.

Andi

At 01:34 PM 9/28/2002 -0600, Lamont R. Peterson wrote:
>All:
>
>I can't hardly wait for PHP 4.3 (Zend 2.0) to hit the streets.  I can't
>express how anxiously I've been waiting for the class model to be reworked.
>Great job!
>
>I would, however, like to see a couple of simple additions to the planned
>release (if these are already coming, then I just haven't seen is talked
>about anywhere).  I would love to have "method" as an alias for "function"
>and "member" as an alias for "var".  These could be just plain aliases, but
>it would be nice if these aliases were only valid within a class definition.
>
>I would love to hear peoples thoughts on this one.  Where I work, the kind of
>software we write on PHP,  it only makes sense to use objects.  However, we
>do mix in plain functions liberally when there is no need for the features of
>an object.  I've worked this way with PHP ever since 4.0.0 was released.
>--
>Sincerely,
>Lamont R. Peterson <[EMAIL PROTECTED]>
>801-580-7323 [cell]
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/session session.c

2002-10-06 Thread Andi Gutmans

Please use sizeof("sid") and not 4 in such code.
Also, why use hash_find() if just calling hash_del() would work?

Andi

At 12:05 AM 9/27/2002 +0200, Markus Fischer wrote:
> Guys,
>
> _Please_ include bug fixes in NEWS entries (or separately
> commit them) so we've complete log.
>
> Browsing back the ChangeLog and finding missing treasures
> ain't that funny.
>
> ;)
>
> thanks,
>
> - Markus
>
>On Thu, Sep 26, 2002 at 06:12:27PM -, Ilia Alshanetsky wrote :
> > iliaa Thu Sep 26 14:12:27 2002 EDT
> >
> >   Modified files:
> > /php4/ext/session session.c
> >   Log:
> >   Fixed bug #11643
> >
> >
> > Index: php4/ext/session/session.c
> > diff -u php4/ext/session/session.c:1.317 php4/ext/session/session.c:1.318
> > --- php4/ext/session/session.c:1.317  Thu Sep 26 12:46:21 2002
> > +++ php4/ext/session/session.cThu Sep 26 14:12:27 2002
> > @@ -17,7 +17,7 @@
> > 
> +--+
> >   */
> >
> > -/* $Id: session.c,v 1.317 2002/09/26 16:46:21 sniper Exp $ */
> > +/* $Id: session.c,v 1.318 2002/09/26 18:12:27 iliaa Exp $ */
> >
> >  #ifdef HAVE_CONFIG_H
> >  #include "config.h"
> > @@ -826,6 +826,7 @@
> >   int module_number = PS(module_number);
> >   int nrand;
> >   int lensess;
> > + zend_constant *c;
> >
> >   PS(apply_trans_sid) = PS(use_trans_sid);
> >
> > @@ -919,7 +920,11 @@
> >   php_session_send_cookie(TSRMLS_C);
> >   }
> >
> > -
> > + /* check if SID constant exists, if it does destroy it. */
> > + if (zend_hash_find(EG(zend_constants), "sid", 4, (void **) &c) != 
> FAILURE) {
> > + zend_hash_del(EG(zend_constants), "sid", 4);
> > + }
> > +
> >   if (define_sid) {
> >   smart_str var = {0};
> >
> >
> >
> >
> > --
> > PHP CVS Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>--
>GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> Derick, while ($xml) $ass->get_new_ideas();
><[James]> Markus: IE on_user_fart()
>-- People doesn't seem to like the new XHTML2 specs :) --
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.c css.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apache php_apache.c

2002-09-24 Thread Andi Gutmans

At 11:01 AM 9/24/2002 -0400, Colin Viebrock wrote:
> > It obviously is not compatible with current browsers as it
> > is really ugly in IE and NS.
>
>It looks pretty much identical to the way it did before in MSIE 5+ and
>NS 6+ and Mozilla.  It only looks "ugly" (i.e. not as nice as before) in
>NS 4.x, a broswer that almost no one uses anymore.
>
> > Indeed, why did you have to change it? Just to get CSS in there?
>
>
>As I said, it was to reduce the size of the file considerably.

Just out of curiosity, what was the size before/after?

Andi


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




Re: [PHP-DEV] sticky perms in CVS?

2002-09-23 Thread Andi Gutmans

At 07:22 PM 9/23/2002 +0100, Wez Furlong wrote:
>Am I the only one who is getting their files chmod'ed to read-only
>every time I do a CVS commit?
>In particular, main/user_streams.c keeps doing this which is quite
>annoying - is there some setting on the server side that affects this?
>(and do we want it switched on?)

No idea. It's never happened to me. Not that I think it can have anything 
to do with it but is your umask OK?

Andi


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




Re: [PHP-DEV] [PATCH] [ZE] More useful error message for class redeclaration

2002-09-23 Thread Andi Gutmans

If the zend_hash_add() fails then you can do a zend_hash_find() to retreive 
the class which is in the hash and print its information. If its 
information is NULL (we have to make sure we init it) then you can print 
out a message that it's an internal class. Does that make sense?

Andi

At 06:26 PM 9/23/2002 +0100, Wez Furlong wrote:
>The problem is (as I understand it!) that the ZEND_DECLARE_CLASS case in 
>do_bind_function_or_class retrieves the class entry for the user-defined
>class and not the internal class, and that is why the message reflects
>the user class.
>
>I can't really see why this is the case, but then I haven't really delved
>into how it all works :-/
>
>--Wez.
>
>
>On 09/23/02, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Can't you make sure that the filename of internal classes will be NULL and
> > then we can check for it and say it's an internal class?
> >
> > Andi
> >
> > At 03:59 PM 9/23/2002 +0100, Wez Furlong wrote:
> > >Caveat Emptor: if someone tries to redeclare an internal/builtin class
> > >such as Directory, the previous declaration will appear to be the
> > >actual declaration in the script.  I'm not sure of the best way to
> > >resolve this.


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




Re: [PHP-DEV] [PATCH] [ZE] More useful error message for class redeclaration

2002-09-23 Thread Andi Gutmans

Can't you make sure that the filename of internal classes will be NULL and 
then we can check for it and say it's an internal class?

Andi

At 03:59 PM 9/23/2002 +0100, Wez Furlong wrote:
>X-Managedo-partname: name="1.1"; mimetype="text/plain"
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>I'm resubmitting this little patch for the ZE; when presented with
>code like this:
>
>class Foo {
>}
>
>class Foo {
>}
>?>
>
>The engine will generate an error message like this:
>
>Cannot redeclare class Foo (previously declared in file.php:2)
>
>Caveat Emptor: if someone tries to redeclare an internal/builtin class
>such as Directory, the previous declaration will appear to be the
>actual declaration in the script.  I'm not sure of the best way to
>resolve this.
>
>--Wez.
>
>--
>Wez Furlong
>The Brain Room Ltd.
>
>X-Managedo-partname: name="1.2"; mimetype="text/plain"
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
>  filename="redclare_class.diff.txt"
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Re: var_export() and arrays

2002-09-08 Thread Andi Gutmans

At 02:48 PM 9/4/2002 +0900, Yasuo Ohgaki wrote:
>Sebastian Bergmann wrote:
>> > $array = array('foo', 'bar');
>> var_export($array);
>> ?>
>>   prints
>> array (
>>   0 => 'foo',
>>   1 => 'bar',
>> )
>>   The comma after 'bar' is superfluous.
>
>I agree, but it has been discussed recently.
>Derick added extra , since it should not harm
>any.
>
>(there are shell script languages accept
>extra , like this also)

C also allows the extra , exactly for the reason of auto-generated source 
files.

Andi


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




[PHP-DEV] Re: [Zend Engine 2] PHP/ZE2 win32 snapshots Bug with Constants

2002-09-08 Thread Andi Gutmans

This sounds very strange. It sounds to me as if your scanner wasn't built 
correctly for some odd reason.

Andi

At 10:45 AM 9/6/2002 +0200, phpsurf wrote:
>Hi
>
>I tried the latest windows binaries of PHP with ZE2 built yesterday by Edin
>on http://snaps.php.net/win32/ZE2 and there is still a bug with pre-defined
>boolean constants :
>
>when php is used as an apache module (apache 1.3.24)
>
>
>var_dump(True);
>var_dump(TrUe);
>var_dump(False);
>var_dump(FaLse);
>
>?>
>
>outputs:
>
>string(4) "True"
>string(4) "TrUe"
>string(5) "False"
>string(5) "FaLse"
>
>instead of:
>
>bool(true)
>bool(true)
>bool(false)
>bool(false)
>
>but what is strange is that when this script is called in command line:
>php -f test.php, then it outputs
>
>bool(true)
>bool(true)
>bool(false)
>bool(false)
>
>
>
> > -Original Message-
> > From: Edin Kadribasic [mailto:[EMAIL PROTECTED]]
> > Sent: jeudi 5 septembre 2002 14:07
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-DEV] PHP/ZE2 win32 snapshots available
> >
> >
> > Hello all,
> >
> > Windows snapshots of the latest version of PHP featuring ZE2 are
> > available at:
> >
> > http://snaps.php.net/win32/ze2/
> > or
> > http://ftp.proventum.net/pub/php/win32-snapshots/ze2/
> >
> > Edin
> >
> >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>Pour mieux recevoir vos emails, utilisez un PC plus performant !
>Découvrez la nouvelle gamme DELL en exclusivité sur i (france)
>http://www.ifrance.com/_reloc/signedell


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




Re: [PHP-DEV] Sound API for php

2002-09-08 Thread Andi Gutmans

At 11:00 AM 9/8/2002 +0100, Wez Furlong wrote:

> > 3) will be midi functions,this is a long way off yet so I haven't given
> > it too much thought yet. Also it is likely to be a separate module as it
> > will need to link against a separate library and I can't think of any
> > PHP modules that link against 2 libs.
>
>I don't think there is a need to make this into two separate extensions
>(it just makes things harder for the end user) - you can link to as many
>libs as you like from your extension.

This isn't quite true. Theoretically you (as the end-user) shouldn't load a 
GPL library with PHP (as that can be looked upon as linking). Only LGPL 
works in such a case.
However, often one can get permission from the author of the GPL library.

Andi


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




Re: [PHP-DEV] Sound API for php

2002-09-07 Thread Andi Gutmans

You might want to put this into Pear. In any case, if you want to post the 
API just to get people's input (naming conventions of functions and so on) 
feel free to post here.

Andi

At 06:28 PM 9/7/2002 +0100, Tony Leake wrote:
>Hi,
>
>I have started to write an audio api for PHP.
>
>I have written a wrapper to ecasound which is a very powerful
>audio processing library that runs on Linux and I believe several
>other *NIX's. At the simple end it will play audio files in most
>audio formats (wav, mp3, ogg-vorbis, AIFF etc) and convert files
>between any supported formats.
>
>At the higher end, ecasound can be used to create a full multi-track
>recording/mixing system in just a few lines of code.
>
>Ecasound currently has bindings for c, c++, perl and python so I
>decided to address the balance to write PHP bindings. I currently
>have this working and am testing it. It will then be possible to
>write advanced audio applications in PHP with a Gtk interface.
>
>My next stage will be to write higher level functions for simple
>tasks such as playing an MP3 file, as, like most powerful libraries,
>the ecasound interface can be cryptic at times.
>
>Further on I plan to write midi functions once I find a suitable
>library.
>
>My question is, is there any interest in bundling an audio extension
>with PHP. If not then I will run this on sourceforge as a separate
>project, but if there is I will publish my proposed api to ensure that
>it is compatible with the rest
>of PHP.
>
>Regards
>Tony Leake
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] ISAPI Crash Debugging Notes

2002-09-01 Thread Andi Gutmans

At 05:11 PM 9/1/2002 -0700, Michael Sisolak wrote:
>Andi,
>
>I download the alpha2 version of the php-4.3.0-dev-zend2 release.
>Unfortunatley out-of-the-box I got an "Invalid access to memory
>location." error returned when I try to view I page.  I was able to
>track it down to something with the browscap processing - something in
>ini_parse() is causing a memory access violation, but I get lost in all
>the lex code trying to figure out exactly what is going on.  I disabled
>my browscap entry and was able to continue with the testing.

That's strange. I know browsecap isn't really supposed to work (I commented 
out lots of code to get Engine 2 to work) but it shouldn't crash. It 
doesn't crash for me. Are you actually calling it? Can you try not loading it?


>It does appear that the issue I'm seeing with the first thread getting
>the GLOBAL_FUNCTION_TABLE as it's own local copy is fixed in Zend2:
>
>[1340] the startup thread is 1996
>[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
>[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360
>[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
>[1340] in HttpExtensionProc thread 532, CG(function table) is 22055840
>[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360
>
>The initial thread does now get it's own copy of the
>GLOBAL_FUNCTION_TABLE.  Since it will be a while before Zend2 is
>production quality do you think it would be possible to port what makes
>this work in Zend2 back to 4.2.x?  The changes in zend.c seem fairly
>straight forward, but there may be interactions with other changes I'm
>not seeing.

This code is quite complex as you have probably noticed. I moved some stuff 
around there for Engine 2 but it's not very easy to port these changes back 
to Engine 1 especially as I'm not sure I actually fixed any bugs. Bugs 
weren't the reason for me shifting it around. If you can figure out what 
changes in Engine 2 actually make the difference then we can look at them 
but it might mean lots of work for you.

Andi


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




Re: [PHP-DEV] adding persistent toggle to zend_stack implementation

2002-09-01 Thread Andi Gutmans

I think this is fine.

Andi

At 11:32 AM 8/27/2002 -0400, George Schlossnagle wrote:
>Hi,
>
>I'd like to use the zend_stack stuff for stacked handlers in the new 
>apache_hooks sapi stuff, but right now, it emalloc's everything, which is 
>unacceptable for my usage.  I could write my own stack implementation just 
>for the sapi stuf, but thats seems less productive than making zend_stack 
>more universally useable.
>
>I've added a persistent attribute to the struct so that it behaves more 
>like zend_hash, added a zend_stack_init_ex which allows setting of this 
>flag, and #define'd zend_stack_init to do a non-persistent 
>zend_stack_init_ex.  Patches are attached.
>
>If this is somehow undesireable, please let me know and I will just 
>reimplement stacks for sapi.
>
>George
>
>
>
>
>Index: Zend/zend_stack.c
>===
>RCS file: /repository/Zend/zend_stack.c,v
>retrieving revision 1.11
>diff -u -3 -r1.11 zend_stack.c
>--- Zend/zend_stack.c   6 Jan 2002 15:21:09 -   1.11
>+++ Zend/zend_stack.c   27 Aug 2002 15:15:37 -
>@@ -21,10 +21,11 @@
>  #include "zend.h"
>  #include "zend_stack.h"
>
>-ZEND_API int zend_stack_init(zend_stack *stack)
>+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent)
>  {
> stack->top = 0;
>-   stack->elements = (void **) emalloc(sizeof(void **) * 
>STACK_BLOCK_SIZE);
>+stack->persistent = persistent;
>+   stack->elements = (void **) pemalloc(sizeof(void **) * 
>STACK_BLOCK_SIZE,  persistent);
> if (!stack->elements) {
> return FAILURE;
> } else {
>@@ -36,13 +37,13 @@
>  ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size)
>  {
> if (stack->top >= stack->max) { /* we need to allocate 
> more memory */
>-   stack->elements = (void **) erealloc(stack->elements,
>-  (sizeof(void **) * (stack->max += 
>STACK_BLOCK_SIZE)));
>+   stack->elements = (void **) perealloc(stack->elements,
>+  (sizeof(void **) * (stack->max += 
>STACK_BLOCK_SIZE)), stack->persistent);
> if (!stack->elements) {
> return FAILURE;
> }
> }
>-   stack->elements[stack->top] = (void *) emalloc(size);
>+   stack->elements[stack->top] = (void *) pemalloc(size, 
>stack->persistent);
> memcpy(stack->elements[stack->top], element, size);
> return stack->top++;
>  }
>@@ -63,7 +64,7 @@
>  ZEND_API int zend_stack_del_top(zend_stack *stack)
>  {
> if (stack->top > 0) {
>-   efree(stack->elements[--stack->top]);
>+   pefree(stack->elements[--stack->top], stack->persistent);
> }
> return SUCCESS;
>  }
>@@ -96,11 +97,11 @@
> register int i;
>
> for (i = 0; i < stack->top; i++) {
>-   efree(stack->elements[i]);
>+   pefree(stack->elements[i], stack->persistent);
> }
>
> if (stack->elements) {
>-   efree(stack->elements);
>+   pefree(stack->elements, stack->persistent);
> }
> return SUCCESS;
>  }
>Index: Zend/zend_stack.h
>===
>RCS file: /repository/Zend/zend_stack.h,v
>retrieving revision 1.13
>diff -u -3 -r1.13 zend_stack.h
>--- Zend/zend_stack.h   6 Jan 2002 15:21:09 -   1.13
>+++ Zend/zend_stack.h   27 Aug 2002 15:15:37 -
>@@ -22,14 +22,14 @@
>  #define ZEND_STACK_H
>
>  typedef struct _zend_stack {
>-   int top, max;
>+   int top, max, persistent;
> void **elements;
>  } zend_stack;
>
>
>  #define STACK_BLOCK_SIZE 64
>-
>-ZEND_API int zend_stack_init(zend_stack *stack);
>+#define zend_stack_init(a) zend_stack_init_ex(a, 0);
>+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent);
>  ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size);
>  ZEND_API int zend_stack_top(zend_stack *stack, void **element);
>  ZEND_API int zend_stack_del_top(zend_stack *stack);
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] ISAPI Crash Debugging Notes

2002-09-01 Thread Andi Gutmans

Any chance you can setup and Engine 2 build and see if this problem persists?

Andi

At 06:42 AM 8/27/2002 -0700, Michael Sisolak wrote:

>--- Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > At 09:53 27/08/2002, Michael Sisolak wrote:
> > > > >i've been doing some debugging of the crashes when running php
> > under
> > > > >the isapi sapi.  is anybody else currently looking at this?  if
> > you
> > > > >are let's talk - here are my notes so far.
> > > >
> > > > first off, can you try using
> > > > http://www.php.net/~zeev/php-4.2.3rc1.tar.gz
> > > > and see if you experience the same problems?  i've made some
> > > > thread-safety related fixes there, even though none should lead
> > > > to a hard crash...
> > >
> > >zeev,
> > >
> > >i believe that i may have tracked down a major isapi filter
> > >thread-safety hole.  if i understand  what zend_startup() is doing
> > >correctly, it assumes that the thread that it runs under will not
> > also
> > >be used to serve http requests.
> >
> > No, the startup thread can be used as a regular HTTP thread, nothing
> > in the
> > code should prevent that.
> > The globals code in the startup sequence is very tricky, but it
> > should work.
>
>This is a sample of the debug output that I'm seeing (this is PHP 4.2.1
>running under Windows 2000 Professional, single CPU):
>
>[1948] the startup thread is 1956
>[1948] GLOBAL_FUNCTION_TABLE is 4226120
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>[1948] in HttpExtensionProc thread 1520, CG(function_table) is 18834536
>[1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>[1948] in HttpExtensionProc thread 1256, CG(function_table) is 19250808
>[1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>
>Notice that the initial thread (1956) appears to continue to use
>GLOBAL_FUNCTION_TABLE as it's own CG(function_table).  I'm reporting
>the GLOBAL_FUNCTION_TABLE value from within zend_startup() - is there
>some point later in the code that makes it okay that this is the same
>value that I get for a CG(function_table) later?
>
> > Either way - starting threads from an ISAPI filter/extension is
> > completely
> > forbidden (or at least strongly discouraged) so even if there is some
> > bug
> > in there, starting our own thread is not an option.
>
>I don't believe that this is true.  In this sample on MSDN:
>
>http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q197728
>
>their code for GetExtensionVersion calls AfxBeginThread.  Also in this
>document:
>
>http://msdn.microsoft.com/library/en-us/vccore/html/vcconatlserverandcom.asp
>
>point 1 recommends "Create your own thread in GetExtensionVersion on
>which you can initialize COM..."
>
> > Can you give me the data I mentioned in the previous letter?
>
>This is PHP 4.2.1 running under Windows 2000 Professional (SP3) on a
>single CPU system.  I can't really send the code as I'm currently
>testing with a large application that I have been running under CGI.
>I'll see if I can come up with a simpler example that causes the crash,
>but the debug output above would be the same either way.  Please let me
>know if there is anything else I can provide to help in tracking this
>down.
>
>
>Michael Sisolak
>[EMAIL PROTECTED]
>
>
>__
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Possible leak in zend_llist ?

2002-09-01 Thread Andi Gutmans

Hey,

I think you're right. Someone changed this code a while ago and might have 
introduced this problem (or it was like this before).
I commited a fix and hope it doesn't break anything :)
If anyone uses llist's please make sure it's OK.

Andi

At 07:30 AM 8/27/2002 -0400, l0t3k wrote:
>hi,
>  im reviewing the source code of zend_llist.c and it appears there may be an
>inconsistency in the way deletions are handled which may cause leaks.
>   in particular the macro DEL_LLIST_ELEMENT only releases memory for a node
>if a destructor is specified for the zend_llist, whereas memory is always
>allocated for the node when an insert is performed.
>this macro is used only in zend_llist_apply_with_del and
>zend_llist_del_element. note that
>no other code in the file assumes that the destructor function is
>responsible for the deallocation of the _node_
>
>compare DEL_LLIST_ELEMENT (snippet)
>
>if ((l)->dtor) {\
> (l)->dtor((current)->data);\
> pefree((current), (l)->persistent);\
>}\
>
>with zend_llist_destroy
>
>   if (l->dtor) {
>l->dtor(current->data);
>   }
>   pefree(current, l->persistent);
>
>
>l0t3k
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] friendly classes

2002-08-21 Thread Andi Gutmans

At 10:59 AM 8/21/2002 +0100, Tom Oram wrote:
>Hi,
>I'm currenly looking at/doing a lot of object orientated PHP so I have been
>looking into what new features Zend 2 will offer me. I have just run into a
>situation where if I was using Zend 2 I would need some sort of implementation
>of C++ friends, I'm not to sure about the java alternative (is it package
>access?). Anyway is this consept likely to appear in PHP at any time?

I wouldn't want to get into what I consider "the ugly sides of C++'s OOP".
If you need friend then just go ahead and make it public :)

Andi


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




Re: [PHP-DEV] Streams filter API

2002-08-20 Thread Andi Gutmans

At 10:47 PM 8/20/2002 +0100, Wez Furlong wrote:
>Filters are created using:
>   php_stream_filter_create(char *filtername, char *filterparams,
> int filterparamslen, int persistent TSRMLS_DC);
>
>filtername corresponds to the name used to register the factory;
>if no exact match is found, it looks for a factory matching
>".*", and then passes the filtername to it's factory method.
>
>Filterparams is a binary safe string parameter which can carry
>some kind of options to a filter implementation.  For example,
>it might specifit the compression level for a zlib filter, or it
>might control the number of bits used in a cypher, or some kind
>of key for cypto filters.
>The filter API doesn't touch this parameter; it's interpreted only
>by the factory object/method.

Hey,

I think it's probably best to make filterparams a void * because then you 
can pass whatever you want (a structure with all the params and so on). Of 
course you can do it with your current prototype too but this is how it's 
usually done.
I haven't looked into the API itself so if it doesn't make much sense 
ignore me :)

Andi


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




Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

2002-08-20 Thread Andi Gutmans

At 11:20 AM 8/20/2002 -0700, Rasmus Lerdorf wrote:
> > By the way, the only personal gain I have in getting ZE2 out of there is
> > that it's my code and that PHP will do much better. I think that PHP is
> > going to loose out big time if things don't start gaining some momentum.
> > Backporting is definitely a momentum breaker *especially* as everyone
> > really really wants to backport it badly. That's exactly my point. If you
> > guys want it so badly then work for it! :)
>
>Andi, everybody reading this list can rather simply patch it in
>themselves. At least, I already have. It's not us we are talking about
>here, it is the general user population. This is a patch that helps users
>now. That's what is important.
>
>Us, the developers of php-dev, will move to php5 at the same rate
>regardless of this patch.  And when the developers move to php5 the users
>will invariably follow as they start to see all the support shifting to
>that version.

I'm also starting to get tired so I'll make this my last Email (hopefully).
I emailed Thies in private about this issue and I have a feeling he'll 
commit the patch.
I just want to summarize a few points I wrote him:
I see adding debug_backtrace() to ZE1 tactical thinking. I think postponing 
it to ZE2 is strategic thinking. It's not to do with who wants to help PHP 
users more, but how we think we'll manage to help them more. Obviously as 
the person who wrote the patch all my intention was to help the average PHP 
user.
The current mood on php-dev is "it'll take years for PHP 5 to be released 
so let's add it". I think if everyone here would work hard on it we could 
get it out within about 4 months. That would only happen if ppl were to 
write less Emails and do more organizing and coding though. Unlikely... PHP 
4.3 has been lingering forever. We could have released PHP 5 in this time. 
Okay, I still have a couple of things on my ZE2 todo but they could have 
been slipped in gradually while the rest get their stuff ready.

Personally, I think it's time to help PHP keep up with its competitors. I 
think we should invest our energy in that.
debug_backtrace() was the wake-up call to remind ppl to look into the future.

Let's just keep it at that because I'm getting tried and prefer working on 
useful stuff like working on the next version of PHP.
Andi


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




Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

2002-08-20 Thread Andi Gutmans

At 09:55 PM 8/19/2002 -0700, Brad LaFountain wrote:
> > I still think it shouldn't go in.  This is the only feature in Engine 2
> > which might make non-OOP people convert. Once this isn't in Engine 2 we
> > don't have a carrot for them.
>
>  You as a Zend owner who's business could be very propitable for Zend2 
> success
>or you as a php developer, think that debug_backtrace is bad for php. 
>Sometimes
>I think that your and zeev's ideas are more business oriented than better for
>the php community. I'm sure im wrong but thats the way it seems from where I
>sit.
>  I think that Thies is right he's not trying to back port all of the zend2
>functionality but debug_backtrace should have been in many years ago. Holding
>back such an important feature just so more people would move to zend2 isnt
>going to make zend2 more popular but I think it doesn't move php forward at
>all. I would like to see everyone to move to zend2 but we all know that isn't
>going to happen with our without including debug_backtrace to zend1, php4 
>isn't
>going to go away as easy as php3 did no matter how big the carrot is.
>
> > Why can't you respect this way of thinking? Especially as I wrote the 
> code?
> > You're basically saying screw them because I'll commit it anyway.
>
>  I think he should commit it anyways. He isn't disrespecting you he just 
> feels
>strongly against you (as do alot of others). Sometimes I don't think you
>respect their way of thinking.
>
>  Sorry if this email sounds like its attacking you. It isn't intended to.

Hey,

The reason for my objection is not business oriented whatsoever. I did 
witness the transitions from PHP/FI 2 -> PHP 3 (ZE 0.5) and PHP 3 -> PHP 4. 
The first transition wasn't too difficult although there were quite a lot 
of BC issues because the user base wasn't too big. The PHP 3 -> PHP 4 
transition was actually quite hard. It took us a long time to get php-dev@ 
moving on the new version because most of them were still using PHP 3 for 
their production sites.
The fact that you guys are so strongly in favor of putting this cool 
feature into ZE1 proves that not putting it in could give ZE2 a big boost 
of momentum. Everyone feels very strongly about this feature. (On a side 
note, at least that makes me happy that people liked this 
revolutionary/negligible performance impact patch :)

I think we need this new momentum. A new version of the engine is very 
important if we want PHP to compete with the latest technologies. If PHP 
doesn't get moving on its next version I'm afraid it won't be able to 
maintain its current position in the market.
The only person I have seen thinking of what he'd like to get done for PHP 
5 is Wez.
By the way, the only personal gain I have in getting ZE2 out of there is 
that it's my code and that PHP will do much better. I think that PHP is 
going to loose out big time if things don't start gaining some momentum. 
Backporting is definitely a momentum breaker *especially* as everyone 
really really wants to backport it badly. That's exactly my point. If you 
guys want it so badly then work for it! :)

Andi


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




Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

2002-08-18 Thread Andi Gutmans

At 07:50 PM 8/18/2002 +0200, Thies C. Arntzen wrote:
>On Sun, Aug 18, 2002 at 10:29:47AM -0700, Rasmus Lerdorf wrote:
> > I don't think we should stop people from tweaking ZE1. ZE2 is probably
> > more than a year away from realistically being available to a lot of
> > people. It takes a while for people to upgrade, and many will skip the .0
> > release.  If a few tweaks to ZE1 can eliminate peoples' motivation to move
> > to ZE2, then why are you writing ZE2?  I obviously don't think that is the
> > case as ZE2 has a number of features people have been asking for.
>
> i (of course) agree with derick and rasmus. i'm all for
> applying the patch as is. if zeev and andi don't want to
> comment on it for their own reasons i cannot help them. if
> the patch has a problem it'll be found very soon and it'll
> be fixed.

This isn't a conspiracy but I just completely forgot about your Email. 
Obviously if it is decided that this patch goes into Engine 1 I will look 
it over. The last thing I'd do was to allow a buggy patch to enter the Engine.


> if there is any *technical* reason why this patch is "not as
> good" as the debug_backtrace that is in ZE2 - let me know.
> otherwise i'll commit on monday.

I don't think that there are any big technical reasons not to include the 
patch although it might be a bit buggy though as it hasn't been tested very 
extensively.

I do think you guys should consider the psychological aspects of starting 
to back port my patches from Engine 2.
I personally think that the ZE2 is essential for PHP to prosper in the next 
few years. The only way it can be pushed is if not only Zeev and I but 
other people in the community help push it too. It was mentioned that there 
are a couple of things still missing. I can sum it up that the two main 
features which are missing are some inheritence problems with nested 
classes, private methods and a delegation mechanism which was discussed on 
engine2 for which came up with a pretty decent way of doing which stays 
with the PHP spirit. These things will be implemented and there is no 
reason to wait until they are fully implemented in order to start pushing 
things a bit more. I started with a couple of alpha's and I definitely want 
to go for another one soon as I fixed some bugs.

In the same way we didn't back port some ideas from PHP 4 to PHP 3 I think 
it's best not to do it now. Because in the end, once we (php-dev) 
transitions to ZE2 our support will naturally start shifting more and more 
towards the latest versions (the same as it did in the PHP 3 -> PHP 4 
transition). After sometime people on php-dev just won't feel like working 
on old stuff anymore. Therefore, I think we should make the benefit of 
transition to ZE2 as great as possible so that people migrate.
As to the comparison to Apache 2 I think you're far off. The PHP 3 -> PHP 4 
transition was much smoother than that and the ZE1 -> ZE2 transition isn't 
even between rewrites but just improvements over the old stable version. 
Once a significant amount of people use it I think it'll take 2-3 months to 
iron out the bugs.

Andi


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




Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

2002-08-18 Thread Andi Gutmans

I also think we should make sure enough people have motivation to move to 
ZE2. If not it'll be hard to push it out and we all know that it's a very 
important step for PHP. As it is, there is still not enough momentum behind it.
Andi

At 05:38 PM 8/18/2002 +0300, Zeev Suraski wrote:
>I said before - I prefer not having any changes in ZE1, for both stability 
>reasons and also as a motivation to get ZE2 out the door more quickly.
>
>Zeev
>
>At 17:21 18/08/2002, Thies C. Arntzen wrote:
>
>> if noone objects i'm going to commit this to -HEAD (and we
>> can start discussing it then;-)
>>
>> re,
>> tc
>>
>>On Fri, Aug 16, 2002 at 07:39:59PM +0200, Thies C. Arntzen wrote:
>> >
>> > hi,
>> >
>> > this patch adds the extremely useful debug_backtrace()
>> > function to ZE1.  as it's more-or-less the same
>> > implementation as in ZE2 so it should be "fast and efficient"
>> > enough for inclusion in 4.3 IMHO.
>> >
>> > it has one extra feature over the ZE2 implementation by
>> > giving some extra information if a method was called
>> > using :: or -> (see the 'type' attribute in the array
>> > returned by debug_backtrace).
>> >
>> > zeev, andi one question: i had to comment line 1628 (just
>> > apply the patch and see for yourself) to make the following
>> > code work correctly (= show the class in the backtrace):
>> >
>> > > > class a {
>> >   function dump() {
>> >   var_dump(debug_backtrace());
>> >   }
>> > }
>> >
>> > $a = new a;
>> > $a->dump();
>> > ?>
>> >
>> > (just uncomment line 1628 in the patched sources and see how
>> > the output of debug_backtrace doesn't show the class-name for
>> > this script any more)
>> >
>> > i don't think that commenting this line will have any
>> > side-effect as EG(object).ptr will be re-initialized in 1665
>> > and i don't see any references to it in between.
>> >
>> > i'd love to have this included in 4.3.0 and i think a lot of
>> > people would be happy as well.
>> >
>> > implementation:
>> > to make this whole thing work i simply added the class_entry
>> > to the execute_data and am pushing and popping it together
>> > with (object).ptr.
>> >
>> > if this patch gets accepted i'll add an php.ini seting so
>> > that errors and warnings will optionally have the full
>> > call-stack.
>> >
>> >
>> > comments are welcome - especially from andi & zeev.
>> > tc
>> >
>> > PS: patch is against -HEAD
>> >
>> > --
>> > Thies C. Arnzten   -   Looking for all sorts of freelance 
>> work  -   just ask..
>> > Whishlist: 
>> http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ/ref=wl_em_to
>>
>> > ? ext/tca_prof
>> > Index: Zend/zend_builtin_functions.c
>> > ===
>> > RCS file: /repository/Zend/zend_builtin_functions.c,v
>> > retrieving revision 1.118
>> > diff -u -r1.118 zend_builtin_functions.c
>> > --- Zend/zend_builtin_functions.c 12 Jun 2002 17:02:22 
>> -  1.118
>> > +++ Zend/zend_builtin_functions.c 16 Aug 2002 17:22:01 -
>> > @@ -65,6 +65,7 @@
>> >  static ZEND_FUNCTION(extension_loaded);
>> >  static ZEND_FUNCTION(get_extension_funcs);
>> >  static ZEND_FUNCTION(get_defined_constants);
>> > +static ZEND_FUNCTION(debug_backtrace);
>> >  #if ZEND_DEBUG
>> >  static ZEND_FUNCTION(zend_test_func);
>> >  #endif
>> > @@ -116,6 +117,7 @@
>> >   ZEND_FE(extension_loaded,   NULL)
>> >   ZEND_FE(get_extension_funcs,NULL)
>> >   ZEND_FE(get_defined_constants,  NULL)
>> > + ZEND_FE(debug_backtrace,NULL)
>> >  #if ZEND_DEBUG
>> >   ZEND_FE(zend_test_func, NULL)
>> >  #endif
>> > @@ -1133,6 +1135,69 @@
>> >   array_init(return_value);
>> >   zend_hash_apply_with_argument(EG(zend_constants), 
>> (apply_func_arg_t) add_constant_info, return_value TSRMLS_CC);
>> >  }
>> > +
>> > +/* {{{ proto void debug_backtrace(void)
>> > +   Prints out a backtrace */
>> > +ZEND_FUNCTION(debug_backtrace)
>> > +{
>> > + zend_execute_data *ptr;
>> > + int lineno;
>> > + char *function_name;
>> > + char *filename;
>> > + char *class_name;
>> > + zend_uint class_name_length;
>> > + zval *stack_frame;
>> > +
>> > + ptr = EG(execute_data_ptr);
>> > +
>> > + /* Skip debug_backtrace() itself */
>> > + ptr = ptr->prev_execute_data;
>> > +
>> > + array_init(return_value);
>> > +
>> > + while (ptr) {
>> > + MAKE_STD_ZVAL(stack_frame);
>> > + array_init(stack_frame);
>> > +
>> > +
>> > +/*   if (ptr->object) {
>> > + class_name = Z_OBJCE(*ptr->object)->name;
>> > + class_name_length = 
>> Z_OBJCE(*ptr->object)->name_length;
>> > + }
>> > + if (ptr->function_state.function->common.scope) {
>> > + class_name = 
>> ptr->functio

RE: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-08-16 Thread Andi Gutmans

At 06:24 PM 8/7/2002 +0200, phpsurf wrote:
>Hi
>
>I'm testing this great feature ...
>but unfortunately, it lokos like it doesn't work for extended classes either
>!
>
>in brad's example (in the history of this mail)
>you cannot remove the include_once statements in the children classes (I
>would rather replace them with the apropriate call to the __autoload
>function)
>
>the class MyFoo extends Foo
>when you try to instantiate Foo, __autoload works perfectly.
>but when you try to instantiate MyFoo, it fails with the following message:
>"Fatal error: Class myfoo: Cannot inherit from undefined class foo in
>c:\webroot\ze2\myfoo.php on line 2"
>
>andi ? is it not supposed to work either with extended classes ?

Can you please send me a very short script which reproduces your problem?

Thanks,

Andi

> > -Original Message-
> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> > Sent: mercredi 26 juin 2002 21:02
> > To: Brad LaFountain; Ivan Ristic; phpsurf
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class
> > Autoloading [PATCH]
> >
> >
> > Hey,
> >
> > What I meant was nested classes, my bad :)
> > I meant it won't work for Foo::Bar::Barbara but only for class Foo.
> >
> > Andi
> >
> > At 11:56 AM 6/26/2002 -0700, Brad LaFountain wrote:
> > > > - will never work for sub-classes so don't even ask!
> > >
> > >Andi,
> > >
> > >  This doesn't need to be an issue. The way that I use
> > sub-classes is I ALWAYS
> > >include_once("subclass.php"); at the top of each superclass file. I know
> > >everyone doesn't code the same way but maybe you can have that
> > as a suggestion
> > >to people who use __autoload.
> > >
> > >Foo.php
> > >class Foo{}
> > >
> > >Bar.php
> > >class Bar{}
> > >
> > >MyFoo.php
> > >include_once("Foo.php");
> > >class MyFoo extends Foo{}
> > >
> > >MyBar.php
> > >include_once("Bar.php");
> > >class MyBar extends Bar{}
> > >
> > >
> > >auto_test.php
> > > > >function __autoload($name) {
> > >  include_once("$name.php");
> > >}
> > >$f = new MyFoo();
> > >$b = new MyBar();
> > >?>
> > >
> > >- brad
> > > >
> > > > At 11:27 PM 6/11/2002 +0100, Ivan Ristic wrote:
> > > > > > Okay, I guess I can live with it :)
> > > > > >
> > > > > > Andi
> > > > >
> > > > >   Is there anyone else who would like to comment on the
> > > > >   patch?
> > > > >
> > > > >   http://www.webkreator.com/download/class_autoload.patch
> > > > >
> > > > >   Or can we have it committed?
> > > > >
> > > > >--
> > > > >Ivan Ristic, [EMAIL PROTECTED]
> > > > >[ Weblog on PHP, Software development, Intranets,
> > > > >and Knowledge Management: http://www.webkreator.com ]
> > > > >
> > > > >
> > > > >--
> > > > >PHP Development Mailing List <http://www.php.net/>
> > > > >To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >
> > >
> > >__
> > >Do You Yahoo!?
> > >Yahoo! - Official partner of 2002 FIFA World Cup
> > >http://fifaworldcup.yahoo.com
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>i (france), c'est aussi une gamme complète de PC en exclusivité avec DELL
>http://www.ifrance.com/_reloc/signedell


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




Re: [PHP-DEV] phpthreads - hints anyone...

2002-08-03 Thread Andi Gutmans

At 09:20 PM 8/3/2002 -0700, Brad LaFountain wrote:
>This isn't always ideal. I would rather see the threads as a function not a
>separate file. Forcing threads to a file would be pretty limited.

I don't think it's that limited. I also don't think that duping the whole 
thread's address space is a good idea. It's slow and prone to errors.

Andi


>  -brad
>--- Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > I still think that if you're going to implement such a thread extension it
> > shouldn't try and copy it's parents data-structures. It'd be very slow and
> > prone to errors.
> > I think giving a filename as the starting point of the thread would be the
> > best solution. It'd mean that the thread is pretty much a completely new
> > request. It would also mean much leaner threads as you could create .php
> > files with only the logic the thread requires.
> >
> > Andi
> >
> > At 02:30 PM 8/3/2002 -0700, Shane Caraveo wrote:
> > >I've cleaned things up a bit, removed code from tsrm and added it to a 
> new
> > >file, and commited to pecl.  This way those interested can start playing
> > >with and developing the module.
> > >
> > >Shane
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>Do You Yahoo!?
>Yahoo! Health - Feel better, live better
>http://health.yahoo.com


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




Re: [PHP-DEV] phpthreads - hints anyone...

2002-08-03 Thread Andi Gutmans

I still think that if you're going to implement such a thread extension it 
shouldn't try and copy it's parents data-structures. It'd be very slow and 
prone to errors.
I think giving a filename as the starting point of the thread would be the 
best solution. It'd mean that the thread is pretty much a completely new 
request. It would also mean much leaner threads as you could create .php 
files with only the logic the thread requires.

Andi

At 02:30 PM 8/3/2002 -0700, Shane Caraveo wrote:
>I've cleaned things up a bit, removed code from tsrm and added it to a new 
>file, and commited to pecl.  This way those interested can start playing 
>with and developing the module.
>
>Shane
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] phpthreads - hints anyone...

2002-08-03 Thread Andi Gutmans

At 12:40 PM 8/3/2002 -0700, Shane Caraveo wrote:
>Andi Gutmans wrote:
>>By the way, if we do end up making this kind of thing mainstream we 
>>should probably use APR (or another library) for thread abstraction. I 
>>wouldn't want to do all of that work over.
>>Andi
>
>That would be nice, but not sure how realistic at this point.  Idealy, we 
>would be using APR throughout PHP.

I'm not saying we should change all of PHP right now but if you're going to 
add thread function abstractions then we might as well use APR.

Andi


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




Re: [PHP-DEV] Error in zend2_example.phps

2002-08-03 Thread Andi Gutmans

Thanks. I've fixed this.

Andi

At 05:51 PM 7/18/2002 +0200, Sander Steffann wrote:
>I think zend2_example.phps has a little error in example 6:
>
>The display function is defined as:
> function display()
> {
> print $this->name;
> print "\n";
> }
>
>But then it is called with:
> print $person->getName()->display();
>
>Either the function should use return, or the call shouldn't use print...
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] New FTP extension functionality

2002-08-03 Thread Andi Gutmans

At 02:05 PM 7/30/2002 -0400, Joao Prado Maia wrote:

>So are we going to rename these functions because of this ? It seems kind
>of weird of having ftp_async_get() when the function is not really
>asynchronous ;)
>
>If what Sterling just said is really accurate, _please_ don't release
>4.3.0 with the wrong function names. It just doesn't look professional :)

I agree :)
It should probably be something like ftp_nb_get().

Andi


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




Re: [PHP-DEV] [ZE2] clone_obj function and __clone method

2002-08-03 Thread Andi Gutmans

clone_obj is the C handler for overloaded objects. In case of PHP objects 
clone_obj calls __clone.

Andi

At 12:37 AM 7/18/2002 -0400, l0t3k wrote:
>A quick question about the above...
>what is the relationship between the clone_obj handler and the __clone
>method. For instance, if i define the clone_obj handler, do i need to define
>the a __clone method on the same object ? is clone_obj for a shallow and
>__clone for deep copying ?
>
>l0t3k
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Weird?!?!

2002-08-03 Thread Andi Gutmans

I think this is a good question.
I'm not quite sure that casting dval to long is the same as multiplying the 
two longs.
Anyone know the answer?

Andi

At 02:28 PM 7/31/2002 +0200, Stefan Esser wrote:
>Hi,
>
>Could someone tell me why the Zend Engine calculates every multiplication
>2 times???
>
>zend_operators.c:
>
>ZEND_API int mul_function(zval *result, zval *op1, zval *op2 TSRMLS_DC)
>{
>...
> if (op1->type == IS_LONG && op2->type == IS_LONG) {
> double dval = (double) op1->value.lval * (double) 
> op2->value.lval;
>
> if ((dval > (double) LONG_MAX) || (dval < (double) 
> LONG_MIN)) {
> result->value.dval = dval;
> result->type = IS_DOUBLE;
> } else {
> result->value.lval = op1->value.lval * 
> op2->value.lval;
> result->type = IS_LONG;
> }
> return SUCCESS;
>
>...
>
>should that be replaced with:
>
>result->value.lval = (long)dval;
>
>instead of calculating the multiplication again???
>
>
>Stefan Esser
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] HANDLE_BLOCK_INTERRUPTIONS

2002-08-03 Thread Andi Gutmans

Theoretically these should be used when the engine is not in a "stable 
state" (i.e. would crash on shutdown).
As this can also include PHP's code and PHP extensions I'm not really sure 
how much this really helps.

Andi

At 08:04 AM 8/2/2002 -0700, Brad LaFountain wrote:
>Thanks.. I figured it out after looking at all the places where it was being
>used. The biggest use was when you are changing link'd lists or arrays. So i
>assumed it did something to that affect.
>
>  - brad
>--- "Thies C. Arntzen" <[EMAIL PROTECTED]> wrote:
> > On Thu, Aug 01, 2002 at 10:10:10AM -0700, Brad LaFountain wrote:
> > > HANDLE_BLOCK_INTERRUPTIONS();
> > > HANDLE_UNBLOCK_INTERRUPTIONS();
> > >
> > > what exactly does these do?
> >
> > this is an apache thingie. you can tell apache that you
> > don't want to be "killed" during certain operations. i doubt
> > very mucht that it really helps;-) look in the apache sapi
> > module.
> >
> > tc
>
>
>__
>Do You Yahoo!?
>Yahoo! Health - Feel better, live better
>http://health.yahoo.com
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] phpthreads - hints anyone...

2002-08-03 Thread Andi Gutmans

At 05:43 PM 8/1/2002 +0800, Alan Knowles wrote:

>>It's not about looking at the perl code, that will tell you nothing 
>>unless you know perl internals.  It's about the way the interpreter 
>>works, some of the architecture, that is simular to PHP.  In PHP, threads 
>>are isolated, kind of like seperate processes, but in threads.
>
>
> From my understanding they are 'forced to be isolated' by the TSRM 
> stuff.  which looks like it stores globals in something like an 
> associated array ( thread id => global c variable - eg. compiler_globals 
> etc.), when ZTS is enabled..
>
>>Everything in PHP works that way, so in creating threads for php scripts, 
>>you have to have a seperate interpreter.  Then you have to create a 
>>"bridge" between the threads for shared variables.  shmop comes close to 
>>what is needed, but not close enough.
>
>the real use of the threading I guess is for people who want to write tcp 
>servers, or desktop gtk apps.
>
>Thoughts on accessing 'threaded shared vars'
>
>$_THREADVAR['gtktext'] type..
>
>php_threads_malloc_lock();
>$_THREADVAR['gtktext']->add_text('some data ouput');
>php_threads_malloc_unlock();
>
>this would I guess involve rather heavy changes to the ZE engine to 
>recogize an lock/unlock, copy (rather than refcount) etc. variables that 
>where threaded..
>
>
>Threaded objects???
>I guess the other consideration is to have thread variable objects..
>$threadvar  = new Thread_Var();
>$threadvar->setNewObject('mywidget','GtkWindow');
>$threadvar->set('mywidget',$gtkobject);
>$var = $threadvar->get('mywidget');
>$var = $threadvar->getArray('key','val');
>$threadvar->callMethod('mywidget', 'add_text','something');
>
>obviously copying and accessing these would probably be easier to cope 
>with ( without having to modify heavily the zend engine) -  we could do 
>'real' copying on the data, rather than refcounting them. and reduce the 
>headaches...
>
>>You're much closer to what needs to happen now.  But you cannot simply 
>>point to the memory for another thread.  Doing that will cause problems 
>>like you are running into.  You actually have to copy a bunch of stuff so 
>>each thread is completely independent.
>
>Do you mean we will have to really physically copy the all theopcode data 
>from one thread to another?
>
>>
>>
>>I've worked up some code in TSRM to abstract native thread calls, and 
>>have started on an extension, but probably won't have it complete until 
>>this weekend some time.  What you've done now is fairly simular, but 
>>pthread specific.  Given time, I might have enough done to email a diff 
>>containing my work tomorrow night if you want to take a look.
>
>Anything I can do to help - testing, understanding - let me know.
>Sounds Great.

First of all I agree that the two threads shouldn't really share the same 
engine instance. It would mean that everything would have to be mutexed. 
The solution of creating a separate interpreter instance and having a 
couple of methods to share data in between them (like shared memory) is the 
way to go.
As creating a copy of a currently executing instance is very hard to do in 
my opinion I suggest an API such as:
create_thread("thread.php");

This would create a new instance of the interpreter which would compile 
thread.php and start running it. So the actual function/class tables of the 
thread could be different from the parent who created it which I think is fine.

Andi


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




[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c zend_compile.h zend_execute.c zend_language_parser.y zend_language_scanner.l zend_operators.c zend_operators.h

2002-08-03 Thread Andi Gutmans

At 02:43 AM 7/30/2002 -0400, Andrei Zmievski wrote:
>On Tue, 30 Jul 2002, Andi Gutmans wrote:
> > Hey,
> >
> > Can't you share the patch before you just go ahead and just commit it? I
> > still have the same issue I used to have.
>
>Hey, the patch has been available for a long while now. :-)
>
> > I think using the cast operators for the types is pretty ugly. The code
> > looks something like:
> > $foo is (int)
> > I we should only support classes and not support basic types? We have the
> > non-OOP function for those. This is really an OOP operator.
>
>Don't you think we should have a unified way of testing for variable's
>type/class? I understand that we don't have type unification yet, but
>having a separate function for each basic type is kind of ugly too.

I'd prefer "is" to be an OOP only construct. i.e. for anything other than 
an object it'd return false.
Just some food for though before we finalize this. This operator will be a 
reserved word. Are we sure we want "is" to be a reserved word? It might be 
used quite a bit.


> > BTW: I think it's a good idea to not declare is_type_expr in the parser 
> but
> > to use catch_or_import_class_entry and change its name to something which
> > fits both. I don't like declaring the same rules more than once if I can
> > help it. This rule will probably also be useful for future things.
>
>Yeah, I think it's a good idea too. Should we call it "class_entry_ref"
>or something like that?

OK by me. I can't think of a very sexy name myself.

Andi


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




Re: [PHP-DEV] phpthreads - hints anyone...

2002-08-03 Thread Andi Gutmans

By the way, if we do end up making this kind of thing mainstream we should 
probably use APR (or another library) for thread abstraction. I wouldn't 
want to do all of that work over.

Andi

At 04:29 PM 8/3/2002 +0800, Alan Knowles wrote:
>Ok, had a play with this
>updated copy on
>http://docs.akbkhome.com/threads.tgz
>
>added a few of pthreads calls to TSRM.c
>
>did most of the testing without this abstraction layer - just to see if I 
>could get it to work.
>
>used php_exectute_script, rather than getting clever and copying the 
>function/class hashtables.
>
>results:
>
>It worked (with a few caveats - that are just a matter of getting to know 
>threading better)...
>
>some of the issues:
>-if the child thread finishes before the main one - then the main one 
>needs to wait somehow..
>** FIX = probably need to keep a count of threads that are running and 
>block at MSHUTDOWN on the main thread if stuff is still going.
>-the child thread needs to have the modules functions loaded before it 
>starts running really - otherwise you get intermitant 'functions not 
>available' if you dont dl() the module in the child thread.
>** FIX = I need to look at the pthreads equivalant for 
>tsrm_wait_event(thread.start_event,TSRM_INFINITE); will be.. this should 
>make sure that the main thread doesnt do anything while the main thread is 
>starting up..
>
>
>- php_request_shutdown(NULL); calls the MSHUTDOWN for all modules - a good 
>example of where this cause trouble is the ext/standard/string.c 
>MSHUTDOWN, which has a static mutex that is freed. (and would be freed 
>twice when the main thread finishes) -
>hence  php_request_shutdown(), probably doesnt want to be called on a 
>thread completion..
>** FIX = not sure? - does this need fixing or should we just ignore 
>php_request_shutdown..
>
>due to the nature of thread scheduling, you dont get anything like '1 
>opcode from thread A, 1 opcode from thread B', more like about 30-40 
>opcodes randomly from each thread..
>
>regards
>alan
>
>
>
>Shane Caraveo wrote:
>
>>Here is a *very* rough peice of code for starting a thread.  It should 
>>get across the idea of how I am thinking threads need to be started, but 
>>it doesn't work (I haven't even tried to run it).  More importantly 
>>though, as a starter, is getting an api into TSRM that will support the 
>>abstraction of any thread calls.  I'm not realy concerned with shared 
>>variables at this point, since I think there is a chunk of work to do in 
>>just getting threads to work.
>>
>>I'm not mailing this onto the list, since I'm sure not too many people 
>>want to get attachments.
>>
>>Shane
>>
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] phpthreads - hints anyone...

2002-08-03 Thread Andi Gutmans

At 04:29 PM 8/3/2002 +0800, Alan Knowles wrote:
>Ok, had a play with this
>updated copy on
>http://docs.akbkhome.com/threads.tgz
>
>added a few of pthreads calls to TSRM.c
>
>did most of the testing without this abstraction layer - just to see if I 
>could get it to work.
>
>used php_exectute_script, rather than getting clever and copying the 
>function/class hashtables.

This was exactly what I suggested a few minutes ago :)

>results:
>
>It worked (with a few caveats - that are just a matter of getting to know 
>threading better)...
>
>some of the issues:
>-if the child thread finishes before the main one - then the main one 
>needs to wait somehow..
>** FIX = probably need to keep a count of threads that are running and 
>block at MSHUTDOWN on the main thread if stuff is still going.
>-the child thread needs to have the modules functions loaded before it 
>starts running really - otherwise you get intermitant 'functions not 
>available' if you dont dl() the module in the child thread.
>** FIX = I need to look at the pthreads equivalant for 
>tsrm_wait_event(thread.start_event,TSRM_INFINITE); will be.. this should 
>make sure that the main thread doesnt do anything while the main thread is 
>starting up..

You should probably make threads a PHP resource and the destructor would 
wait for the thread to finish.


>- php_request_shutdown(NULL); calls the MSHUTDOWN for all modules - a good 
>example of where this cause trouble is the ext/standard/string.c 
>MSHUTDOWN, which has a static mutex that is freed. (and would be freed 
>twice when the main thread finishes) -
>hence  php_request_shutdown(), probably doesnt want to be called on a 
>thread completion..
>** FIX = not sure? - does this need fixing or should we just ignore 
>php_request_shutdown..

I think threads should be treated exactly like a separate request so I 
think most code could run as is.

>due to the nature of thread scheduling, you dont get anything like '1 
>opcode from thread A, 1 opcode from thread B', more like about 30-40 
>opcodes randomly from each thread..

That's fine.

Andi


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




Re: [PHP-DEV] Re: cvs: php4(ZendEngine2) /win32 php4dllts.dsp

2002-07-10 Thread Andi Gutmans

At 05:44 PM 7/10/2002 +0900, Yasuo Ohgaki wrote:
>[EMAIL PROTECTED] wrote:
>>On Wed, 10 Jul 2002, Yasuo Ohgaki wrote:
>>
>>>Hmm. This tag is only for some win32 files.
>>>The name isn't sound good to me.
>>
>>This was brought up before, and it's only needed for some files due to 
>>incompabilities with the ZE1 stuff.
>>Derick
>
>I must have missed that thread and cannot find them with
>quick search.
>
>So we are supposed to use ZendEngine2 tag to support both
>ZE1 and ZE2 if needed, right?

Not sure. Harald created this branch for stuff he was doing. When I package 
Engine 2 alpha's I don't use the branch but use HEAD.

Andi


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




[PHP-DEV] Going on vacation

2002-07-10 Thread Andi Gutmans

Hey,

I'm going on a four day computer-less vacation starting tomorrow morning so 
I won't be reading my Email.
If you guys send patches for the Engine 2 or other queries please give me 
some time to reply when I get back. I'll look them over ASAP.

Thanks,
Andi


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




Re: [PHP-DEV] add'l info: [PHP-DEV] MAKE failed: of php4 cvs/ZendEngine2 dying on OSX Server 10.1.4

2002-07-07 Thread Andi Gutmans

That's really strange. Any chance bison is broken on Mac's?

Andi

At 06:15 PM 7/6/2002 -0700, R Blake wrote:
>continuing to explore this problem, i added --disable-inline-optimization 
>to configure.
>
>now configure fails with:
>
>  Thank you for using PHP.
>
>  config.status: creating php4.spec
>  config.status: creating main/build-defs.h
>  config.status: creating pear/scripts/phpize
>  config.status: creating pear/scripts/php-config
>  config.status: creating main/php_config.h
>  config.status: executing default commands
>  bison -y -p ini_ -v -d 
> /Volumes/ServerSystem/ports/php4/Zend/zend_ini_parser.y -o 
> Zend/zend_ini_parser.c
>  /Volumes/ServerSystem/ports/php4/Zend/zend_ini_parser.y:237: tokens $ 
> and ' both assigned number 0
>  make: *** [Zend/zend_ini_parser.c] Error 1
>
>
>
>a quick test at shell:
>
>[root@server] bison -y -p ini_ -v -d 
>/Volumes/ServerSystem/ports/php4/Zend/zend_ini_parser.y -o 
>Zend/zend_ini_parser.c
>
>gives the same error:
>
>/Volumes/ServerSystem/ports/php4/Zend/zend_ini_parser.y:237: tokens $ and 
>' both assigned number 0
>
>am i closer to the problem?
>
>richard
>
>
>--On Saturday, July 6, 2002 4:03 PM -0700 R Blake <[EMAIL PROTECTED]> wrote:
>
>>hi all,
>>
>>i've been trying to get php4 + ZendEngine2 up & running on OSX Server
>>10.1.4.
>>
>>configure completes OK with:
>>
>>./configure --enable-shared --enable-static --prefix=/usr/local/php4
>>--with-layout=PHP --with-apxs2=/usr/local/apache2/sbin/apxs
>>--with-config-file-path=/private/etc/php4/ --mandir=/usr/local/man
>>--localstatedir=/private/var/php4 --x-includes=/usr/X11R6/include
>>--x-libraries=/usr/X11R6/lib --with-mysql=/usr/local/mysql
>>--enable-force-cgi-redirect --enable-discard-path --disable-xml
>>--with-expat-dir=/usr/local/expat --with-pear
>>
>>but, unfortunately, make is dying at:
>>
>>cc  -IZend/ -I/Volumes/ServerSystem/ports/php4/Zend/ -DPHP_ATOM_INC
>>-I/Volumes/ServerSystem/ports/php4/include
>>-I/Volumes/ServerSystem/ports/php4/main
>>-I/Volumes/ServerSystem/ports/php4 -I/usr/local/apache2/include
>>-I/Volumes/ServerSystem/ports/php4/Zend -I/usr/local/mysql/include/mysql
>>-fno-common -fno-rtti -fno-strict-aliasing -I/System/Library/Frameworks
>>-I/usr/local/include -I/usr/X11R6/include -I/usr/local/BerkeleyDB/include
>>-no-cpp-precomp -no-cpp-precomp -I/Volumes/ServerSystem/ports/php4/TSRM
>>-O3 -L/System/Library/Frameworks -L/usr/lib -L/usr/local/lib
>>-L/usr/X11R6/lib -L/usr/local/BerkeleyDB/lib -DZTS  -c
>>Zend/zend_language_parser.c -o Zend/zend_language_parser.o  && echo >
>>Zend/zend_language_parser.lo Zend/zend_language_parser.c:784: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:785: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:785: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:785: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:785: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:785: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:785: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:785: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:785: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:785: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:785: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:786: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:786: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:786: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:786: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:786: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:786: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:786: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:786: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:786: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:786: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:787: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:787: warning:
>>large integer implicitly truncated to unsigned type
>>Zend/zend_language_parser.c:787: warning: large integer implicitly
>>truncated to unsigned type Zend/zend_language_parser.c:787: warning:
>>large integer implicitly truncated to unsigned typ

[PHP-DEV] Re: [Zend Engine 2] can I have my delete back? :) - patch attached

2002-07-06 Thread Andi Gutmans

Alan,

There was a discussion about this a long time ago and it was decided not to 
support this.
The main reasoning behind this is that we don't want to start supporting 
all other reserved words.
It's one of the things you'll need to cope with when moving to the Engine 2 
but a very simple search&replace on your project should do the trick.

Thanks anyway,
Andi

At 03:06 PM 7/6/2002 +0800, Alan Knowles wrote:
>Attached hopefully is a patch to allow method names called delete .- not 
>functions though..
>
>Speedwise it should not affect performance as its a very small compile 
>time issue..
>
>this would save me an a few others a bit of pain :)
>
>thoughts
>
>regards
>alan
>
>
>
>
>
>
>
>Index: zend_language_parser.y
>===
>RCS file: /repository/ZendEngine2/zend_language_parser.y,v
>retrieving revision 1.59
>diff -u -r1.59 zend_language_parser.y
>--- zend_language_parser.y  29 Jun 2002 15:38:40 -  1.59
>+++ zend_language_parser.y  6 Jul 2002 06:58:49 -
>@@ -429,6 +429,8 @@
> class_variable_decleration ';'
> |   class_constant_decleration ';'
> |   T_FUNCTION { $1.u.opline_num = CG(zend_lineno); } 
> is_reference T_STRING { zend_do_begin_function_declaration(&$1, &$4, 1, 
> $3.op_type TSRMLS_CC); } '('
>+   parameter_list ')' '{' inner_statement_list '}' { 
>zend_do_end_function_declaration(&$1 TSRMLS_CC); }
>+   |   T_FUNCTION { $1.u.opline_num = CG(zend_lineno); } 
>is_reference T_DELETE { zend_do_begin_function_declaration(&$1, &$4, 1, 
>$3.op_type TSRMLS_CC); } '('
> parameter_list ')' '{' inner_statement_list '}' { 
> zend_do_end_function_declaration(&$1 TSRMLS_CC); }
> |   T_OLD_FUNCTION { $1.u.opline_num = CG(zend_lineno); } 
> is_reference T_STRING { zend_do_begin_function_declaration(&$1, &$4, 1, 
> $3.op_type TSRMLS_CC); }
> parameter_list '(' inner_statement_list ')' ';' { 
> zend_do_end_function_declaration(&$1 TSRMLS_CC); }
>alan:/usr/src/php/php4/Zend# cvs diff -u zend_language_scanner.l
>Index: zend_language_scanner.l
>===
>RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
>retrieving revision 1.51
>diff -u -r1.51 zend_language_scanner.l
>--- zend_language_scanner.l 10 Apr 2002 21:33:34 -  1.51
>+++ zend_language_scanner.l 6 Jul 2002 06:59:32 -
>@@ -626,6 +626,9 @@
>  }
>
>  "delete" {
>+   zendlval->value.str.val = (char *)estrndup(yytext, yyleng);
>+   zendlval->value.str.len = yyleng;
>+   zendlval->type = IS_STRING;
> return T_DELETE;
>  }
>


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




Re: [PHP-DEV] [PHP-QA] PHP Annual Bughunt!

2002-07-01 Thread Andi Gutmans

I'll take Pack 40.

Andi

At 03:25 PM 7/1/2002 +0200, [EMAIL PROTECTED] wrote:
>Hello QA-ers,
>
>it's the time of the year again, time for the PHP Bug Hunt Event! Although
>this is the first time, I'm pretty sure it will be fine.
>
>
>What is the PHP Bug Hunt Event?
>---
>The goal of the PHP Bug Hunt Event is too read, verify and updating of bug
>reports. At this moment there are a lot (800+) bug reports which are
>sleeping in our nice bugsystem, and they need to be taken care of.
>
>
>How do I participate?
>-
>Easy! Take a look at http://www.php.net/~derick/bugpacks.html . You will
>see 51 bug packs with bugs in it, nicely categorized. I'm asking you to
>pick one (or more of these 'Bugpacks') to take care of. Taking care of
>means:
>1. Choose a bugpack, and mail your bug pack ID along with your name to
>this list, so that we make sure no pack is done twice. I'll update the
>bugpack list file then.
>2. Read the reports in your bugpack
>3. Verify them (if that is needed), or ask others to verify them. If you
>want to discuss what to do with a report, write to this list.
>4. Update the reports status and add your information. If you think the
>bug is already fixed, choose the "Already fixed" / "Already fixed in
>CVS" QuickFix. If you are not sure how all those statusses work, feel
>free to ask on this list.
>
>You can only update bugs if you have a CVS account, but
>you don't need any specific karma, unless you want to fix the bug
>yourself (which will be _highly_ appreciated). If you want to request a
>CVS account, use the form @ http://www.php.net/cvs-php.php and make
>sure you specify "PHP Bug Hunt Event" while requesting it.
>
>
>What do I get in return?
>
>A nice cleaned up bug database, so that developers can concentrate on the
>real bugs, instead of having the dig through a lot of shitnitz and of
>course much appreciation of the 100's of thousands of PHP users.
>
>
>
>I hope I can count on you all!
>
>Derick
>PHP QA Team
>
>---
>  Derick Rethans   http://www.derickrethans.nl/
>  JDI Media Solutions   http://www.jdimedia.nl/
>---
>
>
>
>--
>PHP Quality Assurance Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] sapi_header_op

2002-07-01 Thread Andi Gutmans

At 07:03 AM 7/1/2002 +0200, Sascha Schumann wrote:
> > I understood the rational of using a struct from the beginning. I still in
> > general don't like using structs very much because as I mentioned it's not
> > as easy to use. I prefer having 2-3 methods then having one method which I
>
> Well, feel free to post those 2-3 methods which cover all
> possible variations.

What is missing from sapi_add_header_ex() right now?

> Using structs as input parameter is not uncommon in APIs, so
> I don't see the issue here.

The fact that it's not uncommon doesn't mean it's easy to use. Look at 
semop(). It's very common but not a very nice function to start using.

Andi


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




Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Andi Gutmans

At 10:03 PM 6/30/2002 +0200, Sascha Schumann wrote:
>On Sun, 30 Jun 2002, Andi Gutmans wrote:
>
> > My only problem with this patch is that I don't like API's which pass
> > around structs. I always find it cumbersome to have to create and fill the
> > struct and then pass it.
> > Can you think of something similar without using structs?
>
> If you look at the main body of the function, you will see a
> number of variables which script authors might want to
> overwrite in the future.
>
> Everytime an addition occurs, the main interface would have
> to change.  You might end up with something like
>
> sapi_add_header12("Test: X", 7, 1, 0, 404, 8372383, 123,
> "", "utf8", "filter_code", 0, -1);
>
> We are almost half way there.
>
> With the new interface of sapi_header_op(), we won't have
> this problem.  It will continue to exist unchanged,
> regardless of how many variables it might accept.  Extension
> developers will be happy about this, because it avoids BC
> issues.  The interface is also less bug prone because of its
> improved semantics.
>
> And thus, I conclude that passing in a struct is the most
> versatile way for this kind of API.

I understood the rational of using a struct from the beginning. I still in 
general don't like using structs very much because as I mentioned it's not 
as easy to use. I prefer having 2-3 methods then having one method which I 
need to pass a struct to. (There is the option of var_args btw, but I agree 
that that is probably a worse option).
If enough people think this change is a good thing then go ahead and commit 
it. It's no as if I think this is the end of the world. Then again, I'm 
sure we can work out the 2-3 function prototypes we need which would do the 
same and would be easier to use.

Andi


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




Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Andi Gutmans

My only problem with this patch is that I don't like API's which pass 
around structs. I always find it cumbersome to have to create and fill the 
struct and then pass it.
Can you think of something similar without using structs?

Andi

At 01:44 PM 6/30/2002 +0200, Sascha Schumann wrote:
> I think it is time for deprecating sapi_add_header* in favor
> of a more general function, called sapi_header_op.
>
> Let me quickly recapitulate the history.
>
> The original function sapi_add_header added and sometimes
> replaced HTTP headers and changed HTTP response codes at
> will.  This was still a real black box.
>
> Then I added a parameter "replace" which turned the black box
> into something more deterministic.  The new function was
> called sapi_add_header_ex to retain source code
> compatibility.
>
> The recent extension for specifying the HTTP response code
> eliminated further black box symptoms, but at the cost of
> changing an established API.
>
> I therefore propose the addition of a saner sapi_header_op()
> and the removal of the API breaking change from a week ago.
> This will allow further extensions regarding parameters
> without the burden of creating new APIs at the same time.
>
> The appended patch also unbreaks the CGI SAPI which did not
> generate status codes at all -- http_status_line was NULL all
> the time.
>
>
>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 {  /* Parameter:   */
> SAPI_HEADER_REPLACE,/* sapi_header_line**/
> SAPI_HEADER_ADD,/* sapi_header_line**/
> SAPI_HEADER_SET_STATUS  /* int  */
>} sapi_header_op_enum;
>
>SAPI_API int sapi_header_op(sapi_header_op_enum op, void *arg TSRMLS_DC);
>
>
> - Sascha
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] zend2 design "arhitecture"

2002-06-27 Thread Andi Gutmans

delete is a keyword like isset and unset so it makes sense for it to be 
without the __.

Andi

At 11:41 AM 6/27/2002 +0200, Tit \"Black\" Petric wrote:
>[quote ZEND_CHANGES.txt]
>
> * Forced deletion of objects.
>
>.. yadda ..
>
>   Note that if you have a user-defined function delete() in an old
>   script, this script will yield a parser error with the Zend
>   Engine 2.0, since 'delete' is now a reserved word.
>
>[/quote]
>
>if you chose internal functions for constructors, destructors, object
>cloning, and other runtime-critical-operations to have a prefixed "__", why
>did you choose "delete" over "__delete" ?
>
>regards,
>black
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] session related connection handling/cvs/mem

2002-06-27 Thread Andi Gutmans

At 10:41 PM 6/27/2002 +0200, [EMAIL PROTECTED] wrote:
> > 4. Our project uses own memory functions, since the sources will be
> > compiled on several different platforms. Do I have to use zend's exxx
> > memory functions?
>
>No, you don't need too, but if you use them they show memory leakage when
>the script ends, and it might be slightly faster.

Actually you should use our memory allocation functions because they make 
sure that even if your extension leaks memory the memory will be cleaned up 
at the end of each request (unless you want it to survive the request and 
then you should use the regular memory allocation functions).

Andi


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




[PHP-DEV] Idea for CLI feature

2002-06-27 Thread Andi Gutmans

Hey,

It'd be cool if phpinfo() would print its output in regular text (no HTML) 
when used with the CLI version (a bonus would be to also be able to pass it 
a parameter in CGI mode to select this mode).
The way phpinfo() is written this is quite easy to do as we're using 
centralized print functions anyway.
Does anyone feel like doing this? I don't have too much time :'(

Andi


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




RE: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-27 Thread Andi Gutmans

At 11:21 AM 6/27/2002 +0200, phpsurf wrote:
> > -Original Message-
> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> > Sent: mercredi 26 juin 2002 21:02
> > To: Brad LaFountain; Ivan Ristic; phpsurf
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class
> > Autoloading [PATCH]
> >
> >
> > Hey,
> >
> > What I meant was nested classes, my bad :)
> > I meant it won't work for Foo::Bar::Barbara but only for class Foo.
> >
>
>Andi,
>
>what is the problem with nested classes ?
>it is that the only class name that could be passed to __autoload is
>"Barbara" instead of "Foo::Bar::Barbara" ?
>or is it the problem to pass the class context to __autoload so the new
>nested class gets created inside the appropriate context ?
>
>just to understand ...

At the time you reach Barbara you have no way of knowing that you're in 
Foo::Bar.
Just make sure that if Foo is autoloaded that you load all its classes if 
you need them.
I think this autoload is more than enough for the people who asked for this 
feature.

Andi


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




Re: [PHP-DEV] Key values starting with .

2002-06-27 Thread Andi Gutmans

At 08:32 AM 6/27/2002 -0700, Brian France wrote:
>Hello,
>
>   I have a url that ends with ?.value=1, but PHP returns this in 
> $_REQUEST as _value instead of .value.  I believe this is because of this code:
>
>main/php_variables.c
>104 /* ensure that we don't have spaces or dots in the variable 
>name (not binary safe) */
>105 for (p=var; *p; p++) {
>106 switch(*p) {
>107 case ' ':
>108 case '.':
>109 *p='_';
>110 break;
>111 }
>112 }
>
>
>I can do this: $_REQUEST['.name'] = "testing" then if I do 
>print_r($_REQUEST) prints it out as .value and not _value.  Any reason for 
>being able to do one, but not the other?  Also what is the "(not binary 
>safe)" part of a variable with a . in its name?

I guess this is a left over from register globals as you can't access 
variables with . such as $image.x won't work (yeah you could always use 
indirect references but I'm just saying what was probably the reasoning 
behind this).
Don't expect it to change because it'll kill a huge amount of PHP scripts.

Andi


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




Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-26 Thread Andi Gutmans

Hey,

What I meant was nested classes, my bad :)
I meant it won't work for Foo::Bar::Barbara but only for class Foo.

Andi

At 11:56 AM 6/26/2002 -0700, Brad LaFountain wrote:
> > - will never work for sub-classes so don't even ask!
>
>Andi,
>
>  This doesn't need to be an issue. The way that I use sub-classes is I ALWAYS
>include_once("subclass.php"); at the top of each superclass file. I know
>everyone doesn't code the same way but maybe you can have that as a suggestion
>to people who use __autoload.
>
>Foo.php
>class Foo{}
>
>Bar.php
>class Bar{}
>
>MyFoo.php
>include_once("Foo.php");
>class MyFoo extends Foo{}
>
>MyBar.php
>include_once("Bar.php");
>class MyBar extends Bar{}
>
>
>auto_test.php
>function __autoload($name) {
>  include_once("$name.php");
>}
>$f = new MyFoo();
>$b = new MyBar();
>?>
>
>- brad
> >
> > At 11:27 PM 6/11/2002 +0100, Ivan Ristic wrote:
> > > > Okay, I guess I can live with it :)
> > > >
> > > > Andi
> > >
> > >   Is there anyone else who would like to comment on the
> > >   patch?
> > >
> > >   http://www.webkreator.com/download/class_autoload.patch
> > >
> > >   Or can we have it committed?
> > >
> > >--
> > >Ivan Ristic, [EMAIL PROTECTED]
> > >[ Weblog on PHP, Software development, Intranets,
> > >and Knowledge Management: http://www.webkreator.com ]
> > >
> > >
> > >--
> > >PHP Development Mailing List 
> > >To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com


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




Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-26 Thread Andi Gutmans

Ivan,

I just commited a patch for autoloading to the CVS. It is improved over 
your patch in the way I discussed (it propogates throughout Zend). I hope 
it works out to work well.
CVS commit message:
- Autoloading support based on patch from Ivan Ristic.
- Again I hope this feature ends up working well because if it doesn't we
- might need to nuke it. This only works for global scoped classes and it
- will never work for sub-classes so don't even ask!
- Just define an __autoload() function in the global scope and it will be
- called with the class name as the parameter if it doesn't manage to find
- the class.

Andi

At 11:27 PM 6/11/2002 +0100, Ivan Ristic wrote:
> > Okay, I guess I can live with it :)
> >
> > Andi
>
>   Is there anyone else who would like to comment on the
>   patch?
>
>   http://www.webkreator.com/download/class_autoload.patch
>
>   Or can we have it committed?
>
>--
>Ivan Ristic, [EMAIL PROTECTED]
>[ Weblog on PHP, Software development, Intranets,
>and Knowledge Management: http://www.webkreator.com ]
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Re: Has this fp fix been considered? - ADDENDUM

2002-06-26 Thread Andi Gutmans

I don't quite understand. Can you give us a few examples, how they are 
handled by PHP today and how they would be handled by your code.
I'll start off:
0.9+0.1

0.9+0.001

8/10.0 + 0.2

I'm sure you know of juicier examples :)

Andi

At 02:33 PM 6/26/2002 +0100, George Whiffen wrote:
>Oops,
>
>I forgot to sort out the catastrophic loss of precision on 
>differences.  So that
>means that on add and subtract we need to use the maximum fabs value
>of the operands to calculate the rounding trather than the result itself:
>
>So redecimalize() becomes:
>
>double redecimalize(double dval,double rval)
>{
> double f;
> if (dval == 0)
>{
>   return dval;
>}
>f = pow(10.0, (double) DBL_DIG - (1 + floor(log10(fabs(rval);
>return (double) (rint(dval*f))/f;
>   }
>
>
>and add_function, div_function need to look more like:
>
>double dop1,dop2,rval;
>
>  if ((op1->type == IS_DOUBLE || op1->type == IS_LONG)
>   && (op2->type == IS_LONG || op2->type == IS_DOUBLE)) {
>   dop1 = (op1->type == IS_LONG) ? ((double) op1->value.lval):op1->value.dval;
>   dop2 = (op2->type == IS_LONG) ? ((double) op2->value.lval):op2->value.dval;
>   result->value.dval = dop1 - dop2;
>   rval = fabs(dop1) > fabs(dop2) ? dop1:dop2;
>   result->value.dval = redecimalize(result->value.dval,rval);
>   result->type = IS_DOUBLE;
>   return SUCCESS;
>  }
>
>The calls to redecimalize on mul_function,div_function simply pass the
>result twice e.g.
>result->value.dval = redecimalize(result->value.dval,result->value.dval);
>
>There's no significant impact on performance.
>
>George
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] ZendEngine2 and $argc,$argv

2002-06-24 Thread Andi Gutmans

Can you try the latest CVS version? It should be fixed there.
Let me know...
Thanks,
Andi

At 11:04 PM 6/24/2002 +0200, Marcus Boerger wrote:
>Since i use ZendEngine2 i cannot use global $argc,$argv.
>
>Example:
>
>function somefunction() {
> global $argc, $argv;
>}
>
>worked before ZE2, PHP-3.0-dev
>now i get: Fatal error - Can't assign by reference non-referencable value!
>
>function somefunction() {
> $argc = $GLOBALS['argc'];
> $argv = $GLOBALS['argv'];
>}
>
>works just fine.
>
>I assume global creates a reference and checks if the variable is writeable.
>But a readonly variable or constant *should* also be referenceable.
>
>regards
>marcus
>


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




Re: [PHP-DEV] Zend 2: return by reference

2002-06-24 Thread Andi Gutmans

At 02:49 PM 6/24/2002 +0100, SCL List Client wrote:
>Sorry Andi, I was wrong. I never managed to test the returned references using
>the CVS version of PHP/Zend2 because I had assumed when I download the php4
>tree from the CVS I got Zend 2, so I compiled Zend 1.x by mistake. I can't
>actually get Zend 2 working - this is what I have been doing ...
>
>I downloaded the php4 and ZendEngine2 trees from CVS, replaced the Zend
>directory in the php4 tree with the ZendEngine2 directory and built, the make
>fails with the following error:
>Zend/zend_language_scanner.c:5513: syntax error before `int'
>
>FYI that line is:
> ZEND_DLIMPORT int isatty YY_PROTO(( int ));
>
>Am I doing this wrong or should I keep looking for the problem?
>
>BTW: System is RedHat linux kernel 2.2.19/glibc 2.1.1

Did you run ./buildconf before running ./configure?

Andi


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




Re: [PHP-DEV] Zend 2: return by reference

2002-06-24 Thread Andi Gutmans

Hi,

This is a bug and I think I fixed it in the CVS version of the Engine.
Any chance you can grab it and check?
In any case, I just want to remind you that you will not want to return 
objects by reference anymore with Engine 2 only possibly some other datatypes.

Andi

At 11:43 AM 6/24/2002 +0100, SCL List Client wrote:
>Hi,
>I have a Zend 2 question, I my code I return things from functions by 
>reference
>e.g.
>function &myFunc(...) {
> // .. Code
> return $x;
>}
>
>$y =& myFunc(...);
>?>
>
>But now I am trying to use Zend 2 version of php I get the following error:
>
>Fatal error: Can't use function return value in write context in 
>/scriptname on
>line x
>
>where x is the line of the actual function call.
>
>Has the syntax been changed for returning by reference or is this a bug?
>
>Cheers
>Tom
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Difference between sprintf, snprintf and spprintf

2002-06-22 Thread Andi Gutmans

I don't think adding a note is a bad idea.

Andi

At 04:44 PM 6/22/2002 -0500, Sterling Hughes wrote:

>Why?  If you're commiting code you should know how to use these basic 
>functions...
>
>besides, sprintf is not really all that bad...
>
>-Sterling
>
>
> > Proposal comment for spprintf/snprintf header. When nobody objects i commit
> > this to spprintf.h and make a notice in snprintf.h.
> >
> > /*
> >
> > Comparing: sprintf, snprintf, spprintf
> >
> > sprintf  offers the ability to make a lot of falures since it does not know
> >  the size of the buffer it uses. Therefore usage of sprintf often
> >  results in possible entries for buffer overrun attacks.
> >  SO PLEASE DO NOT USE IT!
> >
> > snprintf knows the buffers size and will not write behind it. but you will
> >  have to use either a static buffer or allocate one dynamic buffer
> >  before beeing able to call the function. In other words you must
> >  be sure that you really know the maximum size of the buffer
> >  required.
> >  A bad thing is if you hav a big maximum and in most cases you only
> >  need a small buffer.
> >
> > spprintf Is the dynamical version of snprintf it allocates the buffer in
> > size
> >  as neede and allows a maximum setting as snprintf (turn this
> >  feature
> >  of by setting max_len to 0). spprintf is a little bit slower than
> >  snprintf and offers possible memory leakes if you miss freeing the
> >  buffer allocated by the function. Therfore this function should be
> >  used where either no maximum is known or the maximum is much 
> bigger
> >  then normal size required.
> >
> > Example:
> >   char *buffer;
> >   #define MAX 1024
> >
> >   spprintf(&buffer, MAX, "text");
> >   if (!buffer)
> > return OUT_OF_MEMORY
> >   action_with_buffer();
> >   efree(buffer);
> >
> > */
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] What is a persistent constant (resend)

2002-06-22 Thread Andi Gutmans

At 06:44 AM 6/21/2002 -0400, fabwash wrote:
>Hello,
>
>I already sent this question, but there was no answer, and i'm afraid it 
>was not noticed, but if this is the wrong list, let me know :)
>
>
>When you define a constant you can use two things that are not very clear 
>to me. Can someone explain?
>
>1) CONST_PERSISTENT. How can a constant be persistent? The documentation 
>says that the constant is not "forgotten" after the process stops. Well if 
>the process stops, where is the constant stored? I couldn't find any place 
>where the constant would be written to a file or some location.
>
>Then when then module is started again, all programs I have looked at 
>register those same constants again, so what is the point of making them 
>persistent? Something is not getting into my small brain, there.
>
>2) REGISTER_MAIN_..  Those are supposed to remain in the symbol table. The 
>only symbol table I see is the Zend constant symbol table. So if the 
>process ends, then they're lost, and that's fine with me. But if a module 
>registers a constant as MAIN, then gets unloaded, the constants stay, 
>available for other modules I guess.
>
>So I understand REGISTER_MAIN (I think), although I don't really see the 
>point, but i'm totally not clear about CONST_PERSISTENT.
>
>Anyone can explain?

Persistent constants survive in between requests. Usually this is used by 
extensions to define some constants such as the constant 
PREG_PATTERN_ORDER. It is registered at module startup.
Of course it'll die if the Apache process dies.

Andi


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




Re: [PHP-DEV] Re: Bug #17892: Error Handling for eval()

2002-06-21 Thread Andi Gutmans

Markus,

The problem is that compile_string() will add functions and classes to 
PHP's global structures. Also, if there's a parse error it can leave the 
internal compiler structures in an unstable state.
I can't think of any quick and easy way of support this kind of lint 
feature nor eval() recovery.

Andi

At 11:59 AM 6/21/2002 +0200, Markus Fischer wrote:
> Hi,
>
> I think you're idea is pretty good, however not the way you
> engaged the current behaviour imho.
>
> PHP also supports 'lint'ing of source code aka. checking for
> parserer errors. It's just a few minutes work to provide the
> same functionality for a new function:
>
> $retval = lint($code);
>
> This would also throw parserer errors right at you, if you
> don't want, use '@' to supress it. It could be named
> 'eval_test' as someone on IRC (hey guys, btw:) suggested, or
> an optional argument to eval() to do only linting of the
> source, whatever.
>
> I've attached a small patch against
> Zend/zend_builtin_functions.c from CVS a few days ago (but it
> can be done everywhere, e.g. ext/standard ). I didn't
> commited it because a) I wasn't unsure if ppl want it and b)
> if it's the proper way to do it that way ("it works for me").
>
> Any of the developers care reviewing, (fixing,) commiting ?
> :)
>
> - Markus
>
>
>On Fri, Jun 21, 2002 at 08:57:43AM -, [EMAIL PROTECTED] wrote :
> > From: [EMAIL PROTECTED]
> > Operating system: Any
> > PHP version:  4.2.1
> > PHP Bug Type: Feature/Change Request
> > Bug description:  Error Handling for eval()
> >
> > I want to handle Parse_Errors and similar Fatals with my custom error
> > handler when they occur in eval()'d code.
> >
> > This is necessary when i want to execute custom code in my console script
> > and prevent this code from crashing my entire program if there is only a
> > simple typo in there...
> >
> > I have achieved this by a little hack in the "zend_execute.c" but i don't
> > know if this handles any errors right that don't occur in eval'd()
> > code...
> > This is what i changed (to even prevent a segmentation fault)
> > (zend_execute.c, line 1563):
> >
> > if (zend_hash_find(active_function_table, function_name->value.str.val,
> > function_name->value.str.len+1, (void **) &function)==FAILURE) {
> > zend_error(E_USER_ERROR, "Call to undefined function: %s()",
> > function_name->value.str.val);
> > return;
> > }
> >
> > --
> > Edit bug report at http://bugs.php.net/?id=17892&edit=1
> > --
> > Fixed in CVS:http://bugs.php.net/fix.php?id=17892&r=fixedcvs
> > Fixed in release:http://bugs.php.net/fix.php?id=17892&r=alreadyfixed
> > Need backtrace:  http://bugs.php.net/fix.php?id=17892&r=needtrace
> > Try newer version:   http://bugs.php.net/fix.php?id=17892&r=oldversion
> > Not developer issue: http://bugs.php.net/fix.php?id=17892&r=support
> > Expected behavior:   http://bugs.php.net/fix.php?id=17892&r=notwrong
> > Not enough info: http://bugs.php.net/fix.php?id=17892&r=notenoughinfo
> > Submitted twice: http://bugs.php.net/fix.php?id=17892&r=submittedtwice
> > register_globals:http://bugs.php.net/fix.php?id=17892&r=globals
>
>--
>GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
>Did I help you?http://guru.josefine.at/wish_en
>Konnte ich helfen? http://guru.josefine.at/wish_de
>"uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did
>i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Zend Constants PATCH

2002-06-18 Thread Andi Gutmans

Hey,

Please test the attached patch and let me know if it works for you.
I haven't really had the chance to test it too much.

Andi

At 06:21 PM 6/15/2002 -0400, Ilia A. wrote:
>Andi,
>
>I wrote another patch, this time a 'proper' way, which means the old
>functionality of case insensetivity is supported. Please look it over,
>hopefuly this is good enough to commit.
>I've also attached a small php test script you can use to see the problem in
>non patched PHPs.
>
>Ilia
>
>On June 15, 2002 03:25 pm, Andi Gutmans wrote:
> > Ilia,
> >
> > I remember now the problem you're talking about. It has been discussed here
> > in the past and I don't recall us having found a good solution. Basically
> > we need a solution which is backwards compatible but will allow "TEST" and
> > "test" to co-exist if case sensitivity was chosen for them.
> > It's something to think about and not create a quick 2 line patch for the
> > problem. I think one of the suggestions was using two hash tables. First
> > doing a case-sensitive lookup and only if the constant isn't found doing a
> > case-insensitive lookup.
> >
> > Andi
> >
> > At 03:40 PM 6/15/2002 -0400, Ilia A. wrote:
> > >Andi,
> > >
> > >Yes, you are correct in that respect, my patch would accomplish just that.
> > >No where in PHP documentation does it say that you cannot have TEST and
> > > test defines in the same script. Unless you specifically tell the
> > > define() function to treat the define as case insensitive.
> > >Because the defines are always lowercased unless the defines for i18n
> > > systems are always declared in lower case any define with a letter 'I'
> > > for example would break on a system using most non English locales. This
> > > is a VERY serious problems, for example consider the reversal of the
> > > htmlenteties() function. The following code:
> > >get_html_translation_table (HTML_ENTITIES);
> > >will break if a ru_UI or tr_TR or any other number of non-English locales
> > > are exported.
> > >
> > >In addition because all locales are lower cased defines suffer large
> > >performance degradation when compared to other variables because another
> > > copy of the define name needs to be allocated and then lower cased every
> > > single time a define is declared or retrieved.
> > >
> > >As far as I know, php variables are always case sensitive and there is now
> > >way
> > >to make them not, why an exception was made for defines I do not know,
> > >especially when you consider that in C and C++ defines are ALWAYS case
> > >sensitive. IMHO this is a very bad feature, that not only implements
> > > useless functionality but actually causes PHP code to break.
> > >Therefor, I humbly ask that you reconsider your position on this issue.
> > >
> > >
> > >Ilia
> > >
> > >On June 15, 2002 03:03 pm, you wrote:
> > > > Ilia,
> > > >
> > > > Your patch basically makes PHP constants case sensitive.
> > > > Changing this is a very big backwards compatibility problem.
> > > > You're not supposed to register two define's with the same letters but
> > > > different case.
> > > >
> > > > Andi
> > > >
> > > > At 01:21 PM 6/15/2002 -0400, Ilia A. wrote:
> > > > >Hello,
> > > > >
> > > > >While developing software in PHP that supports i18n I've come across
> > > > > several problems that affect defines made in PHP.
> > > > >The first problem is that when a define is declared and its name
> > > > > contains upper case characters such as I, the define becomes unusable
> > > > > if a locale, which does not support those chracters is exported, such
> > > > > as tr_TR or ru_IU. Bug Report at:
> > > > > http://bugs.php.net/bug.php?id=16865
> > > > >
> > > > >There is a problem with case sensetivity of defines, for example, if
> > > > > you create a case sensetive define 'TEST' and then a case sensetive
> > > > > define 'test', the latter define's value will be lost.
> > > > >Bug Report at: http://bugs.php.net/?id=17658
> > > > >
> > > > >The problem occurs because zend internally (zend_constants.c) seems to
> > > > > always lowecase the define before it is fetched/added to the hash
> > >

Re: [PHP-DEV] Zend Constants PATCH

2002-06-18 Thread Andi Gutmans

At 04:07 PM 6/18/2002 +0200, Hartmut Holzgraefe wrote:
>Ilia A. wrote:
>
>>By using a functiont that does not support lowercasing, would also cause 
>>problems, since if a constant name contains non english characters it 
>>would break. IMHO the best implementation is to simply not lowercase 
>>constant names unless the user specifically whats case insensetive locale.
>
>the language parser should not be affected by locale settings at all,
>so we need a locale independant zend_str_tolower() function or make
>sure we have 'C' or 'POSIX' locale

Right. For example, decimal's in PHP use a . (e.g. 3.14).
This should always be the case even if the locale uses a different 
separator like , in German.

Andi


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




Re: [PHP-DEV] Zend Constants PATCH

2002-06-15 Thread Andi Gutmans

We're not going to add configuration options which change the language's 
behavior!
We've said this a million times.

Andi

At 09:41 PM 6/15/2002 +0200, Magnus M wrote:
>What about a configuration option in php.ini
>use_case_sensitive = 0|1
>and let it be 0 as default ?
>
>
>On Sat, 15 Jun 2002 22:25:18 +0300
>Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
> > Ilia,
> >
> > I remember now the problem you're talking about. It has been discussed 
> here
> > in the past and I don't recall us having found a good solution. Basically
> > we need a solution which is backwards compatible but will allow "TEST" and
> > "test" to co-exist if case sensitivity was chosen for them.
> > It's something to think about and not create a quick 2 line patch for the
> > problem. I think one of the suggestions was using two hash tables. First
> > doing a case-sensitive lookup and only if the constant isn't found doing a
> > case-insensitive lookup.
> >
> > Andi
> >
> > At 03:40 PM 6/15/2002 -0400, Ilia A. wrote:
> > >Andi,
> > >
> > >Yes, you are correct in that respect, my patch would accomplish just that.
> > >No where in PHP documentation does it say that you cannot have TEST 
> and test
> > >defines in the same script. Unless you specifically tell the define()
> > >function to treat the define as case insensitive.
> > >Because the defines are always lowercased unless the defines for i18n 
> systems
> > >are always declared in lower case any define with a letter 'I' for example
> > >would break on a system using most non English locales. This is a VERY
> > >serious problems, for example consider the reversal of the htmlenteties()
> > >function. The following code:
> > >get_html_translation_table (HTML_ENTITIES);
> > >will break if a ru_UI or tr_TR or any other number of non-English 
> locales are
> > >exported.
> > >
> > >In addition because all locales are lower cased defines suffer large
> > >performance degradation when compared to other variables because 
> another copy
> > >of the define name needs to be allocated and then lower cased every single
> > >time a define is declared or retrieved.
> > >
> > >As far as I know, php variables are always case sensitive and there is 
> now
> > >way
> > >to make them not, why an exception was made for defines I do not know,
> > >especially when you consider that in C and C++ defines are ALWAYS case
> > >sensitive. IMHO this is a very bad feature, that not only implements 
> useless
> > >functionality but actually causes PHP code to break.
> > >Therefor, I humbly ask that you reconsider your position on this issue.
> > >
> > >
> > >Ilia
> > >
> > >
> > >On June 15, 2002 03:03 pm, you wrote:
> > > > Ilia,
> > > >
> > > > Your patch basically makes PHP constants case sensitive.
> > > > Changing this is a very big backwards compatibility problem.
> > > > You're not supposed to register two define's with the same letters but
> > > > different case.
> > > >
> > > > Andi
> > > >
> > > > At 01:21 PM 6/15/2002 -0400, Ilia A. wrote:
> > > > >Hello,
> > > > >
> > > > >While developing software in PHP that supports i18n I've come across
> > > > > several problems that affect defines made in PHP.
> > > > >The first problem is that when a define is declared and its name 
> contains
> > > > >upper case characters such as I, the define becomes unusable if a 
> locale,
> > > > >which does not support those chracters is exported, such as tr_TR or
> > > > > ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865
> > > > >
> > > > >There is a problem with case sensetivity of defines, for example, 
> if you
> > > > >create a case sensetive define 'TEST' and then a case sensetive define
> > > > >'test', the latter define's value will be lost.
> > > > >Bug Report at: http://bugs.php.net/?id=17658
> > > > >
> > > > >The problem occurs because zend internally (zend_constants.c) seems to
> > > > > always lowecase the define before it is fetched/added to the hash 
> table
> > > > > of defines. This causes problem for i18n because the define is 
> lowercased
> > > > > using c's tolower function, which is affected by locale settings. 
> Because
> > > > > it is stored as lower case, having 2 defines with the same name 
> but in
> > > > > different case also becomes impossible to do.
> > > > >
> > > > >Attached is a patch against zend_constants.c CVS revision 1.38 
> that fixes
> > > > >both
> > > > >of these bugs, I hope the developers would consider adding this 
> patch to
> > > > > the CVS.
> > > > >
> > > > >Ilia
> > > > >--
> > > > >PHP Development Mailing List <http://www.php.net/>
> > > > >To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Zend Constants PATCH

2002-06-15 Thread Andi Gutmans

Ilia,

I remember now the problem you're talking about. It has been discussed here 
in the past and I don't recall us having found a good solution. Basically 
we need a solution which is backwards compatible but will allow "TEST" and 
"test" to co-exist if case sensitivity was chosen for them.
It's something to think about and not create a quick 2 line patch for the 
problem. I think one of the suggestions was using two hash tables. First 
doing a case-sensitive lookup and only if the constant isn't found doing a 
case-insensitive lookup.

Andi

At 03:40 PM 6/15/2002 -0400, Ilia A. wrote:
>Andi,
>
>Yes, you are correct in that respect, my patch would accomplish just that.
>No where in PHP documentation does it say that you cannot have TEST and test
>defines in the same script. Unless you specifically tell the define()
>function to treat the define as case insensitive.
>Because the defines are always lowercased unless the defines for i18n systems
>are always declared in lower case any define with a letter 'I' for example
>would break on a system using most non English locales. This is a VERY
>serious problems, for example consider the reversal of the htmlenteties()
>function. The following code:
>get_html_translation_table (HTML_ENTITIES);
>will break if a ru_UI or tr_TR or any other number of non-English locales are
>exported.
>
>In addition because all locales are lower cased defines suffer large
>performance degradation when compared to other variables because another copy
>of the define name needs to be allocated and then lower cased every single
>time a define is declared or retrieved.
>
>As far as I know, php variables are always case sensitive and there is now 
>way
>to make them not, why an exception was made for defines I do not know,
>especially when you consider that in C and C++ defines are ALWAYS case
>sensitive. IMHO this is a very bad feature, that not only implements useless
>functionality but actually causes PHP code to break.
>Therefor, I humbly ask that you reconsider your position on this issue.
>
>
>Ilia
>
>
>On June 15, 2002 03:03 pm, you wrote:
> > Ilia,
> >
> > Your patch basically makes PHP constants case sensitive.
> > Changing this is a very big backwards compatibility problem.
> > You're not supposed to register two define's with the same letters but
> > different case.
> >
> > Andi
> >
> > At 01:21 PM 6/15/2002 -0400, Ilia A. wrote:
> > >Hello,
> > >
> > >While developing software in PHP that supports i18n I've come across
> > > several problems that affect defines made in PHP.
> > >The first problem is that when a define is declared and its name contains
> > >upper case characters such as I, the define becomes unusable if a locale,
> > >which does not support those chracters is exported, such as tr_TR or
> > > ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865
> > >
> > >There is a problem with case sensetivity of defines, for example, if you
> > >create a case sensetive define 'TEST' and then a case sensetive define
> > >'test', the latter define's value will be lost.
> > >Bug Report at: http://bugs.php.net/?id=17658
> > >
> > >The problem occurs because zend internally (zend_constants.c) seems to
> > > always lowecase the define before it is fetched/added to the hash table
> > > of defines. This causes problem for i18n because the define is lowercased
> > > using c's tolower function, which is affected by locale settings. Because
> > > it is stored as lower case, having 2 defines with the same name but in
> > > different case also becomes impossible to do.
> > >
> > >Attached is a patch against zend_constants.c CVS revision 1.38 that fixes
> > >both
> > >of these bugs, I hope the developers would consider adding this patch to
> > > the CVS.
> > >
> > >Ilia
> > >--
> > >PHP Development Mailing List 
> > >To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Zend Constants PATCH

2002-06-15 Thread Andi Gutmans

Ilia,

Your patch basically makes PHP constants case sensitive.
Changing this is a very big backwards compatibility problem.
You're not supposed to register two define's with the same letters but 
different case.

Andi

At 01:21 PM 6/15/2002 -0400, Ilia A. wrote:
>Hello,
>
>While developing software in PHP that supports i18n I've come across several
>problems that affect defines made in PHP.
>The first problem is that when a define is declared and its name contains
>upper case characters such as I, the define becomes unusable if a locale,
>which does not support those chracters is exported, such as tr_TR or ru_IU.
>Bug Report at: http://bugs.php.net/bug.php?id=16865
>
>There is a problem with case sensetivity of defines, for example, if you
>create a case sensetive define 'TEST' and then a case sensetive define
>'test', the latter define's value will be lost.
>Bug Report at: http://bugs.php.net/?id=17658
>
>The problem occurs because zend internally (zend_constants.c) seems to always
>lowecase the define before it is fetched/added to the hash table of defines.
>This causes problem for i18n because the define is lowercased using c's
>tolower function, which is affected by locale settings. Because it is stored
>as lower case, having 2 defines with the same name but in different case also
>becomes impossible to do.
>
>Attached is a patch against zend_constants.c CVS revision 1.38 that fixes 
>both
>of these bugs, I hope the developers would consider adding this patch to the
>CVS.
>
>Ilia
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] PHP 4.3.0-dev-zend2-alpha segfaulting

2002-06-15 Thread Andi Gutmans

Hi,

Thanks for the good bug report. I have fixed this problem in the CVS.

Andi

At 12:39 PM 6/14/2002 +0200, Hakan Kuecuekyilmaz wrote:
>Hi,
>
>following script segfaults at
>
>in doubleloop 10/22
>Segmentation fault
>
>class benchmark
>{
>   var $index;
>
>   function benchmark($num)
>   {
> for ($i = 0; $i < $num; $i++) {
>   $this->index = $i;
> }
>   }
>}
>
>for ($i = 0; $i < 100; $i++) {
>   for ($j = 0; $j < 100; $j++) {
> $arr[$i][$j] = new benchmark(100);
> echo "in doubleloop ". $i . "/" . $j . "\n";
>   }
>}
>?>
>
>with php 4.2.1 everything is fine
>
>here is a bt:
>
>#0  0x7059c7e8 in realloc () from /lib/libc.so.6
>#1  0x7059c758 in realloc () from /lib/libc.so.6
>#2  0x001940ac in _erealloc (ptr=0x313dd8, size=40960, allow_failure=0,
> __zend_filename=0x21ba50
>"/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_objects_API.c",
> __zend_lineno=51, __zend_orig_filename=0x0, __zend_orig_lineno=0)
> at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_alloc.c:298
>#3  0x001c5254 in zend_objects_store_put (object=0x3a7c00,
> dtor=0x1c4440 , clone=0)
> at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_objects_API.c:51
>#4  0x001c3f5c in zend_objects_new (object=0xefffdcc0,
>class_type=0x320ce8)
> at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_objects.c:58
>#5  0x001b3aa0 in _object_and_properties_init (arg=0x3a7560,
>class_type=0x320ce8, properties=0x0,
> __zend_filename=0x21bc10
>"/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_execute.c",
> __zend_lineno=2516) at
>/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_API.c:594
>#6  0x001b3b9c in _object_init_ex (arg=0x3a7560, class_type=0x320ce8,
> __zend_filename=0x21bc10
>"/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_execute.c",
> __zend_lineno=2516) at
>/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_API.c:610
>#7  0x001cf42c in execute (op_array=0x31b4a0)
> at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_execute.c:2516
>#8  0x001b1b18 in zend_execute_scripts (type=8, retval=0x0,
>file_count=3)
> at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend.c:833
>#9  0x001641fc in php_execute_script (primary_file=0xe8b8)
> at /usr/local/php-4.3.0-dev-zend2-alpha1/main/main.c:1373
>#10 0x001d6008 in main (argc=2, argv=0xe9a4)
> at /usr/local/php-4.3.0-dev-zend2-alpha1/sapi/cli/php_cli.c:674
>
>
>regards
>--
>Hakan Kuecuekyilmaz, University of Applied Sciences Esslingen, Germany
><[EMAIL PROTECTED]>  |  <[EMAIL PROTECTED]>  |   <[EMAIL PROTECTED]>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-13 Thread Andi Gutmans

At 07:00 PM 6/13/2002 +0100, Ivan Ristic wrote:
> > > > The second problem is that I don't see it working with nested classes.
> > > > Is it good enough to only have this work with classes in the global
>scope?
> > >
> > >   I am not really familiar with nested classes; is it because
> > >   you don't know the name of the file in which a nested class
> > >   is located? If so, I would say that trying to accommodate that
> > >   would be an overkill. In any case, the programmer using nested
> > >   classes can always write the __autoload() function that will
> > >   be smart enough.
> >
> > The problem is that if you have MyClass1::MyClass2::MyClass3 then MyClass3
> > is looked up in the result of MyClass2 being looked up in MyClass1. If the
> > lookup fails I can't tell __autoload() the path. The only think I could do
> > is possibly pass it the result of MyClass2 being looked up in MyClass1 and
> > "MyClass3". The question is if people will manage to handle this. I think
> > it might be complicated and it might be best not to go in this direction.
>
>   I see the problem. But I would also like to play with it to
>   understand it better. Why don't you add the feature so that we
>   can test it, and we will remove it later if it prooves unusable?

Well I usually don't like putting stuff into the CVS which I might remove 
later on. The most permanent things are temporary ones.
In any case, I'll look it over again on the weekend. It might make sense to 
commit it and people will have to know that it only is meant for globally 
scoped classes (which kind of makes sense anyway).

Andi


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




Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-12 Thread Andi Gutmans

At 06:53 PM 6/12/2002 +0100, Ivan Ristic wrote:
> > First of all I'd prefer it to call a predefined callback called
> > __autoload() if a class is not found.
>
>   I do not have a problem with the predefined name. However,
>   unserialize is already using the ini setting for the
>   same thing, and it would be a shame to introduce an
>   inconsistency.
>
>   Can we obey the ini setting if it is there, and call __autoload()
>   if it isn't (i.e. introduce "__autoload" as a default value for
>   the ini parameter)?

I was thinking __autoload() would be used everywhere including in 
unserialize. I think standardizing the callback is a good idea.



> > The second problem is that I don't see it working with nested classes.
> > Is it good enough to only have this work with classes in the global scope?
>
>   I am not really familiar with nested classes; is it because
>   you don't know the name of the file in which a nested class
>   is located? If so, I would say that trying to accommodate that
>   would be an overkill. In any case, the programmer using nested
>   classes can always write the __autoload() function that will
>   be smart enough.

The problem is that if you have MyClass1::MyClass2::MyClass3 then MyClass3 
is looked up in the result of MyClass2 being looked up in MyClass1. If the 
lookup fails I can't tell __autoload() the path. The only think I could do 
is possibly pass it the result of MyClass2 being looked up in MyClass1 and 
"MyClass3". The question is if people will manage to handle this. I think 
it might be complicated and it might be best not to go in this direction.

Andi


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




Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-12 Thread Andi Gutmans

I have two problems here.
First of all I'd prefer it to call a predefined callback called 
__autoload() if a class is not found.
The second problem is that I don't see it working with nested classes.
Is it good enough to only have this work with classes in the global scope?

Andi

At 11:27 PM 6/11/2002 +0100, Ivan Ristic wrote:
> > Okay, I guess I can live with it :)
> >
> > Andi
>
>   Is there anyone else who would like to comment on the
>   patch?
>
>   http://www.webkreator.com/download/class_autoload.patch
>
>   Or can we have it committed?
>
>--
>Ivan Ristic, [EMAIL PROTECTED]
>[ Weblog on PHP, Software development, Intranets,
>and Knowledge Management: http://www.webkreator.com ]
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Fwd: Re: [PHP-DEV] filesystem security questions

2002-06-11 Thread Andi Gutmans

Can someone please help out Wez? ;)

Thanks,

Andi

>From: "Wez Furlong" <[EMAIL PROTECTED]>
>Date: Wed, 12 Jun 2002 01:39:53 +0100
>To: "Andi Gutmans" <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED], "Wez Furlong" <[EMAIL PROTECTED]>
>Subject: Re: [PHP-DEV] filesystem security questions
>
>If one of the doc guys can create a section in the docs as a skeleton,
>I'll make an effort to fill in the docs, but I have very limited time for
>a couple of months :-/
>
>--Wez.
>
>On 08/06/02, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > At 12:42 PM 6/8/2002 +0200, Markus Fischer wrote:
> > > Practically, there's no documentation about streams except
> > > some mail Wez sent to php-dev@ a few weeks (months?) ago (and
> > > the sources, of course), I hope you can find it in the
> > > archives.
> >
> > Maybe we can get Wez to write complete documentation for the API docs? :)
> >
> > Andi


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




Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-11 Thread Andi Gutmans

At 11:27 PM 6/11/2002 +0100, Ivan Ristic wrote:
> > Okay, I guess I can live with it :)
> >
> > Andi
>
>   Is there anyone else who would like to comment on the
>   patch?
>
>   http://www.webkreator.com/download/class_autoload.patch
>
>   Or can we have it committed?

Hmm, I was wondering where the patch itself was. I didn't actually find it.
I'll look at it later on today :)

Andi


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




Re: [PHP-DEV] =& problem with ZE2: Can't use function return value in write context

2002-06-11 Thread Andi Gutmans

This should be fixed now.
Note, that it will only work if you are returning your return value by 
reference. In engine 1 doing anything else was buggy.

Andi

At 07:16 PM 6/11/2002 +0300, Andi Gutmans wrote:
>It's supposed to work under the same circumstances as in Engine 1 (if you 
>really returned a reference) although in most cases you will now be 
>returning objects by value and assigning them by value. It was introduced 
>originally to get around the object problems the Engine 2 solved.
>I'll look into it.
>
>Andi
>
>At 06:12 PM 6/11/2002 +0800, John Lim wrote:
>>Hello,
>>
>>With the ZE 2,  PHP 4.3.0-alpha
>>
>>>  :
>>  : # some init code
>>  :
>>$aclass =& afunction($params);
>>?>
>>
>>I get an error that looks like this:
>>
>>Fatal error: Can't use function return value in write context in
>>d:\inetpub\wwwroot\php\test5.php on line 29
>>
>>Is this a bug or a feature of the new ZE2. I noticed there are many places
>>in PEAR and my code that use the =& syntax.
>>
>>Thanks again, John
>>
>>
>>
>>--
>>PHP Development Mailing List <http://www.php.net/>
>>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] =& problem with ZE2: Can't use function return value in write context

2002-06-11 Thread Andi Gutmans

It's supposed to work under the same circumstances as in Engine 1 (if you 
really returned a reference) although in most cases you will now be 
returning objects by value and assigning them by value. It was introduced 
originally to get around the object problems the Engine 2 solved.
I'll look into it.

Andi

At 06:12 PM 6/11/2002 +0800, John Lim wrote:
>Hello,
>
>With the ZE 2,  PHP 4.3.0-alpha
>
>  :
>  : # some init code
>  :
>$aclass =& afunction($params);
>?>
>
>I get an error that looks like this:
>
>Fatal error: Can't use function return value in write context in
>d:\inetpub\wwwroot\php\test5.php on line 29
>
>Is this a bug or a feature of the new ZE2. I noticed there are many places
>in PEAR and my code that use the =& syntax.
>
>Thanks again, John
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] ZE2 and Exceptions - One for Zeev/Andi

2002-06-11 Thread Andi Gutmans

At 07:55 AM 6/11/2002 -0400, l0t3k wrote:
>ive been looking over the ZE2 alpha release code for clues on porting my OO
>extension over to the new engine, but a few things are not clicking yet
>how do i raise an exception from C. last time i asked, Andi said that it
>would be sufficient to do a
>
> EG(exception) = error_object_i_created;
>
> but looking through zend_execute.c there seems to be no explicit check
>for (NULL != EG(exception)) in the main interpreter loop

line 2175

>one other (unrelated) thing : there seems to be an overlap between members
>of the zend_object_handlers struct and the zend_class_entry stuct (function
>pointers for property access and method calls). is the current state
>transitional (i.e. should all code going forward use only the
>zend_object_handlers way ?) then again i guess thats what macros and such
>are for

Use zend_object_handlers.

Andi


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




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

2002-06-11 Thread Andi Gutmans

Okay, I guess I can live with it :)

Andi

At 02:40 PM 6/11/2002 +0200, phpsurf wrote:
>I think handlers are the best solution to make this process configuratble
>without introducing a new ini option.
>we already have such handlers for errors ...
>and then one can define his own process to implement his specific needs
>farther than just setting a classPath.
>
>why don't you like this idea ? is it for performance reasons ?
>
> > -----Original Message-
> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> > Sent: lundi 10 juin 2002 22:33
> > To: phpsurf; Ivan Ristic; Zeev Suraski
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]
> >
> >
> > I'd prefer not having a handler for autoloader. I'd prefer having the
> > Engine look for ClassName.php in the default include_path and if
> > it doesn't
> > exist die... (i.e. not call any user-definable PHP function).
> >
> > Andi
> >
> > At 11:33 AM 6/10/2002 +0200, phpsurf wrote:
> > >this patch would be really great !
> > >
> > >I can remember it has been discussed a lot on the ZE2 mailing
> > list about the
> > >'import' feature.
> > >some people (and I was) would have apreciated another name
> > because this name
> > >was already used in many PHP frameworks to implement a function
> > that loads
> > >classes.
> > >
> > >As far as I followed this thread, the agreement was that the
> > import keyword
> > >can be used fine for namespaces if a autoload statement was
> > patched to the
> > >engine ... so everyone would be happy ! :)
> > >
> > >I guess your patch gives some function like this one :
> > >set_classautoload_handler("myAutoLoader");
> > >
> > >and then, one can implement a function like this:
> > >myAutoLoader($className) {
> > >  if (!class_exists($className)) {
> > >   include("class/".str_replace("_", "/", $className).".php");
> > >   }
> > >}
> > >
> > >I'm sure many programmers would apreciate such a feature.
> > >Especially as it whould have no BC issue at all !
> > >
> > > > -Original Message-
> > > > From: Ivan Ristic [mailto:[EMAIL PROTECTED]]
> > > > Sent: dimanche 9 juin 2002 22:46
> > > > To: Zeev Suraski
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: 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...
> > > >
> > > >   I tried and I tried but I couldn't find a discussion on anything
> > > >   similar on the mailing list.
> > > >
> > > >   The code I sent is *already* in use, and has been in
> > > >   use for some time now. Take a look at this message from
> > > >   November 2001:
> > > >
> > > >   http://marc.theaimsgroup.com/?l=php-dev&m=100687224711738&w=2
> > > >
> > > >   I didn't introduce anything new, so if it was OK then it should be
> > > >   OK now. Also, the code cannot affect the people that are not using
> > > >   the feature so I do not think that there will be any kind of impact
> > > >   on the existing user base.
> > > >
> > > >   This feature makes it possible to have one class per file and not
> > > >   to worry about inclusion at all. It becomes especially useful when
> > > >   used together with products such as Zend Accelerator, where files
> > > >   are cached (and you do not have to worry about a large number of
> > > >   small files).
> > > >
> > > > --
> > > > Ivan Ristic, [EMAIL PROTECTED]
> > > > [ Weblog on PHP, Software development, Intranets,
> > > > and Knowledge Management: http://www.webkreator.com ]
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >
> > >
> > >_
> > _
> > >ifrance.com, l'email gratuit le plus complet de l'Internet !
> > >vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> > >http://www.ifrance.com/_reloc/email.emailif
> > >
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>ifrance.com, l'email gratuit le plus complet de l'Internet !
>vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
>http://www.ifrance.com/_reloc/email.emailif


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




[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

2002-06-10 Thread Andi Gutmans

Or have a user-definable classpath. But I think it's better not to call 
into PHP code.

Andi

At 11:32 PM 6/10/2002 +0300, Andi Gutmans wrote:
>I'd prefer not having a handler for autoloader. I'd prefer having the 
>Engine look for ClassName.php in the default include_path and if it 
>doesn't exist die... (i.e. not call any user-definable PHP function).
>
>Andi
>
>At 11:33 AM 6/10/2002 +0200, phpsurf wrote:
>>this patch would be really great !
>>
>>I can remember it has been discussed a lot on the ZE2 mailing list about the
>>'import' feature.
>>some people (and I was) would have apreciated another name because this name
>>was already used in many PHP frameworks to implement a function that loads
>>classes.
>>
>>As far as I followed this thread, the agreement was that the import keyword
>>can be used fine for namespaces if a autoload statement was patched to the
>>engine ... so everyone would be happy ! :)
>>
>>I guess your patch gives some function like this one :
>>set_classautoload_handler("myAutoLoader");
>>
>>and then, one can implement a function like this:
>>myAutoLoader($className) {
>>  if (!class_exists($className)) {
>>   include("class/".str_replace("_", "/", $className).".php");
>>   }
>>}
>>
>>I'm sure many programmers would apreciate such a feature.
>>Especially as it whould have no BC issue at all !
>>
>> > -Original Message-
>> > From: Ivan Ristic [mailto:[EMAIL PROTECTED]]
>> > Sent: dimanche 9 juin 2002 22:46
>> > To: Zeev Suraski
>> > Cc: [EMAIL PROTECTED]
>> > Subject: 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...
>> >
>> >   I tried and I tried but I couldn't find a discussion on anything
>> >   similar on the mailing list.
>> >
>> >   The code I sent is *already* in use, and has been in
>> >   use for some time now. Take a look at this message from
>> >   November 2001:
>> >
>> >   http://marc.theaimsgroup.com/?l=php-dev&m=100687224711738&w=2
>> >
>> >   I didn't introduce anything new, so if it was OK then it should be
>> >   OK now. Also, the code cannot affect the people that are not using
>> >   the feature so I do not think that there will be any kind of impact
>> >   on the existing user base.
>> >
>> >   This feature makes it possible to have one class per file and not
>> >   to worry about inclusion at all. It becomes especially useful when
>> >   used together with products such as Zend Accelerator, where files
>> >   are cached (and you do not have to worry about a large number of
>> >   small files).
>> >
>> > --
>> > Ivan Ristic, [EMAIL PROTECTED]
>> > [ Weblog on PHP, Software development, Intranets,
>> > and Knowledge Management: http://www.webkreator.com ]
>> >
>> >
>> > --
>> > PHP Development Mailing List <http://www.php.net/>
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>>
>>
>>__
>>ifrance.com, l'email gratuit le plus complet de l'Internet !
>>vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
>>http://www.ifrance.com/_reloc/email.emailif
>>
>>
>>
>>--
>>PHP Development Mailing List <http://www.php.net/>
>>To unsubscribe, visit: http://www.php.net/unsub.php


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




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

2002-06-10 Thread Andi Gutmans

I'd prefer not having a handler for autoloader. I'd prefer having the 
Engine look for ClassName.php in the default include_path and if it doesn't 
exist die... (i.e. not call any user-definable PHP function).

Andi

At 11:33 AM 6/10/2002 +0200, phpsurf wrote:
>this patch would be really great !
>
>I can remember it has been discussed a lot on the ZE2 mailing list about the
>'import' feature.
>some people (and I was) would have apreciated another name because this name
>was already used in many PHP frameworks to implement a function that loads
>classes.
>
>As far as I followed this thread, the agreement was that the import keyword
>can be used fine for namespaces if a autoload statement was patched to the
>engine ... so everyone would be happy ! :)
>
>I guess your patch gives some function like this one :
>set_classautoload_handler("myAutoLoader");
>
>and then, one can implement a function like this:
>myAutoLoader($className) {
>  if (!class_exists($className)) {
>   include("class/".str_replace("_", "/", $className).".php");
>   }
>}
>
>I'm sure many programmers would apreciate such a feature.
>Especially as it whould have no BC issue at all !
>
> > -Original Message-
> > From: Ivan Ristic [mailto:[EMAIL PROTECTED]]
> > Sent: dimanche 9 juin 2002 22:46
> > To: Zeev Suraski
> > Cc: [EMAIL PROTECTED]
> > Subject: 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...
> >
> >   I tried and I tried but I couldn't find a discussion on anything
> >   similar on the mailing list.
> >
> >   The code I sent is *already* in use, and has been in
> >   use for some time now. Take a look at this message from
> >   November 2001:
> >
> >   http://marc.theaimsgroup.com/?l=php-dev&m=100687224711738&w=2
> >
> >   I didn't introduce anything new, so if it was OK then it should be
> >   OK now. Also, the code cannot affect the people that are not using
> >   the feature so I do not think that there will be any kind of impact
> >   on the existing user base.
> >
> >   This feature makes it possible to have one class per file and not
> >   to worry about inclusion at all. It becomes especially useful when
> >   used together with products such as Zend Accelerator, where files
> >   are cached (and you do not have to worry about a large number of
> >   small files).
> >
> > --
> > Ivan Ristic, [EMAIL PROTECTED]
> > [ Weblog on PHP, Software development, Intranets,
> > and Knowledge Management: http://www.webkreator.com ]
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>ifrance.com, l'email gratuit le plus complet de l'Internet !
>vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
>http://www.ifrance.com/_reloc/email.emailif
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




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

2002-06-09 Thread Andi Gutmans

At 12:53 PM 6/9/2002 -0700, Aaron Bannert wrote:
>On Sun, Jun 09, 2002 at 03:09:24AM +0300, Zeev Suraski wrote:
> > Hmm, but doesn't that mean that the largest contiguous block this heap 
> will
> > be able to provide is 8KB, then?
>
>8K is just the minimum chunk size, there is no absolute maximum.
>
> > > * There's a two-layer structure to the heaps:
> > > - apr_pool objects are what the application uses.  Each pool
> > >   provides a fast alloc interface, no free function, and a
> > >   "destructor" that returns all the allocated space when the
> > >   pool is destroyed.
> >
> > This is probably not very suitable for PHP.  We allocate and free *a lot*,
> > not being able to free is going to increase memory consumption
> > significantly.  If we use APR heaps, are we bound by this behavior?
>
>The expectation is that pools are cleared at normal intervals, so
>that eventually the memory allocation for an application reaches a
>"steady state". In PHP this could be accomplished by simply using
>the per-request pool that is already available when the internal PHP
>functions are called from httpd. At the end of a request this pool is
>"cleared", and then able to be reused on subsequent requests.

I haven't looked at the source for too long but it seems to be much worse 
than HeapCreate().If it doesn't have a node for a certain size it uses 
malloc(). So in the end it seems as if you might reach a situation where 
you do lots of malloc()'s instead of allocating another few pages and 
dividing them up yourself without mutexes.
Please correct me if I'm wrong. I haven't had time to study this code in 
great depth.
Andi


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




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

2002-06-08 Thread Andi Gutmans

At 04:57 PM 6/8/2002 -0700, Brian Pane wrote:
>Zeev Suraski wrote:
>
>>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 allocation 
>>'constructor').
>>
>>>  For PHP processing, do
>>>you need a memory heap that is created at startup and used by all requests,
>>>or is it sufficient to create and destroy a private heap for each request?
>>
>>
>>We can go either way, but won't allocating and freeing these heaps 
>>increase fragmentation?  Remember that PHP functions will also allocate 
>>memory outside these heaps (in 3rd party libraries).
>
>
>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.
>  * There's a two-layer structure to the heaps:
>  - apr_pool objects are what the application uses.  Each pool
>provides a fast alloc interface, no free function, and a
>"destructor" that returns all the allocated space when the
>pool is destroyed.
>  - apr_allocator objects provide blocks of memory for the
>apr_pools to use.  Each apr_allocator maintains a free
>list of blocks.  When a pool is destroyed, its space is
>returned to the apr_allocator from which it was created.
>The next time we create a pool from that apr_allocator,
>we can take an 8KB block from that allocator's free list
>rather than interacting with the system heap.

It sounds to me as if we're going to have to write a new allocator with the 
same semantics as the Win32 API one.
I don't think any of these two allocators would suit us very well.

Andi


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




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

2002-06-08 Thread Andi Gutmans

At 10:47 AM 6/8/2002 -0700, Brian Pane wrote:
>Andi Gutmans wrote:
>
>>I just checked and it seems like Apache APR memory pools use mutex locking.
>>It'd be better to use functions like the Win32 ones which don't use mutex 
>>locking (as we made sure that only one thread allocates from its pool). 
>>This could be achieved by compiling apr_pools.c without APR_HAS_THREADS 
>>but I bet the default Apache 2 build has this enabled.
>>Any ideas?
>>Andi
>
>
>It's not as bad as it looks. :-)
>
>The APR pools do locking only in a few situations:
>  * Creating a new pool
>  * Creating a subpool of a pool
>  * Destroying a pool
>  * Adding space to an existing pool, if it's used up its initial 8KB 
> allocation
>
>So the simplest case, the lifetime of a pool looks like:
>  - create the pool, requiring a lock/unlock
>  - do hundreds of allocations from the pool, none of which require locking

You mean that different threads can allocate/free memory without requiring 
locking? How does it accomplish this?

>  - destroy the pool at the end of the request, requiring one lock/unlock for
>the entire thing
>
>In general, that model works well: over the lifetime of a pool that
>handles O(n) allocation operations, we only have to do O(1) lock/unlock
>operations.
>
>But there's an additional optimization that's possible: Sander Striker
>added support for thread-specific allocators a while back.  The per-request
>pools in most of the Apache 2.0 MPMs take advantage of this.  Each pool
>has an "apr_allocator" object that supplies it with raw memory blocks.
>These allocators can be designated as either thread-private or shared
>across threads.  And a thread-private allocator gets to skip the mutex
>operations.

The thread-private pool is exactly what we need. That's what we're doing in 
IIS and it improved performance significantly.
Do I have access to these pools by default? What would be the equivalent of 
the MS HeapCreate(HEAP_NO_SERIALIZE, ..) call? If you're interested take a 
look at zend_alloc.c and look for Heap. You'll see all of the relevant places.
If you could work with me on this it would definitely be good for PHP. We'd 
just have to find a way to make it work nicely with the SAPI abstraction. 
It's no problem #ifdef'ing for WIN32 in zend_alloc.c but we can't do the 
same for SAPI modules.
Andi


>If you want to try the APR pools, the easiest approach might be to either
>use the request_rec->pool directly or create a sub-pool from it.



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




[PHP-DEV] Re: PHP profiling results under 2.0.37 Re: Performance of Apache2.0 Filter

2002-06-08 Thread Andi Gutmans

On Fri, 7 Jun 2002, Cliff Woolley wrote:

> 
> On Fri, 7 Jun 2002, Brian Pane wrote:
> 
> > IMHO, that's a design flaw.  Regardless of whether PHP is doing
> > buffering, it shouldn't break up blocks of static content into
> > small pieces--especially not as small as 400 bytes.  While it's
> > certainly valid for PHP to insert a flush bucket right before a
> > block of embedded code (in case that code takes a long time to
> > run), breaking static text into 400-byte chunks will usually mean
> > that it takes *longer* for the content to reach the client, which
> > probably defeats PHP's motivation for doing the nonbuffered output.
> > There's code downstream, in the httpd's core_output_filter and
> > the OS's TCP driver, that can make much better decisions about
> > when to buffer and when not to buffer.
> 
> FWIW, I totally agree here.  One of the biggest problems with the way PHP
> handles buckets (as I'm sure has been discussed before I know) is that
> static content cannot remain in its native form as it goes through PHP, or
> at least not in very big chunks.  Take as a counterexample the way
> mod_include deals with FILE buckets.  It reads the FILE bucket (which
> causes the file the be MMAPed if allowed), and from there it just scans
> through the mmaped region, and if it finds nothing, it hands it on to the
> next filter still in the single-MMAP-bucket form.  PHP/Zend, on the other
> hand, takes the file descriptor out of the file bucket, runs it through a
> lexical analyzer which tokenizes it up to 400 bytes at a time, runs it
> through the yacc-generated grammar as necessary, and handles it from
> there.  Far more optimal would be to take the input, do a search through
> it for a starting tag just as mod_include does, and if none is found (or
> up until one is found), just tell the SAPI module to "go ahead and send up
> to THIS point out to the client unmodified".
> 
> So basically the difference between this and what we have now is that the
> lexer should not take each 400 byte buffer and say "here is (up to) 400
> bytes of inline HTML, send it to the client as-is"; instead, it should be
> able to do something along the lines of taking the input 400 bytes at a
> time, and as soon as it starts seeing inline HTML, keep track of the
> starting offset (in bytes), and keep scanning through those 400 byte
> buffers in a tight loop until it finds something that's NOT inline HTML,
> and set the ending offset.  Then it can notify PHP in one call "send bytes
> 375-10136 to the client as-is, it's inline html".

I don't believe that this is what's slowing PHP down on Apache 2. Don't
forget that after the first piece of PHP code we can't optimize inline
HTML any more because they can be conditional.
I think that the non-mutexed per-thread memory pool would improve
performance much more significantly.

Andi


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




Re: [PHP-DEV] filesystem security questions

2002-06-08 Thread Andi Gutmans

At 12:42 PM 6/8/2002 +0200, Markus Fischer wrote:
> Practically, there's no documentation about streams except
> some mail Wez sent to php-dev@ a few weeks (months?) ago (and
> the sources, of course), I hope you can find it in the
> archives.

Maybe we can get Wez to write complete documentation for the API docs? :)

Andi


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




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

2002-06-08 Thread Andi Gutmans

At 10:41 AM 6/8/2002 +0300, Andi Gutmans wrote:
>At 09:12 PM 6/7/2002 -0700, Brian Pane wrote:
>>In case it's helpful to the PHP developers, here are
>>some more performance problems that I found by running
>>a quick system call profile of PHP-4.2.1 within
>>Apache-2.0.37-dev:
>>
>>* php_request_shutdown() calls shutdown_memory_manager(), which
>>  does a large number of calls to free() per request.  If there's
>>  any way to get the PHP allocator to use an APR pool, that
>>  should help speed things up a lot.  (The mallocs and frees are
>>  going to be especially problematic within multithreaded MPMs.)
>
>We're already doing this for Win32. Check out 
>ZEND_DO_MALLOC/ZEND_DO_FREE/ZEND_DO_REALLOC in zend_alloc.c. Note that in 
>Win32 we only skip the free's if we're in release mode. If we're in debug 
>mode we use a per-thread pool but we do the frees because it's our memory 
>leak detector.

I just checked and it seems like Apache APR memory pools use mutex locking.
It'd be better to use functions like the Win32 ones which don't use mutex 
locking (as we made sure that only one thread allocates from its pool). 
This could be achieved by compiling apr_pools.c without APR_HAS_THREADS but 
I bet the default Apache 2 build has this enabled.
Any ideas?
Andi


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




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

2002-06-08 Thread Andi Gutmans

At 05:02 AM 6/8/2002 +0100, Michael Dransfield wrote:
>At 02:40 08/06/2002 +0100, you wrote:
>> > 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.
>>
>>Anyone wanting PHP to be a "simple" or "more flexable" Java is barking up
>>the wrong tree... in fact all of the people I know who Im lobbying "better
>>OO functionality in PHP" for know Java and know PHP - and use both where
>>each is best. What we are requesting is that PHP expands its OO
>>capabilities - not change the way it does things, not do anything
>>outlandish or "stolen" from another language. Think about it - all it
>>would be is like adding an extra gear to a car. Wouldnt change the
>>concept, the design or the idea of the car... not the make nor model... it
>>would however give it added depth and use.
>
>
>I agree completely, for what its worth ;)
>
>I have a question about this whole debate.
>
>If PHP's core goal is to provide easy quick development for 'dynamic 
>pages' , then why is there no built-in template engine?
>
>Having this would solve many of the niggling problems that are associated 
>with current PHP-written (OO) template engines.  Is it that there is no 
>desire for such an extension?

Please read the archives on this issue because I wouldn't want yet another 
long thread to start on php-dev.

Andi


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




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

2002-06-08 Thread Andi Gutmans

At 09:12 PM 6/7/2002 -0700, Brian Pane wrote:
>In case it's helpful to the PHP developers, here are
>some more performance problems that I found by running
>a quick system call profile of PHP-4.2.1 within
>Apache-2.0.37-dev:
>
>* php_request_shutdown() calls shutdown_memory_manager(), which
>  does a large number of calls to free() per request.  If there's
>  any way to get the PHP allocator to use an APR pool, that
>  should help speed things up a lot.  (The mallocs and frees are
>  going to be especially problematic within multithreaded MPMs.)

We're already doing this for Win32. Check out 
ZEND_DO_MALLOC/ZEND_DO_FREE/ZEND_DO_REALLOC in zend_alloc.c. Note that in 
Win32 we only skip the free's if we're in release mode. If we're in debug 
mode we use a per-thread pool but we do the frees because it's our memory 
leak detector.


>* The lex_scan() function consumed a lot of CPU time, even though
>  in my test case (a file with no actual embedded scripting code)
>  only the loop right after the "yy_match" label ever got executed.

In general I've profiled PHP and the scanning stage doesn't take too much 
CPU time. You shouldn't test an empty html page but rather a real-life PHP 
script. I've profiled PHP a lot and be aware that the profiling results 
change a lot according to what script you're running. As it's gone through 
various optimizations already there isn't an easy to find bottleneck.
Andi


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




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

2002-06-07 Thread Andi Gutmans

At 01:14 PM 6/7/2002 -0700, Brian France wrote:
>Yes, zend_hash_graceful_reverse_destroy() fixes the problem as well. Is 
>this a better solution for the fix?

It's the same but doesn't require a new function.

Andi


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




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

2002-06-07 Thread Andi Gutmans

At 01:00 PM 6/7/2002 -0700, Brian France wrote:
>I will try that, but I was worried that the pDestructor function would not 
>get called for each item like it was in zend_hash_destroy. Is this the 
>case?  Looking at the code what is the difference between 
>zend_hash_graceful_destroy and zend_hash_destroy?

Yeah the destructor should be called. The graceful_destroy() is just a bit 
more careful and used when destroying the resource list.

Andi


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




[PHP-DEV] Fwd: REJECTED: <5.1.0.14.2.20020607225328.03df2740@127.0.0.1>

2002-06-07 Thread Andi Gutmans

Any idea why I got this when posting to php-dev?

Andi

>Delivered-To: [EMAIL PROTECTED]
>Sender: <[EMAIL PROTECTED]> (reject)
>Date: Thu, 06 Jun 2002 08:50:05 -0700
>X-Autogenerated: Reply
>To: Andi Gutmans <[EMAIL PROTECTED]>
>From: [EMAIL PROTECTED]
>Subject: REJECTED: <[EMAIL PROTECTED]>
>X-Autogenerated: UNSOLICITED ELECTRONIC COMMUNICATION
>Sender: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>Original-Message-ID: <[EMAIL PROTECTED]>
>Original-Sender: Andi Gutmans <[EMAIL PROTECTED]>
>Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
>Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
>
>
>SERVICE of LEGAL NOTICE:
>
>Pursuant to California Law (cref. California Business & Professions Code
>§§ 17538.4, 17538.45 (2001)), the message referenced herein, uniquely
>identified by the following Internet messaging headers:
>
> {
>     Original-Message-ID: 
> <[EMAIL PROTECTED]>
> Original-Sender: Andi Gutmans <[EMAIL PROTECTED]>
> Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
> Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
> }
>
>has been categorized as either Unsolicited Bulk E-mail (UBE), or
>Unsolicited Commercial E-Mail (UCE).
>
>Your server is one of those included in the headers of the message, and
>thus has been deemed an offending server used in the delivery of this message.
>
>California Law establishes Civil Right of Action against violators:
>
> "In addition to any other action available under law, any
> electronic mail service provider whose policy on unsolicited
> electronic mail advertisements is violated as provided in this
> section may bring a civil action to recover the actual monetary loss
> suffered by that provider by reason of that violation, or liquidated
> damages of fifty dollars ($50) for each electronic mail message
> initiated or delivered in violation of this section, up to a maximum
> of twenty-five thousand dollars ($25,000) per day, whichever amount
> is greater."
>
>Your cooperation, as outlined below, is REQUIRED by California Law.
>
>To avoid being cited as an accomplice in this matter, PRESENCE-GROUP.COM
>requires you to take immediate and appropriate actions to stop the problem
>in the future. You are to notify us within three (3) days of those actions.
>Our experience shows that all legitimate Internet providers take immediate 
>action.
>
>If your server is an offending server in the *origination* of this message,
>PRESENCE-GROUP.COM demands that you provide us with the name, mailing address
>and other contact information of the originator of this message.
>If you furnish PRESENCE-GROUP.COM with this information, PRESENCE-GROUP.COM
>will release you from liability in this incident. Merely telling us you have
>cancelled or deleted the account is *not* adequate to satisfy the
>PRESENCE-GROUP.COM policy.
>
>If your server is an offending server in the *relay* of this message,
>PRESENCE-GROUP.COM demands that you take measures to stop the "open relay"
>from your insecure mailserver.
>
>If you do not furnish PRESENCE-GROUP.COM with the information we have 
>requested,
>or provide us only with auto-responder or form messages, 
>PRESENCE-GROUP.COM will
>consider how often your server is involved with UBE/UCE. We may then:
>
> 1. Block access to & from your server.
> 2. Deem you to be a co-conspirator in the delivery of UBE/UCE 
> messages.
> 3. Hold you liable for fees & damages.
>
>There is no need for you to send your appropriate use policy to us; As 
>stated by law,
>it is our policy that governs.
>
>In order to provide required response to this notice, or if you believe 
>you have
>received this notice in error, please forward your communication to:
>"[EMAIL PROTECTED]", with the words "SPAM EXCEPTION" exactly 
>included in
>the message Subject: header.
>
>Further, you may choose to notify your intended recipient by an additional,
>alternate method requesting that they address this matter with the
>PRESENCE-GROUP.COM mail server administrator.


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




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

2002-06-07 Thread Andi Gutmans

Can you check and see if using zend_hash_graceful_reverse_destroy() fixes 
your problem?

Andi

At 11:44 AM 6/7/2002 -0700, Brian France wrote:
>Zend Engine unloading extension in the wrong order! (Re-post due to no 
>response)
>
>I have been tracking down a core dump with my php extension when it is 
>unloading some of its shared libraries.  I have shared extension that is 
>link against libexpat and will load fine if it is the only on in the 
>php.ini.  If I then load xml.so extension then my extension it works fine, 
>but if it is my extension then xml.so it crashes while xml.so is unloading 
>libexapt.
>
>What I have found is the Zend Engine is unloading extension in the same 
>order it loaded them.
>
>load: foo_bar.so
>load: xml.so
>
>unload: foo_bar.so
>unload: xml.so
>
>I believe this is wrong and think it should be in reverse order.
>
>load: foo_bar.so
>load: xml.so
>
>unload: xml.so
>unload: foo_bar.so
>
>
>There are two ways to fix this problem.  One is to push the modules to the 
>head of the hash, but looking at the zend_hash_add function I decided to 
>go with the second.  Second way is to destroy them in reverse order.  I 
>created a zend_hash_reverse_destroy and call that instead of 
>zend_hash_destroy.  There may be a better way to do this, but this is the 
>quick fix for me.
>
>I have included a patch below, should I submit a bug report as well?
>
>Thanks,
>
>Brian
>
>
>diff -rc php-4.2.1/Zend/zend.c
>*** php-4.2.1/Zend/zend.c   Tue Feb 26 10:59:25 2002
>--- php-4.2.1/Zend/zend.c   Thu Jun  6 11:32:57 2002
>***
>*** 487,493 
> zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
>   #endif
> zend_destroy_rsrc_list_dtors();
>!   zend_hash_destroy(&module_registry);
> zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
> free(GLOBAL_FUNCTION_TABLE);
> zend_hash_destroy(GLOBAL_CLASS_TABLE);
>--- 487,493 
> zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
>   #endif
> zend_destroy_rsrc_list_dtors();
>!   zend_hash_reverse_destroy(&module_registry);
> zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
> free(GLOBAL_FUNCTION_TABLE);
> zend_hash_destroy(GLOBAL_CLASS_TABLE);
>diff -rc php-4.2.1/Zend/zend_hash.c
>*** php-4.2.1/Zend/zend_hash.c  Mon Apr 22 23:53:26 2002
>--- php-4.2.1/Zend/zend_hash.c  Thu Jun  6 11:32:57 2002
>***
>*** 550,555 
>--- 550,579 
> SET_INCONSISTENT(HT_DESTROYED);
>   }
>
>+ ZEND_API void zend_hash_reverse_destroy(HashTable *ht)
>+ {
>+   Bucket *p, *q;
>+
>+   IS_CONSISTENT(ht);
>+
>+   SET_INCONSISTENT(HT_IS_DESTROYING);
>+
>+   p = ht->pListTail;
>+   while (p != NULL) {
>+   q = p;
>+   p = p->pLast;
>+   if (ht->pDestructor) {
>+   ht->pDestructor(q->pData);
>+   }
>+   if (!q->pDataPtr && q->pData) {
>+   pefree(q->pData, ht->persistent);
>+   }
>+   pefree(q, ht->persistent);
>+   }
>+   pefree(ht->arBuckets, ht->persistent);
>+
>+   SET_INCONSISTENT(HT_DESTROYED);
>+ }
>
>   ZEND_API void zend_hash_clean(HashTable *ht)
>   {
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




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

2002-06-06 Thread Andi Gutmans

A couple of months ago it was agreed on how to get multiple inheritance 
like behavior in a way which could work with PHP. I just haven't had time 
to implement it yet.
The talk was about aggregation of instances of classes with auto-proxy.
So you'd do something like:
class foo extends bar contains barbara, foobar {

}

$obj = new foo();
$obj->method(); /* would check foo and if method doesn't exist will 
auto-proxy to objects barbara and foobar in that order whatever matches 
first.*/
You could access the specific object by $obj->classname or $obj->barbara.

Try and find it in the archives.
Andi

At 06:59 PM 6/6/2002 +0100, Dan Hardiker wrote:
> > I believe the OO level we have in ZE2 is the upper limit
> > of  what a scripting language should have.  There's no doubt in my mind
> > that  going beyond that is going to complicate the language beyond what
> > our  average users want.
>
>I would have to disagree to this statement extremly. It would not
>complicate the language as those not interested would just ignore the new
>options and go along as normal. (i.e. all methods and variables being
>public by default)
>
>I sit in many PHP channels (IRC), and observe many class-based PHP
>networks (php-classes.org is one I monitor closely) and can say definatly
>that the majority of PHP users want *more* OO capabilities in PHP.
>Interfaces provide a simple framework for expansive web scripts, which
>currently can only be botched with extends... and multiple inheritance
>would help my current PHP (web-based) project. If these features are too
>complex for you to understand - ignore them!
>
>In my opinion the demand is certainly there, if a subset of people dont
>want to use it - we're not asking them to. What the masses are calling for
>(and they obviously are with the frequency of this kind of post appearing)
>is the option to decide. Although Im no expert on the PHP source code and
>the underlying ZE - is it really that complex to please everyone and give
>a choice? [for those concerned about the proposed stuff having performance
>impacts - then make it a configure option... --with-more-oop (or
>whatever)]
>
>--
>Dan Hardiker [[EMAIL PROTECTED]]
>ADAM Software & Systems Engineer
>First Creative Ltd
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Snapshots not build correctly..

2002-06-05 Thread Andi Gutmans

At 09:25 PM 6/5/2002 +0300, Jani Taskinen wrote:
>On Wed, 5 Jun 2002, Andi Gutmans wrote:
>
> >At 11:35 PM 6/4/2002 +0300, Jani Taskinen wrote:
> >
> >> The source snapshots don't have the bison/flex generated
> >> files anymore..why is that?
> >
> >genfiles was broken but I fixed it in HEAD. Is this still not the case?
>
> I have no idea how the snapshots are generated..but latest
> I downloaded yesterday did not have those files.

They are probably not generated with makedist then.
Anyone know how they are created?

Andi


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




Re: [PHP-DEV] Snapshots not build correctly..

2002-06-04 Thread Andi Gutmans

At 11:35 PM 6/4/2002 +0300, Jani Taskinen wrote:

> The source snapshots don't have the bison/flex generated
> files anymore..why is that?

genfiles was broken but I fixed it in HEAD. Is this still not the case?

Andi


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




Re: [PHP-DEV] Quality of this list

2002-06-04 Thread Andi Gutmans

Was one of the questions about AG(allocated_memory)? Are you sure it's not 
initialized in zend_alloc.c? I see an initialization there.

Andi

At 11:45 AM 6/4/2002 +0200, Hans Rakers wrote:

>Hello all,
>
>No offence, but whatever happened to the technical level on this list? 
>Last two weeks i posted 2 serious stories on the list, one about some 
>difficulties i had when building an extension and one about a possible 
>problem in the memory limit code of the Zend engine, but nobody seems to care.
>
>Yet discussions like 'PHP's vision' seem to get enough attention, which is 
>a discussion that IMHO should really be held on php-evangelism. I thought 
>my questions would make the most sense on php-dev, but if i'm wrong it 
>would have been nice if someone told me so. It's not just my 
>development-related questions on this list that go unanswered.
>
>I don't want to bitch about too much, but as a lurker and occasional 
>question-asker on this list its just something i noticed lately.
>
>With regards,
>
>Hans Rakers
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




[PHP-DEV] Re: PHP's vision

2002-06-03 Thread Andi Gutmans

Hey,

I don't think we need a whole new vision for PHP. PHP's vision has always 
been "to be the best web scripting language out there with a focus on ease 
of use". I think for most of us this hasn't changed. Sure it's cute that 
you can do other things with it but let's be realistic; the focus of PHP is 
the web and PHP is competing in the web applications market. I guess as a 
hypothetical goal we should aim for 100% of dynamic web applications being 
run on PHP.

I think that writing down what we should be doing in the next few months to 
take PHP one step further could be nice, but as Rasmus said, someone's 
going to have to do the work.
I also think that writing a roadmap might just lead to 10,000 Email's being 
sent about all the cool features people want from 1000 different languages 
and we'd have a huge list and no code. Well maybe 10 of those would make it 
in to a release.
I think setting up the php-soap@ list was a good first step. It's getting 
people to discuss things and hopefully we'll have *one* native SOAP 
implementation in the default PHP relatively soon. Hopefully there will be 
a consensus on that list on how to move forward. It'd be a shame if 
there'll be zillions of Email threads but no official SOAP, XML, XSLT, 
DOM/XML layer.

Important things I think should be addressed in the next few months are:
- A native and official "Web services" implementation. For those of you who 
hate the general term I'm talking about SOAP, WDSL, UDDI and strong 
DOM/XML, XSLT, XML support.
- Improved scripting language (I've already packaged an alpha of ZE2 w/ 
PHP-4.3.0-dev and will put it up in the next couple of days so people can 
play around with it). It might not cover everyone's wishes but it does 
cover enough to take PHP one step further IMO. Doing too much at once can 
end up being lethal.
- Stable Apache 2 implementation including real connection pooling across 
thread's in MT mode.
- Improving I18N (mostly done by the Japanese group).
- Seeing the evangelism guys come up with some nice ways of marketing PHP. 
I'm including this because I think it's of great importance although it's 
not a technical issue.

I'm sure you guys can think of a million things but if I'd have to pick big 
main topics I think these would be them.

Andi


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




Re: [PHP-DEV] PHP's vision

2002-06-03 Thread Andi Gutmans

At 03:27 PM 6/3/2002 +0300, Jani Taskinen wrote:
>On Mon, 3 Jun 2002, Andi Gutmans wrote:
>
> >> >the web but more for Enterprise transaction based applications such as
> >> >billing systems.
> >>
> >> Twisting your words a bit: You don't think PHP should be used for such
> >> tasks ??
> >
> >No I definitely don't. And in most cases I wouldn't use J2EE either but I'd
> >use a C++ App server. There are also performance problems with J2EE App
> >servers but often company's clients require J2EE.
>
> Would you write that C++ App server yourself or use some existing one?
> (just wondering whether there is some open source c++ app server 
> around..)

Most people I know who are working in these kind of demanding environments 
(soft real-time requirements) have written these themselves. I don't know 
of any open source ones except for ACE which isn't a complete app server 
but gives you a framework to start on.
BEA's Tuxedo is a commercial example.

Andi


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




Re: [PHP-DEV] PHP's vision

2002-06-02 Thread Andi Gutmans

At 03:36 AM 6/3/2002 +0300, Jani Taskinen wrote:
>On Sun, 2 Jun 2002, Andi Gutmans wrote:
>
> >At 04:21 PM 6/2/2002 +0200, 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.
> >
> >Are you aware how complex and expensive it is to create a Java application
> >server solution?
> >I know it's a great buzz word but in my opinion it is not very suitable for
> >the web but more for Enterprise transaction based applications such as
> >billing systems.
>
> Twisting your words a bit: You don't think PHP should be used for such
> tasks ??

No I definitely don't. And in most cases I wouldn't use J2EE either but I'd 
use a C++ App server. There are also performance problems with J2EE App 
servers but often company's clients require J2EE.

Andi

Andi


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




Re: [PHP-DEV] PHP's vision

2002-06-02 Thread Andi Gutmans

At 04:21 PM 6/2/2002 +0200, 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.

Are you aware how complex and expensive it is to create a Java application 
server solution?
I know it's a great buzz word but in my opinion it is not very suitable for 
the web but more for Enterprise transaction based applications such as 
billing systems.

Andi

>   And coming back to the original topic of this thread: perfect support
>   for XML and all related technologies. Working with Java and XML is a
>   charm.
>
>--
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] libxml bundling

2002-05-31 Thread Andi Gutmans

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 install or filesize.
>  cons:
>Forces people to install themselves.

I just want to mention one of the more important reasons why I think it's a 
good idea to include it in the tree. It means that PHP itself and its 
extensions can rely on having the C API present and can add XML 
functionality in various places.

Andi


>2) trim down libxml and put in cvs
>  pros:
>Build outta the box. Makes php to build without having to download extra
>libaries for highly used extension like domxml. Since domxml requires a newer
>version of libxml than most people have it requires them to go an install it
>before buiding php.
>  cons:
>People feel that maintaing this would be too much of a hassle.
>Conserns about file size of the php package.
>
>3) figure out some method to auto download config/install
>   pros:
> No extra filesize for php source. No matinance for php developers.
>   cons:
> Someone needs to build this (semi complex).
> Reliant on other servers being up/ asseable from clients machines (ie 
> have
>internet connection from the machinge its being installed from)
>
>4) Try and automate the sliming down of libxml and incorp it in the make dist.
>   pros:
> Still have outta the box but it doesn't live in our cvs.
>   cons:
> Someone needs to build this (relitivly simple).
> Still have the filesize issue.
>
>
>Do we vote?
>
>
>  - Brad
>
>__
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_objects.c

2002-05-31 Thread Andi Gutmans

Try now.

Andi

At 16:55 31/05/2002 +0200, Sebastian Bergmann wrote:
>Andi Gutmans wrote:
> > andiFri May 31 10:32:19 2002 EDT
> >
> >   Modified files:
> > /ZendEngine2zend_objects.c
> >   Log:
> >   - Fix build
>
>   I still get
>
> ZendTS.lib(zend_objects.obj): error LNK2001:
> Unresolved external symbol _zend_objects_store_put
> ZendTS.lib(zend_objects.obj): error LNK2001:
> Unresolved external symbol _zend_object_store_get_object
> ZendTS.lib(zend_execute_API.obj): error LNK2001:
> Unresolved external symbol _zend_objects_store_init
> ZendTS.lib(zend_execute_API.obj): error LNK2001:
> Unresolved external symbol _zend_objects_store_destroy
> ZendTS.lib(zend_execute_API.obj): error LNK2001:
> Unresolved external symbol _zend_objects_store_call_destructors
> ZendTS.lib(zend_object_handlers.obj): error LNK2001:
> Unresolved external symbol _zend_objects_store_delete_obj
> ZendTS.lib(zend_object_handlers.obj): error LNK2001:
> Unresolved external symbol _zend_objects_store_del_ref
> ZendTS.lib(zend_object_handlers.obj): error LNK2001:
> Unresolved external symbol _zend_objects_store_add_ref
>
>--
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


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




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

2002-05-30 Thread Andi Gutmans

At 16:39 30/05/2002 -0400, Dan Kalowsky wrote:
>On Thu, 30 May 2002, brad lafountain wrote:
>
> > I personally will take responsiblity for bundling and upgrading it.
>
>Brad,
>
>Nothing personal (so please don't take it that way), but in my opinion
>this isn't a good enough assurance.  Historically you will see people
>come and people go with Open Source development, and while you have a lot
>of free time to do this now, N months from now will you?
>
>As Rasmus stated earlier the reason the MySQL stuff is bundled is due to
>an assurance from the MySQL developers to keep it updated.  They know
>their code inside and out.  I'm not familiar with what you do or don't
>know, or what development you're active in either.  Unless you were/are an
>active developer on the libxml code, the ability to introduce bugs
>completely dependent to the PHP bundle is increased considerably due to
>bad merges.
>
>I really see little to no advantage to this bundling yet.  Only
>increasingly more reasons not to do this.

Just to set the record straight, the MySQL guys haven't been very good at 
syncing the MySQL libraries in our tree. One fix I had to apply myself 
because they just didn't get to it.
I don't really mind because there wasn't anything critical but that's what 
happened.
I
Andi


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




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

2002-05-30 Thread Andi Gutmans

At 19:03 30/05/2002 +0200, [EMAIL PROTECTED] wrote:
>On Thu, 30 May 2002, Rasmus Lerdorf wrote:
>
> > Except with MySQL we have a commitment from the MySQL developers
> > themselves to maintain it and keep it current.
>
>Which they do very often, isn't it Zak ;) But there is a point, there is
>much more familiarity between MySQL and PHP then between the libxml guys
>and PHP.

XML is an extremely important technology. I like the MS way where this kind 
of stuff works out of the box.
It would also allow other extensions to use it and make XML support much 
more integrated in PHP.
So if you can cut it down to something small I'm +1.

Andi


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




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

2002-05-30 Thread Andi Gutmans

At 08:46 30/05/2002 +0200, [EMAIL PROTECTED] wrote:
>On Thu, 30 May 2002, Andi Gutmans wrote:
>
> > I think that XML is a core technology and giving plug&play access to our
> > users is important. Having bundled the MySQL library made it easier for
> > people to get started with MySQL. Does that mean I think every library
> > should be bundled with PHP? No, I don't.
> > But if libxml2 is a moving target and it's hard to stay in sync then it
> > certainly sounds beneficial to take away this headache from our users. It
> > also means that other XML based extensions could use it by default.
> > Of course it also depends how big it is. If we can strip it down a lot I'd
> > be a +1. If it'd add 1 MB to our .tar.gz I would be against.
>
>THe normal source distribution is almost 2 MB...

In that case I'm against :)

Andi


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




<    1   2   3   4   5   6   7   8   9   10   >