[PHP-DEV] Re: PHP 5.0.4 PEAR issue

On Sat, 02 Apr 2005 00:00:18 +0200 [EMAIL PROTECTED] (Zeev Suraski) wrote: > Folks, > > We have a bit of a situation with the PEAR distro that's embedded > in 5.0.4. It's missing the RunTest.php file, so PEAR doesn't > install. > > The options we have, as far as I can tell, are: > > [a] Re-re

Re: [PHP-DEV] PHP 5.1

On Sun, 5 Jun 2005 22:29:13 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Sun, 5 Jun 2005, Johannes Schlueter wrote: > > > Is there progress with the new date stuff? I'd really like to > > have dates before 1970. > > Should go in this week. Finally :) If Derick's TZ and new strt

Re: [PHP-DEV] PHP 5.1

On Sun, 5 Jun 2005 23:57:40 +0200 [EMAIL PROTECTED] (David Zülke) wrote: > How about bundling PIMP with 5.1? ;o) Pimp as php ext is not on my top priority :) However it should be available on its own repository later this summer. That said, for the current GD, I'm working to sync the Boutell and

Re: [PHP-DEV] PHP 5.1

On Fri, 10 Jun 2005 09:07:26 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Thu, 9 Jun 2005, Andi Gutmans wrote: > > > I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start > > getting some very much needed feedback from the public for HEAD. > > I'll put the date time stuf

Re: [PHP-DEV] PHP 5.1

On Sat, 11 Jun 2005 11:06:48 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > At 07:41 PM 6/11/2005 +0200, Derick Rethans wrote: > >On Sat, 11 Jun 2005, Andi Gutmans wrote: > > > > > Hi Wez and all, > > > > > > I built Beta 2 with the latest CVS which appears to have > > > Wez's fixes. > > Please

Re: [PHP-DEV] forward compatibility "public" in 4.4

On Wed, 15 Jun 2005 16:36:38 +0200 [EMAIL PROTECTED] (Lukas Smith) wrote: > Stanislav Malyshev wrote: > > > LS>>I think its a good idea to have, to make it somewhat > > LS>>possible to prepare for the PHP5 E_STRICT world, while > > LS>>still developing PHP4 compatible code. I could for example >

[PHP-DEV] Re: cvs: php-src /ext/date config.m4 php_date.c /ext/date/lib .cvsignore dow.c parse_date.c parse_tz.c timelib.c timelib.h timelib.m4 timelib_structs.h tm2unixtime.c unixtime2tm.c /ext/dat

On Thu, 16 Jun 2005 23:12:11 - [EMAIL PROTECTED] ("Jani Taskinen") wrote: > sniperThu Jun 16 19:12:11 2005 EDT > > Added files: > /php-src/ext/date/lib timelib.m4 > > Modified files: > /php-src/ext/date config.m4 php_date.c >

[PHP-DEV] Re: 5.0.4 refcounting bug?

On Mon, 27 Jun 2005 16:06:41 +0100 [EMAIL PROTECTED] (Joe Orton) wrote: > We're getting a lot of reports from Fedora Core 4 users that the > shipped PHP 5.0.4 is triggering some refcounting bug breaking > some common apps; the attached file is a repro case which > triggers the segfault after follo

[PHP-DEV] Re: 5.1.0 Release Process

On Wed, 29 Jun 2005 18:10:15 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > Sorry to break up the allow_url_fopen discussion but I think that > thread is getting a bit old already and definitely clogging up > the mailing list. (hint hint) > > I'd like to start moving forward with the 5.1.0 relea

Re: [PHP-DEV] Re: 5.1.0 Release Process

On Thu, 30 Jun 2005 07:52:04 -0400 Wez Furlong <[EMAIL PROTECTED]> wrote: > On 6/30/05, Pierre-Alain Joye <[EMAIL PROTECTED]> wrote: > > > So to summarize a schedule I suggest: > > > a) 5.1.0 Beta 3 Friday, July 8th. > > > b) Release & branch 5.1.0 RC

Re: [PHP-DEV] Re: 5.1.0 Release Process

On Thu, 30 Jun 2005 09:35:22 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > Yep that was exactly the reason. > We've had these feature freezes in the past and we will branch > off after RC1 to allow commiting to HEAD (sans core due to > Unicode merge). So it's really minimal time (2-3 weeks) whi

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS /ext/date php_date.c php_date.h/ext/date/tests bug26198.phpt bug29585.phpt default-timezone-2.phpttimezone-configuration.phpt

On Sun, 3 Jul 2005 13:38:38 +0100 [EMAIL PROTECTED] ("Nuno Lopes") wrote: > So, you can give precedence to the ini option over the TZ var. > That way you don't need the functions. > IMHO this is the better choice, as it allows you to set a site > wide ini option, without touching in the environmen

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS /ext/datephp_date.c php_date.h/ext/date/tests bug26198.phpt bug29585.phptdefault-timezone-2.phpttimezone-configuration.phpt

