[PHP-DEV] Bug #12956 Updated: libgd2 + TTF = ugly fonts.

2001-08-26 Thread wez 

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 folks a while ago.
--Wez.

Previous Comments:


[2001-08-25 21:12:15] [EMAIL PROTECTED]

How do you know?  All I said was that this was known, but that I don't know what 
causes truecolour images to not support anti-aliasing.  ie. whether the bug is in PHP 
or GD or a combination of both is yet to be determined.



[2001-08-25 20:59:40] [EMAIL PROTECTED]

Not a PHP bug then..

--Jani




[2001-08-25 16:59:27] [EMAIL PROTECTED]

Yes, this is known.  Anti-aliasing of TTF fonts in GD2 only works with paletted 
images.  No idea why.  Try asking the GD folks.



[2001-08-25 13:47:49] [EMAIL PROTECTED]

More on the problem. (This could be a libGD bug, but the libGD test works fine, but 
I'm not sure if its doing the same thing)

This is from the ./configure to show that it is configured right (I have removed some 
lines to make it shorter):

checking whether to include GD support... yes
checking whether to enable truetype string function in gd... yes

checking for freetype(2)... yes
checking whether to include include FreeType 1.x support... no
checking whether to include T1lib support... yes
checking for T1_LoadFont in -lt1... yes
checking for gdImageCreateFromPng in -lgd... yes
checking for gdImageCreateFromJpeg in -lgd... yes
checking for gdImageCreateTrueColor in -lgd... Yes

So here is the script:
?php
Header (Content-type: image/jpeg);
$im = imagecreatetruecolor (400, 30);
$black = ImageColorAllocate ($im, 0, 0, 0);
$white = ImageColorAllocate ($im, 255, 255, 255);
ImageTTFText ($im, 20, 0, 10, 20, $white, /Fonts/arial.ttf, Testing... Omega: 
#937;);
ImageJPEG ($im);
ImageDestroy ($im);
?

I have also found out if I do not use truecolor, then the font is ok, but if I create 
from a jpeg or png, I get crap fonts.  I guess its a truecolor problem.  I dont know 
if it is in PHP or in GD.  Maybe I'm posting this to the wrong place.  Is anyone else 
using libGD2 and truecolor TTF graphics?
Here is some samples that I made: http://rtfm.c0de.net/helpfiles/ttf-test.html

Thank you for your help.



[2001-08-25 07:50:48] [EMAIL PROTECTED]

First, create a short but complete example script and
include it here so we can test it.

Second, you should use the correct paths for the configure
options:

--with-freetype-dir=/usr

And btw. This configure option is for freetype2. 
( --with-ttf is for freetype 1.x )

Also note that GD2 is in BETA.
This might instead being a bug in PHP, be a bug in GD2.

--Jani




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=12956


Edit this bug report at http://bugs.php.net/?id=12956edit=1


-- 
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] Anybody tested the Apache module recently?

2001-08-26 Thread Zeev Suraski 

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9740 Updated: wrong xml node content

2001-08-26 Thread joey 

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:


[2001-03-14 09:54:05] [EMAIL PROTECTED]

Element nodes contain the wrong content

When I loop through all the children of the node root of the following xml then the 
fourth child (second my)contains ($node-content) 
2newlinenewline3newlinenewline which should be nothing since its empty.
When I examine the output of a domxml_dumpmem dump of the $xml variable it does 
contain the correct data.
Libxml version is 2.3.2

xml:
?xml version=1.0?
root
my1/my
my/
my2/my
my/
my3/my
/root

output of my script:
idx=0 name=text content=

idx=1 name=my content=1
idx=2 name=text content=

idx=3 name=my content=
2

3

idx=4 name=text content=

idx=5 name=my content=2
idx=6 name=text content=

idx=7 name=my content=
3

idx=8 name=text content=

idx=9 name=my content=3
idx=10 name=text content=
end of output


my script:
?php

$txt  = ?xml version=\1.0\?\n;
$txt .= root\n;
$txt .= my1/my\n;
$txt .= my/\n;
$txt .= my2/my\n;
$txt .= my/\n;
$txt .= my3/my\n;
$txt .= /root\n;

$xml = xmldoc($txt);

$root = $xml-children();

$children = $root[0]-children();

echo pre\n;
for($i=0; $i  count($children); $i++) {
echo idx=$i name= . $children[$i]-name;
echo  content= . $children[$i]-content;
echo \n;
}
echo /pre\n;
?





Edit this bug report at http://bugs.php.net/?id=9740edit=1


-- 
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] Bug #9893 Updated: Wrong args in xpath_ functions makes apache crash

2001-08-26 Thread joey 

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:


[2001-03-21 05:37:39] [EMAIL PROTECTED]

System: Windows 2000 SP1
Server: Apache 1.3.14 
PHP:4.0.4pl1 as module, php_domxml.dll extension

both these lines will crash Apache:

xpath_new_context($nothing);
xpath_eval($foo,$bar);






Edit this bug report at http://bugs.php.net/?id=9893edit=1


-- 
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] Crash in var_dump and print_r

