Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

i - are you getting the same values after 5 reloads? Or any chance you're getting the same value if you're reloading very quickly, at the same second? Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e

Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

At 14:57 29/4/2001, Andi Gutmans wrote: >At 01:55 PM 4/29/2001 +0300, Zeev Suraski wrote: >>At 13:58 29/4/2001, Andi Gutmans wrote: >>>The seed was initialized in MINIT before the children forked. So what >>>happened was that the children started returning the s

Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

here a function which gives us the > pid for both threaded and un-threaded modes? Or do we need to use #ifdef > ZTS and use the tsrm_thread_id() function in threaded mode and getpid() > in non-threaded? I don't think there's such a function right now... Zeev -- PHP Devel

Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

So it's probably not a lot more random than it was before... Zeev At 15:44 29/4/2001, Andi Gutmans wrote: >At 02:35 PM 4/29/2001 +0300, Zeev Suraski wrote: >>At 15:27 29/4/2001, Andi Gutmans wrote: >>>Jani has already moved it to RINIT which is a good beginning. >>

Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

Since it only occurs on the first time, chances are that (on a reasonably loaded web site), most rinits will happen at the same second. Zeev At 15:54 29/4/2001, Andi Gutmans wrote: >At 02:50 PM 4/29/2001 +0300, Zeev Suraski wrote: >>So it's probably not a lot more random than

Re: [PHP-DEV] key_exists from php

Why would you care if a key exists and is null? In general the behavior is so close to isset() that it's annoying to have to introduce a whole new function just for this difference. Zeev At 04:50 30/4/2001, David Croft wrote: >There doesn't seem to be any way for a php script

Re: [PHP-DEV] key_exists from php

Why? It's only interesting if you're trying to understand the table schema from one of the arrays. The right way to do it (IMHO) would be by querying the result using the field fetching functions... Zeev At 13:12 30/4/2001, David Croft wrote: >mysql_fetch_array (and probably o

RE: [PHP-DEV] php.ini location

> > > > > > > Phew. > > :> > > > > Mike Robinson > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] >

[PHP-DEV] PHP 4.0.5 is out

the PHP QA team, which worked a lot to make sure that this release works as well as expected, and beyond. Special thanks to Mr. J, which managed to survive the long and thrilling QA process without getting a heart attack :) Zeev 30 Apr 2001, Version 4.0.5 - IMPORTANT: removed /F modifier han

Re: [PHP-DEV] PHP Conference

It wasn't official... I guess it should change to the first official PHP conference. Zeev At 08:10 2/5/2001, Sebastian Bergmann wrote: > Hi there, > > I just read the following on php.net: > > "[1-May-2001] The first ever PHP Conference, part of the O'Re

Re: [PHP-DEV] PHP Conference

Officially announced by the PHP Group and on www.php.net. It doesn't make much of a difference. Zeev At 15:49 2/5/2001, Hartmut Holzgraefe wrote: >Zeev Suraski wrote: > > > > It wasn't official... I guess it should change to the first official PHP > > c

Re: [PHP-DEV] Re: [PHP-QA] 4.0.6

>and i would suggest to announce the RCs not only here but on php.net >and freshmeat.net as well I don't think that's a good idea, because then people will treat them as releases. I think that the way things are currently, plus the natural growth of the QA team, are the right way to

Re: [PHP-DEV] Re: [PHP-QA] 4.0.6

d most of the bugs which aren't found can only be found in wide scale testing, but I don't think that announcing RCs in prominent places is the way to go. Perhaps we should announce the QA team again, so that people who would join but don't know about it would get a chance. Zeev

Re: [PHP-DEV] Re: [PHP-QA] 4.0.6

I don't see any unusual peak now; We have tons of bug reports all the time. IMHO our problem is no longer lack of QA, but lack of developer resources to fix bugs. I truly think that making RCs effective releases gains nothing. If everyone else thinks differently, so be it. Zeev At 16

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6