On Mon, 4 Jul 2005 11:48:06 +0100 "Nuno Lopes" <[EMAIL PROTECTED]> wrote: > >> So, you can give precedence to the ini option over the TZ var. > >> That way you don't need the functions. > >> IMHO this is the better choice, as it allows you to set a site > >> wide ini option, without touching in th

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS /ext/datephp_date.cphp_date.h/ext/date/tests bug26198.phpt bug29585.phptdefault-timezone-2.phpttimezone-configuration.phpt

On Mon, 4 Jul 2005 13:52:24 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > The database can not be editable this easily, but that should not > be needed anyway. No it's not that easy to make it editable. It should have been easier using hashtables or other methods. > For aliases, these

[PHP-DEV] Re: Timezone Function Name (Was: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS /ext/datephp_date.cphp_date.h/ext/date/tests bug26198.phpt bug29585.phptdefault-timezone-2.phpttimezone-conf

On Mon, 4 Jul 2005 14:16:53 +0200 (CEST) Derick Rethans <[EMAIL PROTECTED]> wrote: > > The Oslon's database changes (rarely but does :). > > It actually does about once a month... I meant the amount of usefull changes. I can see some advantages to move the TZ as an extension. It can contains onl

Re: [PHP-DEV] Timezone Function Name (Was: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src/ NEWS /ext/datephp_date.cphp_date.h/ext/date/tests bug26198.phptbug29585.phptdefault-timezone-2.phpttimezone-config

On Mon, 4 Jul 2005 13:32:28 +0100 [EMAIL PROTECTED] ("Nuno Lopes") wrote: > >> Last point, can you rename date_timezone_* to > >> date_default_timezone_*? > > > > Yes, but it's too long. Can we come up with something better? > > > > Derick > > Sorry, but I still didn't understand why the need for

Re: [PHP-DEV] Timezone Function Name (Was: Re: [PHP-DEV] Re:[PHP-CVS] cvs: php-src/ NEWS /ext/datephp_date.cphp_date.h/ext/date/testsbug26198.phptbug29585.phptdefault-timezone-2.phpttimezone-configur

On Mon, 4 Jul 2005 13:44:29 +0100 "Nuno Lopes" <[EMAIL PROTECTED]> wrote: > Are you sure? I was not :) but still remains TS issues and inconsistencies between OSes. In short, we need this function, we can move to the name choice now :) --Pierre -- PHP Internals - PHP Runtime Development Mai

Re: [PHP-DEV] Timezone Function Name (Was: Re: [PHP-DEV] Re:[PHP-CVS]cvs: php-src/ NEWS /ext/datephp_date.cphp_date.h/ext/date/testsbug26198.phptbug29585.phptdefault-timezone-2.phpttimezone-configurat

On Mon, 4 Jul 2005 14:10:42 +0100 [EMAIL PROTECTED] ("Nuno Lopes") wrote: > > On Mon, 4 Jul 2005, Pierre-Alain Joye wrote: > > > >> I was not :) but still remains TS issues and inconsistencies > >> between OSes. > > > > Don't forget the

Re: [PHP-DEV] Timezone Function Name (Was: Re: [PHP-DEV] Re:[PHP-CVS]cvs: php-src/ NEWS /ext/datephp_date.cphp_date.h/ext/date/testsbug26198.phptbug29585.phptdefault-timezone-2.phpttimezone-configurat

On Mon, 4 Jul 2005 14:56:41 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Mon, 4 Jul 2005, Pierre-Alain Joye wrote: > > > I was not :) but still remains TS issues and inconsistencies > > between OSes. > > Don't forget the thread safety issues...

[PHP-DEV] Re: date/timezone classes

On Thu, 7 Jul 2005 23:10:16 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > Hei, > > I wrote up a little document about how I want to implement the > date and timezone "class"es - although I'm not planning any OO > methods. I'm just wrapping the timelib_time and timelib_tzinfo > structur

Re: [PHP-DEV] date/timezone classes

On Thu, 07 Jul 2005 16:56:51 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > Hey Derick, > > If you're just wrapping the date type with a class, I don't see > why it shouldn't be a resource. It'd give you the same thing but > would be easier to implement (unless I'm missing something). > I realiz

Re: [PHP-DEV] date/timezone classes

On Fri, 8 Jul 2005 09:16:29 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > Objects are not harder to implement, I found it actually more > straight forward. Besides that, making it an object allows other > people to extend it, something that Pierre wants for his pecl/ > date. I do not

Re: [PHP-DEV] date/timezone classes

On Fri, 8 Jul 2005 14:31:14 +0200 (CEST) Derick Rethans <[EMAIL PROTECTED]> wrote: > On Fri, 8 Jul 2005, Edin Kadribasic wrote: > > > I would love to be able to do something like this: > > > > $d = new Date(time()); > > $d->month++; > > $d->print("Y-m-d"); // date() equiv. > > Adding methods is

Re: [PHP-DEV] date/timezone classes

On Mon, 11 Jul 2005 10:16:45 -0700 Andrei Zmievski <[EMAIL PROTECTED]> wrote: > Can we please wrap up the whole OO/non-OO discussion and just fix > the damn ext/date so that it works as advertised? The rest can be > done later. Let's not hold up RC1 unless really necessary. It's not a stopping fo

Re: [PHP-DEV] php 4.4 BC break

On Tue, 12 Jul 2005 20:53:16 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Tue, 12 Jul 2005, Chuck Hagenbuch wrote: > > > Relax, I'm not debating the decision. Just: > > > > PLEASE can someone put a big fat warning on the php 4.4 > > announcement on www.php.net that it breaks exist

Re: [PHP-DEV] php 4.4 BC break

On Tue, 12 Jul 2005 13:04:36 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > Just for the record, most compilers have such "bugs". It happens > when the compiler is too lenient and allows incorrect code to be > compiled. I've seen similar things happen in C/C++ and other > languages. Sure :) Was

[PHP-DEV] Re: CVS Account Request: crafics

On Sun, 17 Jul 2005 08:34:05 -0700 [EMAIL PROTECTED] ("Manfred Weber") wrote: > cvs account for > /pear/Services_Webservice > > http://pear.php.net/pepr/pepr-proposal-show.php?id=262 > > Pierre told me to ask for cvs account Confirmed, requires karma for pear/Services_Webservice --Pierre --

[PHP-DEV] Re: cvs: php-src / NEWS /ext/date TODO php_date.c php_date.h /ext/date/lib parse_date.c parse_tz.c timelib.h timelib_structs.h timezonedb.h unixtime2tm.c /ext/date/lib/resource parse_date.re /ext/date/tests bug33414-2.phpt bug33578.phpt date_create-1.phpt

On Wed, 20 Jul 2005 08:31:04 - [EMAIL PROTECTED] ("Derick Rethans") wrote: > +#ifdef EXPERIMENTAL_DATE_SUPPORT > + /* Advanced Interface */ > + PHP_FE(date_create, NULL) > + PHP_FE(date_format, NULL) > + PHP_FE(date_modify, NULL) > + PHP_FE(date_timezone_get, NULL) > +

[PHP-DEV] Re: cvs: php-src / NEWS /ext/date TODO php_date.c php_date.h /ext/date/lib parse_date.c parse_tz.c timelib.h timelib_structs.h timezonedb.h unixtime2tm.c /ext/date/lib/resource parse_date

On Wed, 20 Jul 2005 08:31:04 - [EMAIL PROTECTED] ("Derick Rethans") wrote: > +#ifdef EXPERIMENTAL_DATE_SUPPORT > + /* Advanced Interface */ > + PHP_FE(date_create, NULL) > + PHP_FE(date_format, NULL) > + PHP_FE(date_modify, NULL) > + PHP_FE(date_timezone_get, NULL) > +

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/date...

On Wed, 20 Jul 2005 10:40:20 +0200 [EMAIL PROTECTED] (Edin Kadribasic) wrote: > Derick, > > Didn't we agree not to do this until 5.1 was released? Please > revert the object support. Derick told me on IRC that he agreed on that with Andi. I still think that we should not expose the new lib now.

Re: [PHP-DEV] Re: SOAP SSL support doesn't work whenallow_url_fopen is turned off

On Thu, 28 Jul 2005 16:10:59 +0300 [EMAIL PROTECTED] (Zeev Suraski) wrote: > At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote: > >>Are you therefore saying SOAP support should be 100% diabled > >>when allow_url_fopen is off? > I tend to agree with Adam (and I guess Wez) - SOAP should not be > affect

[PHP-DEV] Re: PHP 5.1 Release Candidate 1

On Tue, 26 Jul 2005 17:50:07 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > Hi all, > > As planned (a tiny bit delayed), I'd like to RC1 PHP 5.1 within > the next few days. I suggest to aim for Tuesday in a week. > If there are any critical issues which need addressing please > email me. Mind t

[PHP-DEV] Re: RC1, instanceof?

On Fri, 05 Aug 2005 13:52:13 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > Hi all, > > Another reminder, I'd like to roll RC1 on Monday. Everyone will > be back from OSCON and we can start the Unicode merge right > afterwards. One thing I would like to solve in 5.1 is instanceof (or the deprec

[PHP-DEV] Re: RC1, instanceof?

Hello, I took a short look to the implementation. instanceof_ex works as expected, no error display there. The problem comes from the usage of class_name_reference in the parser. class_name_reference calls zend_do_fetch_class, which raises this error as no class is loaded. Now I'm not sure abou

Re: [PHP-DEV] type hinting throwing a fatal error

On Mon, 8 Aug 2005 15:09:06 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Mon, 8 Aug 2005, Sebastian Bergmann wrote: > > > Derick Rethans schrieb: > > > Throwing two different kinds of Exceptions is evil. > > > > Just as evil as allowing SPL to be disabled. > > Not really. SPL is

Re: [PHP-DEV] type hinting throwing a fatal error

On Mon, 08 Aug 2005 15:56:55 +0200 [EMAIL PROTECTED] (Jochem Maas) wrote: > IMHO btw, semantically, calling it S(tandard)PL and then making > it so that it's not standard (i.e. it's an extension) seems odd. I was pretty sure until today that it was not possible to disable it. But it's not possibl

[PHP-DEV] Re: RC1, instanceof?

On Mon, 08 Aug 2005 18:26:30 +0200 [EMAIL PROTECTED] (Michael Wallner) wrote: > Hi Pierre-Alain Joye, you wrote: > > > I can write a patch to "fix" it if we agree that the current > > behavior is not correct. > > While you're at it, could you conti

Re: [PHP-DEV] Re: RC1, instanceof?

On Mon, 08 Aug 2005 14:43:25 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > I don't agree that instanceof on a class which doesn't exist > should work. It doesn't do so in other languages (or at least not > in Java/C++(dynamic_cast)) nor does it really seem to make a lot > of sense and be useful.

Re: [PHP-DEV] Re: RC1, instanceof?

On Tue, 09 Aug 2005 14:31:08 +0800 [EMAIL PROTECTED] (Alan Knowles) wrote: > On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote: > > You are wrong because __autoload() *is* called and you can load > > the class on the-fly. The only problem is if the class does not > > exist in your code base, i

Re: [PHP-DEV] Re: RC1, instanceof?

On Tue, 9 Aug 2005 10:15:15 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > > > This technique is already frequently used to cope with lazy > > > loaded code, which even with cached code compilers, is pretty &

[PHP-DEV] Re: PHP 5.5 or 6.0

On Tue, 9 Aug 2005 10:41:07 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > Now that we branched it's time to rename HEAD to something else > than 5.1 in order to have different version numbers. Although the > name PHP 5.5 was mentioned before, I do think we should call it > PHP 6.0. As t

Re: [PHP-DEV] PHP 5.5 or 6.0

On Tue, 9 Aug 2005 12:03:28 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Tue, 9 Aug 2005, Weyert de Boer wrote: > > > >6.0 if the Namespaces patch makes it in, 5.5 with Unicode > > >only? ;) > > > > Namespaces patch is a patch so it's fine for version 5.5, if > > you would ask me.