2001-08-26 Thread Joey Smith 

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 (write_func=0x808d098 php_body_write_wrapper, 
expr=0x0, indent=8) at zend.c:203
#1  0x81bf5c4 in zend_print_zval_r (expr=0x0, indent=8) at zend.c:197
#2  0x81bf22b in print_hash (ht=0x86f5824, indent=4) at zend.c:111
#3  0x81bf66a in zend_print_zval_r_ex (write_func=0x808d098 php_body_write_wrapper, 
expr=0x86e71a4, indent=0) at zend.c:211
#4  0x81bf5c4 in zend_print_zval_r (expr=0x86e71a4, indent=0) at zend.c:197
#5  0x8133c00 in zif_print_r (ht=1, return_value=0x86f4c24, this_ptr=0x0, 
return_value_used=0) at basic_functions.c:2176
#6  0x81eb8aa in execute (op_array=0x86cb5a4) at ./zend_execute.c:1590
#7  0x81c05f4 in zend_execute_scripts (type=8, file_count=3) at zend.c:807
#8  0x808df0f in php_execute_script (primary_file=0xbbac) at main.c:1310
#9  0x808b79c in main (argc=3, argv=0xbc3c) at cgi_main.c:737


#0  0x8172a40 in php_var_dump (struc=0x8700a30, level=3) at var.c:67
#1  0x8172a0d in php_array_element_dump (zv=0x8700a30, num_args=1, args=0xbfffe56c, 
hash_key=0xbfffe540) at var.c:55
#2  0x81c5cd2 in zend_hash_apply_with_arguments (ht=0x86f5824, destruct=0x81729a0 
php_array_element_dump, num_args=1)
at zend_hash.c:714
#3  0x8172c67 in php_var_dump (struc=0x86c3024, level=1) at var.c:93
#4  0x8172ddd in zif_var_dump (ht=1, return_value=0x86f4c24, this_ptr=0x0, 
return_value_used=0) at var.c:132
#5  0x81eb8aa in execute (op_array=0x86cb5a4) at ./zend_execute.c:1590
#6  0x81c05f4 in zend_execute_scripts (type=8, file_count=3) at zend.c:807
#7  0x808df0f in php_execute_script (primary_file=0xbbac) at main.c:1310
#8  0x808b79c in main (argc=3, argv=0xbc3c) at cgi_main.c:737


-- 
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] Bug #12963: ImageColorAllocate() doesn't work with PNGs

2001-08-26 Thread perry 

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);
$background_color = ImageColorAllocate ($im, 100, 100, 255);
$text_color=imageColorAllocate($image,255,100,100);
$textX=(imageSX($image)-imageFontWidth(4)*strlen($text))/2;
imageString($image,5,$textX,10,$text,$text_color);
imagePNG($image);
imageDestroy($image);
?

This is only a small modification of the example given in the manual, but
the $text_color is always white.

This works for JPEG, but the quality suffers, and my build of PHP doesn't
support GIF's.
-- 
Edit bug report at: http://bugs.php.net/?id=12963edit=1


-- 
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] Crash in var_dump and print_r

2001-08-26 Thread Zeev Suraski 

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 backtrace points to
zend_print_zval_r_ex...see attachment 1.

Attachment 2 show that var_dump() gives more or less the same result.


--
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]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Bug #12964: direct access to an array fails but walkthrough by foreach works

2001-08-26 Thread jan 

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 environment called pasta which 
results in a quite large class-tree. This is a problem for 
PHP as it looses a some parts of the class:

The code:
print_r($this-sec_global);
print incpath: 
.$this-sec_global[includepath].\n;
foreach($this-sec_global as $k = $v) {
print $k -- $vbr /;
}

results in the following output:

Array
(
[debug_level] = 0
[incremental] = 0
[enable_resolver] = 1
[outputdir] =
[include] =
[includepath] = ../etc/
)
 
 
Warning:  Undefined index:  includepath in 
/pages/projects/modlogan/mlaconfiggen.php on line 262
 
incpath:
debug_level -- 0
incremental -- 0
enable_resolver -- 1
outputdir --
include --
includepath -- ../etc/


As you can see a print_r and foreach display the same 
result. The array is filled with these data like I've 
expected it. But a direct access to the array results in a 
'undefined index' which looks very odd to me.

This problem exists for other class variables of this 
class too:

Undefined property: processorplugin ...

This happens in the default branch of a switch.

The full code can be found at 
http://jan.kneschke.de/showsource.php?page=%2Fprojects%2Fmodlogan%2Fmlaconfiggen.php

The output is at
http://jan.kneschke.de/projects/modlogan/mlaconfiggen.php

(click 3 times on the '--', fill in some data into the 
4th page and click on '--' again. This will result in the 
described behaviour which has been reproduced with 
PHP4.0.6 and PHP4.0.7rc1)


-- 
Edit bug report at: http://bugs.php.net/?id=12964edit=1


-- 
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] Bug #12963 Updated: ImageColorAllocate() doesn't work with PNGs

2001-08-26 Thread mathieu 

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
expect.


Previous Comments:


[2001-08-26 06:01:52] [EMAIL PROTECTED]

?php
header (Content-type: image/png);
$text=implode($argv, );
$image=imageCreateFromPNG(basic.png);
$background_color = ImageColorAllocate ($im, 100, 100, 255);
$text_color=imageColorAllocate($image,255,100,100);
$textX=(imageSX($image)-imageFontWidth(4)*strlen($text))/2;
imageString($image,5,$textX,10,$text,$text_color);
imagePNG($image);
imageDestroy($image);
?