We're going to have a Windows build machine at Zend, that will have automated builds (it's actually quite around the corner now). Once it's ready, we're going to have daily snapshots as well as RC builds all the time. Zeev At 16:51 2/5/2001, Jani Taskinen wrote: >O

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)

Experience IRCG > http://schumann.cx/http://schumann.cx/ircg > > > >-- >PHP Quality Assurance Mailing List <http://www.php.net/> >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To conta

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6

their job to deliver these? >IMO we should be providing them. Or is setting up some Windows machine >to build them so hard? (I don't know shit about compiling on Windows :) Well, that's just the way things usually work; If you can donate something, you do it... Zeev -- PHP Develop

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)

At 17:29 2/5/2001, Sascha Schumann wrote: >On Wed, 2 May 2001, Zeev Suraski wrote: > > > The question is, if you think people will actually download the RC in order > > to test it (as opposed to using it) - why won't they join the QA team? > > Their job des

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)

Okay guys, do whatever you want. Most people seem to agree with you. Zeev At 17:42 2/5/2001, Andi Gutmans wrote: >At 05:34 PM 5/2/2001 +0300, Zeev Suraski wrote: > >>I don't seem to recall Linux publishing far-reaching announcements about >>-pre versions. If you walked

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6

At 22:38 2/5/2001, Andi Gutmans wrote: >How about we stop this thread and invest all of this time in going over >the bugs database and fixing bugs? :) I'll drink to that :) -- PHP Development Mailing List To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6

think that a random group of a few thousand users is a good idea to start with. Zeev At 21:36 2/5/2001, Hartmut Holzgraefe wrote: >James Moore wrote: > > > If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is > > released (remeber PHP users are incapable of re

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6

At 22:52 2/5/2001, Daniel Beulshausen wrote: >At 22:46 02.05.2001 +0300, Zeev Suraski wrote: >>I think very much like James, that we're trying to fix something that >>wasn't broken. Ten RC's and twenty PRC's won't have done anything, if >>betwe

Re: [PHP-DEV] 4.0.6

At 23:06 2/5/2001, Troels Arvin wrote: >Note that there was no such problem with PHP 4.0.4pl1 and earlier. That's very odd, as PHP never considered \r alone to be a linefeed... Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL

Re: [PHP-DEV] api question

That's because of an internal small-scale garbage collection mechanism in Zend. Objects may not be freed as soon as they're no longer linked, but may be freed shortly afterwards. Zeev At 01:16 3/5/2001, Harald Radi wrote: >when i register a destructor with zend_register_list_d

[PHP-DEV] Re: [PHP-QA] Re: 4.0.6

ot laws, and we should work to improve those guidelines as we gather experience. I still think that the FastCGI thingy was fine, by the way. It's modifying existing code in the last minute that causes trouble. Zeev At 04:54 3/5/2001, Jani Taskinen wrote: >On Wed, 2 May 2001, Steve Langasek

Re: [PHP-DEV] Re: [PHP-QA] Re: 4.0.6

At 12:12 3/5/2001, Jani Taskinen wrote: >On Thu, 3 May 2001, Zeev Suraski wrote: > > >And you expect us to give you that power? :) > >Did I suggest that? I didn't. I was referring only to >the rest of that piece of text, not the part about 'giving power'. &

[PHP-DEV] Release process

here IMHO, comments welcome... Those were the two main broken things about the last release. Let's concentrate on fixing them instead of rethinking the whole architecture, because it *worked*. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL

Re: [PHP-DEV] Release process

What's the status of the show stoppers list James put up? We should fix as many bugs as we can (at least those which are planned to be fixed in 4.0.6) before branching, to avoid having to synchronize two branches for every bug fix. Zeev At 13:04 3/5/2001, Andi Gutmans wrote: >At 05

[PHP-DEV] Re: [PHP-QA] Re: 4.0.6

