ID: 12956
Updated by: wez
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: GD related
Operating System: Debian GNU/Linux
PHP Version: 4.0CVS-2001-08-25
New Comment:
It's a GD bug; I know this because my patched GD works fine with TTF. I submitted the
patch to the GD
My fault :I I'm working on it.
At 02:54 26-08-01, Rasmus Lerdorf wrote:
It should be fixed now. Please let me know if it isn't.
Well, as of right now, it is still broken. Or am I waiting for a commit?
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail:
ID: 9740
Updated by: joey
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: DOM XML related
Operating System: Linux 2.2.16-3 (RH)
PHP Version: 4.0.4pl1
New Comment:
Closed in CVS, fix will be part of 4.0.7.
Previous Comments:
ID: 9893
Updated by: joey
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: DOM XML related
Operating System: Windows 2000 SP1
PHP Version: 4.0.4pl1
New Comment:
Fixed in CVS. Will be part of 4.0.7.
Previous Comments:
This may be due to the way domxml is doing things, but the test script
in bug #10936 still creates a crash, and the backtrace points to
zend_print_zval_r_ex...see attachment 1.
Attachment 2 show that var_dump() gives more or less the same result.
#0 0x81bf5d6 in zend_print_zval_r_ex
From: [EMAIL PROTECTED]
Operating system: Windows95
PHP version: 4.0.6
PHP Bug Type: *Graphics related
Bug description: ImageColorAllocate() doesn't work with PNGs
?php
header (Content-type: image/png);
$text=implode($argv, );
$image=imageCreateFromPNG(basic.png);
It looks like domxml is responsible here. The hash table that's sent to it
contains a NULL value, which should be a valid zval *...
Zeev
At 13:04 26-08-01, Joey Smith wrote:
This may be due to the way domxml is doing things, but the test script
in bug #10936 still creates a crash, and the
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.6
PHP Bug Type: Scripting Engine problem
Bug description: direct access to an array fails but walkthrough by foreach works
It seems that I've reached one of the borders of PHP/Zend.
I'm coding a qt-like
ID: 12963
Updated by: mathieu
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: GD related
Operating System: Windows95
PHP Version: 4.0.6
New Comment:
I'm not a PNG expert but you could try ImageColorResolve()
The palette used in 'basic.png' may be different than you
OK, I'll track it down. Thanks.
On Sun, 26 Aug 2001, Zeev Suraski wrote the following to Joey Smith :
It looks like domxml is responsible here. The hash table that's sent to it
contains a NULL value, which should be a valid zval *...
Zeev
At 13:04 26-08-01, Joey Smith wrote:
This may
On Sun, Aug 26, 2001 at 10:26:20AM -, PHP Bug Database wrote:
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.6
PHP Bug Type: Scripting Engine problem
Bug description: direct access to an array fails but walkthrough by foreach works
As I havn't set
ID: 12964
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4.0.6
New Comment:
Jan,
It's our all paperbag since you consultet a few not-so-newbie people before submitting
... ;-)
Ok, it is working again now.
--
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]
Hi Rasmus!
On Sun, 26 Aug 2001, Rasmus Lerdorf wrote:
Ok, it is working again now.
How about Apache2? Is any eye on it?
just askin'
-- teodor
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
If NULL's a valid zval*, then both of thise routines need to be fixed to
handle null pointers. Here's some patches:
--- zend.c.orig Sun Aug 26 11:14:28 2001
+++ zend.c Sun Aug 26 11:20:22 2001
@@ -199,6 +199,10 @@
ZEND_API void zend_print_zval_r_ex(zend_write_func_t write_func, zval
What Zeev meant is that it should be a valid zval * but it isn't.
Andi
At 11:31 AM 8/26/2001 -0400, George Schlossnagle wrote:
If NULL's a valid zval*, then both of thise routines need to be fixed to
handle null pointers. Here's some patches:
--- zend.c.orig Sun Aug 26 11:14:28 2001
+++
p.s. casual inspection suggest that having NULL zval pointers in
HashTables may break alot of places.
On Sunday, August 26, 2001, at 11:31 AM, George Schlossnagle wrote:
If NULL's a valid zval*, then both of thise routines need to be fixed
to handle null pointers. Here's some patches:
At 11:45 AM 8/26/2001 -0400, George Schlossnagle wrote:
Ahh... that makes much more sense. Should there be any protection though
from populating a hash with NULL values, or is this solely the
responsibility of the extension writer? While there is the
zend_has_add_empty_element(), it appears
Sounds fair to me.
On Sunday, August 26, 2001, at 11:51 AM, Andi Gutmans wrote:
At 11:45 AM 8/26/2001 -0400, George Schlossnagle wrote:
Ahh... that makes much more sense. Should there be any protection
though from populating a hash with NULL values, or is this solely the
responsibility
ID: 12830
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Apache related
Operating System: linux 2.4
PHP Version: 4.0.6
New Comment:
First: i used OpenLDAP version 2.0.11 while compiling php4
Second: i configured the library with:
Zeev,
how do you test before commit? I mean, what web server do you use
for development?
-- Adam
On Sun, Aug 26, 2001 at 02:48:14AM +0300, Zeev Suraski wrote:
I think that was some breakage I was responsible for (I committed a fix
about 30 minutes later, only apparently I never actually
Hi all,
The rand()-redesign is already looking like something. The next few days I'm
N/A, and I would appreciate it if people who:
- possibly have remarks on the new behaviour of rand() co, take a look at
my second proposal on this subject:
But it is not :)
It was a double meaning sentence I guess, what I meant that what was
*supposed* to be a valid zval *, was in fact a NULL (which is not a valid
zval *)
At 18:31 26-08-01, George Schlossnagle wrote:
If NULL's a valid zval*, then both of thise routines need to be fixed to
IIS and Apache, roughly 50/50...
At 23:07 26-08-01, Adam Dickmeiss wrote:
Zeev,
how do you test before commit? I mean, what web server do you use
for development?
-- Adam
On Sun, Aug 26, 2001 at 02:48:14AM +0300, Zeev Suraski wrote:
I think that was some breakage I was responsible for (I
[Changed subject, I missed this thread until now because of it...]
I assume this difference between 12 and 3 is _strictly_ performance, and
_nothing_ else?
And a note for others: You don't need TSRML* in every function, but you do
need it if you use:
- Global variables, like BG(...) co.
- Use
At 00:23 27-08-01, Jeroen van Wolffelaar wrote:
[Changed subject, I missed this thread until now because of it...]
I assume this difference between 12 and 3 is _strictly_ performance, and
_nothing_ else?
Well, it's also results in shorter code (there were plenty of functions
that used both
Hey, could you summarize your changes to trans_sid and the session sutff?
I'm losing track with all these patches...
On Mon, 27 Aug 2001, Zeev Suraski wrote:
zeev Sun Aug 26 20:23:55 2001 EDT
Modified files:
/php4/ext/session php_session.h session.c
/php4/ext/standard
It's basically all a part of the same title.
What I did is de-coupling of the session trans_sid code and the output
code. The session module now uses chunked output buffering, and has no
special cases in the output layer. The advantages to doing that are:
- Faster performance (theoretical,
One thing I couldn't get to the bottom of is PS(define_sid) and the
define_sid logic in php_session_start(). I understand the code, but I
couldn't understand why we define SID in certain cases to contain valid
data, and sometimes just an empty string. It's also being used in
On Mon, Aug 27, 2001 at 01:33:46AM +0300, Zeev Suraski wrote:
The other issue is a suggestion I want to pitch - right now, if sessions
are started after the headers are already sent, we'll get a nice
headers-already-sent error. If we have trans_sid enabled (which we will
most probably,
Hey,
Currently working on the Binary Tree implementations for the ADT
extension and was wondering what people thought as more intuitive,
something like:
$tree = tree_new(AVL_TREE);
tree_insert($tree, $element, compare_func);
// ...
Or:
$tree =
On Sun, Aug 26, 2001 at 07:29:59PM -0400, Sterling Hughes wrote :
Currently working on the Binary Tree implementations for the ADT
extension and was wondering what people thought as more intuitive,
something like:
$tree = tree_new(AVL_TREE);
tree_insert($tree,
On Sun, Aug 26, 2001 at 07:29:59PM -0400, Sterling Hughes wrote:
Hey,
extension and was wondering what people thought as more intuitive,
something like:
$tree = tree_new(AVL_TREE);
tree_insert($tree, $element, compare_func);
// ...
I prefer this notation.
On Sun, 26 Aug 2001, Jon Parise wrote:
On Sun, Aug 26, 2001 at 07:29:59PM -0400, Sterling Hughes wrote:
Hey,
extension and was wondering what people thought as more intuitive,
something like:
$tree = tree_new(AVL_TREE);
tree_insert($tree, $element,
At 07:29 PM 8/26/01 -0400, Sterling Hughes wrote:
Hey,
Currently working on the Binary Tree implementations for the ADT
extension and was wondering what people thought as more intuitive,
something like:
$tree = tree_new(AVL_TREE);
tree_insert($tree, $element,
Quoting Sterling Hughes [EMAIL PROTECTED]:
Jep -- I'm writing PEAR OO wrappers for every ADT that I implement
in a functional manner. I'm think for the OO wrappers, seperate
class names wouldn't be horrible, something like:
$tree = new AVLTree;
Please stick to the naming
On Sun, 26 Aug 2001, Chuck Hagenbuch wrote:
Quoting Sterling Hughes [EMAIL PROTECTED]:
Jep -- I'm writing PEAR OO wrappers for every ADT that I implement
in a functional manner. I'm think for the OO wrappers, seperate
class names wouldn't be horrible, something like:
37 matches
Mail list logo
