At 18:07 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
BTW, there's no good reason not to load all of the extensions you may need
in all of your scripts from php.ini. Loading many extensions doesn't pose
a significant/noticeable load. Loading using dl() does
more sound and stable :) Using php.ini for loading
extensions should be the way to go.
Zeev
At 18:18 06/08/2001, Stig Sæther Bakken wrote:
[Zeev Suraski [EMAIL PROTECTED]]
Please don't just say it's useful, please say why :)
dl() has absolutely nothing over loading in php.ini, and has many
It's not a big deal and we can commit it (as it's done in the
'put-expensive-operations-here' part of PHP, the module-init, hint hint :).
However, is it really necessary?
Zeev
At 05:53 06/08/2001, Sterling Hughes wrote:
Hey,
The attached patch adds support for passing a variable
At 06:30 06/08/2001, Sterling Hughes wrote:
On Mon, 6 Aug 2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
How so? I can understand that people get used to it, but it's really
bad. extensions should be loaded in the php.ini file. There's really no
good reason
empty. As a general rule, it's a bad thing, since it repeats things which
don't have to be repeated.
At 18:34 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
Drawbacks:
- It's slow. We encourage putting expensive operations into the
module_init, using dl
At 19:29 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
By the way, I can't really quantify significantly, as it depends on what
kind of minit you have. For a module such as the COM module, it can
double
the amount of time it takes the script to run (if you
At 07:10 06/08/2001, Sterling Hughes wrote:
What if you use 50 different shared extensions, for different
scripts on the same box? Should you load them all in each time?
I don't think so...
Other than your phobia, there's no real reason not to do it :)
Zeev
--
PHP Development
At 19:40 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
At 07:10 06/08/2001, Sterling Hughes wrote:
What if you use 50 different shared extensions, for different
scripts on the same box? Should you load them all in each time?
I don't think so
At 19:45 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
Nothing measurable. That was actually measured (changing PHP to
initialize
extensions just-in-time, in case they're actually being used) - and it
turned out it wasn't giving any noticeable performance
On Mon, 6 Aug 2001, Sterling Hughes wrote:
On Mon, 6 Aug 2001, Zeev Suraski wrote:
At 19:40 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
At 07:10 06/08/2001, Sterling Hughes wrote:
What if you use 50 different shared extensions, for different
On Mon, 6 Aug 2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
I think the disk weights about the same regardless of the data inside it
:)
Yes, but 50 extensions will consume more memory than 1.
Nothing noticable, really. Unless you allocate dozens of megabytes
. For
example, an extension to access a scanner. You don't want this loaded
everywhere, just in your scanner application, and certainly not in your
webserver.
You can achieve the same goal using a command line entry.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
performance, encourages slow app writing
- Complicates the development of extensions and the engine
- Will not work in thread safe mode
All in all, dl() is simply bad, in just about every level.
Zeev
At 00:03 07-08-01, George Schlossnagle wrote:
In a few words:
For a webserver: ban dl()
For generic
.
--Jani
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
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
At 17:55 07-08-01, Stig Sæther Bakken wrote:
Now we're talking! I assume it is not straightforward, what are the
technical challenges in doing JIT module initialization?
It's not much of a challenge really. If we decide it should be done, it
can be done...
Zeev
--
PHP Development Mailing
Considering the amount of changes done, plus the few changes pending, plus
the QA time, I'd say that it's at least a month away, probably more...
Zeev
At 00:58 08-08-01, Colin Viebrock wrote:
Just planning some upgrades here at easyDNS and wondering if there is a
plan yet for when 4.0.7 might
At 10:39 08-08-01, Thies C. Arntzen wrote:
On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken
wrote:
[Zeev Suraski [EMAIL PROTECTED]]
At 17:55 07-08-01, Stig Sæther Bakken wrote:
Now we're talking! I assume it is not straightforward, what are the
technical challenges
At 21:14 08-08-01, Jani Taskinen wrote:
On Wed, 8 Aug 2001, Cynic wrote:
At 20:02 8/8/2001, Zeev Suraski wrote the following:
--
At 21:01 08-08-01, Jani Taskinen wrote:
[moving this to php-dev]
First: Great! Woohoo! Thanks Zeev
My top of the list is:
$_REQUEST
$_EVIL (Andi and I think it's really pretty good, but we both figured we'll
end up going with a different alternative :)
Zeev
At 21:12 08-08-01, Jason Greene wrote:
What about using the acronyms in any combination.
like $_GPC
and $_GC
and etc
-Jason
actually using the new $_GETfriends features, which can
otherwise go unnoticed.
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]
At 21:51 08-08-01, Andrei Zmievski wrote:
On Wed, 08 Aug 2001, Zeev Suraski wrote:
As those of you who are subscribed to php-cvs may have noticed, Andi and I
implemented today the functionality I suggested to replace
register_globals:
- $_GET, $_POST, $_COOKIE, $_FILES, $_ENV
From what I understand, Sascha doesn't have time to do that in the near
future, so waiting for this is probably not the right thing to do.
Is this a new issue?
Zeev
At 22:01 08-08-01, Jason Greene wrote:
There is one issue with 4.0.7 that probably should be fixed before branch.
The build
At 22:13 08-08-01, Thies C. Arntzen wrote:
On Wed, Aug 08, 2001 at 09:20:55PM +0300, Zeev Suraski wrote:
My top of the list is:
$_REQUEST
$_REQ would be even nicer - and less to type without hiding
the meaning.
I agree with Andrei on this one...
$_EVIL (Andi and I think it's
]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Are you *sure* you're running the very current CVS, and not some snapshot?
Zeev
At 01:16 09-08-01, Simon Roberts wrote:
Seems like the Zend changes that were just committed broke something - all
scripts are causing a segfault. I'm looking at what changed now.
Script:
?php phpinfo
)[LANG_SCNG(yy_leng)-1])) {
+ CG(increment_lineno) = 1;
+ }
retval = ';'; /* implicit ; */
break;
case T_OPEN_TAG_WITH_ECHO:
- Original Message -
From: Zeev Suraski [EMAIL
At 02:49 09-08-01, Simon Roberts wrote:
Aiee! I'd just done that, when I got your message. I'd deleted my
entire php4 source dir, downloaded from CVS, rebuilt, and it appears to be
working. Aiee. I'll keep an eye on it.
Bugger
(Sorry Zeev)
That's fine. Self-repairing bugs are the ones I
We can add it as an experimental, sure. When do you think it'd be ready?
Zeev
At 12:14 09-08-01, David Eriksson wrote:
Quoting Zeev Suraski [EMAIL PROTECTED]:
This change was my last major TODO item for PHP 4.0.7. At this point,
we
should try to get PHP 4.0.7 out the door soon. I
I won't have time to mess with this... Everyone should make sure that they
get their stuff in by Tuesday :)
Zeev
At 23:47 09-08-01, Jani Taskinen wrote:
As the satellite extension has been experimental all of it's lifetime,
and it doesn't even compile (at least very easily :) I'd say nuke
. An app built on a certain infrastructure is dependant on that
infrastructure, but not the other way around.
However, if everyone on php-dev thinks the above look to a PHP extension
is just fine, I'll stop bickering.
I'm +1 on that :)
Zeev
--
PHP Development Mailing List http://www.php.net
bickering.
I'm +1 on that :)
-1 here.
Bicker on then, bicker on.
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]
, and load into the engine in other apps that use this engine
in the future. This is just another example of why the basic soft-dev rule
of putting the infrastructure-derived macros in the infrastructure and not
in the application on top of it is correct.
Zeev
At 17:21 10-08-01, Jason Greene wrote
At 17:31 10-08-01, Andrei Zmievski wrote:
On Fri, 10 Aug 2001, [EMAIL PROTECTED] wrote:
This is not about renaming, it's about removing duplicate macro's.
Of course it's about renaming. We used to have just PHP_* macros and
then Zeev added the ZEND_* versions and now PHP_* ones are just
At 19:06 12-08-01, Zeev Suraski wrote:
I don't think that this happens too often - I think that comments like
Sebastian's are much more
Ick, Sterling's that is. Sorry Sebastian ;)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED
where these issues could really
be worked on, face to face?)
I don't really agree (the only relevant forum is php-dev in my opinion,
group is only for administrative stuff), but let's give it a rest for now.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail
Were/are the register_global entries and $HTTP_SESSION_VARS[] entries
references to each other or not?
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
don't remember if it was a dead end, or just something I
didn't have the mental strength to deal with back then...
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
At 12:47 13-08-01, Markus Fischer wrote:
I was just kidding, really.
You sure have fooled me ;)
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
on this machine (i.e. a build of mysql,
which should evoke generic memory or CPU issues as well, runs through
pretty clean), it only keeps crashing with PHP (and the Zend Cache, that is
;-) ).
Does it crash every time - will a simple highlight_string(hello); crash it?
Zeev
--
PHP Development
Just a reminder - I plan on branching 4.0.7 today as planned, in a few hours.
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]
At 10:23 15-08-01, Stig Sæther Bakken wrote:
[Hi,
I think one of the problems with this is that even if php-dev comes up
with a system for determining which feature it wants to see in PHP, we
still depend on Zeev, Andi or someone else @ Zend to implement them.
An RFC system would be a support
At 12:15 15-08-01, Sterling Hughes wrote:
On Wed, 15 Aug 2001, Zeev Suraski wrote:
At 10:23 15-08-01, Stig Sæther Bakken wrote:
[Hi,
I think one of the problems with this is that even if php-dev comes up
with a system for determining which feature it wants to see in PHP, we
still
At 13:06 15-08-01, Jani Taskinen wrote:
p.s. Zeev, did you forget to tag the Zend / TSRM for 4.0.7 ??
Nah, I even did that last night at 2am... But I got a bug report in the
CGI that required fixing, and there's some COM patch that should go in
before RC1, so RC1 will be delayed in a few
the rest of us do what we're good at, which is
developing PHP. Perhaps setting up a separate mailing list like Sterling
suggested, a-la [EMAIL PROTECTED] isn't such a bad idea.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
. I believe Hartmut will help documenting the
API, but that's about it.
But chaning the license is only one step that Andi and Zeev need
to take, IMHO.
A second one would be documenting the Zend Engine's internals.
And this can only be done properly by Andi and Zeev, since
PROTECTED] isn't such a bad idea.
Thanks for proving that you are not interested in a dialogue.
If bickering is your definition of dialogue then all I can say is - you're
quite welcome!
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED
you're missing is the point of these threads. They have
very little to do with the situation itself, and everything to do with
politics. If, God forbid, you only look at the facts - then you're not
missing anything.
Thanks for providing a rational look!
Zeev
--
PHP Development Mailing
At 18:13 15-08-01, Andrei Zmievski wrote:
On Wed, 15 Aug 2001, Zeev Suraski wrote:
like. That's why the situation wouldn't change radically if/when the
engine license changes, much like it wasn't any different *before* the
engine license was even introduced, in the PHP 3.0 days. Having
, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
At 18:40 15-08-01, Daniel Beulshausen wrote:
At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
Is there any reason to have them even exported? I think we can just
nuke SAPI_API altogether (I could be wrong, we might be referencing them
At 20:20 15-08-01, Daniel Beulshausen wrote:
At 19:33 15.08.2001 +0300, Zeev Suraski wrote:
At 18:40 15-08-01, Daniel Beulshausen wrote:
At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
Is there any reason to have them even exported? I think we
http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored)
--
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]
At 20:35 15-08-01, Daniel Beulshausen wrote:
isn't that exactly what i meant in my first mail? :)
I'm thick ;)
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
Done!
At 21:32 15-08-01, Jani Taskinen wrote:
Could you add a symbolic link for it:
php-4.0.7RC-latest.tar.gz
And keep that linked to the latest.
--Jani
On Wed, 15 Aug 2001, Zeev Suraski wrote:
http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored)
--
Zeev Suraski [EMAIL
At 21:24 15-08-01, Sterling Hughes wrote:
Oh - I see! So the Zend on the License is really just shorthand for
Zeev and Andi, has nothing to do with Zend Technologies Ltd. Good
to know. ;))
In practice, pretty much, yes. I don't remember Doron's, Adi's or Daniel's
last
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. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail
Very nice non-PC statement! :)
Zeev
At 02:20 16-08-01, Blake Schwendiman wrote:
Just my opinion, but right now (meaning this year, maybe a little longer) I
feel that PHP is more than adequate for developing small, medium and large
sites. I work on both sides of the fence. My day job has been
a different license, you would have to write it from scratch.
5. If, say, Microsoft beats Zeev and Andi in a Redmond basement for
three weeks, until they sign away all rights with bloody, mangled
hands, can PHP go forward, or does it have to back up? (See the
tim robbins antitrust movie... he becomes
(which .NET is, apparently).
Giving it a try doesn't hurt, though. I just explained why I liked Blake's
non politically correct statement :)
Zeev
At 10:58 16-08-01, Kristian Koehntopp wrote:
On Thu, Aug 16, 2001 at 02:24:27AM +0300, Zeev Suraski wrote:
I've rambled a bit, but my feeling
don't
want to hard-code the idea that the form must be patches.
http://www.trolltech.com/products/download/freelicense/annotated.html
(this is not an encouragement to make you fork, just pointing out that
you're wrong).
Zeev
--
PHP Development Mailing List http://www.php.net
improvements in order to meet the meaning of the Annotated
License..As Applied To The Qt Free Edition Version 2.0.
Could be. Chances are that with the company who wrote the license
explaining what it meant the way it did, it'll be an uphill battle to fight
against it.
Zeev
--
PHP
/*,
and not perform compression otherwise
- We can look into sending the content length header from the output
compression callback
Can anybody think of good reasons not to send the content-length header in
case we're performing output buffering?
Zeev
--
PHP Development Mailing List http
At 15:37 16-08-01, Troels Arvin wrote:
On Thu, 16 Aug 2001 14:26:09 +0200, Zeev Suraski [EMAIL PROTECTED] wrote:
Can anybody think of good reasons not to send the content-length header
in case we're performing output buffering?
I meant in case we're performing output compression :I
, you all count :)
We need to look at what's the best way to support this though. HTML (or
XHTML) is very loose as to which entry appears first, and to whatever other
entries appear within the tag. The current scanner is not...
Zeev
--
PHP Development Mailing List http://www.php.net
At 21:27 16-08-01, Thies C. Arntzen wrote:
On 16 Aug 2001 15:26:09 +0300, Zeev Suraski wrote:
- Output compression should probably check that the content type is
text/*,
and not perform compression otherwise
that means adding another sapi call - but i think it would make sense.
Yep
is 1.
Ick. What compiler is that?
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]
Can you try the latest CVS?
Zeev
At 21:22 16-08-01, Mike Hepworth wrote:
The snapshot gives me the following error on the php make command:
Making all in Zend
/bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H
-I. -I. -I
../main -I../TSRM -g -prefer-non-pic -static -c
At 12:00 17-08-01, Hellekin O. Wolf wrote:
At 21:15 16/08/2001 +0300, Zeev Suraski wrote:
What is the default error_reporting ? (When no value has been defined ?)
The default error reporting is E_ALL ~E_NOTICE - or, in other words,
all types of errors and warnings, except for notices.
Zeev
this mess upon us - and turn URL fopens off
by default.
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]
.
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]
* not the cleanest language around, and
it's not meant to be, either. That's why not every action that would
result in a 'cleaner' language is automatically applied.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
of fopen-wrappers).
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]
with coding style, not
security.
Yes, average PHP code is full of security or other holes.
E_NOTICE's only sometimes imply a security hole or a bug. Very often, they
imply absolutely nothing.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED
there if you want to.
We can have a wrapper function, url_fopens_enable() which would in turn
call ini_set(), but generally I think it's a bad idea to add these
redundant functions.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED
good idea unless they're integrated parts of the application.
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]
A news entry won't hurt that much it will probably aid ... wether
EXP or not, domxml is stuff used by many people. We shouldn't be
that strict just because its marked EXP after all..
I'm with Markus here... It's quite easy to skip non interesting entries.
Zeev
--
PHP Development Mailing List
At 19:37 19-08-01, Markus Fischer wrote:
print_r( $a-b()-e()[0]);
The last line gives parse error. So, I guess no yet supported?
There are no plans to support this kind of dereferencing (arrays are still
native types).
Zeev
--
PHP Development Mailing List http://www.php.net
At 19:48 19-08-01, Markus Fischer wrote:
On Sun, Aug 19, 2001 at 07:40:06PM +0300, Zeev Suraski wrote :
At 19:37 19-08-01, Markus Fischer wrote:
print_r( $a-b()-e()[0]);
The last line gives parse error. So, I guess no yet supported?
There are no plans to support this kind
in any way with
this respect.
'Hadin Yikov Et Hahar'. I wish I knew how to translate that :)
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
could argue with that last sentence of
yours, though :)
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]
a lot of sense
to have as part of the distribution. I'm not sure I've ever seen a clear
argument as to why they don't.
Yep, I agree.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact
, RFC2109 Set-Cookie, or
RFC2965 Set-Cookie2)?
I think that's fine, but it'll be coming after a long list of optional
arguments :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact
is, in my opinion, one
of the key reasons to its success. It doesn't mean that this system cannot
be redesigned in a way in which the extensions would ship separately, but
we have to make sure it will not make installing extensions any more
complicated or annoying than it is today.
Zeev
--
PHP
to them?
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]
, then it will just
return Object like now.
Good luck trying to get this in.
I implemented this once, and it was even in for several mini versions. But
it causes inconsistencies, and it was thus removed (I don't remember what
the inconsistencies were, look up the archives...)
Zeev
--
PHP
() in convert_to_string(),
then it may be consistent (I'm not sure, I haven't thought about it
thoroughly). There was a reason on why we didn't switch to this as well,
though.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
!
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]
How about phf_, for PHP Helper Function?
I see a point in differentiating language level API functions (e.g. like
output buffering) and module-specific helper functions (e.g., like
php_mysql_do_connect()).
Zeev
At 22:57 22-08-01, Jeroen van Wolffelaar wrote:
I'm against that. Usually
At 23:09 22-08-01, Andrei Zmievski wrote:
On Wed, 22 Aug 2001, Zeev Suraski wrote:
How about phf_, for PHP Helper Function?
I see a point in differentiating language level API functions (e.g. like
output buffering) and module-specific helper functions (e.g., like
php_mysql_do_connect
At 23:18 22-08-01, Andrei Zmievski wrote:
Is it a big deal? No, but it can be useful and has no real drawbacks.
Okay. But I'll be forced to pronounce phf as FF, so FF_mysql_connect..
:)
Ok, one real drawback then ;)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe
is way too general to be good for such a purpose... I'd try
and use a fairly descriptive name, which is unlikely to be used again in
the future.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
work everywhere
(or find a working solution to keep the tree in a working
state). Branching away for long periods in the hope of merging back in is
not a good idea.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
)
having the tree broken for a few hours or even a couple of days under the
'less-mainstream' configurations is not a complete disaster...
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact
, it is
simply not ready, it's about the idea.
Sigh. Ok then. Commit the broken changes to a branched ext/standard, but
let's set a dead line to branching it back in, or killing it :) I think
that 2 or 3 days should be enough to call the shots...
Zeev
--
PHP Development Mailing List http
administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
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
in right now, the first string cannot
be empty so this case is not checked). Any chance your first string is empty?
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
poor coding, and I don't think it's being used too often (far less
often than plain random numbers are, anyway). If somebody wants to get a
predictable series, let him ask for it explicitly.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED
I think that was some breakage I was responsible for (I committed a fix
about 30 minutes later, only apparently I never actually finished editing
the commit message, so it never left my machine).
It should be fixed now. Please let me know if it isn't.
Zeev
At 02:43 26-08-01, Rasmus Lerdorf
My fault :I I'm working on it.
At 02:54 26-08-01, Rasmus Lerdorf wrote:
It should be fixed now. Please let me know if it isn't.
Well, as of right now, it is still broken. Or am I waiting for a commit?
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail:
It looks like domxml is responsible here. The hash table that's sent to it
contains a NULL value, which should be a valid zval *...
Zeev
At 13:04 26-08-01, Joey Smith wrote:
This may be due to the way domxml is doing things, but the test script
in bug #10936 still creates a crash
501 - 600 of 1273 matches
Mail list logo
