Re: [PHP-DEV] [PATCH] destructors called after module shutdown
Hello Florian, hello Andi to me this is the way to go. At least the order of shutdown pieces is correct with this patch but maybe Andi has a better idea? regards marcus Friday, July 2, 2004, 11:51:44 PM, you wrote: > Currently object's destructors are called in the zend_deactivate function in > main.c after the modules > request_shutdown_func has been called (main.c - > php_call_shutdown_functions(void); ) . > Since no code should be executed after module request shutdown unexpected > behaviour might > occur like the one descibed in bug#27555 affecting the session extension. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: [PHP-DOC] #28994 [Opn]: pg_field_prtlen takes int instead of string as third argument
Can anybody take a look into this, please?
Thanks,
Nuno
> ID: 28994
> User updated by: bas at vanklinkenbergsoftware dot nl
> Reported By: bas at vanklinkenbergsoftware dot nl
> Status: Open
> Bug Type: Documentation problem
> Operating System: N/A
> PHP Version: 4.3.7
> New Comment:
>
> All right, some more investigation shows me that when using lower case
> column names, all works well. When using mixed case column names, using
> a string as the third argument generates the 'Bad Column Offset' error.
> See code snippet below. Note that fieldnames are correctly retrieved
> with pg_field_name().
>
> $db_conn = pg_connect("host = localhost port = 5432 dbname = test
> user = test password = test");
> $result = pg_query($db_conn, 'SELECT * FROM test');
> echo "table column index 0, has a lower case name, works
> fine:\n";
> $fieldname = pg_field_name($result, 0);
> echo "fieldname: $fieldname \n";
> $fieldlength = pg_field_prtlen($result, 0, 0);
> echo "fieldlength: $fieldlength \n";
> $fieldlength2 = pg_field_prtlen($result, 0, $fieldname);
> echo "fieldlength: $fieldlength2 \n";
>
> echo 'table column index 1, has a mixed case name, generates
> e_notice and empty fieldlength:\n';
> $fieldname = pg_field_name($result, 1);
> echo "fieldname: $fieldname \n";
> $fieldlength3 = pg_field_prtlen($result, 0, 1);
> echo "fieldlength: $fieldlength3 \n";
> $fieldlength4 = pg_field_prtlen($result, 0, $fieldname);
> echo "fieldlength: $fieldlength4 \n";
>
> You can test the code above at this url:
> http://212.61.21.72/test/pg_field_prtlen_test.php
>
> The database table used in the above code looks like this:
> ==
> Welcome to psql 7.3.4-RH, the PostgreSQL interactive terminal.
>
> You are now connected to database test as user test.
> test=> select * from test;
> first_column | Second_Column
> --+
> 1 | some text
> 2 | some more text
> (2 rows)
>
> test=>
>
>
> Appearantly it looks like there are two problems: the documentation
> problem, where the possibility to pass an int as the third argument is
> not documented, and the error that occurs when using mixed case column
> names. Should I file the latter as a separate bug?
>
> Regards,
> Bas
>
>
> Previous Comments:
>
>
> [2004-07-02 23:17:01] [EMAIL PROTECTED]
>
> What I can see in the sources is that the proto is:
>
> int pg_field_prtlen(resource result, [int row,] mixed
> field_name_or_number
>
>
> Row is optional and the last parameter can be either a string or an
> integer. If it's passed as string, it is recongnised as the field name,
> otherwise as the field number.
>
> I've never used PostgreSQL, so can you or somebody confirm if the
> function is behaving as I've stated, please??
>
> Thanks,
> Nuno
>
>
>
> [2004-07-02 15:50:02] bas at vanklinkenbergsoftware dot nl
>
> Description:
>
> In the online documentation for pg_field_prtlen, the function
> arguments are described as follows:
>
> int pg_field_prtlen (resource result, int row_number, string
> field_name)
>
> but actually it should be:
>
> int pg_field_prtlen (resource result, int row_number, int
> column_number)
>
> (The third argument should be column number instead of field name).
> When using pg_field_prtlen as stated in the online documentation, a
> 'Bad Column Offset' error is generated.
>
>
>
>
>
> Edit this bug report at http://bugs.php.net/?id=28994&edit=1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: keyword arguments?
On Fri, 25 Jun 2004, Daniel Crookston wrote: > I was actually asking which part of the PHP code I'd want to modify. I > haven't been able to find an overview of what all the different files are > for - possibly I'm just not looking in the right place. Does such an > overview exist that I could read over? No, there is no such thing at all. There is some very limited and outdated information in the manual and the places you most likely need to change for this are in Zend/: zend_language_parser.y and zend_language_scanner.l and ofcourse the zend_compile.c and zend_execute.c files. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 'make install' fails when --enable-memory-limit is present
On Wed, 23 Jun 2004, Zeev Suraski wrote: > > > My suggestion - add -dmemory_limit=32M to PEAR_INSTALL_FLAGS (16M solves > > > the problem on my Linux box, but I think we should go higher to be on the > > > safe side). > > > >We prolly should highen the limit to a default 16M too for PHP 5. > > Why? Because applications in PHP 5 will most likely be larger usually due to the better support for OO. People will earlier attempt to create more complex applications and easily get over the low limit of 8MB. Additionaly to this, you can't even resize a truecolor jpg (1600x1200) at this moment with the default memory limit because GD uses about 4 times the amount of pixels in an image as memory. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mem leak fix
Hello Andi, Since some time ago (I don't remember when), my Apache 2 started crashing when I stop or restart it. I'm using PHP 5 has an apache module and Windows. If I disable the module, apache behaves correctly. The message I get from windows is 'memory could not be "read"'. I know this info isn't enough to trace the error, but as Apache run as a service, I don't know how to attach a debugger to it. (I've never compilled php has an apache module either, just as CGI). Nuno - Original Message - > Hi, > > As Sterling and others have mentioned, PHP 5 HEAD was leaking badly. > I just commited a fix which I hope works. Can you please check it out and > let me know if there are any problems/crashes? > > Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP-DOC] #28994 [Opn]: pg_field_prtlen takes int instead of string as third argument
--- Nuno Lopes <[EMAIL PROTECTED]> wrote: > Can anybody
take a look into this, please?
>
>From having a look in the source, and more pain with
pgsql than anyone should be subjected to, I think
what's happening is a cross-confusion of two issues.
You're right in that if you call it with three
parameters the validation equates to your
interpretation, not his, and the column can be
specified as either string (name) or long (number).
Where *he's* going wrong is in dealing with pgsql's
case-handling. Postgres will lower-case all column
names by default, *unless* you wrap them in quotes
when you create the table to preserve the casing. This
means that you have to wrap the column names in quotes
(to preserve the casing) in *every damn statement /
query* you make to that table thereafter. What he's
doing is initialising the column name *directly* with
the return value of another query, but not wrapping it
in escaped quotes, so postgres is treating the
$fieldname in the later pg_field_prtlen() call as
'second_column' and not '"Second_Column"'. Basically:
it's a combination of a postgres issue and his code. I
think. :)
Cris
>
> > ID: 28994
> > User updated by: bas at vanklinkenbergsoftware
> dot nl
> > Reported By: bas at vanklinkenbergsoftware
> dot nl
> > Status: Open
> > Bug Type: Documentation problem
> > Operating System: N/A
> > PHP Version: 4.3.7
> > New Comment:
> >
> > All right, some more investigation shows me that
> when using lower case
> > column names, all works well. When using mixed
> case column names, using
> > a string as the third argument generates the 'Bad
> Column Offset' error.
> > See code snippet below. Note that fieldnames are
> correctly retrieved
> > with pg_field_name().
> >
> > $db_conn = pg_connect("host = localhost port =
> 5432 dbname = test
> > user = test password = test");
> > $result = pg_query($db_conn, 'SELECT * FROM
> test');
> > echo "table column index 0, has a lower case
> name, works
> > fine:\n";
> > $fieldname = pg_field_name($result, 0);
> > echo "fieldname: $fieldname \n";
> > $fieldlength = pg_field_prtlen($result, 0, 0);
> > echo "fieldlength: $fieldlength \n";
> > $fieldlength2 = pg_field_prtlen($result, 0,
> $fieldname);
> > echo "fieldlength: $fieldlength2 \n";
> >
> > echo 'table column index 1, has a mixed
> case name, generates
> > e_notice and empty fieldlength:\n';
> > $fieldname = pg_field_name($result, 1);
> > echo "fieldname: $fieldname \n";
> > $fieldlength3 = pg_field_prtlen($result, 0,
> 1);
> > echo "fieldlength: $fieldlength3 \n";
> > $fieldlength4 = pg_field_prtlen($result, 0,
> $fieldname);
> > echo "fieldlength: $fieldlength4 \n";
> >
> > You can test the code above at this url:
> > http://212.61.21.72/test/pg_field_prtlen_test.php
> >
> > The database table used in the above code looks
> like this:
> > ==
> > Welcome to psql 7.3.4-RH, the PostgreSQL
> interactive terminal.
> >
> > You are now connected to database test as user
> test.
> > test=> select * from test;
> > first_column | Second_Column
> > --+
> > 1 | some text
> > 2 | some more text
> > (2 rows)
> >
> > test=>
> >
> >
> > Appearantly it looks like there are two problems:
> the documentation
> > problem, where the possibility to pass an int as
> the third argument is
> > not documented, and the error that occurs when
> using mixed case column
> > names. Should I file the latter as a separate bug?
> >
> > Regards,
> > Bas
> >
> >
> > Previous Comments:
> >
>
> >
> > [2004-07-02 23:17:01] [EMAIL PROTECTED]
> >
> > What I can see in the sources is that the proto
> is:
> >
> > int pg_field_prtlen(resource result, [int row,]
> mixed
> > field_name_or_number
> >
> >
> > Row is optional and the last parameter can be
> either a string or an
> > integer. If it's passed as string, it is
> recongnised as the field name,
> > otherwise as the field number.
> >
> > I've never used PostgreSQL, so can you or somebody
> confirm if the
> > function is behaving as I've stated, please??
> >
> > Thanks,
> > Nuno
> >
> >
>
> >
> > [2004-07-02 15:50:02] bas at
> vanklinkenbergsoftware dot nl
> >
> > Description:
> >
> > In the online documentation for pg_field_prtlen,
> the function
> > arguments are described as follows:
> >
> > int pg_field_prtlen (resource result, int
> row_number, string
> > field_name)
> >
> > but actually it should be:
> >
> > int pg_field_prtlen (resource result, int
> row_number, int
> > column_number)
> >
> > (The third argument should be column number
> instead of field name).
> > When using pg_field_prtlen as stated in the online
> documentation, a
> > 'Bad Column Offset' error is generated.
> >
> >
[PHP-DEV] Ignore
Ignore
Re: [PHP-DEV] 'make install' fails when --enable-memory-limit is present
On Sat, 2004-07-03 at 12:13, Derick Rethans wrote: > > > > My suggestion - add -dmemory_limit=32M to PEAR_INSTALL_FLAGS (16M solves > > > > the problem on my Linux box, but I think we should go higher to be on the > > > > safe side). > > >We prolly should highen the limit to a default 16M too for PHP 5. > Because applications in PHP 5 will most likely be larger usually due to > the better support for OO. People will earlier attempt to create more > complex applications and easily get over the low limit of 8MB. > Additionaly to this, you can't even resize a truecolor jpg (1600x1200) > at this moment with the default memory limit because GD uses about 4 > times the amount of pixels in an image as memory. To be honest, I've never understood why. php_imlib2 seems to run though things fine with large files, and the structure of that is hardly uncommon, and it's not like I've been doing anything dodgy with fudging the zend api to get it to work right. Might take a look at that one tomorrow. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