This is only a small modification of the example given in the manual, but the 
$text_color is always white.

This works for JPEG, but the quality suffers, and my build of PHP doesn't support 
GIF's.





Edit this bug report at http://bugs.php.net/?id=12963edit=1


-- 
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] Crash in var_dump and print_r

2001-08-26 Thread Joey Smith 

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 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.
 
 
 --
 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]
 
 --
 Zeev Suraski [EMAIL PROTECTED]
 CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/
 
 
 


-- 
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: Bug #12964: direct access to an array fails but walkthrough by foreach works

2001-08-26 Thread jan 

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 a password for the bugreport I can't close it. 

Please set this bug to 'bogus'. 

The key of the array elements was includepath (including the ). :(
The brown paperbag is mine.

 -- 
 Edit bug report at: http://bugs.php.net/?id=12964edit=1
 

  Jan

-- 
  = http://www.kneschke.de == http://www.random-downloads.com =
   mailto: [EMAIL PROTECTED]

-- 
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] Bug #12964 Updated: direct access to an array fails but walkthrough by foreach works

2001-08-26 Thread mfischer 

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 
... ;-)

cheers,
 Markus

--
All the paperbags are belong to #php.de

Previous Comments:


[2001-08-26 06:26:20] [EMAIL PROTECTED]

It seems that I've reached one of the borders of PHP/Zend.

I'm coding a qt-like environment called pasta which 
results in a quite large class-tree. This is a problem for 
PHP as it looses a some parts of the class:

The code:
print_r($this-sec_global);
print incpath: 
.$this-sec_global[includepath].\n;
foreach($this-sec_global as $k = $v) {
print $k -- $vbr /;
}

results in the following output:

Array
(
[debug_level] = 0
[incremental] = 0
[enable_resolver] = 1
[outputdir] =
[include] =
[includepath] = ../etc/
)
 
 
Warning:  Undefined index:  includepath in 
/pages/projects/modlogan/mlaconfiggen.php on line 262
 
incpath:
debug_level -- 0
incremental -- 0
enable_resolver -- 1
outputdir --
include --
includepath -- ../etc/


As you can see a print_r and foreach display the same 
result. The array is filled with these data like I've 
expected it. But a direct access to the array results in a 
'undefined index' which looks very odd to me.

This problem exists for other class variables of this 
class too:

Undefined property: processorplugin ...

This happens in the default branch of a switch.

The full code can be found at 
http://jan.kneschke.de/showsource.php?page=%2Fprojects%2Fmodlogan%2Fmlaconfiggen.php

The output is at
http://jan.kneschke.de/projects/modlogan/mlaconfiggen.php

(click 3 times on the '--', fill in some data into the 
4th page and click on '--' again. This will result in the 
described behaviour which has been reproduced with 
PHP4.0.6 and PHP4.0.7rc1)







Edit this bug report at http://bugs.php.net/?id=12964edit=1


-- 
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] Anybody tested the Apache module recently?

2001-08-26 Thread Rasmus Lerdorf 

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]

Re: [PHP-DEV] Anybody tested the Apache module recently?

2001-08-26 Thread teo 

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]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Crash in var_dump and print_r