Re: [PHP-DEV] Re: RC1, instanceof?

On Tue, 09 Aug 2005 13:24:56 +0300 [EMAIL PROTECTED] (Pasha Zubkov) wrote: > Alan Knowles wrote: > > The basic point is that is_a() provided negative testing of > > non-existant classes > > if (!is_a($obj, "SomeRarelyUsedClass")) { > > > > instance_of does not, and can not, at present. > >

Re: [PHP-DEV] Re: PHP 5.5 or 6.0

On Tue, 9 Aug 2005 12:47:50 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > > But I have some about what we will do in php 5.x (without > > unicode, namespace), and 6.0. > > > > I like to see once that we

Re: [PHP-DEV] Re: PHP 5.5 or 6.0

On Tue, 9 Aug 2005 13:02:47 +0200 (CEST) Derick Rethans <[EMAIL PROTECTED]> wrote: > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > > On Tue, 9 Aug 2005 12:47:50 +0200 (CEST) > > [EMAIL PROTECTED] (Derick Rethans) wrote: > > > > > On T

Re: [PHP-DEV] Re: RC1, instanceof?

On Tue, 09 Aug 2005 12:29:45 -0700 Andi Gutmans <[EMAIL PROTECTED]> wrote: > we'd have to first "try" and load the class to make > sure we can actually check the instanceof Pardon me? :) As I said in my 2nd post about this topic, the problem (and only problem here) is that in the lexer, the rig

Re: [PHP-DEV] PHP 5.5 or 6.0

On Tue, 09 Aug 2005 12:25:27 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > I think Unicode warrants a major version. I'd go with PHP 6 and > aim to release it before Perl 6 :) > From judging by a Perl 6 talk we attended at OSCON, that might > actually be a realistic goal. No rush please... Bet

Re: [PHP-DEV] Re: RC1, instanceof?

On Tue, 09 Aug 2005 12:44:59 -0700 Andi Gutmans <[EMAIL PROTECTED]> wrote: > But that's a good point. For the few frameworks that might > require such functionality they can use class_exists() or other > methods. That doesn't mean we should change instanceof for > mainstream usage which is 99.99%.

[PHP-DEV] is_a, instanceof, conclusion

Hello, As there is no way to find a solution to the two different vision (pedantic, non pedantic ;). I propose to do not deprecate is_a. It cannot hurt neither is_a (is_a uses instanceof too) or instanceof. The only cons for is_a is a little slow down, which is negligeable. Any objection? Regar

Re: [PHP-DEV] is_a, instanceof, conclusion

Hello, Can we just "undeprecate" is_a and move on? I do not have zend karma (hopefully ;), Andi, can you take care of that? Besides real world usages, the main point is not going to be solved that soon, both sides can live with an unpedantic is_a (and not deprecated) and a pedantic instanceof. R

[PHP-DEV] Re: PHP 6.0 Wishlist

Hello, +1 to all things, same comment as the opcode cache Ilia's one. I would like to add one from my wishes: Bump version for the required library as high as possible (or realist) and do not support museum softwares at all, like droping freetype v1 for example. Most of the users do not use it a

Re: [PHP-DEV] Re: PHP 6.0 Wishlist

On Sat, 13 Aug 2005 00:21:29 +0300 (EEST) [EMAIL PROTECTED] (Jani Taskinen) wrote: > > Very good idea. We do bundle the thing? :) I do not think we can use the extern GD2 in the same nice way than we use ours. But droping _extern_ gd2 support is possible. The only remaining thing is to che

