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
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 a
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,
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
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:
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..
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 is
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
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
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
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
add
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
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 should
be
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 using
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
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 to what we
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 of the
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 solve the problem
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
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,
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 phpize or
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 broke 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 install
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
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
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
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 do
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.
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
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 work in
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 passing
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
think
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 required by newer
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 parameter
34 matches
Mail list logo