2001-08-26 Thread George Schlossnagle 

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 
*expr, int indent)
  {
+   if(expr == NULL) {
+   ZEND_PUTS( (NULL));
+   return;
+   }
 switch(expr-type) {
 case IS_ARRAY:
 ZEND_PUTS(Array\n);


--- var.c.orig  Thu Aug 16 11:16:52 2001
+++ var.c   Sun Aug 26 11:24:54 2001
@@ -63,7 +63,10 @@
 if (level1) {
 php_printf(%*c, level-1, ' ');
 }
-
+   if ((*struc) == NULL) {
+   php_printf( (NULL));
+   return;
+   }
 switch ((*struc)-type) {
 case IS_BOOL:
 php_printf(%sbool(%s)\n, COMMON, 
Z_LVAL_PP(struc)?true:false);


On Sunday, August 26, 2001, at 06:15 AM, Zeev Suraski wrote:

 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 backtrace points to
 zend_print_zval_r_ex...see attachment 1.

 Attachment 2 show that var_dump() gives more or less the same result.


 --
 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: php-list-
 [EMAIL PROTECTED]

 --
 Zeev Suraski [EMAIL PROTECTED]
 CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


 -- 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 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] Crash in var_dump and print_r

2001-08-26 Thread Andi Gutmans 

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
+++ 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 
 *expr, int indent)
  {
+   if(expr == NULL) {
+   ZEND_PUTS( (NULL));
+   return;
+   }
 switch(expr-type) {
 case IS_ARRAY:
 ZEND_PUTS(Array\n);


--- var.c.orig  Thu Aug 16 11:16:52 2001
+++ var.c   Sun Aug 26 11:24:54 2001
@@ -63,7 +63,10 @@
 if (level1) {
 php_printf(%*c, level-1, ' ');
 }
-
+   if ((*struc) == NULL) {
+   php_printf( (NULL));
+   return;
+   }
 switch ((*struc)-type) {
 case IS_BOOL:
 php_printf(%sbool(%s)\n, COMMON, 
 Z_LVAL_PP(struc)?true:false);


On Sunday, August 26, 2001, at 06:15 AM, Zeev Suraski wrote:

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 backtrace points to
zend_print_zval_r_ex...see attachment 1.

Attachment 2 show that var_dump() gives more or less the same result.


--
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: php-list-
[EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 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 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 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] Crash in var_dump and print_r

2001-08-26 Thread George Schlossnagle 

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:

 --- 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 
 *expr, int indent)
  {
 +   if(expr == NULL) {
 +   ZEND_PUTS( (NULL));
 +   return;
 +   }
 switch(expr-type) {
 case IS_ARRAY:
 ZEND_PUTS(Array\n);


 --- var.c.orig  Thu Aug 16 11:16:52 2001
 +++ var.c   Sun Aug 26 11:24:54 2001
 @@ -63,7 +63,10 @@
 if (level1) {
 php_printf(%*c, level-1, ' ');
 }
 -
 +   if ((*struc) == NULL) {
 +   php_printf( (NULL));
 +   return;
 +   }
 switch ((*struc)-type) {
 case IS_BOOL:
 php_printf(%sbool(%s)\n, COMMON, 
 Z_LVAL_PP(struc)?true:false);


 On Sunday, August 26, 2001, at 06:15 AM, Zeev Suraski wrote:

 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 backtrace points to
 zend_print_zval_r_ex...see attachment 1.

 Attachment 2 show that var_dump() gives more or less the same result.


 --
 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: php-list-
 [EMAIL PROTECTED]

 --
 Zeev Suraski [EMAIL PROTECTED]
 CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


 -- 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: php-list-
 [EMAIL PROTECTED]


 -- 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 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] Crash in var_dump and print_r

2001-08-26 Thread Andi Gutmans 

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 as if there is no protection from 
adding a NULL pData pointer if you just call zend_hash_add_or_update().

If you're talking about HashTable's which are used in zval's for array 
values or object properties then there should be no protection. Extension 
writers need to make sure they don't write broken code the same way they 
shouldn't put junk pointers in those hash tables.

Andi



On Sunday, August 26, 2001, at 11:32 AM, Andi Gutmans wrote:

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
+++ 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 
 *expr, int indent)
  {
+   if(expr == NULL) {
+   ZEND_PUTS( (NULL));
+   return;
+   }
 switch(expr-type) {
 case IS_ARRAY:
 ZEND_PUTS(Array\n);


--- var.c.orig  Thu Aug 16 11:16:52 2001
+++ var.c   Sun Aug 26 11:24:54 2001
@@ -63,7 +63,10 @@
 if (level1) {
 php_printf(%*c, level-1, ' ');
 }
-
+   if ((*struc) == NULL) {
+   php_printf( (NULL));
+   return;
+   }
 switch ((*struc)-type) {
 case IS_BOOL:
 php_printf(%sbool(%s)\n, COMMON, 
 Z_LVAL_PP(struc)?true:false);


On Sunday, August 26, 2001, at 06:15 AM, Zeev Suraski wrote:

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 backtrace points to
zend_print_zval_r_ex...see attachment 1.

Attachment 2 show that var_dump() gives more or less the same result.


--
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: php-list-
[EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 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: php-list-
[EMAIL PROTECTED]

--
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: php-list-
[EMAIL PROTECTED]


-- 
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] Crash in var_dump and print_r

2001-08-26 Thread George Schlossnagle 

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 of the extension writer?  While there is the 
 zend_has_add_empty_element(), it appears as if there is no protection 
 from adding a NULL pData pointer if you just call 
 zend_hash_add_or_update().

 If you're talking about HashTable's which are used in zval's for array 
 values or object properties then there should be no protection. 
 Extension writers need to make sure they don't write broken code the 
 same way they shouldn't put junk pointers in those hash tables.

 Andi

-- 
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] Bug #12830 Updated: undefined symbol: sasl_set_alloc

2001-08-26 Thread owanse 

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: ./configure --prefix=/usr --exec-prefix=/usr 
--sysconfdir=/etc \
--localstatedir=/var/run --libexecdir=/usr/lib/openldap \
--mandir=%{_mandir} --enable-wrappers \
--enable-aclgroups --enable-spasswd --enable-dynamic \
--enable-shared --with-tls --with-cyrus-sasl --enable-aci

Third: ld.so.conf contains all necessary entries for running OpenLDAP

Fourth: Of Course ! I ran ldconfig (serveral times) before and after 
compiling anything


Previous Comments:


[2001-08-18 19:21:56] [EMAIL PROTECTED]

Which ldap libraries do you use? How did you configure them?
Do you have the necessary entry in /etc/ld.so.conf for
the ldap libraries path? Have you run /sbin/ldconfig ?

--Jani




[2001-08-18 18:52:04] [EMAIL PROTECTED]

Sorry ! Did not enter a password in bug-report 12825 (so i am not able to submit a 
direct reply), anyway ...
I started compiling php4.0.6 with:

./configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib 
--with-config-file-path=/etc --with-exec-dir=%{libdir}/php/bin --with-pgsql=/usr 
--with-mysql=/usr --with-gd=yes --with-tiff-dir=/usr --with-jpeg-dir=/usr 
--with-png-dir=/usr --with-xpm-dir=/usr/X11R6 --with-pdflib=/usr --with-ldap=yes 
--with-imap=yes --with-imap-ssl --with-zlib=yes --with-bz2 --with-xml --with-ttf 
--with-t1lib --with-mcal=/usr/include/mcal/ --with-sablot --with-readline --with-ftp 
--with-ndbm --with-gdbm --with-mcrypt --with-gettext --with-curl --with-mm 
--with-gd=yes --with-qtdom=/usr/lib/qt2/ --enable-versioning --enable-yp 
--enable-bcmath --enable-trans-sid --enable-inline-optimization --enable-track-vars 
--enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem 
--enable-sysvshm --enable-shmop --enable-calendar --enable-exif --enable-ftp 
--enable-memory-limit --enable-wddx --enable-filepro --enable-dbase --enable-ctype 
--enable-debug --enable-force-cgi-redirect --enable-discard-path --enable-sigchild 
--enable-gd-imgstrttf --with-openssl --with-swf=./usr --with-apxs=/usr/sbin/apxs 
--with-sybase-ct=/usr/local/freetds

And once again, all worked fine, all but starting apache's http daemon.
Nevertheless, i could not find anything describing the undefined symbol error in 
general.






Edit this bug report at http://bugs.php.net/?id=12830edit=1


-- 
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] Anybody tested the Apache module recently?

2001-08-26 Thread Adam Dickmeiss 

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 finished editing 
 the commit message, so it never left my machine).
 
 It should be fixed now.  Please let me know if it isn't.
 
 Zeev
 
 At 02:43 26-08-01, Rasmus Lerdorf wrote:
 It seems to have completely broken as of a CVS update of a few minutes
 ago.  Most of the time I get no output, but sometimes I get a very very
 long row of ZZ's or sometimes I get
 ZZZ?Ì?*Z?Ì?*Z
 
 Repeatedly loading a phpinfo() tends to toggle back and forth.  Single
 stepping through things looks normal.  zif_phpinfo() is getting called and
 everything looks fine.  So it is something lower level.  Output bufferring
 changes messing things up?
 
 relevant php.ini settings:
 
 output_buffering= Off
 output_handler  =
 implicit_flush  = Off
 zlib.output_compression = Off
 
 Same thing happens on a simple echo Hello World script.
 An strace on that shows:
 
 {sin_family=AF_INET, sin_port=htons(42216), 
 sin_addr=inet_addr(127.0.0.1)}}, [16]) = 3
 rt_sigaction(SIGUSR1, {SIG_IGN}, {0x8074490, [], SA_INTERRUPT|0x400}, 
 8) = 0
 getsockname(3, {sin_family=AF_INET, sin_port=htons(80), 
 sin_addr=inet_addr(127.0.0.1)}}, [16]) = 0
 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
 alarm(300)  = 0
 read(3, GET /t.php HTTP/1.0\r\nConnection:..., 4096) = 334
 rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
 time(NULL)  = 998782781
 alarm(300)  = 300
 alarm(0)= 300
 stat64(/home/rasmus/phpweb/t.php, {st_mode=S_IFREG|0664, st_size=30, 
 ...}) = 0
 alarm(300)  = 0
 umask(077)  = 022
 umask(022)  = 077
 setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
 rt_sigaction(SIGPROF, {0x402102b0, [PROF], SA_RESTART|0x400}, 
 {0x402102b0, [PROF], SA_RESTART|0x400}, 8) = 0
 rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
 getcwd(/usr/local/home/rasmus/phpweb, 4095) = 30
 chdir(/home/rasmus/phpweb)= 0
 open(/home/rasmus/phpweb/t.php, O_RDONLY) = 4
 getcwd(/usr/local/home/rasmus/phpweb, 4095) = 30
 lstat64(/home, {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
 readlink(/home, /usr/local/home, 4095) = 15
 lstat64(/usr, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
 lstat64(/usr/local, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
 lstat64(/usr/local/home, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
 lstat64(/usr/local/home/rasmus, {st_mode=S_IFDIR|0777, st_size=12288, 
 ...}) = 0
 lstat64(/usr/local/home/rasmus/phpweb, {st_mode=S_IFDIR|0755, 
 st_size=4096, ...}) = 0
 lstat64(/usr/local/home/rasmus/phpweb/t.php, {st_mode=S_IFREG|0664, 
 st_size=30, ...}) = 0
 ioctl(4, TCGETS, 0xbfffe110)= -1 ENOTTY (Inappropriate ioctl 
 for device)
 fstat64(4, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
 = 0x40018000
 read(4, ?php\n\techo \Hello World\;\n?\n, 8192) = 30
 read(4, , 4096)   = 0
 read(4, , 8192)   = 0
 ioctl(4, TCGETS, 0xbfffd0d0)= -1 ENOTTY (Inappropriate ioctl 
 for device)
 close(4)= 0
 munmap(0x40018000, 4096)= 0
 chdir(/usr/local/home/rasmus/phpweb)  = 0
 alarm(300)  = 300
 alarm(0)= 300
 writev(3, [{HTTP/1.1 200 OK\r\nDate: Sat, 25 A..., 173}, 
 {ZZZ\204\314\217*\0\0\0\0\0..., 4096}], 2) = 4269
 rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
 setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
 umask(022)  = 022
 alarm(0)= 0
 time(NULL)  = 998782781
 write(17, 127.0.0.1 - - [25/Aug/2001:16:39..., 74) = 74
 alarm(30)   = 0
 shutdown(3, 1 /* send */)   = 0
 select(4, [3], NULL, NULL, {2, 0})  = 1 (in [3], left {2, 0})
 read(3, , 512)= 0
 close(3)= 0
 alarm(0)= 30
 rt_sigaction(SIGUSR1, {0x8074490, [], SA_INTERRUPT|0x400}, {SIG_IGN}, 
 8) = 0
 alarm(0)
 
 Rolling back to my libphp4.so build on Aug.13 built with exactly the same
 ./configure flags makes it work again.
 
 Those flags are
 
 #! /bin/sh
 #
 # Created by configure
 
 './configure' \
 '--with-mysql=/usr' \
 '--with-gd=/home/rasmus/gd-2.0.1' \
 '--with-freetype-dir=/usr' \
 '--enable-gd-native-ttf' \
 '--enable-gd-imgstrttf' \
 '--with-jpeg-dir=/usr' \
 '--with-png-dir=/usr' \

[PHP-DEV] rand()-redesign - please read

2001-08-26 Thread jeroen 

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:
http://marc.theaimsgroup.com/?l=php-devm=99802330332087w=2
- want to guard for correctneat coding in PHP, take a quick look at the
RAND_REDESIGN branch. It isn't ready, and it'd be a wonder if it compiles,
since I didn't try, but the intention on how it will be coded is quite clear
now.

And please send any remarks, both positive and negative, to me and/or to
php-dev. Because the further it gets, the harder it will be to change it.
(and I'm _not_ going to revert anymore...)


Thanks a lot,
Jeroen



-- 
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] Crash in var_dump and print_r

2001-08-26 Thread Zeev Suraski 

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 
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 
 *expr, int indent)
  {
+   if(expr == NULL) {
+   ZEND_PUTS( (NULL));
+   return;
+   }
 switch(expr-type) {
 case IS_ARRAY:
 ZEND_PUTS(Array\n);


--- var.c.orig  Thu Aug 16 11:16:52 2001
+++ var.c   Sun Aug 26 11:24:54 2001
@@ -63,7 +63,10 @@
 if (level1) {
 php_printf(%*c, level-1, ' ');
 }
-
+   if ((*struc) == NULL) {
+   php_printf( (NULL));
+   return;
+   }
 switch ((*struc)-type) {
 case IS_BOOL:
 php_printf(%sbool(%s)\n, COMMON, 
 Z_LVAL_PP(struc)?true:false);


On Sunday, August 26, 2001, at 06:15 AM, Zeev Suraski wrote:

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 backtrace points to
zend_print_zval_r_ex...see attachment 1.

Attachment 2 show that var_dump() gives more or less the same result.


--
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: php-list-
[EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 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]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Anybody tested the Apache module recently?

2001-08-26 Thread Zeev Suraski 

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 committed a fix
  about 30 minutes later, only apparently I never actually finished editing
  the commit message, so it never left my machine).
 
  It should be fixed now.  Please let me know if it isn't.
 
  Zeev
 
  At 02:43 26-08-01, Rasmus Lerdorf wrote:
  It seems to have completely broken as of a CVS update of a few minutes
  ago.  Most of the time I get no output, but sometimes I get a very very
  long row of ZZ's or sometimes I get
  ZZZ?Ì?*Z?Ì?*Z
  
  Repeatedly loading a phpinfo() tends to toggle back and forth.  Single
  stepping through things looks normal.  zif_phpinfo() is getting called and
  everything looks fine.  So it is something lower level.  Output bufferring
  changes messing things up?
  
  relevant php.ini settings:
  
  output_buffering= Off
  output_handler  =
  implicit_flush  = Off
  zlib.output_compression = Off
  
  Same thing happens on a simple echo Hello World script.
  An strace on that shows:
  
  {sin_family=AF_INET, sin_port=htons(42216),
  sin_addr=inet_addr(127.0.0.1)}}, [16]) = 3
  rt_sigaction(SIGUSR1, {SIG_IGN}, {0x8074490, [], SA_INTERRUPT|0x400},
  8) = 0
  getsockname(3, {sin_family=AF_INET, sin_port=htons(80),
  sin_addr=inet_addr(127.0.0.1)}}, [16]) = 0
  setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
  alarm(300)  = 0
  read(3, GET /t.php HTTP/1.0\r\nConnection:..., 4096) = 334
  rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
  time(NULL)  = 998782781
  alarm(300)  = 300
  alarm(0)= 300
  stat64(/home/rasmus/phpweb/t.php, {st_mode=S_IFREG|0664, st_size=30,
  ...}) = 0
  alarm(300)  = 0
  umask(077)  = 022
  umask(022)  = 077
  setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
  rt_sigaction(SIGPROF, {0x402102b0, [PROF], SA_RESTART|0x400},
  {0x402102b0, [PROF], SA_RESTART|0x400}, 8) = 0
  rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
  getcwd(/usr/local/home/rasmus/phpweb, 4095) = 30
  chdir(/home/rasmus/phpweb)= 0
  open(/home/rasmus/phpweb/t.php, O_RDONLY) = 4
  getcwd(/usr/local/home/rasmus/phpweb, 4095) = 30
  lstat64(/home, {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
  readlink(/home, /usr/local/home, 4095) = 15
  lstat64(/usr, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
  lstat64(/usr/local, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
  lstat64(/usr/local/home, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
  lstat64(/usr/local/home/rasmus, {st_mode=S_IFDIR|0777, st_size=12288,
  ...}) = 0
  lstat64(/usr/local/home/rasmus/phpweb, {st_mode=S_IFDIR|0755,
  st_size=4096, ...}) = 0
  lstat64(/usr/local/home/rasmus/phpweb/t.php, {st_mode=S_IFREG|0664,
  st_size=30, ...}) = 0
  ioctl(4, TCGETS, 0xbfffe110)= -1 ENOTTY (Inappropriate ioctl
  for device)
  fstat64(4, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
  = 0x40018000
  read(4, ?php\n\techo \Hello World\;\n?\n, 8192) = 30
  read(4, , 4096)   = 0
  read(4, , 8192)   = 0
  ioctl(4, TCGETS, 0xbfffd0d0)= -1 ENOTTY (Inappropriate ioctl
  for device)
  close(4)= 0
  munmap(0x40018000, 4096)= 0
  chdir(/usr/local/home/rasmus/phpweb)  = 0
  alarm(300)  = 300
  alarm(0)= 300
  writev(3, [{HTTP/1.1 200 OK\r\nDate: Sat, 25 A..., 173},
  {ZZZ\204\314\217*\0\0\0\0\0..., 4096}], 2) = 4269
  rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
  setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
  umask(022)  = 022
  alarm(0)= 0
  time(NULL)  = 998782781
  write(17, 127.0.0.1 - - [25/Aug/2001:16:39..., 74) = 74
  alarm(30)   = 0
  shutdown(3, 1 /* send */)   = 0
  select(4, [3], NULL, NULL, {2, 0})  = 1 (in [3], left {2, 0})
  read(3, , 512)= 0
  close(3)= 0
  alarm(0)= 30
  rt_sigaction(SIGUSR1, {0x8074490, [], SA_INTERRUPT|0x400}, {SIG_IGN},
  8) = 0
  alarm(0)
  
  Rolling back to my libphp4.so build on Aug.13 built with exactly the same
  ./configure flags makes it work again.
  
  Those flags are
  
  #! /bin/sh
  #
  # Created by configure
  
  './configure' \
  '--with-mysql=/usr' \

[PHP-DEV] How to make Thread Safety work (ZTS,TSRMLS) (was: Re: [PHP-CVS] cvs: php4 /main streams.c )

2001-08-26 Thread Jeroen van Wolffelaar 

[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 a function which is declared TSRMLS_C[C] in your function
- more?

Greetz,
Jeroen

Zeev Suraski [EMAIL PROTECTED] wrote in message
news:5.1.0.14.2.20010826123513.03102660@localhost...
 The thread safety macros pass around a context that the rest of the thread
 safety macros use.  There are three types of such macros:

 1.  Macros that are used in function declarations, to denote that the
 function accepts this context as an argument:
  TSRMLS_D - if it's the only argument  (Thread Safe Resource Manager
 Local Storage, Declaration)
  TSRMLS_DC - if it's not the only argument  (Thread Safe Resource
 Manager Local Storage, Declaration with Comma)

 2.  Macros that are used in function calls, to pass the context to
 functions that accept it:
   TSRMLS_C - if it's the only argument (Thread Safe Resource Manager
 Local Storage, Call)
   TSRMLS_CC - if it's not the only argument (Thread Safe Resource
 Manager Local Storage, Call with Comma)


 3.  If the context cannot be passed using function arguments (e.g., in
 certain callbacks), it can be obtained by calling TSRMLS_FETCH()  at the
 end of the variable declarations (Thread Safe Resource Manager Local
 Storage Fetch)


 For performance reasons, using 1+2 is usually preferred to using 3.

 Zeev



 At 12:07 26-08-01, Joey Smith wrote:
 I really don't understand the thread-safety stuff, but shouldn't this
 also be using TSRMLS_CC instead of TSRMLS_FETCH()?
 
 
   - TSRMLS_FETCH();
   -
 /* these names depend on the values of the
  PHP_STREAM_AS_XXX defines in php_streams.h */
 static const char * cast_names[3] = {
 STDIO FILE*, File Descriptor, Socket
Descriptor
 };
   + TSRMLS_FETCH();
   +
 zend_error(E_WARNING, %s(): cannot represent a stream
of
  type %s as a %s,
 get_active_function_name(TSRMLS_C),
 stream-ops-label,
 
 
 --
 PHP CVS 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]

 --
 Zeev Suraski [EMAIL PROTECTED]
 CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/



-- 
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: How to make Thread Safety work (ZTS,TSRMLS) (was: Re: [PHP-CVS] cvs: php4 /main streams.c )

2001-08-26 Thread Zeev Suraski 

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 ELS, CLS, PLS and SLS, so their prototypes looked like ... 
ELS_DC CLS_DC PLS_DC SLS_DC, which was a mess).  It's performance and 
cleanliness.

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.

Note that most of the callbacks in the engine and in PHP now accept TSRMLS, 
so you don't need to fetch it (including internal functions, 
start/shutdown/activation/deactivation, etc.)

Zeev


-- 
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: [PHP-CVS] cvs: php4 /ext/session php_session.h session.c /ext/standard url_scanner_ex.c url_scanner_ex.re

2001-08-26 Thread Rasmus Lerdorf 

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/standardurl_scanner_ex.c url_scanner_ex.re
   Log:
   More fixes and refinements




-- 
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: [PHP-CVS] cvs: php4 /ext/session php_session.h session.c /ext/standard url_scanner_ex.c url_scanner_ex.re

2001-08-26 Thread Zeev Suraski 

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, I haven't actually tested it)
- Allows using trans-sid in conjunction with other output buffering 
features, such as ob_start(), output compression, and so on.

Zeev

At 01:12 27-08-01, Rasmus Lerdorf wrote:
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/standardurl_scanner_ex.c url_scanner_ex.re
Log:
More fixes and refinements
 
 

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] A couple of session issues

2001-08-26 Thread Zeev Suraski 

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 
session_adapt_uris() later.

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, from now on) - we can check whether the headers are already 
sent, and if they are, move to use trans_sid instead.  Any comments?

Zeev


-- 
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] A couple of session issues

2001-08-26 Thread Jon Parise 

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, from now on) - we can check whether the headers are already 
 sent, and if they are, move to use trans_sid instead.  Any comments?

I think that sounds reasonable, although the aforementioned error
does indirectly enforce better coding and organization.  Your
proposed change should make things easier for developers, though.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
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] API Thoughts?

2001-08-26 Thread Sterling Hughes 

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 = avl_tree_new();
avl_tree_insert($tree, $element, compare_func);

Basically the difference between a generalized tree api, where you
pass a constant to the constructor (if you allow me to use that term
:), or where every form of the tree has a different set of functions
(currently planned are Red-black tree's, AVL tree's, Simple Binary
Search Tree's and Btree's).

Thoughts?  I'm currently leaning towards the first one...

-Sterling


-- 
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] API Thoughts?

2001-08-26 Thread Markus Fischer 

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, $element, compare_func);
 // ...
 
 Or:
 
 $tree = avl_tree_new();
 avl_tree_insert($tree, $element, compare_func);
 
 Basically the difference between a generalized tree api, where you
 pass a constant to the constructor (if you allow me to use that term
 :), or where every form of the tree has a different set of functions
 (currently planned are Red-black tree's, AVL tree's, Simple Binary
 Search Tree's and Btree's).
 
 Thoughts?  I'm currently leaning towards the first one...

+1

-- 
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] API Thoughts?

