> >I would think that sticking with the current ini files would
> probably lead
> >to less confusion.
>
> I second that...
Just a quick note here - if this code gets taken on board,
ext/standard/config.w32 and win32/php5dllts.dsp will need to be updated with
the relevant src files too.
- Steph
I like the new $obj instanceof ClassName way of checking class /
interface types, but this method does have one major drawback
compared to the old is_a() approach:
The class must be loaded in order to perform an instanceof check!
Apparently is_a() has also been deprecated, so that an E_
Which generic sort function? They all use the same sorting code as far
as I can tell.
John
On Tue, 2004-08-10 at 15:59, Rasmus Lerdorf wrote:
> On Tue, 10 Aug 2004, Sterling Hughes wrote:
> > i don't think sort() should be changed - this is how php works, for
> > better or sometimes worse, changi
no argument there, having a few more reasonable sort options/methods
makes sense to me, so long as they offer new functionality (as opposed
to fixing an "inconsistency") and don't affect the default
behaviour...
-sterling
On Tue, 10 Aug 2004 12:59:09 -0700 (PDT), Rasmus Lerdorf <[EMAIL PROTECTED]
On Tue, 10 Aug 2004, Andi Gutmans wrote:
> I think my explanation explains the problem and why I don't think it should
> be fixed.
> I agree with Sterling on this one.
I concur too.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
Marcus Boerger wrote:
Hello Andrey,
Can you take a look also at http://bugs.php.net/bug.php?id=29421
We don't affect those. We simply correct the sorting to something
understandable when it comes to edge cases with zero. We don't touch
any other automatic typeconversion related behavior as mention
On Tue, 10 Aug 2004, Sterling Hughes wrote:
> i don't think sort() should be changed - this is how php works, for
> better or sometimes worse, changing it any other way would break BC,
> and it doesn't make much sense.
I agree that we should keep the generic sort function the same. Might be
nice
At 09:32 PM 8/10/2004 +0200, Marcus Boerger wrote:
Hello Sterling,
Tuesday, August 10, 2004, 9:19:33 PM, you wrote:
> i don't think sort() should be changed - this is how php works, for
> better or sometimes worse, changing it any other way would break BC,
> and it doesn't make much sense.
Yep, mea
Hello Sterling,
Tuesday, August 10, 2004, 9:19:33 PM, you wrote:
> i don't think sort() should be changed - this is how php works, for
> better or sometimes worse, changing it any other way would break BC,
> and it doesn't make much sense.
Yep, meanwhile i think that if at all we could privide a
I didn't realize that completely inconsistent behavior was no longer
considered a bug, and this edge case is certainly inconsistent with the
behavior of any other set of values sorted. Using the BC reasoning when
something is broken (i.e. it's not a bug, its a "feature") makes even
less sense.
Joh
i don't think sort() should be changed - this is how php works, for
better or sometimes worse, changing it any other way would break BC,
and it doesn't make much sense.
-Sterling
On Fri, 30 Jul 2004 15:39:19 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> How would you expect the sort function t
Andi Gutmans wrote:
I'd like to roll it today but haven't heard feedback from people about
successful installation.
Anyone installed it?
Just tried out the Win32 zip. All my tests pass without a problem, so
I'll put it up on the demo server and see what happens :)
--
Lester Caine
---
Hello Andrey,
Friday, July 30, 2004, 11:30:18 AM, you wrote:
> Andi Gutmans wrote:
>> I talked to John about this yesterday. I'll take a closer look at this
>> within the coming days to see if this makes sense and how it affects BC
>> in general (if at all).
>>
> Can you take a look also at ht
On Tue, 10 Aug 2004, Andi Gutmans wrote:
> I'd like to roll it today but haven't heard feedback from people about
> successful installation.
> Anyone installed it?
Nope, I'd suggest to release on Thursday (like we often do :)
I'll install it now and see if it compiles.
Derick
--
PHP Internals
Hello Andi,
Tuesday, August 10, 2004, 8:07:51 PM, you wrote:
> I'd like to roll it today but haven't heard feedback from people about
> successful installation.
> Anyone installed it?
=
CWD : /usr/src/PHP_5_0
PHP
I'd like to roll it today but haven't heard feedback from people about
successful installation.
Anyone installed it?
Andi
At 06:58 PM 8/10/2004 +0200, Romain Bourdon wrote:
Hi,
sorry to ask this question but
do you think that PHP 5.0.1 will be out soon?
not that I'm that impatient but the http a
At 07:10 10/08/2004, Jay Smith wrote:
Ilia Alshanetsky wrote:
> While anything would be better then the current solution I wonder is
> perhaps going the INI way is not the best idea due to the potential
> confusion. The fellow who supplies the ini files with browser information
> also has a csv fil
Thanks for your answer Wez.
Romain
"Wez Furlong" <[EMAIL PROTECTED]> a écrit dans le message de
news:[EMAIL PROTECTED]
> Stable snapshots == released version + bug fixes.
> There is no reason why you wouldn't want to run one if you are running
> with a buggy 5.0.0 release, especially if you are c
Stable snapshots == released version + bug fixes.
There is no reason why you wouldn't want to run one if you are running
with a buggy 5.0.0 release, especially if you are complaining about a
bug known to be fixed there.
Having said that, 5.0.1 is due any day now.
--Wez.
On Tue, 10 Aug 2004 18:58
Hi,
sorry to ask this question but
do you think that PHP 5.0.1 will be out soon?
not that I'm that impatient but the http authentication bug is really
anoying and I'd prefer not to pack a WAMP5 release with a snapshot...
Thanks
Romain
--
PHP Internals - PHP Runtime Development Mailing List
To
On Tue, 10 Aug 2004 10:32:58 -0400, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Wez Furlong <[EMAIL PROTECTED]> writes:
>
> > I would say don't bother as its something I have planned for PDO.
> > But that's just me ;-)
>
> Sorry, TLA knowledge problem here. What's "PDO"?
>
Hi Derrell,
PDO
Wez Furlong <[EMAIL PROTECTED]> writes:
> I won't commit to a definite time, but keep in mind that the current sqlite
> only took me around 2 hours to code from scratch (plus various refinements
> since then); this is the kind of thing that will pop into existence real soon
> now when I get a spar
I won't commit to a definite time, but keep in mind that the current
sqlite only took me around 2 hours to code from scratch (plus various
refinements since then); this is the kind of thing that will pop into
existence real soon now when I get a spare couple of hours, and some
writing deadline
[EMAIL PROTECTED] writes:
> Wez Furlong <[EMAIL PROTECTED]> writes:
>
>> I would say don't bother as its something I have planned for PDO.
>> But that's just me ;-)
>
> Sorry, TLA knowledge problem here. What's "PDO"?
Ok, now I know what PDO is. Wez, what do you anticipate as a completion
sched
Wez Furlong <[EMAIL PROTECTED]> writes:
> I would say don't bother as its something I have planned for PDO.
> But that's just me ;-)
Sorry, TLA knowledge problem here. What's "PDO"?
Derrell
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub
I would say don't bother as its something I have planned for PDO.
But that's just me ;-)
--Wez.
[EMAIL PROTECTED] wrote:
I'm considering implementing sqlite3 bindings in PHP, but before I undertake
that project, is anyone else already working on it?
Derrell
--
PHP Internals - PHP Runtime Developmen
Ilia Alshanetsky wrote:
> While anything would be better then the current solution I wonder is
> perhaps going the INI way is not the best idea due to the potential
> confusion. The fellow who supplies the ini files with browser information
> also has a csv file with the very same data that is muc
I'm considering implementing sqlite3 bindings in PHP, but before I undertake
that project, is anyone else already working on it?
Derrell
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Wow, these files look really nice. Good job.
> Thanks,
> Andi
Thanks, Andi!
>From now, we will generate these files automatically from the manual, so
that they can be always up-to-date.
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
Also commited to HEAD. Should I commit to PHP_4_3 too? It looks as if these
instructions are for both 4.3.x and 5.0.x
Yes, I skimmed over the Unix instructions and they appear to be solid.
Probably a good idea to be consistent and have the same instuctions in
both trees.
Since these were generated
> Edin, can you roll a Win32 package (tag php_5_0_1RC1)?
http://snaps.php.net/~edink/
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10.8.2004 9:52 Uhr, Andi Gutmans wrote:
I was hoping to release it tomorrow but if you can fix this in a
reasonable time frame I can wait.
Yep. Fixed and committed.
chregu
In any case, we should go live in the
near future unless new bugs are found which didn't exist in 5.0.0.
Anyway, 5.0.1RC
On Mon, Aug 09, 2004 at 09:46:21AM +0200, Edin Kadribasic wrote:
> On Monday 09 August 2004 09:00, Derick Rethans wrote:
> > On Sat, 7 Aug 2004, Joe Orton wrote:
> > > That would mean adding exactly the reverse set of #defines to allow the
> > > the GD extension to be built against an external copy
I was hoping to release it tomorrow but if you can fix this in a reasonable
time frame I can wait. In any case, we should go live in the near future
unless new bugs are found which didn't exist in 5.0.0.
Anyway, 5.0.1RC1 is up at http://snaps.php.net/~andi. Please check it out
and make sure it w
On 7.8.2004 2:50 Uhr, Andi Gutmans wrote:
Just a heads-up. I haven't rolled 5.0.1 yet because I haven't heard back
from Dmitry about the SOAP bugs yet. I'll ping him again...
We currently have a segfault in the xsl extension, when there's an error
in the XSLT file. It doesn't disturb the day-to-
If that's the case (actually, if it's the case for Linux which I personally
only care about), then I guess I won't miss it :) I was thinking maybe a
stream_socket_set_option() would be nice, but I personally only used it to
for SO_REUSEADDR, which seems to be default behaviour for a socket stream
n
Yep. It was decided not to go down that route. You should have a good
enough handle of your application to know where you are referencing global
objects from (local ones are destroyed once a function is terminated).
If you don't, well, maybe try and improve the code which deals with global
objec
IIRC, quite a few OSs also ignore whatever you pass to listen()
At 08:19 AM 8/9/2004 +0100, Wez Furlong wrote:
The listen(2) backlog? It defaults to 5, and there is no way to alter
this, yet.
Exposing more lower level features is a TODO item; you're welcome to
suggest which ones you need.
--Wez.
O
38 matches
Mail list logo