Re: [PHP-DEV] PHP 6.0 Wishlist

On Fri, 12 Aug 2005 20:19:04 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Fri, 12 Aug 2005, George Schlossnagle wrote: > > > > 3. Add input filter extension which will include a mechanism > > > for application developers to very easily turn it off which > > > would swap the raw GPC

Re: [PHP-DEV] PHP 6.0 Wishlist

On Fri, 12 Aug 2005 15:03:36 -0400 [EMAIL PROTECTED] (Ilia Alshanetsky) wrote: > > I have a #9 to share, too: > > Assuming that PHP 6.0 will also have namespaces support (which > > would be cool), it might make sense to move all internal > > functions to use namespaces (if they support functions s

Re: [PHP-DEV] Re: PHP 6.0 Wishlist

On Sat, 13 Aug 2005 14:17:52 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Fri, 12 Aug 2005, Sara Golemon wrote: > > > > 7. Make identifiers case-sensitive > > > > > Or perhaps optionally case sensitive? I dunno, I've made my > > peace with PHP being (mostly) case-insensitive. > >

Re: [PHP-DEV] PHP 6.0 Wishlist

Hello, PHP 5 was an evolution of php4, adding good OO things and some new extensions. PHP 5.1 is going a bit further and make the new engine more efficient. Both keep old and annoyed things we had in php4. PHP 6.0 is not going to be realease in the next months or maybe even not this year. PHP5

