headers
Sebastian Bergmann | 1 Aug 2006 05:06
Picon
Gravatar

[PHP-DEV] PHP_5_2 segfaults

 sb <at> wopr-mobile php-5.2 % ./cvsclean && ./buildconf && ./configure &&
                          make -j3 && gdb ./sapi/cli/php

GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

gdb> r

Program received signal SIGINT, Interrupt.
_______________________________________________________________________________
     eax:FFFFFE00 ebx:00000000  ecx:B7FE3000  edx:00000400     eflags:00000246
     esi:B7E27420 edi:B7D0CB70  esp:BFF6CA28  ebp:BFF6CA4C     eip:FFFFE410
     cs:0073  ds:007B  es:007B  fs:0000  gs:0033  ss:007B    o d I t s Z a P c
[007B:BFF6CA28]---------------------------------------------------------[stack]
BFF6CA58 : 00 30 FE B7  00 04 00 00 - F4 6F E2 B7  20 74 E2 B7
.0.......o.. t..
BFF6CA48 : 00 04 00 00  6C CA F6 BF - 90 D0 D6 B7  20 74 E2 B7
....l....... t..
BFF6CA38 : F4 6F E2 B7  68 BE D6 B7 - 00 00 00 00  00 30 FE B7
.o..h........0..
BFF6CA28 : 4C CA F6 BF  00 04 00 00 - 00 30 FE B7  F3 A2 DB B7
L........0......
[007B:B7E27420]---------------------------------------------------------[
data]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andi Gutmans | 1 Aug 2006 05:36
Favicon

RE: [PHP-DEV] Supporting version specific INI files as well as SAPI specific INI files.

Richard,

One more question. What takes precedence? If I have PHP 4 on my system which
uses php.ini, and then download a PHP 5 version with your patch and have a
php5.ini file, am I right to assume that the version specific INI file will
take precedence? (I guess otherwise it would defeat its purpose but just
checking :)

Andi 

> -----Original Message-----
> From: Richard Quadling [mailto:rquadling <at> googlemail.com] 
> Sent: Sunday, July 30, 2006 8:25 AM
> To: Andi Gutmans
> Cc: internals <at> lists.php.net
> Subject: Re: [PHP-DEV] Supporting version specific INI files 
> as well as SAPI specific INI files.
> 
> http://rquadling.php1h.com/ini_patch.diff.txt contains the 
> same attachment.
> 
> On 30/07/06, Richard Quadling <rquadling <at> googlemail.com> wrote:
> > I've attached the changes that have been requested.
> >
> > The idea is that you can have settings which are from global (not 
> > version specific) to the exact PHP version. Including -dev releases.
> >
> > php [major [.minor [.release [ extra]]]] -sapi.ini
> >
> > or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Bergmann | 1 Aug 2006 07:20
Picon
Gravatar

Re: [PHP-DEV] Adding pecl/zip to 5.2

Antony Dovgal wrote:
> -0.
> 
> I would rather move more extensions from core to PECL, than from PECL
> to core.

 I second that emotion.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
helly | 1 Aug 2006 08:53
Picon

[PHP-DEV] Build and gcov test of PHP_5_2 finished

Hello!

A gcov test run has just been finished on the PHP_5_2 branch.

You can view the make log here: http://gcov.php.net/PHP_5_2/make.log.php

You can watch the test results: http://gcov.php.net/PHP_5_2/run-tests.log.php

And you can watch gcov results: http://gcov.php.net/PHP_5_2/lcov/index.php

If you are an extension developer please check your extension for any new 
defects. If you are a general developer please check any code you feel
responsible for or you touched in any way. 

In case you spot any untested source area and can provide a test, please do
so and send the test to this list. If you do not know how to write test visit
this page: http://qa.php.net/write-test.php .

best regards
Marcus

--
Marcus Boerger
http://php.net/~helly

--
PHP Internals list < http://www.php.net >
To unsubscribe, visit: http://www.php.net/unsub.php

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Bergmann | 1 Aug 2006 10:31
Picon
Gravatar

Re: [PHP-DEV] PHP_5_2 segfaults

Sebastian Bergmann wrote:
>  sb <at> wopr-mobile php-5.2 % ./cvsclean && ./buildconf && ./configure &&
>                           make -j3 && gdb ./sapi/cli/php

 A fresh CVS checkout solved this issue.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
helly | 1 Aug 2006 19:00
Picon

[PHP-DEV] Build and gcov test of PHP_5_2 finished

Hello!

A gcov test run has just been finished on the PHP_5_2 branch.

You can view the make log here: http://gcov.php.net/PHP_5_2/make.log.php

You can watch the test results: http://gcov.php.net/PHP_5_2/run-tests.log.php

And you can watch gcov results: http://gcov.php.net/PHP_5_2/lcov/index.php

If you are an extension developer please check your extension for any new 
defects. If you are a general developer please check any code you feel
responsible for or you touched in any way. 

