[PHP-DEV] Metadata, active properties, garbage collection
A few questions on Zend internals: Is it possible to add (opaque, as far as the PHP script will be concerned) data to object of internal class from C? Preferably, this data would not even be visible to the script. I see the class declaration struct has functions that seem to be related to getting and setting properties. How would I use these to create 'active' attributes? When the refcount of a value drops to 0, when is it garbage collected? Can I hook into that (from C) to clear up related resources? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Add function aliases at runtime?
Is it possible to add a function entry for a C-coded funtion at runtime? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Add function aliases at runtime?
[EMAIL PROTECTED] wrote: Is it possible to add a function entry for a C-coded funtion at runtime? I once was interested in that and Sascha said it's possible to do that. It was quite a while back ,so I dunno if recent changes changed also the situation. Any pointers into the mailinglist archives? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Add function aliases at runtime?
[EMAIL PROTECTED] wrote: uh, sorry, it was on #php :) on efnet you mean? I tried there but there wasn't anyone around that could answer the question. Any particular time/place where the PHP gurus lounge? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Woah
Rasmus Lerdorf wrote: reuse. We can get back to the idea of letting people define % as htmlspecialchars(), You can do that in PHP? How? You can't. You missed the dripping sarcasm. Well, I was torn between accepting it as sarcasm, and getting hints on how to accomplish it :) Totally impossible? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Macro functionality
Is there any way (with C coding or otherwise) to implement macros a la #define in C for PHP? I need to have something that looks like a function but that calls eval in the body, and I need that eval to be executed in the calling scope. If that's not possible, would it be OK to do something akin to (pseudocode here): save_current_symbol_table=EG(active_symbol_table); EG(active_symbol_table) = EG(symbol_table); ops = compile_string(param) execute(ops) EG(active_symbol_table)=save_current_symbol_table; Thiis wouldn't execute in the calling scope (which looks like it's trapped in execute) but the global scope. It'd be a comrpomise but I'd settle for it. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Imap SSL support (Bug #10330)
Jani Taskinen wrote: IMAP-2000 ext/imap does not compiles well using phpize because both PHP_ARG_WITH() in its config.m4. Why would anyone want to use phpize on imap extension? (forgive me but I never have needed phpize..) You do when you want to develop self-contained extensions. SCEs are useful for large PHP extensions that have to live outside the main PHP tree, or for package builders that want to develop a main php4 package and separate packages for the extensions (much like debian does). Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Imap SSL support (Bug #10330)
Jani Taskinen wrote: So, it means that you never test PHP extensions in SCE mode. So? I have no use for SCEs. All the world, fall in line with Jani. Some people do need them. For PHP too, see package argument earlier. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] maybe not a PHP library?
I'm trying to create a minimal module to do some debugging work, but it fails to load. I essentially used ext_skel to create an fresh extension, moved it out of the PHP tree, then did: $ phpize $ ./configure --enable-apdebug $ make # make install The extension is generated OK AFAICT, but it lacks the symbol get_module, which gets me 'PHP Warning: Invalid library (maybe not a PHP library) 'apdebug.so' in Unknown on line 0' in my error log. Any ideas, anyone? Using Apache 1.3.19 and 4.0.4.5rc6 on Debian sid. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] maybe not a PHP library?
Alexander Bokovoy wrote:
I'm trying to create a minimal module to do some debugging work, but it
fails to load. I essentially used ext_skel to create an fresh extension,
moved it out of the PHP tree, then did:
$ phpize
$ ./configure --enable-apdebug
$ make
# make install
The extension is generated OK AFAICT, but it lacks the symbol
get_module, which gets me 'PHP Warning: Invalid library (maybe not a
PHP library) 'apdebug.so' in Unknown on line 0' in my error log.
Any ideas, anyone? Using Apache 1.3.19 and 4.0.4.5rc6 on Debian sid.
Yes. This known bug for self contained extensions when config.h isn't read
by php_apdebug.c so HAVE_APDEBUG and COMPILE_DL_APDEBUG aren't defined.
Try to do bizzare thing;
CFLAGS=$CFLAGS -DHAVE_APDEBUG=1 -DCOMPILE_DL_APDEBUG=1 ./configure --with-apdebug
OK, that worked and brings us closer to my problem.
I have said module compiled as a self-contained extension, loaded via
php.ini. No other extensions are loaded, and I'm using apache and php4
from debian packages.
The only thing I do in my debug extension is this:
PHP_RINIT_FUNCTION(apdebug)
{
request_rec *r;
r = ((request_rec *) SG(server_context));
fprintf(stderr,
APDEBUG: request_config=%#lx\n, r-request_config);
return SUCCESS;
}
request_config is always 0x1, while I can confirm that in other
apache modules request config is a sane value in the fixup phase (before
PHP is active) and the logging phase (after the PHP script has ran).
Does this ring a bell for anyone?
Emile
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
James Moore wrote: This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. True, but in this case the main issue is a problem in the autoconf system. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. Doesn't have my preference, of course, but if that's the general feel on php-dev then that's what needs to happen. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)
Rasmus Lerdorf wrote: Having midgard in the PEAR infrastructure makes sense once the PEAR infrastructure is such that it is easy to install PEAR components that include C bits. And yes, perhaps the midgard folks are the right people to push this along, if they are willing and able. Someone called? Heck yes, willing. Able, most probably, with some help on how to set up things right for PEAR. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PEAR (was: Re: [PHP-CVS] cvs: php4/ext/midgard config.m4)
Zeev Suraski wrote: At 02:04 20/3/2001, Rasmus Lerdorf wrote: No, we need tighter integration. We want to be able to do something along the lines of "pear pear.php.net/midgard" and it would go and fetch the the component, build it and install it. I completely agree with Andi about this. If it won't be simple, it will simply not be. We can start simple, and work our way up. For unixoids, this could probably be a glue script that uses CVS. There'd probably need to be checkin-time phpize setup or somesuch to make it distribution-ready, or people would need autoconf et al on their systems allways. I don't know how this would work for windows system, though. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
Wolfgang Drews wrote: delivering .tar.gz, but in addition offer this .bz2 thing. So why not, if at least those modem-users would benefit of it? Could benefit, not would benefit. They'd need to download and install bzip2 first. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
Cameron wrote: i'll agree its about due for release, can we do SOMETHING about the download size tho? i dont really have any ideas on decent ways to shrink it but it seems to be bloating to me. could do with the mcrypt fix's and zeev's output buffer fix 1st tho . . . Hum, having just contributed to said download size... we've done our best to minimize the KLOC, removing some cruft and moving a couple of functions into a (separate) library, but we'd be down to stripping comments to go further... the only other thing I could suggest is using bzip2 instead of gzip: -rw-r--r--1 emileemile 1952068 Feb 19 10:53 php-4.0.4pl1.tar.bz -rw-r--r--1 emileemile 2439189 Feb 19 10:52 php-4.0.4pl1.tar.gz which is a 20% size reduction without changing anything else. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] time to upgrade our bundled expat?
"Thies C. Arntzen" wrote: We use it a lot. Works well, supports multiple charsets, and is now in as sane library format so internalizatin isn't strictly necesary anymore (although there can be reasons to do so all the same, of course). Is there anything specific you want to know about it? -was the upgrade from the original jclark-dist painfull at all? We haven't seen any API changes ourselves, and I think we use a fairly sizeable part of the API. We had our own version of expat-lib, built from jclark-dist, and include file name changes aside, it was painless. -are there any known incompatiblities? Not that I know of, altough ISTR that apache had renamed some function names for their internalized version. Our resident expat 'expert' will be online in a few hours and I'm sure he can give you more details. -do you think that if we upgrade the PHP 4 bundled expat we'll hit any wall? In what sense? Just to satisfy my curiosity, why is expat being internalized when it's available as a library? To minimize external dependancies? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Time for 4.0.5?
"Hellekin O. Wolf" wrote: Can we propose extensions outside of the main distribution ? I like the idea of downloading what you want. Through a form, you would chose the extensions you need, then submit and receive a custom GZIP or BZ2 file. It sounds doable. Any constraint, dependency to work out ? Yes, the m4 stuff... Can we open a thread on that specific topic of a PHP-downloader ? * Regarding midgard, although it is considered beta, I'm for including it into the main distrib for RC1, so that people can test it and eventually the midgard team can release a final version before 4.0.5 ships. Yes. We're gearing up for final beta (or RC, would be another term for it) end of this week. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Midgard
Emiliano wrote: Midgard extension contains 200k of vanity images. This is unreasonable bloat to the core of PHP. Can you please remove them? They've been removed days ago. My mistake, they were removed from our own CVS. We forgot to do that at cvs.php.net. The mistake has been rectified. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Midgard (Was: cvs: php4 /ext/midgard .cvsignore...)
Peter "[DiSAStA]" Petermann wrote: Well right now it won't really solve it because pear is included in the distribution. However, the idea behind pear is to be something more similar what if midgard would be handled like php-gtk? How would that be? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Midgard (Was: cvs: php4 /ext/midgard .cvsignore...)
Andi Gutmans wrote: OK, my mistake. So moving php4/ext/midgard to php4/pear/midgard would solve this? Well right now it won't really solve it because pear is included in the distribution. However, the idea behind pear is to be something more similar to CPAN which means both PHP and C code. OK, but CPAN is huge too. Does the build process differ here? And like my previous question, are there examples on how to build config.m4s, and other supportive files, so an extension can easily be built as an php-dloabable, a static extension, and a static extension in a statically-compiled PHP (into Apache itself)? The easiest way to get it working is "cd php4; cp -r /path/to/midgard ext; ./buildconf". That's all people need to do in order to get it to work with their vanilla PHP. You can check out some of the other extensions to see how to build a shared library but with my example it's not necessary. What I couldn't find there is how to detect that we're being built using apxs or statically in apache, for example. There is also the phpize stuff (which I don't know). It's something like phpize /path/to/midgard and then compiling the midgard as a shared library. I think the first example I gave you is probably good enough though. The phpize methods works (it's what we use right now), but loading the midgard extension for every request does not have my preference. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Midgard (Was: cvs: php4 /ext/midgard .cvsignore...)
Stanislav Malyshev wrote: E With the PHP4 version of Midgard, patching is no longer a E necessity. It's an ordinary extension like the others. Ah, so parser modifications are out? Good to know. Yes, they are. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Midgard (Was: cvs: php4 /ext/midgard .cvsignore...)
James Moore wrote: With the PHP4 version of Midgard, patching is no longer a necessity. It's an ordinary extension like the others. Perhaps it would be an idea to move it out of the main PHP CVS (into another cvs module) for now and put links on php.net, personally I would really like to see things like this in PEAR which is where I feel they should be. But PEAR is a repository for scripts written in PHP, right? php4/ext/midgard is a 'regular' (albeit admittedly large) PHP extension, written in C. Is there any work being done on some sort of deamon/server for PEAR so people get a client build when PHP builds and then they can just tell it to fetch various modules for PHP from php.net and any mirrors etc. In the end somthing like $pearclient get midgard which would do everything needed (IE fetch midgard from PHP.net place in it right place etc) would be cool then all the client would have to do is either build it as .so or rebuild php with --enable-midgard for example. That would indeed be nice. Well, since we're on the topic of re-seperating, are there examples on how to build config.m4s, and other supportive files, so an extension can easily be built as an php-dloabable, a static extension, and a static extension in a statically-compiled PHP (into Apache itself)? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Building stand-alone/built-in
Hi all, I'm building a PHP extension that I'd like to be able to build both as fully external and embedded into PHP. I include some apache headers si I need the build environment to either tell me where apxs is or have the include directories 'handed to me' in the php-provided build environment. How can I tell how I'm being compiled? Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