2001-08-26 Thread Jon Parise 

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.  There's more room for future expansion
without encroaching on namespace.

I think it would be neat to be able to do this, though:

$tree = new Tree(AVL_TREE);
$tree-insert($element, 'compare_func');

But such a wrapper shouldn't be too difficult to write.
 
-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
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] API Thoughts?

2001-08-26 Thread Sterling Hughes 

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, compare_func);
  // ...

 I prefer this notation.  There's more room for future expansion
 without encroaching on namespace.

 I think it would be neat to be able to do this, though:

 $tree = new Tree(AVL_TREE);
 $tree-insert($element, 'compare_func');

 But such a wrapper shouldn't be too difficult to write.



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;

-Sterling



-- 
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] API Thoughts?

2001-08-26 Thread Andrei Zmievski 

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, compare_func);
 // ...

I like this better, but please prefix constants with ADT.

-Andrei


-- 
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] API Thoughts?

2001-08-26 Thread Chuck Hagenbuch 

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 conventions, which would make this:

$tree = new ADT_Tree_AVL();

... or something similar. Also, you could easily have a factory method:

$tree = ADT::factory('tree_avl');

or:

$tree = ADT_Tree::factory('avl');

-chuck

--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.

-- 
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] API Thoughts?

2001-08-26 Thread Sterling Hughes 

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:
 
  $tree = new AVLTree;

 Please stick to the naming conventions, which would make this:

 $tree = new ADT_Tree_AVL();

 ... or something similar. Also, you could easily have a factory method:

 $tree = ADT::factory('tree_avl');

 or:

 $tree = ADT_Tree::factory('avl');


The above are imho pretty ugly, and this is meant as more of a language
level feature, I'm thinking of using PEAR as more of a method of
distribution than a mindset.  I'd prefer to code the OO wrapper in
PHP -- it stops me from having to be aware of changes to the Zend OO
model and writing code that works with both the functional interface
and the OO interface (some form of automatic handling of this would
be a very cool/useful feature for Zend, imho).

The current way I have it organized is as follows:

php4/pear/ADT.php
php4/pear/ADT/LList.php
php4/pear/ADT/Stack.php
php4/pear/ADT/Queue.php
php4/pear/ADT/AVLtree.php
php4/pear/ADT/BTree.php
php4/pear/ADT/RBTree.php
php4/pear/ADT/Heap.php
php4/pear/ADT/Set.php

then you could do something like:

?php
require_once('ADT/Queue.php');

$sounds = new Queue;
$sounds-push(Bing);
$sounds-push(Bamm);
$sounds-push(Booom);

while ($sounds-count()  0) {
echo $sounds-shift();
}
?

Which I think works quite nicely :)

-Sterling


-- 
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]