Hello Andi,
Sunday, November 30, 2003, 12:08:33 AM, you wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
>>On Fri, 28 Nov 2003, Andrei Zmievski wrote:
>>
>> > On Thu, 27 Nov 2003, Marcus Boerger wrote:
>> > > Convert objects to string if string is required by newer param
Hello Andrei,
Friday, November 28, 2003, 1:59:35 PM, you wrote:
> On Thu, 27 Nov 2003, Marcus Boerger wrote:
>> hellyThu Nov 27 14:24:38 2003 EDT
>>
>> Modified files:
>> /ZendEngine2 zend_API.c
>> Log:
>> Convert objects to string if string is requir
On Sun, Nov 30, 2003 at 01:08:33AM +0200, Andi Gutmans wrote:
> Wrong. __toString() isn't supposed to work in every case the engine expects
> a string.
> You'd probably also want $obj[3] to work as a string offset?
> In this case, maybe we should rename __toString to __toPrintable, because I
> t
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> I kind of agree with Andrei here. We discussed in the past that
> __toString() will not propogate to every place in the engine where we check
> for IS_STRING but will only effect print.
> I think getting into this is a bad idea. If the old parameter passi
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
> >As far as I'm concerned, if you don't want your object to be
> >auomatically cast to a string, you shouldn't provide a __toString()
> >method.
>
> Wrong. __toString() isn't supposed to wo
Georg Richter wrote:
> If you're using BUILD/compile scripts it should work fine.
It doesn't. I now built with BUILD/compile-pentium and still get the
same errors.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://profe
The strict was introduced so that we can add warnings about practices we
recommend and deprecated behavior.
I think "var" belongs there.
We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and
save ppl the trouble of seeing these warnings.
Then again, we could remove the warning
At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
On Fri, 28 Nov 2003, Andrei Zmievski wrote:
> On Thu, 27 Nov 2003, Marcus Boerger wrote:
> > Convert objects to string if string is required by newer parameter
parsing
> > since we do this for older parameter parsing does so too.
At 04:59 AM 11/28/2003 -0800, Andrei Zmievski wrote:
On Thu, 27 Nov 2003, Marcus Boerger wrote:
> helly Thu Nov 27 14:24:38 2003 EDT
>
> Modified files:
> /ZendEngine2 zend_API.c
> Log:
> Convert objects to string if string is required by newer parameter
parsing
> since we
I believe the problem here is in how mssql_query handles result sets
that have multiple results returned, but none with rows (such as in
this bug where there are multiple commands executed and multiple errors
returned). In the php_mssql.c for PHP 4.3.4 the block at line 1145
reads:
while
Hi,
On Sat, Nov 29, 2003 at 06:09:36PM +0100, Marcus Boerger wrote :
> this works now.
Thanks. Sorry for the order of reply of the mails, my spam filer
catches this one and I only discovered it yet.
> > Besides the segfaults above, is there a chance we have a nicer HTML
> >
Jani Taskinen wrote:
I don't really understand how removing a deprecated function
would hurt anyone..doesn't all people test their scripts before
putting new PHP version into production?
You seem to be forgetting that the people in charge of the PHP
installation and the ones doing the
On November 30, 2003 12:35 pm, Sara Golemon wrote:
> Perhaps I'm confused.
>
> I had the impression that the point of moving obsolesced extensions to PECL
> was so that they WOULDN'T be included in the main source tarball. Then,
> should user X out there need ext/foo they can do a: pear insta
On Sun, 30 Nov 2003, Jani Taskinen wrote:
> On Sun, 30 Nov 2003, Derick Rethans wrote:
>
> >SQlite is already in the normal tree, and pear install worked for PECL
> >extensions, but recently somebody broke that.
>
> I meant that it has worked fine for sqlite for long time.
> If someone bro
On Sun, 30 Nov 2003, Derick Rethans wrote:
>On Sun, 30 Nov 2003, Jani Taskinen wrote:
>
>>
>> I kinda have thought all the time that those extensions
>> that will be in a release stay in the php-src CVS module.
>> And the rest is put into PECL, where people can find them
>> and use
On Sun, 30 Nov 2003, Jani Taskinen wrote:
>
> I kinda have thought all the time that those extensions
> that will be in a release stay in the php-src CVS module.
> And the rest is put into PECL, where people can find them
> and use phpize or whatever to build them.
>
> Doesn't
I kinda have thought all the time that those extensions
that will be in a release stay in the php-src CVS module.
And the rest is put into PECL, where people can find them
and use phpize or whatever to build them.
Doesn't that 'pear install' thing work already? (sqlite, an
Perhaps I'm confused.
I had the impression that the point of moving obsolesced extensions to PECL
was so that they WOULDN'T be included in the main source tarball. Then,
should user X out there need ext/foo they can do a: pear install foo.
If >that's< the case, then there need be no "pic up
On Sun, Nov 30, 2003 at 01:39:13PM +0100, Derick Rethans wrote :
> On Sun, 30 Nov 2003, Markus Fischer wrote:
> > On Wed, Nov 19, 2003 at 12:00:30AM +0200, Andi Gutmans wrote :
> > > I added an E_STRICT error level today which purists can use to make sure
> > > that there scripts are using the lat
Hey, all I'm talking about is a script to put the golden extensions
into ext (and exclude the cruft) when we build our tarball distro.
--Wez.
> >> Why not go with RPM's then? The eays way is to split up the RPM's so
that we
> >> can have RPMs for the basic stuff like INI, Docs and all, then for t
Hello Derick,
Sunday, November 30, 2003, 1:39:36 PM, you wrote:
> On Sun, 30 Nov 2003, Marcus Boerger wrote:
>> Hello Wez,
>>
>> Sunday, November 30, 2003, 11:01:51 AM, you wrote:
>>
>> > There is no point moving unmaintained code from ext to pecl;
>> > its just a waste of time until we can solv
On Sun, 30 Nov 2003, Marcus Boerger wrote:
> Hello Wez,
>
> Sunday, November 30, 2003, 11:01:51 AM, you wrote:
>
> > There is no point moving unmaintained code from ext to pecl;
> > its just a waste of time until we can solve the problem at
> > packaging time, which is why I'm suggesting that one
On Sun, 30 Nov 2003, Markus Fischer wrote:
> On Wed, Nov 19, 2003 at 12:00:30AM +0200, Andi Gutmans wrote :
> > Hey,
> >
> > I added an E_STRICT error level today which purists can use to make sure
> > that there scripts are using the latest and greatest suggested method of
> > coding (according t
Hello Wez,
Sunday, November 30, 2003, 11:01:51 AM, you wrote:
> There is no point moving unmaintained code from ext to pecl;
> its just a waste of time until we can solve the problem at
> packaging time, which is why I'm suggesting that one of the build
> guru's that hates these unmaintained exte
On Wed, Nov 19, 2003 at 12:00:30AM +0200, Andi Gutmans wrote :
> Hey,
>
> I added an E_STRICT error level today which purists can use to make sure
> that there scripts are using the latest and greatest suggested method of
> coding (according to what we decide).
> Ideas are things like:
> a) Not
Hello Ferdinand,
Sunday, November 30, 2003, 10:42:20 AM, you wrote:
> Hello everyone,
> I think we have reached a point where we should really consider a
> naming convention for build-in classes and interfaces. In my opinion,
> popular class names like "exception", "iterator" or "directory" sho
When I throw an exception which is derived from the internal
Exception class and implement __toString but do not return a value,
the reported error (in case I don't catch the exception) is:
Fatal error: Uncaught
thrown in /home/mfischer/htdocs/php5/MySQL.php on line 8
i.e. the
There is no point moving unmaintained code from ext to pecl;
its just a waste of time until we can solve the problem at
packaging time, which is why I'm suggesting that one of the build
guru's that hates these unmaintained extensions *cough* Jani
*cough* should work on the distro building tool whic
> Georg Richter wrote:
> > works fine here [tm]. Tested with both Apache 1 + 2.
>
> Strange. Do you have any idea why it doesn't work here?
If you're using BUILD/compile scripts it should work fine. Tested here with
BUILD/compile-pentium-debug. If you want to use embedded-mysqli you have to
a
Jani Taskinen wrote:
> Perhaps your mysql 4.1 is borked? Dunno as I don't know
> how you build it..if you have shared libs, etc..
Georg just helped me on IRC with this. We'll see if this works when my
laptop has finished its current task ...
--
Sebastian Bergmann
http://sebastian-bergmann.de
I didn't mean they would be totally unaccesible.
Just not supported in the main distribution..
--Jani
On Sun, 30 Nov 2003, Wez Furlong wrote:
>Then why not make a new module called "unsupported" and put them
>in there? PECL is not siberia.
>
>--Wez.
>
>> I think th
Ken,
I don't think those questions are appropriate for 99% of the uses
to which legitimate users will be applying their CVS accounts.
If you don't like the CVS account requests, you can filter them
out of your mail.
Yes, it can be annoying, but its quite simple to ignore them.
--Wez.
> I, like
Then why not make a new module called "unsupported" and put them
in there? PECL is not siberia.
--Wez.
> I think the point in moving them to PECL is to make
> people realize that they are not supported. :)
>
> --Jani
--
PHP Internals - PHP Runtime Development Mailing List
To u
Hello everyone,
I think we have reached a point where we should really consider a
naming convention for build-in classes and interfaces. In my opinion,
popular class names like "exception", "iterator" or "directory" should
be left to user land.
Moreover we should make more use of interfaces for
I think the point in moving them to PECL is to make
people realize that they are not supported. :)
--Jani
p.s. Can someone PLEASE nuke ext/db finally?!
On Sun, 30 Nov 2003, Wez Furlong wrote:
>The point is that there is no need to waste time moving
>things around if there i
On Sun, 30 Nov 2003, Sebastian Bergmann wrote:
>Georg Richter wrote:
>> works fine here [tm]. Tested with both Apache 1 + 2.
>
> Strange. Do you have any idea why it doesn't work here?
Perhaps your mysql 4.1 is borked? Dunno as I don't know
how you build it..if you have shared libs, etc.
The point is that there is no need to waste time moving
things around if there is no build infrastructure in place.
Having these extensions in php-src/ext is no different to
having them in pecl/ except that they currently build under
ext, but would require work to make them build under pecl.
They
Georg Richter wrote:
> works fine here [tm]. Tested with both Apache 1 + 2.
Strange. Do you have any idea why it doesn't work here?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-
Hi,
> Sebastian Bergmann wrote:
> > Building ext/mysql and ext/mysqli together works okay when building
> > only the sapi/cli, but fails when building sapi/apache2handler:
> >
> > http://www.sebastian-bergmann.de/stuff/mysql-mysqli-good.txt
> > http://www.sebastian-bergmann.de/stuff/mysql-mysq
Hello!
Maybe we should move extensions like dbase, ovrimos, ingress_ii, qtdom &
pfpro to PECL before releasing beta 3 ?
Wez said, on IRC, that we need a script to pick out the "golden" extensions
for bundling, but Ilia pointed out that there's nothing golden about a few of
these.
/Magnus
-
Hi Marcus,
On Sat, Nov 29, 2003 at 06:09:36PM +0100, Marcus Boerger wrote :
> Hello Markus,
>
> this works now.
>
> regards
> marcus (the other one)
Thanks, calling parent::__toString() or accessing $this->string
works now. I've found just another scenario which causes
Sebastian Bergmann wrote:
> Building ext/mysql and ext/mysqli together works okay when building
> only the sapi/cli, but fails when building sapi/apache2handler:
>
> http://www.sebastian-bergmann.de/stuff/mysql-mysqli-good.txt
> http://www.sebastian-bergmann.de/stuff/mysql-mysqli-bad.txt
Did
42 matches
Mail list logo
