Hello all,
I just fetched the latest php5 package for win32 from snaps.php.net
(Built On: Jul 07, 2004 06:30 GMT).
It seems like the ini-setting for memory_limit is ignored and the
default of 8MB is used instead. This also causes installation of PEAR to
fail and probably affects bug #29023.
Memory limit checking is not compiled in on Windows. So bugs must be caused by
something else.
Edin
On Wednesday 07 July 2004 12:24, Peter Rendl wrote:
Hello all,
I just fetched the latest php5 package for win32 from snaps.php.net
(Built On: Jul 07, 2004 06:30 GMT).
It seems like the
Edin Kadribasic wrote:
Memory limit checking is not compiled in on Windows. So bugs must be
caused by
something else.
Unfortunately phpinfo() does not show compile options for this build.
But http://snaps.php.net/win32/snapshot.log contains this line
snapshot: forcing memory-limit on. Is it a
Peter Rendl wrote:
Edin Kadribasic wrote:
Memory limit checking is not compiled in on Windows. So bugs must be
caused by
something else.
Unfortunately phpinfo() does not show compile options for this build.
But http://snaps.php.net/win32/snapshot.log contains this line
snapshot: forcing
On Wednesday 07 July 2004 14:21, Peter Rendl wrote:
Edin Kadribasic wrote:
Memory limit checking is not compiled in on Windows. So bugs must be
caused by
something else.
Unfortunately phpinfo() does not show compile options for this build.
But http://snaps.php.net/win32/snapshot.log
Edin Kadribasic wrote:
You have uncovered an error in win32 configure script which is fixed now. The
next snap should again have memory limit disabled.
This is good, thank you.
One more question for my understanding:
Checking the memory limit and setting it, are 2 different things to me.
Why did
Attached is a patch for zend_execute.c which will fall to read_property if
get_property_ptr_ptr returns NULL in zend_fetch_property_address_inner.
Hopefully this is the correct fix as it didnt break any tests and resolves
the issue I hit.
Rob
From: Marcus Boerger
Sounds more like small
On 2004/07/07, at 14:18, Kamesh Jayachandran wrote:
In this case while making a copy og global_class_table to thread
specific class_table in a deep fashion. zend_hash_copy has to do the
double dereferencing which it can't being a generic fuinction.
Sorry, but I don't quite understand what you
Hi Moriyoshi,
Thanks for replying.
My question is very simple.
Please answer the following question.
1)Zend has global_class_table of type HashTable with a key as the class
name ('char*') and value of type 'zend_class_entry**'. True or False?
As I look at the code the above statement seems to be
Work on php_zeroconf with gabe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2004/07/08, at 1:04, Kamesh Jayachandran wrote:
My question is very simple.
Please answer the following question.
1)Zend has global_class_table of type HashTable with a key as the class
name ('char*') and value of type 'zend_class_entry**'. True or False?
Keys are just strings and associated
At 16:32 07/07/2004, Rob Richards wrote:
Attached is a patch for zend_execute.c which will fall to read_property if
get_property_ptr_ptr returns NULL in zend_fetch_property_address_inner.
Hopefully this is the correct fix as it didnt break any tests and resolves
the issue I hit.
It's not a correct
i experienced this using PHP4 ( guess it is 4.2.x ) in our local
production enviroment and with one of our clients servers ( 4.3.2 )
-- red
Nuno Lopes wrote:
Hello,
A user have reported a bug in the documentation about ini_get().
Check this:
?
// if register_globals is off
From: Zeev Suraski
It's not a correct fix :I get_ptr_ptr must return the address of an
allocated zval *, one which can later be separated,
etc. T(result-u.var).var.ptr doesn't fall into that category - it can be
gone in the next opcode...
The only safe way to return a zval ** is for the
At 22:27 07/07/2004, Rob Richards wrote:
From: Zeev Suraski
It's not a correct fix :I get_ptr_ptr must return the address of an
allocated zval *, one which can later be separated,
etc. T(result-u.var).var.ptr doesn't fall into that category - it can be
gone in the next opcode...
The only
Last one expired today in Canada. So will we be seeing GIF support in
4.3.8 and 5.0.0? I'm hoping it's not too late for 5.0.0 at least.
Scott
Andi Gutmans wrote:
If we were a couple of years away from the patent expiry in the rest of
the world, then I'd suggest a --i-am-in-the-us switch. But as
- Original Message -
From: Scott MacVicar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 07, 2004 6:56 PM
Subject: Re: [PHP-DEV] GIF create support for bundled GD
Last one expired today in Canada. So will we be seeing GIF support in
4.3.8 and 5.0.0? I'm hoping it's
At 01:56 08/07/2004, Scott MacVicar wrote:
Last one expired today in Canada. So will we be seeing GIF support in
4.3.8 and 5.0.0? I'm hoping it's not too late for 5.0.0 at least.
It probably is - it will come out in 5.0.1.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To
IBM's patent is invalid as the patent was issued to Unisys before hand.
Scott
Paul G wrote:
- Original Message -
From: Scott MacVicar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 07, 2004 6:56 PM
Subject: Re: [PHP-DEV] GIF create support for bundled GD
Last one expired
- Original Message -
From: Scott MacVicar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 07, 2004 7:13 PM
Subject: Re: [PHP-DEV] GIF create support for bundled GD
IBM's patent is invalid as the patent was issued to Unisys before hand.
afaik, ibm *filed* earlier than
On 4/15/2004 Jason Garber asked about a new language construct to
simplify testing if a variable isset() and assinging a default value for
those that aren't. The thread title was Construct Request.
I rember reading it while the discussion went on, I just went back and
browsed through it
Hi Marc,
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
If I recall correctly, Marcus had a patch that implemented it and it was
going to be plugged in in the 4.1 branch (when it is created).
I'm eagerly waiting
Jason Garber wrote:
Hi Marc,
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
So ?: is out then? Or just delayed until it can be tackled.
If I recall correctly, Marcus had a patch that implemented it and it was
Hi Marc,
At 7/7/2004 09:06 PM -0400, Marc Richards wrote:
Jason Garber wrote:
Hi Marc,
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
So ?: is out then? Or just delayed until it can be tackled.
Who am I to say it's
Hello Marc,
it somply was far too lat3e in relase process. That's wy we ae all agreed
to delay that until 5.1. Also we were very unsure about the name of such
an operatorif you can collect all the ideas or can come up with ther
perfect one!?!
a patch is here:
At 09:20 PM 7/7/2004 -0400, Jason Garber wrote:
On a related note, does anyone know when 5.1 is going to be
branched? Shortly after the 5.0.0 release, I assume.
Yeah I'd like to branch 5.0 off right away as there are some things I'd
like to start working on, mainly some performance patches.
http://bugs.php.net/28999
It seems the behaviour of exec() and the array being returned
changed when iliaa revamped a lot of code pre 4_3_2RC1, which caused the
array being passed to always get initialized.
So it does seem questionable if it should be refixed since this
behaviour has been
Hi Moriyoshi,
File: Zend/zend_compile.c
Function: do_bind_class
some code snippet
zend_class_entry *ce
zend_hash_add(class_table, opline-op2.u.constant.value.str.val,
opline-op2.u.constant.value.str.len+1, ce, sizeof(zend_class_entry *),
NULL)
some code snippet
From the above zend_hash_add I came
28 matches
Mail list logo
