Re: [PHP-DEV] Building extension for Mac OS X
Rasmus Lerdorf skrev: Fredrik Olsson wrote: No problem, my guess is that #include "php.h" for some reason uses the php4 header file. How do I force phpize, ./configure, #include "php.h" etc, to use the installed php5 files (All residing under /usr/local/php5)? How about: /usr/local/php5/bin/phpize ? Unfortunately not quite as easy :(. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] imap_savebody()
I wrote: > Currently there is no way to fetch a big message/attachment through > ext/imap if memory_limit is enabled. I'd like to kindly ask for > consideration of the following patch: > > http://dev.iworks.at/PATCHES/imap_savebody.patch.txt Thanks a lot for review; the patch has been updated with your suggestions. Additionally the whole thing is ifdef'd out in ZTS mode as the c-client gets function is a global variable. I tested the function with a 17M message saving to a file as well to an already opened stream. Thanks, -- Michael - < mike(@)php.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: clockwerx
helgi (dufus) sez: http://www.php.net/cvs-php.php ask for a CVS user and mention you need karma for pear/Validate, but I guess the pear group will give the karma but php group accept the user Just mention that Helgi (cvs user dufuz) told you to get a user to maintain Validate_AU do the same on pear.php.net to get the user so you can register the package ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shutdown order changed again? broken dl()'d modules, again
Actually, it's using php.ini to load pdo for the CLI, and not calling dl(). The script is just a test script, but this is still a PHP level bug that we should, IMO, fix before 5.1. --Wez. On 9/22/05, Andi Gutmans <[EMAIL PROTECTED]> wrote: > Yep, we reverted to the previous state because we broke stuff. The > real solution is to have a two phase shutdown. > Is your script just for testing? (it's weird to have a persistent > connection with a dl(), but that doesn't mean we shouldn't introduce > another shutdown stage.) > > At 07:27 PM 9/22/2005, Wez Furlong wrote: > >I'm getting this on shutdown with PHP 5.1 when using persistent > >connections with a dl'd PDO. > >Dan mentioned something similar with the ibm_db2 extension: > > > >==23982== > >==23982== Jump to the invalid address stated on the next line > >==23982==at 0x1BCE5C0B: ??? > >==23982==by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574) > >==23982==by 0x81BB665: zend_hash_graceful_reverse_destroy > >(zend_hash.c:640) > >==23982==by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240) > >==23982== Address 0x1BCE5C0B is not stack'd, malloc'd or (recently) free'd > >==23982== > >==23982== Process terminating with default action of signal 11 (SIGSEGV) > >==23982== Access not within mapped region at address 0x1BCE5C0B > >==23982==at 0x1BCE5C0B: ??? > >==23982==by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574) > >==23982==by 0x81BB665: zend_hash_graceful_reverse_destroy > >(zend_hash.c:640) > >==23982==by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240) > > > >Sounds like we're unloading the modules before calling the dtors again. > > > >--Wez. > > > >-- > >PHP Internals - PHP Runtime Development Mailing List > >To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shutdown order changed again? broken dl()'d modules, again
Yep, we reverted to the previous state because we broke stuff. The real solution is to have a two phase shutdown. Is your script just for testing? (it's weird to have a persistent connection with a dl(), but that doesn't mean we shouldn't introduce another shutdown stage.) At 07:27 PM 9/22/2005, Wez Furlong wrote: I'm getting this on shutdown with PHP 5.1 when using persistent connections with a dl'd PDO. Dan mentioned something similar with the ibm_db2 extension: ==23982== ==23982== Jump to the invalid address stated on the next line ==23982==at 0x1BCE5C0B: ??? ==23982==by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574) ==23982==by 0x81BB665: zend_hash_graceful_reverse_destroy (zend_hash.c:640) ==23982==by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240) ==23982== Address 0x1BCE5C0B is not stack'd, malloc'd or (recently) free'd ==23982== ==23982== Process terminating with default action of signal 11 (SIGSEGV) ==23982== Access not within mapped region at address 0x1BCE5C0B ==23982==at 0x1BCE5C0B: ??? ==23982==by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574) ==23982==by 0x81BB665: zend_hash_graceful_reverse_destroy (zend_hash.c:640) ==23982==by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240) Sounds like we're unloading the modules before calling the dtors again. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] shutdown order changed again? broken dl()'d modules, again
I'm getting this on shutdown with PHP 5.1 when using persistent connections with a dl'd PDO. Dan mentioned something similar with the ibm_db2 extension: ==23982== ==23982== Jump to the invalid address stated on the next line ==23982==at 0x1BCE5C0B: ??? ==23982==by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574) ==23982==by 0x81BB665: zend_hash_graceful_reverse_destroy (zend_hash.c:640) ==23982==by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240) ==23982== Address 0x1BCE5C0B is not stack'd, malloc'd or (recently) free'd ==23982== ==23982== Process terminating with default action of signal 11 (SIGSEGV) ==23982== Access not within mapped region at address 0x1BCE5C0B ==23982==at 0x1BCE5C0B: ??? ==23982==by 0x81BB4BC: zend_hash_apply_deleter (zend_hash.c:574) ==23982==by 0x81BB665: zend_hash_graceful_reverse_destroy (zend_hash.c:640) ==23982==by 0x81BD680: zend_destroy_rsrc_list (zend_list.c:240) Sounds like we're unloading the modules before calling the dtors again. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] imap_savebody()
Use 8192 chunk size; anything bigger than that is a complete waste of memory. --Wez. On 9/22/05, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: > Sara Golemon wrote: > >>#define GETS_FETCH_SIZE 2048000 > >> > > > > That size doesn't seem a bit excessive to you? I thought the whole point of > > dumping it to a file was to avoid huge memory chunks. Not to mention the > > fact that reserving 2MB of stack space makes me a little twitchy... > > Indeed, 2 megs of stack space seems a bit much, not to mention > completely bypassed PHP's memory limit. I'd recommend allocating 1 > megabyte buffer via emalloc(), a bit slower, but much "nicer" IMHO. > > > Ilia > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] imap_savebody()
Sara Golemon wrote: >>#define GETS_FETCH_SIZE 2048000 >> > > That size doesn't seem a bit excessive to you? I thought the whole point of > dumping it to a file was to avoid huge memory chunks. Not to mention the > fact that reserving 2MB of stack space makes me a little twitchy... Indeed, 2 megs of stack space seems a bit much, not to mention completely bypassed PHP's memory limit. I'd recommend allocating 1 megabyte buffer via emalloc(), a bit slower, but much "nicer" IMHO. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] imap_savebody()
> #define GETS_FETCH_SIZE 2048000
>
That size doesn't seem a bit excessive to you? I thought the whole point of
dumping it to a file was to avoid huge memory chunks. Not to mention the
fact that reserving 2MB of stack space makes me a little twitchy...
> /* {{{ proto bool imap_savebody(resource stream_id,
> string file, int msg_no, string section[, int options])
>
I'd make section option with the default being whatever it is that just
gives you the whole body. Come to that it probably makes sense to be able
to save the entire message (including headers).
I'd also suggest either a second function, or an overloaded second parameter
so that an existing stream could be used. This way a scripter could shuttle
multiple messages off to a spool file, or open one for appending and add a
message, or dump it to network socket (maybe they're implementing their own
POP3=>IMAP gateway (god only knows why).
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] on-the-fly changes to php.ini values?
Hello! I'm working on an Apache2 module which pulls vhost info from LDAP, and I've got it all knocked out save one really important feature: I need to be able to change the open_basedir on a per-vhost basis, but obviously, NOT via php_admin_value in the configuration file(s), since each vhost is loaded dynamically from LDAP data. I dug around a bit and found the zend_alter_ini_entry function, the prototype of which, at least, looked really promising. However, it always returns FAILURE for me. I've tried every combination of mod_type. I went and copied the source for zend_alter_ini_entry directly into my module, which let me determine that the call to zend_find_hash() is what's failing. So this leads me to believe zend_alter_ini_entry isn't really what I need to do this. I also poked around in the per-dir configuration handler (sapi/apache2handler/apache_config.c:merge_php_config), but that hasn't shed enough light on the problem for me to just jump in and start hacking away at the php module config data block. So, my question is: is there a programmatic way, via some function call or procedure, to alter PHP's runtime configuration as I describe above? Thanks and further details forthcoming to anyone who can lend a hand. Todd D. Esposito -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] imap_savebody()
Hi, Currently there is no way to fetch a big message/attachment through ext/imap if memory_limit is enabled. I'd like to kindly ask for consideration of the following patch: http://dev.iworks.at/PATCHES/imap_savebody.patch.txt The patch introduces a new function imap_savebody(rsrc imap, string file, int msgno, string sect[, int flags]) which will save the specified body section to a file. Thanks, -- Michael - < mike(@)php.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension silently fails
David Olsson wrote: > Hello all! > > Not really sure if this is posted in the correct newsgroup. If not, > please just ignore my post... :-) > > Anyhow, I have a strange problem with a PHP extension I have written in > C++. It builds fine and it also runs fine when I use it with the PHP > CLI. When I use it from Apache 2, it simply fails with the following > error in the Apache error log: > > [Thu Sep 22 16:13:06 2005] [notice] child pid 4151 exit signal Aborted (6) > > Otherwise, PHP works fine with Apache 2. All I need to do is comment out > the lines which use functions in my extension. > > What could be the difference between running the PHP CLI and PHP as a > Apache 2 module? They both use the same php.ini file. Is there any way > of getting something more in the log from PHP? Run Apache under gdb and get a backtrace from that abort to see where that is happening. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Building extension for Mac OS X
Fredrik Olsson wrote: > I use the binary installation of PHP 5.0.4 from > http://www.entropy.ch/software/macosx/php/ > > And a tiny test case trying to introduce the module hello, with the > function hello_world() that simply returns a string. Actually I have > just used copy and paste from this tutorial http://tinyurl.com/cahsj > > At first I ran > php -r 'echo hello_world();' > With "Fatal error: Call to undefined function: hello_world() in Command > line code on line 1" as result. > I checked into it and reallies that the default php was php 4, so I tried: > > /usr/local/php5/bin/php -r 'echo hello_world();' > To be sure. > This yields a better result :) > PHP Warning: PHP Startup: : Unable to initialize module > Module compiled with module API=20020429, debug=0, thread-safety=0 > PHPcompiled with module API=20041030, debug=0, thread-safety=0 > These options need to match > > No problem, my guess is that #include "php.h" for some reason uses the > php4 header file. How do I force phpize, ./configure, #include "php.h" > etc, to use the installed php5 files (All residing under /usr/local/php5)? How about: /usr/local/php5/bin/phpize ? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Extension silently fails
Hello all! Not really sure if this is posted in the correct newsgroup. If not, please just ignore my post... :-) Anyhow, I have a strange problem with a PHP extension I have written in C++. It builds fine and it also runs fine when I use it with the PHP CLI. When I use it from Apache 2, it simply fails with the following error in the Apache error log: [Thu Sep 22 16:13:06 2005] [notice] child pid 4151 exit signal Aborted (6) Otherwise, PHP works fine with Apache 2. All I need to do is comment out the lines which use functions in my extension. What could be the difference between running the PHP CLI and PHP as a Apache 2 module? They both use the same php.ini file. Is there any way of getting something more in the log from PHP? These are the extact versions of things I am using: PHP 4.3.11 Apache 2.0.54 GCC 3.2.3 Redhat Enterprise 3 2.4.21-15 Thanks for any help! David Olsson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Building extension for Mac OS X
I use the binary installation of PHP 5.0.4 from http://www.entropy.ch/software/macosx/php/ And a tiny test case trying to introduce the module hello, with the function hello_world() that simply returns a string. Actually I have just used copy and paste from this tutorial http://tinyurl.com/cahsj At first I ran php -r 'echo hello_world();' With "Fatal error: Call to undefined function: hello_world() in Command line code on line 1" as result. I checked into it and reallies that the default php was php 4, so I tried: /usr/local/php5/bin/php -r 'echo hello_world();' To be sure. This yields a better result :) PHP Warning: PHP Startup: : Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=0 PHPcompiled with module API=20041030, debug=0, thread-safety=0 These options need to match No problem, my guess is that #include "php.h" for some reason uses the php4 header file. How do I force phpize, ./configure, #include "php.h" etc, to use the installed php5 files (All residing under /usr/local/php5)? regards Fredrik Olsson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build config.w32
Derick Rethans wrote: > On Thu, 22 Sep 2005, Edin Kadribasic wrote: > > >>edink Thu Sep 22 09:18:14 2005 EDT >> >> Modified files: >>/php-src/win32/build config.w32 >> Log: >> MFB: Fix building of extensions that inlcude extname/header.h > > > Wouldn't it be better to fix the extensions to include "ext/" in their > include path to the headers? This makes more sense IMO. This was something done by design for PDO to ease pecl installation AFAIK. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php version of GD lib
I am using the version of GD packaged with php 4.3.x for windows and am having a problem with opening images and not being able to lock them. As soon as I have multiple users requiring the same dynamically generated image, the image sent to the browser is all distorted and blurred but only happens when multiple users are accessing the exact same dynamically generated image. I would like to lock the images before processing but the functions for gd (eg. imagecreatefromgif() require a filename string and not a resource handle created by flock(). Any insight would be appreciated. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build config.w32
On Thu, 22 Sep 2005, Edin Kadribasic wrote: > Derick Rethans wrote: > > On Thu, 22 Sep 2005, Edin Kadribasic wrote: > > > > > >>edink Thu Sep 22 09:18:14 2005 EDT > >> > >> Modified files: > >>/php-src/win32/buildconfig.w32 > >> Log: > >> MFB: Fix building of extensions that inlcude extname/header.h > > > > > > Wouldn't it be better to fix the extensions to include "ext/" in their > > include path to the headers? This makes more sense IMO. > > This was something done by design for PDO to ease pecl installation > AFAIK. Interesting, as the "normal" PHP build system doesn't add the "ext/" part either... Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PDO questions
I plan to add some kind of prepared statement caching in a (not too distant) future PDO release, however... You'd only benefit from prepared statement caching when the underlying driver supports it. Not only does it require support from the driver, but it also requires good, solid support for it to be worthwhile. Taking postgres as an example, it's prepared statement implementation has some issues with query planning that might make this an unnatractive prospect--to the point where the postgres driver has a flag to disable native prepared statements for those cases where it makes a difference. Caching PDO emulated prepared statements will have negligible benefit. Just like any feature, you'll need to evaluate whether it's use will make sense for your application. --Wez. On 9/22/05, Ron Korving <[EMAIL PROTECTED]> wrote: > > > 2) Could it be a good idea (performance wise) and possible in the first > > > place to maintain a pool of prepared statements? Something like this: > > > > This should be done on the RDBMS end. I havent looked at how PDO does > > this in detail, but it would be nice to get some more control over this. > > Some RDBMS will pool this automatically, some do not (AFAIK pgsql will > > always create a new statement instead of returning a handle to an > > existing statement). There is a reason why you may want more control > > over this. One of the key aspects of a prepared statement is that you > > safe time due to not having to build a query plan on every execution. > > This may bite you however if you prepare a statement and then things > > change within the database that would make it more feasible to use a new > > plan. > > It would be very nice if this was indeed done by the RDBMS. That would mean > you don't have to "remember" any prepared statements yourself and would > definately benefit the performance a great deal. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PDO questions
> Ron Korving wrote:
>
> > 1) Does unsetting $stmt trigger a closeCursor() as well? I assume so,
but
> > the article doesn't mention it. It only talks about the importance of
> > calling that method.
>
> yes this is done automatically ..
Great :)
> > 2) Could it be a good idea (performance wise) and possible in the first
> > place to maintain a pool of prepared statements? Something like this:
>
> This should be done on the RDBMS end. I havent looked at how PDO does
> this in detail, but it would be nice to get some more control over this.
> Some RDBMS will pool this automatically, some do not (AFAIK pgsql will
> always create a new statement instead of returning a handle to an
> existing statement). There is a reason why you may want more control
> over this. One of the key aspects of a prepared statement is that you
> safe time due to not having to build a query plan on every execution.
> This may bite you however if you prepare a statement and then things
> change within the database that would make it more feasible to use a new
> plan.
It would be very nice if this was indeed done by the RDBMS. That would mean
you don't have to "remember" any prepared statements yourself and would
definately benefit the performance a great deal.
> > 3) Wouldn't it be nice if you could do a $stmt->execute("foo", "bar");
> > (numeric parameters) instead of $stmt->execute(array("foo", "bar")); ?
>
> I think this would severely hurt the extensibility of the API not only
> for PDO itself, but also for people who want to transparently extend the
> API.
Good point, I take that back.
> regards,
> Lukas
Thanks,
Ron
Scanned and protected by SecureMail v2.2
http://www.axit.nl
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PDO questions
Lukas Smith wrote:
3) Wouldn't it be nice if you could do a $stmt->execute("foo", "bar");
(numeric parameters) instead of $stmt->execute(array("foo", "bar")); ?
I think this would severely hurt the extensibility of the API not only
for PDO itself, but also for people who want to transparently extend the
API.
Also note your suggestion would only work for ? placeholders and not for
:foo style placeholders (which I would generally recommend for
readability reasons).
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PDO questions
Ron Korving wrote:
1) Does unsetting $stmt trigger a closeCursor() as well? I assume so, but
the article doesn't mention it. It only talks about the importance of
calling that method.
yes this is done automatically ..
2) Could it be a good idea (performance wise) and possible in the first
place to maintain a pool of prepared statements? Something like this:
This should be done on the RDBMS end. I havent looked at how PDO does
this in detail, but it would be nice to get some more control over this.
Some RDBMS will pool this automatically, some do not (AFAIK pgsql will
always create a new statement instead of returning a handle to an
existing statement). There is a reason why you may want more control
over this. One of the key aspects of a prepared statement is that you
safe time due to not having to build a query plan on every execution.
This may bite you however if you prepare a statement and then things
change within the database that would make it more feasible to use a new
plan.
3) Wouldn't it be nice if you could do a $stmt->execute("foo", "bar");
(numeric parameters) instead of $stmt->execute(array("foo", "bar")); ?
I think this would severely hurt the extensibility of the API not only
for PDO itself, but also for people who want to transparently extend the
API.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PDO questions
After reading the php|architect article on PDO by Ilia I have a couple of
questions:
1) Does unsetting $stmt trigger a closeCursor() as well? I assume so, but
the article doesn't mention it. It only talks about the importance of
calling that method.
2) Could it be a good idea (performance wise) and possible in the first
place to maintain a pool of prepared statements? Something like this:
class MyClass
{
private $stmts = array();
public function __construct($db)
{
$this->db = $db;
}
public function getInfo()
{
if (!isset($this->stmts["info"])) $this->stmts["info"] =
$this->db->prepare("select .");
$this->stmts["info"]->execute(array("foo", "bar"));
...
}
}
3) Wouldn't it be nice if you could do a $stmt->execute("foo", "bar");
(numeric parameters) instead of $stmt->execute(array("foo", "bar")); ?
Nice article by the way, Ilia, although I think the php|arch editor(s)
really could do a better job. I wrote an article for them myself on SOAP a
while ago, and I can't say I was too satisfied on the job the editor did on
it.
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