At 13:47 3/5/2001, Cynic wrote: >Zeev, > >do you think ASF is a Nazi-like group? I don't think so. >Nor do I witness endless discussions caused by the fact that >the Apache release cycle is far (in a galaxy far, far away.. :) >stricter than the PHP one. I was talking ab

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

At 13:27 3/5/2001, Jani Taskinen wrote: >I just want to remind everyone that the 4.0.6 is suppose to have mainly >bug fixes..or wasn't this agreed on yet? Yes it was. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For ad

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

these constructs can be used to figure out whether an element exists and is null. Whether or not this should be detectable is a different issue... Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

there are. I'd like to change it back... Zeev At 16:53 3/5/2001, Andrei Zmievski wrote: >On Thu, 03 May 2001, Andi Gutmans wrote: > > Yeah but I'm afraid it'll make scripts be written on behavior which > > shouldn't be counted on. > > Maybe in future versions

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

sing. > >Yeah but you can use === NULL for those. >You might be right but I remember we decided it's problematic. Not really, === NULL will return true for both a non existant value and a NULL value. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-m

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

#x27;s behavior in a way that may change in the future (implementation dependent). Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

No plans to do anything at this point. You can keep all your hairs in tact :) Zeev At 17:42 3/5/2001, Jani Taskinen wrote: >On Thu, 3 May 2001, Zeev Suraski wrote: > > >At 17:20 3/5/2001, Cynic wrote: > >>I very much agree with Andrei on this. Please, keep the >

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

function is_null() are both functions that duplicate language-level functionality, and shouldn't exist IMHO. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list adm

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

At 18:25 3/5/2001, Andrei Zmievski wrote: >On Thu, 03 May 2001, Zeev Suraski wrote: > > Sure. I just did. :) > > > > Adding an isnull() language construct may be the right way to solve this > > situation; key_exists() and the today's function is_null() are b

[PHP-DEV] Classes & function names

as a non-default option. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Classes & function names

Let's not worry about the versions right now; I'm mostly interested in getting feedback about the concept itself. Zeev At 14:30 4/5/2001, Stig Sæther Bakken wrote: >[Zeev Suraski <[EMAIL PROTECTED]>] > > I think that there are two ways to look at the issue that John

Re: [PHP-DEV] Classes & function names

At 15:34 4/5/2001, Edin Kadribasic wrote: >I agree on this one too. What about writing a migration tool that can "fix" >the existing code automagically? It'll be possible. Let's take it one step at a time though... Zeev -- PHP Development Mailing List <http://ww

RE: [PHP-DEV] Classes & function names

At 15:32 4/5/2001, John Parker wrote: >Hmm... hope Sterling's work on ADT (sweet, sweet ADT, drool, etc.) isn't >delayed due to this. (Doubt it would be, but you never know.) ADT? (I know what it means, but not in the context of PHP) Zeev -- PHP Development Mailing List <

RE: [PHP-DEV] Classes & function names - ADT

Ah; I'd imagine it'll be implemented as an extension module and not on the language level, so it shouldn't be related in any way. Zeev At 15:56 4/5/2001, John Parker wrote: > > >Hmm... hope Sterling's work on ADT (sweet, sweet ADT, drool, etc.) isn't > &g

Re: [PHP-DEV] Classes & function names

n be avoided altogether if case sensitivity is enabled. Zeev At 16:41 4/5/2001, Sebastian Bergmann wrote: >Zeev Suraski wrote: > > It would also improve performance fairly significantly. > > Just curious, since I don't know the 'inner magic' of the ZendEngine: >W

Re: [PHP-DEV] Classes & function names

At 16:45 4/5/2001, Wez Furlong wrote: >Stig suggested making it case-insensitive by default until 4.2; I think >that has a higher WTF factor than making it case sensitive in 4.1 I truly suggest to keep the version number issue to some other time... Zeev -- PHP Development Mailing List

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

ll value, or is undefined completely. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