[PHP-DEV] PHP 6.0, wishlist, pear

Hello, Being in a spring cleaning session, I removed pear from php-src in HEAD, meaning php 6.0. I will not introduce it back in any form. The README.PEAR is all I would like to see in any future PHP distributions. Any other solutions is impossible to manage in a safe and sane way. As some knows

[PHP-DEV] ext/gd, cleanup, iirc

Hello, This is a last warning before I cleanup the GD in HEAD. The cleanup consists of: * Drop Freetype 1 support * Drop GD1 support * Remove functions getting deprecated by the precendent 2 points * bump the minimum version of the required libs (I left zlib to the base dependency as it is

Re: [PHP-DEV] ext/gd, cleanup, iirc

On Thu, 18 Aug 2005 15:36:55 +0200 Edin Kadribasic <[EMAIL PROTECTED]> wrote: > I say we do not have to require the latest and the greatest libs. > Just require the latest known working. > > I'm using freetype-2.0.9 and libpng-1.0.14 and see no reason why > we should artificially increase the re

Re: [PHP-DEV] 5.0.5 RC2

On Fri, 26 Aug 2005 09:12:51 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Fri, 26 Aug 2005, Sonke Ruempler wrote: > > > Hi Zeev, > > > > Zeev Suraski wrote on Thursday, August > > 25, 2005 7:37 PM: > > > > >> Fatal error: Only variables can be passed b

Re: [PHP-DEV] Re: PHP 5.1: Does it still require ext/xmlrpc for pear?

On Mon, 29 Aug 2005 07:58:33 -0400 [EMAIL PROTECTED] (John Coggeshall) wrote: > On Mon, 2005-08-29 at 13:23 +0200, Steph wrote: > > It's the 'given that it doesn't appear to have an active > > maintainer' part that's important here. It takes a little TLC > > to make a PECL package available for d

[PHP-DEV] Re: PHP 5.1

On Tue, 30 Aug 2005 05:06:07 +0300 [EMAIL PROTECTED] (Zeev Suraski) wrote: > For those of you who submitted patches to 5.1 since RC1 - do you > believe that we need another RC or can we go ahead and roll 5.1 > final and run a sanity test for 24 hours? I went over the > patches, none of them appea

[PHP-DEV] Re: Version number x.y.z for package.xml/package.xml

On Sun, 11 Sep 2005 11:59:03 +0200 [EMAIL PROTECTED] (Pierre Joye) wrote: > Except lazyness, there should be no reason to follow this little > rule, thanks :-) to not follow :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: 5.1.0RC2

