headers
Marcus Börger | 1 Jul 2003 02:06
Picon
Favicon

[PHP-DEV] Moving SPL into the engine ?

Hello Andi,

you asked for a spl patch against ZE2. Ok, i spent some hours to move
spl-foreach hooking into the engine.

Here is the diff:
http://marcus-boerger.de/php/ext/ze2/ze2-spl-20030630.diff.tgz
Here are modified tests:
http://marcus-boerger.de/php/ext/ze2/ze2-spl-tests-20030630.tgz
Here is the diff needed for sqlite:
http://marcus-boerger.de/php/ext/ze2/ze2-spl-sqlite-20030630.tgz

As soon as i find some more time i'll give the array stuff a go. Anyway it
would be good to receive some feedback before doing it.

As you can see easily, the impact on the foreah opcode handlers is even less
than i thought. So i guess it is more than acceptable when compared to what we
gain.

Happy experimenting

Best regards,
 Marcus                            mailto:helly <at> php.net

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Alan Knowles | 1 Jul 2003 03:07
Favicon
Gravatar

Re: [PHP-DEV] Reflection API

It would be alot nicer if you could provide the majority of these as 
object variables (and/or) functions, it would enable
print_r(new PHP_Function('counter'));
which would save a lot of messing around, and writing code for general 
queries..
Regards
Alan

> $obj = new PHP_Function("counter");
>
> print $obj->getName()." was decared in ".$obj->getFileName()." 
> starting at ".$obj->getStartLine().
> "and ending at ".$obj->getEndline."\n";
> print "Here is what it's docs have to say: "$obj->getDocComment(). "\n";
> if($statics = $obj->staticVariables()) {
>     print $obj->getName()." has the following static 
> variables:\n".print_r($statics);
> }
> print $obj->invoke();
>
> Something like that.
>

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 9 comments |
headers
Andi Gutmans | 1 Jul 2003 07:33
Favicon

[PHP-DEV] Re: Moving SPL into the engine ?

Hi,

It is still not possible to understand from this .diff what the impact on 
the Engine will be because the code it still saturated with copying of code 
from the Engine. My intentation was to review a patch that is ready to be 
commited. You shouldn't have to replace opcodes anymore and you shouldn't 
have to make copies of functions from within Zend.
Also, does the array overloading stuff allow extension developers like 
Andrei also to hook into this?

Andi

At 02:06 AM 1/7/2003 +0200, Marcus Börger wrote:
>Hello Andi,
>
>you asked for a spl patch against ZE2. Ok, i spent some hours to move
>spl-foreach hooking into the engine.
>
>Here is the diff:
>http://marcus-boerger.de/php/ext/ze2/ze2-spl-20030630.diff.tgz
>Here are modified tests:
>http://marcus-boerger.de/php/ext/ze2/ze2-spl-tests-20030630.tgz
>Here is the diff needed for sqlite:
>http://marcus-boerger.de/php/ext/ze2/ze2-spl-sqlite-20030630.tgz
>
>As soon as i find some more time i'll give the array stuff a go. Anyway it
>would be good to receive some feedback before doing it.
>
>As you can see easily, the impact on the foreah opcode handlers is even less
>than i thought. So i guess it is more than acceptable when compared to what we
(Continue reading)

Permalink | Reply | 3 comments |
headers
Zeev Suraski | 1 Jul 2003 11:27
Favicon
Gravatar

Re: [PHP-DEV] bundling libxml2

At 00:16 28/06/2003, John Coggeshall wrote:
>On Fri, 2003-06-27 at 13:08, Sterling Hughes wrote:
> > Because, this will encourage people to do :
> >
> > --without-xml
> >
> > Instead of upgrading the system libxml2.
>
>If someone actually *needs* XML support for whatever they are doing, and
>they have absolutely no option but to upgrade libxml2, they'll do it. It
>doesn't require becoming maintainers of an entirely different code base.

We have no intentions to become maintainers of a different codebase, 
integrating libxml into the PHP distribution is a completely separate 
issue.  Please read the archives.

Zeev

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 1 comment |
headers
John Coggeshall | 1 Jul 2003 11:40

Re: [PHP-DEV] bundling libxml2

> We have no intentions to become maintainers of a different codebase, 
> integrating libxml into the PHP distribution is a completely separate 
> issue.  Please read the archives.

This message must have been stuck in my queue, because i sent this
Friday. It's outdated, and as far as I care is a dead thread.

John
-- 
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org                 http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Sascha Schumann | 1 Jul 2003 12:25

Re: [PHP-DEV] [PATCH] SQLite session storage

On Sat, 28 Jun 2003, John Coggeshall wrote:

> Since SQLite will be bundled in the future, I sat down and got
> acquainted with it by writing a module for the session extension which
> allows users to store their session data in a SQLite database*.
>
> To use, just apply the patch to session.c (which adds the reference to
> the new module and adds the mod_sqlite.c to config.m4) and compile.. To
> use it set session.save_handler = sqlite.

    Sounds fine in principle.  Where is the patch?

    - Sascha

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 4 comments |
headers
Derick Rethans | 1 Jul 2003 12:27
Picon
Gravatar

Re: [PHP-DEV] [PATCH] SQLite session storage

On Tue, 1 Jul 2003, Sascha Schumann wrote:

> On Sat, 28 Jun 2003, John Coggeshall wrote:
> 
> > Since SQLite will be bundled in the future, I sat down and got
> > acquainted with it by writing a module for the session extension which
> > allows users to store their session data in a SQLite database*.
> >
> > To use, just apply the patch to session.c (which adds the reference to
> > the new module and adds the mod_sqlite.c to config.m4) and compile.. To
> > use it set session.save_handler = sqlite.
> 
>     Sounds fine in principle.  Where is the patch?

Wouldn't it be much nicer to put this in the sqlite extension instead 
because people may turn sqlite support off? php_register_session_module 
should be used here IMO.

Derick

-- 
"Interpreting what the GPL actually means is a job best left to those
                    that read the future by examining animal entrails."
-------------------------------------------------------------------------
 Derick Rethans                                 http://derickrethans.nl/ 
 International PHP Magazine                          http://php-mag.net/
-------------------------------------------------------------------------

--

-- 
PHP Internals - PHP Runtime Development Mailing List
(Continue reading)

Permalink | Reply | 3 comments |
headers
Wez Furlong | 1 Jul 2003 12:29

Re: [PHP-DEV] [PATCH] SQLite session storage

Hey John,

Mail me the patch and I'll look at integrating it into the sqlite extension
itself; as Derick says, it is probably the best place for it.

--Wez.

----- Original Message -----
From: "Derick Rethans" <derick <at> php.net>
To: "Sascha Schumann" <sascha <at> schumann.cx>
Cc: "John Coggeshall" <john <at> coggeshall.org>; <internals <at> lists.php.net>
Sent: Tuesday, July 01, 2003 11:27 AM
Subject: Re: [PHP-DEV] [PATCH] SQLite session storage

> On Tue, 1 Jul 2003, Sascha Schumann wrote:
>
> > On Sat, 28 Jun 2003, John Coggeshall wrote:
> >
> > > Since SQLite will be bundled in the future, I sat down and got
> > > acquainted with it by writing a module for the session extension which
> > > allows users to store their session data in a SQLite database*.
> > >
> > > To use, just apply the patch to session.c (which adds the reference to
> > > the new module and adds the mod_sqlite.c to config.m4) and compile..
To
> > > use it set session.save_handler = sqlite.
> >
> >     Sounds fine in principle.  Where is the patch?
>
> Wouldn't it be much nicer to put this in the sqlite extension instead
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sascha Schumann | 1 Jul 2003 12:29

Re: [PHP-DEV] [PATCH] SQLite session storage

On Tue, 1 Jul 2003, Derick Rethans wrote:

> On Tue, 1 Jul 2003, Sascha Schumann wrote:
>
> > On Sat, 28 Jun 2003, John Coggeshall wrote:
> >
> > > Since SQLite will be bundled in the future, I sat down and got
> > > acquainted with it by writing a module for the session extension which
> > > allows users to store their session data in a SQLite database*.
> > >
> > > To use, just apply the patch to session.c (which adds the reference to
> > > the new module and adds the mod_sqlite.c to config.m4) and compile.. To
> > > use it set session.save_handler = sqlite.
> >
> >     Sounds fine in principle.  Where is the patch?
>
> Wouldn't it be much nicer to put this in the sqlite extension instead
> because people may turn sqlite support off? php_register_session_module
> should be used here IMO.

    Yes, "principle" referred to having a sqlite-enabled storage
    container in the base distribution.  The implementation
    should be self-contained, of course.

    - Sascha

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Coggeshall | 1 Jul 2003 12:51

Re: [PHP-DEV] [PATCH] SQLite session storage


On Tue, 2003-07-01 at 06:29, Wez Furlong wrote:
> Hey John,
> 
> Mail me the patch and I'll look at integrating it into the sqlite extension
> itself; as Derick says, it is probably the best place for it.

http://www.coggeshall.org/php/mod_sqlite.tar.gz

I missed rolling the mini-patch I had for session.c in the tarball,
which doesn't matter if you are integrating into ext/sqlite... but if
your curious

http://www.coggeshall.org/php/session.c.patch

John

-- 
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org                 http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |

Gmane