e future versions of PHP. Zeev At 18:04 4/5/2001, Colin Viebrock wrote: > > I don't think it is trivial to implement this without: > > a) Creating a second version of our hash tables (I don't like duplicate >code). > > b) Adding more complexity to the already com

Re: [PHP-DEV] Zend API changes

It's in everyone's interest to keep the API intact. The Zend API is now fairly stable (I don't expect compatibility breaking changes in the 4.0 line); Judging from the experience of PHP 3.0, there too, the API stabilized around x.0.5. Zeev At 18:29 4/5/2001, Brian Foddy

Re: [PHP-DEV] Zend API changes

Hope is always a good thing :) There's a good starting point already, people are more than welcome to extend it. Zeev At 19:30 4/5/2001, Hartmut Holzgraefe wrote: >Zeev Suraski wrote: > > > > It's in everyone's interest to keep the API intact. The Zend API is

Re: [PHP-DEV] erealloc and the API

sn't crash you, a leak :) Zeev At 19:49 4/5/2001, Johan Ekenberg wrote: >I have a question regarding the API, something that bit me while I was >working with the php_imap code: > >Basically I did this (pseudocode): > >char init_value[10] = "foobar"; > >

Re: SV: [PHP-DEV] erealloc and the API

At 20:32 4/5/2001, Johan Ekenberg wrote: >Zeev, > >thanks, that made all the difference! > >I got a suggestion from another PHP-developer that mixing calls to >emalloc() and strcpy() might be a problem. Is this so? Not it's not; A block you get from emalloc() is very mu

Re: [PHP-DEV] Zend API changes

At 20:20 4/5/2001, Björn Schotte wrote: >* Zeev Suraski wrote: > > There's a good starting point already, people are more than welcome to > > extend it. > >I don't understand why people should work in their spare-time >on a tool which is published under the Zend

Re: [PHP-DEV] Zend API changes

dy else does it, it'll simply remain undone. >- afair there was someone who started to write a 'extension >building manual' or something about a year ago and it was you >, Zeev, who told him that this was useless effort as this was >already beeing taken care o

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

We're way too far away from this to even discuss it. Zeev At 22:51 4/5/2001, Wez Furlong wrote: >"Sterling Hughes" <[EMAIL PROTECTED]> wrote: > > On Fri, 4 May 2001, Chuck Hagenbuch wrote: > > > That's a problem with it being an option, yes. I'd v

Re: [PHP-DEV] Zend API changes

You can always suggest... :) At 02:14 5/5/2001, Billy Rose wrote: >The company I work for has a very quick bug turn over rate. I was wondering >if I may make a few suggestions concerning release issues / bugtracking? > >- Original Message ----- >From: "Zeev Suraski"

Re: [PHP-DEV] __FILE__ constant

I'm unable to reproduce it with the current CVS, btw. Zeev At 17:32 5/5/2001, Andi Gutmans wrote: >By the way, can you open a bug report about this? Please include PHP >version, Web server setup and short reproducing script. >At the same time if one of you guys can get an idea w

Re: [PHP-DEV] __FILE__ constant

gy >http://www.csh.rit.edu/~jon/ : Computer Science House Member > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To contact the list administrators, e-mail: [EMAIL PR

Re: [PHP-DEV] Zend API changes

somewhere? CVS maybe? Yep, sure thing; cvs.zend.com, co ZendAPI; Released under OPL, and written in the same formats everyone in here's used to work with :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,

Re: [PHP-DEV] Generating code on fly

This is not the right forum to ask this type of questions - it's for people who develop PHP, not (necessarily) people who develop with PHP. The right forum to ask this question would be [EMAIL PROTECTED] In order to cut down time, look at http://www.php.net/eval Zeev At 12:23 6/5

RE: [PHP-DEV] Zend API changes

ect to me splitting >it up into more manageable chunks like we do with phpdoc etc? Nope - go ahead! Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: AW: [PHP-DEV] Zend API changes