On 9/14/05, Zeev Suraski <[EMAIL PROTECTED]> wrote: > Any last minute additions to 5.1.0RC2 or can we roll it? cd php-src/pear && wget http://pear.php.net/install-pear.phar for both sources and win32 releases. As a little reminder :) --Pierre -- PHP Internals - PHP Runtime Development Mailin

Re: [PHP-DEV] [PATCH] Three new GD functions

On Fri, 4 Apr 2003 13:11:04 -0500 "John Coggeshall" <[EMAIL PROTECTED]> wrote: > > I've ported three GD functions from the 2.0.12 version of GD into the > bundled version: imagesetclip(), imagegetclip(), and > imagecopyrotated()... I may go through and port more but I wanted to > see the response

Re: [PHP-DEV] [PATCH] Three new GD functions

On Fri, 4 Apr 2003 20:30:23 -0500 "John Coggeshall" <[EMAIL PROTECTED]> wrote: > > I haven't done a comparison, but imagecopyrotated() isn't something I > made -- I ported it from the latest version of the GD library. If you > think you could make a better imagecopyrotated() I don't have a > prob

Re: [PHP-DEV] Moving to PECL

On Sun, 8 Jun 2003 09:23:29 -0700 (PDT) Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > The one point on the QA issue is that nobody ever looks through all > the PECL extensions, but we occasionally grep through all the ext/* > extensions to make sure that an API change, or just a simple mistake > tha

Re: [PHP-DEV] Moving to PECL

On 10 Jun 2003 11:36:09 +0200 Per Lundberg <[EMAIL PROTECTED]> wrote: > On Sun, 2003-06-08 at 18:23, Rasmus Lerdorf wrote: > > Getting it out of PEAR and up to its own top-level cvs module is a > > start. > > +1 on this -- I know myself, when I was trying to find a PECL module > that I *knew* sho

Re: [PHP-DEV] Why Move to PECL?

On Mon, 9 Jun 2003 15:16:30 +0100 "James Cox" <[EMAIL PROTECTED]> wrote: > How do we get here? > > By moving PECL into the limelight. This week, I will be splitting PECL > into it's own cvs module, and (after discussion) I'd like to create a > version of pearweb for pecl.php.net, essentially sepe

Re: [PHP-DEV] Why Move to PECL?

On Tue, 10 Jun 2003 12:09:28 +0100 "James Cox" <[EMAIL PROTECTED]> wrote: > Actually, it should be fairly easy to use the same codebase for two > different sites and have a few if statements to stylize the site > depending on which url is going to. (btw, pecl.php.net is already an > alias for pea

Re: [PHP-DEV] Moving to PECL

On Tue, 10 Jun 2003 15:37:31 +0200 Martin Jansen <[EMAIL PROTECTED]> wrote: > Splitting PECL out of PEAR in terms of the website (*) will improve > PECL's position a lot: Right now people consider it to be a subset of > PEAR (the PECL packages are really pretty much hidden in PEAR atm) and > thus

Re: [PHP-DEV] Moving to PECL

On Sat, 14 Jun 2003 19:24:03 +0200 "Tomas V.V.Cox" <[EMAIL PROTECTED]> wrote: > > That's we call dependencies, and the pear cmd supports a wide range of > them, including: package, extension, php, zend, os, external prog, > etc. Can you solve all this with CVS branches/tags? ;) As a sidenote, yo

[PHP-DEV] Re: [PEAR-DEV] Re: [PHP-DEV] [RFC] Binary pecl packages

On Fri, 20 Jun 2003 01:56:41 +0200 Markus Fischer <[EMAIL PROTECTED]> wrote: > For example mod_ssl [1] always includes the version number of > the Apache server it works with: > > 21-Mar-2003: Released 2.8.14-1.3.27: Important bugfixes. > > So, with a quick look on the file

[PHP-DEV] [take #2][RFC] Binary pecl packages

On Fri, 20 Jun 2003 05:59:09 -0700 (PDT) "Jesus M. Castagnetto" <[EMAIL PROTECTED]> wrote: > Bottomline, most discussions on what formats to support specifically > (apart from a source tarball), boils down to: If you want FOO to be > supported, write the code to support FOO. Even topline current

Re: [PHP-DEV] [Operators overloading] PHP 5.1

On Thu, 3 Feb 2005 11:47:13 +0100 (CET) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Thu, 3 Feb 2005, Sebastian Bergmann wrote: > > > Derick Rethans wrote: > > > Use C++/Java if you want this. > > > > Java does not support operator overloading. > > So, that means PHP shouldn't get it either,

Re: [PHP-DEV] PHP 5.1

On Thu, 3 Feb 2005 13:00:13 +0200 (IST) [EMAIL PROTECTED] (Stanislav Malyshev) wrote: > SB>> patch [1] by Johannes Schl?ter that has been floating around > SB>for a> while? > > 1. I personally don't think operator overloading is a good idea. > It doesn't add you anything you couldn't do without i

Re: [PHP-DEV] [Operators overloading] PHP 5.1

On Thu, 3 Feb 2005 18:12:44 +0100 [EMAIL PROTECTED] (Terje Slettebø) wrote: > > On Thu, 3 Feb 2005 11:47:13 +0100 (CET) > > [EMAIL PROTECTED] (Derick Rethans) wrote: > > > > > On Thu, 3 Feb 2005, Sebastian Bergmann wrote: > > > > > > > Derick Rethans wrote: > > > > > Use C++/Java if you want this.

Re: [PHP-DEV] XMLReader in PHP 5.1

On Mon, 07 Feb 2005 17:48:27 -0800 [EMAIL PROTECTED] (Andi Gutmans) wrote: > Yeah, unless someone objects that'd be great. What's about its brother XMLWriter (even as experimental)? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsu

Re: [PHP-DEV] Autoboxing in php 5.1

On Sat, 12 Feb 2005 08:35:09 -0800 [EMAIL PROTECTED] (Andi Gutmans) wrote: > I think the right way to implement this is in a development tools. > There is other data that needs to be gathered for creating a WSDL > file such as URI, authentication (if required) etc. I agree here. However having a:

Re: [PHP-DEV] Autoboxing in php 5.1

On Sat, 12 Feb 2005 12:26:06 -0500 [EMAIL PROTECTED] (George Schlossnagle) wrote: > > On Feb 12, 2005, at 11:35 AM, Andi Gutmans wrote: > > > I think the right way to implement this is in a development > > tools. There is other data that needs to be gathered for > > creating a WSDL file such as

[PHP-DEV] Re: [patch] DOM canonize method

On Thu, 17 Feb 2005 02:24:02 +0100 [EMAIL PROTECTED] (David Kingma | jool.nl) wrote: > Hi Rob / Chregu, > > As a first (small) step to implementing xml-security specs > (dig-sign, encryption) I created a patch against HEAD to expose > (exclusive-)C14n functionality from libxml2. I allows you to >

[PHP-DEV] Re: Writing an Extension

On Tue, 22 Feb 2005 09:38:38 +0100 [EMAIL PROTECTED] (Michael Wallner) wrote: > Hi Arjun Jain, you wrote: > > > We need to write a PHP extension for the PI API > > (http://www.picorp.com). > > > Other than ext_skel and PECL_Gen, are there any other options? > > What should I use? And also for th

Re: [PHP-DEV] PHP 5.0.4RC1 and PHP 4.3.11RC1 rolled

On Mon, 14 Mar 2005 14:20:36 -0500 [EMAIL PROTECTED] (Greg Beaver) wrote: > Edin Kadribasic wrote: > > Windows binaries are now available at: > > > > PHP 5.0.4RC1 > > http://downloads.php.net/edink/php-5.0.4RC1-Win32.zip > > > > PHP 4.3.11RC1 > > http://downloads.php.net/edink/php-4.3.11RC1-Win3

Re: [PHP-DEV] PHP 5.0.4RC1 and PHP 4.3.11RC1 rolled

On Mon, 14 Mar 2005 18:19:41 -0500 [EMAIL PROTECTED] (Daniel Convissor) wrote: > On Mon, Mar 14, 2005 at 11:54:54PM +0100, Pierre-Alain Joye wrote: > > > > Feel like it was not updated on the building host. PEAR should > > be 1.3.5, I do not remember the other, but

Re: [PHP-DEV] enabling sqlite by default

On Tue, 24 Jun 2003 10:03:51 -0400 George Schlossnagle <[EMAIL PROTECTED]> wrote: > This is a good synopsis of some of my feelings. PECL == Siberia is a > recurrent gripe, but anytime someone works on a cool project they want > > it to bundle, ship and be enabled by default instead of promoting

[PHP-DEV] HEAD, files not in branch

Hello, While syncing the HEAD branch, I got the following errors on commit? cvs server: sticky tag `HEAD' for file `Installer.php' is not a branch cvs server: sticky tag `HEAD' for file `Packager.php' is not a branch cvs server: sticky tag `HEAD' for file `Registry.php' is not a branch cvs serve

Re: [PHP-DEV] Re: networking bugs and bugme.osdl.org (fwd)

On Sat, 28 Jun 2003 19:37:54 +0200 Andi Gutmans <[EMAIL PROTECTED]> wrote: > We should force maintainers to subscribe to their sections :) This is what I plan for bugs.pear :-) pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HEAD won't compile on Linux

On Wed, 09 Jul 2003 19:27:05 +0200 Sebastian Bergmann <[EMAIL PROTECTED]> wrote: > /usr/src/php/php5/ext/gd/libgd/gd.c: In function `gdImageRotate': > /usr/src/php/php5/ext/gd/libgd/gd.c:2768: `clrBackR' undeclared (first > use in this function) > /usr/src/php/php5/ext/gd/libgd/gd.c:2768: (Each un

Re: [PHP-DEV] CVS Account Request: neufeind

On 8 Aug 2003 12:56:48 - "Stefan Neufeind" <[EMAIL PROTECTED]> wrote: > working on pear-package Validate; already have the okay for my > contributions from package-lead Confirmed. pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub

Re: [PHP-DEV] request for thread safety advice

On Mon, 20 Oct 2003 17:35:30 -0700 (PDT) Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > True, I should have mentioned that the mutex might have to span an > entire sequence of calls from open to close or something to that > effect. > > In the specific case of GD, it wouldn't actually be hard to make

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

On Wed, 3 Dec 2003 10:42:33 +0100 (CET) Derick Rethans <[EMAIL PROTECTED]> wrote: > On Wed, 3 Dec 2003, Sebastian Bergmann wrote: > > > Derick Rethans wrote: > > > -[6] Method names follow the 'studlyCaps' > > > > This is insane. > > > > Whether you like it or not, most people who use program

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

On Wed, 03 Dec 2003 19:13:13 +0900 Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote: > Derick Rethans <[EMAIL PROTECTED]> wrote: > > > On Wed, 3 Dec 2003, Sebastian Bergmann wrote: > > > > > Derick Rethans wrote: > > > > -[6] Method names follow the 'studlyCaps' > > > > > > This is insane. > > > >

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

On Wed, 03 Dec 2003 11:52:35 +0100 Ulf Wendel <[EMAIL PROTECTED]> wrote: > php_native_func() > myFunc() We are not talking about function names but methods. > or even: > > obj->php_native_func() > obj->myFunc() Quick thought, does that work with overload? See Lukas post. pierre -- PHP Inter

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

Hello, On Wed, 03 Dec 2003 14:02:00 +0100 Ulf Wendel <[EMAIL PROTECTED]> wrote: > Nevertheless I preferr PHP not to use studyCaps for it's native > functions/methods/whatever. It seperates the build-in functionality > nicely from my code. I like the counter and nicely move from PHP classes to

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

On Wed, 03 Dec 2003 14:30:08 +0100 Hartmut Holzgraefe <[EMAIL PROTECTED]> wrote: > One of the reasons that you don't see PHP 3 in use anymore is that > the transition was so easy. Now that we have even more installations > out there and a lot of open projects that run on PHP 4 it is even > more im

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

Thanks for the history, always funny :) On Wed, 3 Dec 2003 15:05:19 +0100 (CET) Sascha Schumann <[EMAIL PROTECTED]> wrote: > Fortunately, we can avoid falling into that trap. PHP > supports underscores, and terminals which cannot display the > character correctly don't prevail any l

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

On Wed, 3 Dec 2003 15:44:52 +0100 (CET) Sascha Schumann <[EMAIL PROTECTED]> wrote: > The point is that uglyCaps are backwards, a hack/workaround > for a missing feature in a language. > > uglyCaps have no inherent advantage which should be > considered by those advocating their wi

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

On Wed, 3 Dec 2003 16:16:14 +0100 (CET) Sascha Schumann <[EMAIL PROTECTED]> wrote: > > Well, as (hopefully) a last post from me in this thread, the fact is > > the"UglyCaps" is widely used, with PHP and others OO langages. The > > fact is that is somehow a de facto standard and ease our life to >

Re: [PHP-DEV] New win32 build system

On Wed, 03 Dec 2003 16:41:24 +0100 Sebastian Bergmann <[EMAIL PROTECTED]> wrote: > Wez Furlong wrote: > > Fixed. > > Yes, but now it fails with > > NMAKE : fatal error U1073: 'ext\standard\parsedate.c' konnte nicht > erstellt werd > en > Stop. means "... cannot be generated Stop." ;-) -- PH

Re: [PHP-DEV] mingw32

On Wed, 3 Dec 2003 17:01:23 +0100 (CET) Sascha Schumann <[EMAIL PROTECTED]> wrote: > Hi Wez, > > now that the dependency on VC has been dropped, what would it > take to get mingw32 build support? Should be really great :). By the way (or a bit OT), I got little little success by run

  1   2   >