In case you spot any untested source area and can provide a test, please do
so and send the test to this list. If you do not know how to write test visit
this page: http://qa.php.net/write-test.php .

best regards
Marcus

--
Marcus Boerger
http://php.net/~helly

--
PHP Internals list < http://www.php.net >
To unsubscribe, visit: http://www.php.net/unsub.php

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Lynch | 1 Aug 2006 18:49

Re: [PHP-DEV] New Installer for PHP 5.2

On Mon, July 24, 2006 9:55 am, Ilia Alshanetsky wrote:
>
> On 24-Jul-06, at 10:52 AM, John Mertic wrote:
>>
>> Thanks to Edin Kadribasic, the public test version ( which installs
>> a
>> recent snapshot of PHP 5.2 ) is located at
>> http://downloads.php.net/edink/php-5.2.0-win32-installer.msi.
>>
>> I am looking for feedback on the installer, namely in the following
>> areas:
>>
>> - Default install options; what should the default install consist
>> of?
>
> I'd say it should contain all of the extensions that are enabled by-
> default.
>
>
>> - Lite Installer. The current install file weighs in at 18mb. Would
>> we
>> want a lite installer with fewer components and if so what would
>> those
>> be?
>
> I think if the 1st is done the size of the file should be much
> smaller, if not we can examine the enabled extensions one by one and
> perhaps turn off some of the "less important" ones.

Given the number of Windows users who can't find the DLLs they need,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Lynch | 1 Aug 2006 19:38

Re: [PHP-DEV] RfC: rethink OO inheritance strictness

On Fri, July 21, 2006 4:32 am, Lukas Smith wrote:
> Derick Rethans wrote:
>> On Fri, 21 Jul 2006, Lukas Smith wrote:
>>
>>> Richard Quadling wrote:
[snip]
>>> Its not about being "right". Acedemically Marcus changes are
>>> correct.

With all due respect...

There are several languages in which it's not "right" at all.

Whether PHP wants to move more in one direction or another, or cut its
own path and stand on its own merits is the question *I* see at issue
here.

Are we aiming to be "just like Java" (tm) or are we going more towards
some spices tossed in from, say, Common Lisp / Scheme, to create
something new?

Are we aiming towards polymorphism in PHP 7?  (or 8, or 9, or ???)

What will it look like?

> Or it will mean that the established user base gets ticked off and the
> other people see PHP as just playing catch up to Java. Now is probably
> the time to hire a consulting firm ;)

I use OOP so seldom that I just don't care *that* much, but if I'm
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrei Zmievski | 1 Aug 2006 20:02
Gravatar

Re: [PHP-DEV] zend_u_strtod is slow - possible fix

Yes. With your patch applied, the numeric unicode string to double 
conversion is about 100% slower than from binary strings. If this is 
acceptable we can commit the patch. Otherwise, we should port 
zend_strtod() to deal with unicode strings directly.

-Andrei

On Jul 31, 2006, at 1:58 AM, Matt W wrote:

> Hi all,
>
> As I was working on upgrading the dec[bin|hex|oct] functions to convert
> large doubles, I noticed how much slower things were when converting 
> Unicode
> strings to double.  I found that converting the whole thing to string 
> and
> using regular zend_strtod() was much faster.  Then I decided to try
> modifying the u_strtod() function to do the same, but just on the 
> relevant
> numeric portion.
>
> I don't know if I did everything right, but it seems to work fine with 
> my
> limited testing.  (I was working from zend_u_strtol() and
> zval_unicode_to_string_ex(). :-))  The function is now about *8 times*
> faster, and nearly 20 times faster on a non-numeric string!  (I'm on
> Windows.)
>
> diff: http://realplain.com/php/zend_u_strtod.diff
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Lynch | 1 Aug 2006 20:49

Re: [PHP-DEV] RfC: rethink OO inheritance strictness

On Fri, July 21, 2006 4:30 am, Derick Rethans wrote:
> On Fri, 21 Jul 2006, Mike Bretz wrote:
>
>> Michael Wallner wrote:
>> > mike <at> honeybadger:~/build/php-unicode-debug$ cli
>> > -d"error_reporting=8191" -r 'class c{function f(){}} class d
>> extends
>> > c{function f($a){}}'
>> > Fatal error: Declaration of d::f() must be compatible with that of
>> > c::f() in Command line code on line 1
>> >
>> >
>> > I *really* think that this enforcements are no good idea and I
>> _beg_
>> > you that we leave this "area" to interfaces.
>> +1
>>
>> In real live "C++" world I often have parent classes with function
>> f()
>> and an extended class which also uses the function name f(..) but
>> with
>> other, possibly class specific, variables, which then calls parent
>> f()... I do not see a good reason to enforce that both functions
>> must be
>> exactly the same when extending, especially since c::f() does not
>> get
>> called automatically, _when_ overwriting it in class d.
>
> It's quite a different thing in C++ as there you have method
> overloading
(Continue reading)

Permalink | Reply | 1 comment |

Gmane