At 16:32 6/5/2001, Harald Radi wrote: > > -Ursprüngliche Nachricht- > > Von: Zeev Suraski [mailto:[EMAIL PROTECTED]] > > Gesendet: Sonntag, 06. Mai 2001 10:49 > > An: Stig Sæther Bakken > > Cc: Hartmut Holzgraefe; [EMAIL PROTECTED] > > Bet

Re: [PHP-DEV] default location of php.ini changed?

An install of a snapshot from this morning puts the >default location as /usr/local/etc > >Was this intended? No it wasn't; Guys, wasn't this changed back? Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additio

[PHP-DEV] Removing 4.0.6 branch; Rebranch target: Thursday

As the subject suggests, because of the large amount of bug fixes that flowed and are still flowing in, we're canceling the 4.0.6 branch for now. The new target day is (this) Thursday, so do your best to submit all bug fixes by then. Thanks, Zeev -- PHP Development Mailing List

Re: [PHP-DEV] default location of php.ini changed?

>spending most of my spare time transforming the "jungle" outside my >house to something more lawn-ish these days. :-) Ok :) We need to be well aware of this though, to make sure it doesn't stay that way in 4.0.6. The feedback will be merciless :) Zeev -- PHP Development Maili

[PHP-DEV] Re: mysql and unbuffered queries

case of defining the constants and passing it to the >"do_query_general" function, right? Probably... Are you sure you can't use mysql_unbuffered_query(), though? If you're really used to supplying the database argument, you can easily write a 2 line PHP function that does th

Re: [PHP-DEV] Re: mysql and unbuffered queries

enerally better, especially with complex/large queries. You get the first row as soon as it's available, instead of having to wait for the MySQL server to find all of the rows. Zeev At 11:45 7/5/2001, Jani Taskinen wrote: >On Mon, 7 May 2001, Zeev Suraski wrote: > > >At 0

Re: [PHP-DEV] Re: mysql and unbuffered queries

advantages: - In smaller queries (that is, smaller result sets), mysql_query() is probably considerably faster - You can't use mysql_num_rows() on an unbuffered query result Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additio

Re: [PHP-DEV] Re: mysql and unbuffered queries

; > You didn't say anything about any disadvantages on using it. :) > >The disadvantage is that you have to retrieve all the rows before you can >issue further SQL on that connection. > >It can be a real pain. Zeev, Does the extension take care of this case, or >does it

Re: [PHP-DEV] Re: mysql and unbuffered queries

At 12:23 7/5/2001, Wez Furlong wrote: >On 2001-05-07 00:26:02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote: > > At 02:16 7/5/2001, Wez Furlong wrote: > > >Should I create a patch that enables the parameter? > > Probably... Are you sure you can't use mys

Re: [PHP-DEV] Zend API changes

You should be using ZEND_EXTENSION_API_NO, it's an integer. Zeev At 23:32 8/5/2001, Dan Libby wrote: >ok, so ZEND_VERSION_DOUBLE is crazy talk. the preprocessor doesn't like floats >either. But something like ZEND_VERSION_MAJOR 4, ZEND_VERSION_MINOR 6 would >satisfy it. >

[PHP-DEV] Daily PHP snapshots for Win32

I finally got around to set up the automatic Win32 snapshots. You can find it at http://www.zend.com/snapshots/ Right now it only builds the main DLL, and the CGI and ISAPI SAPI modules; We'll add more SAPI modules and extension modules as soon as we get some free time. Zeev --

Re: AW: [PHP-DEV] 4.1 & Declaration Case Persistance

At 06:46 10/5/2001, Harald Radi wrote: >looking forward to getting php case sensitive i'm just wondering that >function names are exported mixed case in the com extension. >e.g. there's a COM_load() and a com_set(), is there a special reason for >this (zeev) ? There's

Re: [PHP-DEV] unbuffered mysql_db_query for 4.0.6?

people, there are millions of users out there who don't appreciate us at all for every downwards-compatibility break that we make, and for a good reason. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-

Re: [PHP-DEV] unbuffered mysql_db_query for 4.0.6?

At 14:39 10/5/2001, Jani Taskinen wrote: >On Thu, 10 May 2001, Zeev Suraski wrote: > > >What does that mean that it takes 'too long', though. Too long for > >what? I don't see any strong reason to nuke it at all, definitely not in > >the near future. &g

Re: [PHP-DEV] multiselects and arrays

Why does it make more sense? Is there any advantage in using this over using foo[]? By changing this behavior, we're actually losing functionality, not adding any. Zeev At 18:53 10/5/2001, Adam Wright wrote: >Just from my point of view, I've got a lot of legacy code that relies

Re: [PHP-DEV] multiselects and arrays

At 19:20 10/5/2001, Andrei Zmievski wrote: >On Thu, 10 May 2001, Zeev Suraski wrote: > > Why does it make more sense? Is there any advantage in using this over > > using foo[]? By changing this behavior, we're actually losing > > functionality, not adding any. > &g

[PHP-DEV] stat/fstat

[5] => 513 [6] => 11065 [7] => 1024 [8] => 989532201 [9] => 989532201 [10] => 989532201 [11] => 4096 [12] => 2 ) Is there any reason for this? If not, I'd like to add meaningful names as well (I guess it's way too late to re

Re: [PHP-DEV] stat/fstat

hat gives? At 01:07 11/5/2001, Zeev Suraski wrote: >Hey, > >I just got around to writing a PHP script that uses stat(), and was quite >surprised to find that instead of using string indices, it uses >hardcoded/obscure numeric indices, e.g.: > >Array >( > [0]

Re: [PHP-DEV] stat/fstat

At 12:18 11/5/2001, Stig Sæther Bakken wrote: >[Zeev Suraski <[EMAIL PROTECTED]>] > > Hey, > > > > I just got around to writing a PHP script that uses stat(), and was > > quite surprised to find that instead of using string indices, it uses > >

Re: [PHP-DEV] Is this still true?

List <http://www.php.net/> >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski <[EMAIL PROTECTED]> CTO & co-founder, Zend Technologies Ltd. h

Re: [PHP-DEV] stat/fstat

At 18:21 11/5/2001, Brian Foddy wrote: >[EMAIL PROTECTED] wrote: > > > > On 11 May 2001, Stig Sæther Bakken wrote: > > > > > Why not have both numerical and descriptive indices? Backwards > > > compatible, slightly bloatish, but not really a problem. > > > > it's already implemented this way now

Re: [PHP-DEV] stat/fstat

l)+sizeof(zend_mem_header)), and possibly slightly more, actually :) Next thing you know you'd run out of memory just because of this. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTE

Re: [PHP-DEV] stat/fstat

zend_mem_header).+whatever of memory : ) > >-Jason > >- Original Message - >From: "Zeev Suraski" <[EMAIL PROTECTED]> >To: "Andrei Zmievski" <[EMAIL PROTECTED]> >Cc: "Jason Greene" <[EMAIL PROTECTED]>; "Jason Greene" <[

Re: [PHP-DEV] zval_copy_ctor

urn void but I'd have to go back in time and think why it was done the >way it was :) It can't really fail today, other than failing for out-of-memory, in which we bail straight out... Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EM

Re: [PHP-DEV] Fork() in php?

the child, otherwise you'd get zombie processes... Generally, implementing that sort of stuff within the Apache framework is a bit of asking for trouble :I Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-ma

Re: [PHP-DEV] unix install paths changed

. I wouldn't do that on a 0.0.1 change... Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] unix install paths changed

php.ini mainly, as it will affect each and every installation. The others may also make more sense to wait for 4.1, even though they'll affect less people. Zeev At 10:09 22/4/2001, Stig Sæther Bakken wrote: >[Zeev Suraski <[EMAIL PROTECTED]>] > > At 04:25 22/4/2001, Stig

Re: AW: [PHP-DEV] arrays

Why do you need it? Nobody ever needed it until now. It'll slightly slow down each and every hash update all over PHP, so unless it's really necessary, we should do without it... Zeev At 19:40 13/5/2001, Harald Radi wrote: >thanks, but wouldn't it desireable to hav

Re: [PHP-DEV] efree() and NULL

in a way that already takes this assumption. I think that efree() crashing on NULL pointers actually helps weed out bugs (bugs that could go unnoticed because they'd have no symptoms if it silently ignores NULLs). Zeev -- PHP Development Mailing List <http://www.php.net/> To un

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

r sites are compatible with it, and turn this mode on. The only drawback I see to this approach is that the code itself remains and 'bloats' the various files. We can probably overcome this problem by separating legacy code to separate files. Zeev At 22:28 14/5/2001, Sterling Hug

Re: AW: AW: [PHP-DEV] arrays

Ok, if we humor ourselves with this feature... What kind of behavior would you expect if a key gets deleted, and there are no longer associative members in the array? Zeev At 02:42 15/5/2001, Harald Radi wrote: > > Any XML-RPC implementation would benefit from seeing easily whe

Re: AW: AW: [PHP-DEV] arrays

It doesn't necessarily mean having to scrap the whole idea, just that we'd actually have to count elements, instead of just flagging. I'll try to think if there are any problems with this approach. Zeev At 02:57 15/5/2001, Andrei Zmievski wrote: >At 02:51 AM 5/15/01 +0300,

[PHP-DEV] Re: HTTP Server Development Questions

Your best approach would be looking at one of the other Web server modules, which can be found under the sapi/ directory in the PHP 4.0 distribution. All you need to do in order to support your Web server is implement a SAPI module for it. Zeev At 11:38 15/5/2001, Thomas Storey wrote: >

Re: [PHP-DEV] disktotalspace()

I'm pretty sure we're already incompatible with Windows 95, so I'm not sure we should go through those hoops - we can just call the function directly... Zeev At 05:57 15/5/2001, Jon Parise wrote: >Does anyone object to my adding a new function disktotalspace()? > >A f

Re: [PHP-DEV] disktotalspace()

At 01:35 16/5/2001, Jon Parise wrote: >On Tue, May 15, 2001 at 10:43:25PM +0300, Zeev Suraski wrote: > > > >Does anyone object to my adding a new function disktotalspace()? > > > > > >A friend of mine ran into a situation where he required an > > >OS-inde

Re: [PHP-DEV] disktotalspace()

hat much of an issue. We've had a huge thread about this, we did decide to try and stick with the standard... Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] disktotalspace()

t I understood, going in that direction was the general idea. Slowly, but surely :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] removing ereg functions

ue out there. :) No way. ereg() has got to be used by millions of code lines around the world. I don't see it being removed in this millennium. These functions can fit nicely into the lean-and-mean approach. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

the added bloat. If kept closely documented, people who care enough >>about the bloat will be able to go through the checklist, make sure their >>sites are compatible with it, and turn this mode on. > >well, you can't have your cake and eat it too. No need to get in

Re: AW: AW: [PHP-DEV] arrays

At 13:34 16/5/2001, Stig Sæther Bakken wrote: >Acknowledged. But IMO the arrays will be either clearly continous or >clearly associative/non-continous in 99.2% of the cases (Zeev >statistics applied). I never claim to be accurate, I usually say 99% :) > I think it's fine to

Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()

At 14:06 16/5/2001, Jani Taskinen wrote: >On Wed, 16 May 2001, Zeev Suraski wrote: > > >Also bare in mind that a very large percentage of the developers don't > >*want* to be forced to change their code, and consider it to be a > >Who's forcing anybody to update

<    1   2   3   4   5   6   7   8   9   10   >