I believe he meant the query id's that the engine uses, and not the auto
increment id's. Wez's response was accurate, we'll overflow at some
point. This is basically because PHP was designed with short requests in
mind. We could probably fix it relatively easily for ZE2.
Zeev
At 13:15
At 23:48 12/03/2003, Andrei Zmievski wrote:
Seeing as how we now have only one-level deep namespaces and classes
(which is another topic), does it make sense to have both 'scope' and
'ns' fields in zend_op_array structure? I would think they can be merged
into one.
Not really, we can't. You can
At 15:54 13/03/2003, Andrei Zmievski wrote:
On Thu, 13 Mar 2003, Zeev Suraski wrote:
Not really, we can't. You can have functions inside a namespace, that
don't have a class entry attached to them.
I guess we could create some hybrid of the namespace and ce, but it would
end up being ugly
At 02:48 12/03/2003, Stephen Thorne wrote:
How soon till
('pre'.($_GET['textArea']-strip_tags()).'/pre')-print(); ?
Considering $_GET is an array of strings, infinity :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Fixed!
Thanks,
Zeev
At 18:17 11/03/2003, Andrei Zmievski wrote:
With the latest ZE2:
?php
class Bar {
function boo()
{
::zoo();
}
}
Bar::boo();
?
-Andrei http://www.gravitonic.com/
The day Microsoft makes something that doesn't suck,
I agree, this auto language detection is quite annoying...
Zeev
At 11:05 10/03/2003, Stefan Esser wrote:
Good morning,
is there any chance that we can revert this annoying feature?
The translated documentation is always behind and partly lacks
important information from the english version. I
At 18:17 09/03/2003, Derick Rethans wrote:
Hello,
I guess nobody is interested in fixing this? Then I guess we won't get
4.3.2 ever.
4.3.2 will be coming out soon either way, there's really no need for this
kind of talk.
I'll see if I can get some of these fixed, but we should get ready to
I wanted to do this for some time, but until recently, it wasn't very
feasible, because the order of registration could be designated by the user
(gpc_order, variables_order, etc.). Now that register_globals is off by
default, and that we have the auto-globals, it's much more feasible.
I
. Ifwhen _SERVER is created, it will attempt to
copy them. Thoughts?
Zeev
At 17:15 02/03/2003, Marcus Börger wrote:
At 11:19 02.03.2003, Zeev Suraski wrote:
zeevSun Mar 2 05:19:17 2003 EDT
Log:
Add JIT initialization for _SERVER and _ENV
(it's less important for the others, even
At 17:56 02/03/2003, Marcus Börger wrote:
At 16:38 02.03.2003, Zeev Suraski wrote:
Looks like for some reason, CLI registers $argv and $argc globals even
though register_globals is off. Why's that?
CLI overwrites register_argc_argv:
zend_alter_ini_entry(register_argc_argv, 19, 1, 1
At 17:50 28/02/2003, Sascha Schumann wrote:
I think that simply adding OnUpdateLong and deprecating
OnUpdateInt is fine while retaining its current semantics.
+1
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On timeout, the engine will call zend_bailout(), which performs a
longjmp(). It does unwind the stack, but since we're dealing with C and
not C++ and there are no destructors, it's your responsibility to clean
after yourself. You can do it by properly registering your resources with
PHP's
At 17:05 20/02/2003, [EMAIL PROTECTED] wrote:
- Original Message -
On timeout, the engine will call zend_bailout(), which performs a
longjmp(). It does unwind the stack, but since we're dealing with
C and
not C++ and there are no destructors, it's your responsibility to
clean
after
At 17:20 20/02/2003, Jeremy Mullin wrote:
Don't call malloc? Wow, that puts some serious restrictions on what an
external library can do. :)
In the code that you control, obviously.
Couldn't drivers be required to implement something like SQLCancel in
ODBC? A mechanism that lets the driver
At 16:58 20/02/2003, [EMAIL PROTECTED] wrote:
I have a question in regards to page timeouts and how the initial
I've noticed if a query takes longer than the default 30 seconds to
execute, php returns a timeout message to the user. From what I can
tell, php uses the SIGPROF signal to stop
At 17:38 20/02/2003, [EMAIL PROTECTED] wrote:
- Original Message -
I looked into the bug report, and it is true that
BLOCK_INTERRUPTIONS
should indeed block SIGPROF. I'll fix this in the weekend.
I'm not sure if after unblocking interruptions PHP will get SIGPROF ...
it could cause
At 01:37 07/01/2003, Joseph Tate wrote:
Well, according to my highly technical methods of deduction (fprintf(stderr,
Inside sapi_shutdown);) sapi_shutdown is never called when serving a PHP
request when served using mod4_php under Apache. This is because the
shutdown_wrapper never gets
At 13:36 06/02/2003, moshe doron wrote:
b. sunrise()
c. sunset()
Hrm, what are these functions?
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
I don't think we can rely on GNU grep being installed though...
At 17:29 04/02/2003, J Smith wrote:
GNU grep should work. Just make sure /usr/local/bin comes before /bin in
your $PATH.
J
Sebastian Nohn wrote:
Latest CVS (PHP5-dev) on Solaris:
Configuring TSRM
checking for stdarg.h...
Fixed.
At 01:44 28/01/2003, Magnus Määttä wrote:
This is in current head.
(cd .libs rm -f libphp4.la ln -s ../libphp4.la libphp4.la)
Installing PHP SAPI module
Installing shared
extensions:
/usr/local/www/php5mincli/lib/php/extensions/debug-non-zts-20020429/
Installing PEAR environment:
Joseph,
Your latest patch seems to be in the right direction (admittedly I haven't
reviewed it until now). A couple of random points:
- It sounds dangerous to me to move php_request_shutdown() to be called
from Apache's shutdown without further inspection. At least one thing
comes to mind -
Fixed.
At 08:04 28/01/2003, Magnus Määttä wrote:
Hi!
This code produces this segfault under HEAD.
?php declare(ticks = 1); function test() { } ?
bt ( for the whole bt: http://novell.stoldgods.nu/~magnus/bt ):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384
At 19:54 28/01/2003, Joseph Tate wrote:
Then, could we add a sapi_flush()/ob_flush() call at the end of
apache_php_module_main after calling the normal register_shutdown_functions?
Yeah, something along these lines.
What else might have problems?
Might is a powerful word :)
Zeev
--
PHP
At 14:29 27/01/2003, Sebastian Bergmann wrote:
Right now if one uses trigger_error() to trigger an error the
line number that gets displayed is that of the trigger_error() line.
Would it be possible to add additional parameters to trigger_error()
to pass a filename and a line number to
At 19:59 25/01/2003, Friedhelm Betz wrote:
Hi,
I rewrote the part in the phpdoc manual about building on windows.
zlib is builtin with 4.3.0 but the shipped Workspace for VC++
relies on a precompilded external zlib.lib.
Therefore building on win32, out of the box, is not possible without
At 00:25 26/01/2003, Friedhelm Betz wrote:
Saturday, January 25, 2003, Zeev Suraski wrote:
1.) Are there future plans to include the zlib sources?
No. zlib is included in a similar way to the way we include
bindlib_w32. It's in a different repository on cvs.php.net, that we
expect
Rasmus,
The whole point of the list was to avoid threads like this letter is going
to spawn. Let's stop it here, please.
John - if you feel you belong in php5-dev(*) and want to actively
participate in the discussions, we'll add you. The point of php5-dev was
to create a working group for
Ok, I can't be bothered to fight a mailing list that was supposed to trim
down endless discussions. I'm not the one that asked for the list, but I
definitely supported it, as unlike most of the members on this list, I
remember the pre-v4 days, and what kind of mountains we had to push in
order
At 00:08 24/01/2003, Rasmus Lerdorf wrote:
You should have learned this by now. Perception and warm fuzzies is an
extremely important part of a large open source project that relies
heavily on a large number of volunteers. Messing with that is playing
with fire. I believe we can get work done
At 02:52 16/01/2003, Rasmus Lerdorf wrote:
In trying to implement a security policy I need to pass all user-supplied
data (GET/POST/Cookie) through a filter function which implements this
security. This isn't all that hard to implement as an extension through
new 4.3 treat_data and post_handler
At 08:26 14/01/2003, Derick Rethans wrote:
A patch for naming it libphp5 or a patch that enables them to work
together in the same webserver? The latter is quite hard and 'cookie a
patch' for that will almost certainly not work.
Wouldn't --enable-versioning work just fine?
Zeev
--
PHP
At 12:30 14/01/2003, Derick Rethans wrote:
On Tue, 14 Jan 2003, Zeev Suraski wrote:
At 08:26 14/01/2003, Derick Rethans wrote:
A patch for naming it libphp5 or a patch that enables them to work
together in the same webserver? The latter is quite hard and 'cookie a
patch' for that will almost
At 12:40 14/01/2003, Derick Rethans wrote:
On Tue, 14 Jan 2003, Zeev Suraski wrote:
At 12:30 14/01/2003, Derick Rethans wrote:
Also, why would we need it for php4/php5?
Because it'll probably not be 100.0% downwards compatible...
hmm, I think a nice thing to do is to make a list of those
At 19:24 11/01/2003, Andi Gutmans wrote:
At 07:13 AM 1/11/2003 +0100, Sebastian Bergmann wrote:
The project file(s) for the non threadsafe Windows build are out of
sync with the thread safe one(s).
IIRC, there was already some discussion to ditch the non threadsafe
version. That way we
Tate wrote:
That's no good. If I remove the sapi_close stuff, and try to execute the
shutdown functions in php_apache_request_shutdown() all I get is stuff in
the error log listing the leaked memory. The requested function does not
get executed.
Joseph
-Original Message-
From: Zeev
At 19:47 29/12/2002, Sascha Schumann wrote:
If that language had interested me, I would have made my
Hebraicum in addition to the Latinum.
[snip off-topic]
^^^
You're kidding, right?
Thankfully, your interest in young languages does not concern me, nor does
your show-off
At 20:12 29/12/2002, Michael Sisolak wrote:
Zeev Suraski wrote:
It's zlib. I'm not sure why people relied on users having zlib
installed
as a part of their standard libraries under Windows, but it's not a
reasonable assumption...
checkout zlib, build it (under both Release and Debug), delete
At 19:29 29/12/2002, Sebastian Bergmann wrote:
Zeev Suraski wrote:
Probably due to different .dsp's (I assume you have two different
checkouts of the PHP source tree? Any chance one of them is modified)
No, one checkout. For a Zend Engine 2 build I rename Zend to Zend1 and
ZendEngine2
That's a bit of an odd way to implement it - are you sure closing the link
explicitly at that point won't interfere with anything? In 4.1 (or
whatever the last version it worked like that was), it was taking advantage
of the fact PHP's resource pool was being destroyed after the link was
At 20:52 30/12/2002, Sascha Schumann wrote:
Zeev, you start to bore me.
Thank God, I was hoping you were already being bored as much as I am for
the past 4 years of pointless discussions with you, but better late than never!
Zeev
--
PHP Development Mailing List http://www.php.net/
To
the connection
is closed rather than after, causing PHP to appear slower than it needs to.
Joseph
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 30, 2002 12:55 PM
That's a bit of an odd way to implement it - are you sure closing
the link
explicitly
It appears the .dsp's were misconfigured (for future reference- we should
never need to use 'ignore libraries' for any of the MSVC runtime
libraries; If we do - we have a problem somewhere else).
I suspect this happened around the time zlib support was added, and it was
added improperly. I
At 18:01 29/12/2002, Sebastian Bergmann wrote:
Zeev Suraski wrote:
It appears the .dsp's were misconfigured
I tested this with a fresh checkout of php4/ and ZendEngine2/ and still
get the library conflict warning during a ZendEngine2 build. I did not
yet test the other issue I mentioned
At 18:27 29/12/2002, Sebastian Bergmann wrote:
Zeev Suraski wrote:
checkout zlib, build it (under both Release and Debug)
Thank you Zeev, that did the trick. But I still wonder why I got this
only with the Zend Engine 2 and not with the Zend Engine 1...
Probably due to different .dsp's (I
At 19:21 29/12/2002, Sascha Schumann wrote:
On Sun, 29 Dec 2002, Zeev Suraski wrote:
At 11:46 29/12/2002, Sebastian Bergmann wrote:
Rasmus Lerdorf wrote:
Sascha, we need to give you something constructive to work on...
-Rasmus (top-posted with lots of quoted text just for you
You grabbed the words from my throat :)
Zeev
At 20:36 28/12/2002, Rasmus Lerdorf wrote:
Sascha, we need to give you something constructive to work on...
-Rasmus (top-posted with lots of quoted text just for you)
On Sat, 28 Dec 2002, Sascha Schumann wrote:
After looking at a few messages
Give us a break. And spare me an intelligent explanation about why we're
fools and you roolz, and why we don't deserve a break.
Only a fool would blow such an idiotic thing out of proportion.
Zeev
At 00:23 29/12/2002, Sascha Schumann wrote:
Only a fool would decry the importance of
At 00:48 29/12/2002, Sascha Schumann wrote:
On Sun, 29 Dec 2002, Zeev Suraski wrote:
Give us a break. And spare me an intelligent explanation about why we're
fools and you roolz, and why we don't deserve a break.
Only a fool would blow such an idiotic thing out of proportion.
I ran
At 00:52 29/12/2002, Sascha Schumann wrote:
Read back your (as usual) condescending remarks, and the entire
thread. You're a smart guy, figure it out!
Well, I would appreciate an answer on why this thing is
'idiotic' and 'out of proportion'. Please enlighten my poor
soul, dear
That was quite a funny way of putting it (it did make me literally laugh
out loud a bit), but I have to agree :)
Either way, as Sterling pointed out and I pointed out a few days ago, this
+-N is really nothing but an 'I (strongly) (dis)agree', and it is in no way
a voting system. That's one
Just to somewhat limit my agreement with that statement, I'd rephrase it so
that it's clear that people's opinion does matter. Something along the
lines of 'Too many people think that they're in a position to decide about
PHP'.
Zeev
At 02:35 19/12/2002, Sascha Schumann wrote:
On 18 Dec 2002,
At 14:14 19/12/2002, Sascha Schumann wrote:
On Thu, 19 Dec 2002, Zeev Suraski wrote:
Just to somewhat limit my agreement with that statement, I'd rephrase it so
that it's clear that people's opinion does matter. Something along the
lines of 'Too many people think that they're in a position
I think you forgot to take one fact into account - PHP 4.2.x already had
CLI/CGI binaries, both having the same name. Keeping 4.3 with the 4.2
behavior, and then merging the modules back in 4.3.1 is the best solution
as far as I can tell. Merging the modules does not have serious
At 14:34 19/12/2002, Edin Kadribasic wrote:
On Thu, 19 Dec 2002, Zeev Suraski wrote:
I disagree. For instance, if I helped writing the combined module, and
someone separated it without thoroughly making sure that everyone is ok
with this separation, I believe it's upto him to be responsible
[Stas answered you in a very thorough and accurate way, and since it took
several hours since I started composing this reply and the time I actually
sent it, I cut it down to minimum]
Marcus,
I (as well as basically all major OO languages I can think of) disagree
with you.
OO and inheritance
At 10:28 10/12/2002, Sebastian Bergmann wrote:
Zeev Suraski wrote:
If we use this KISS approach, why the heck are we even considering this
rename?
1.) Using 'php' to run a PHP script from the command-line sounds like
the right choice of name (for the sapi/cli binary).
Maybe, maybe
At 11:00 10/12/2002, Edin Kadribasic wrote:
The CGI sapi was first renamed to php-cgi on Feb 28, and the change was
temporarily reverted for the 4.2.x release because CLI sapi was
considered experimental.
That maybe the way you see this. A handful of php-dev programmers may see
it in the same
At 14:00 11/12/2002, Derick Rethans wrote:
On Wed, 11 Dec 2002, Zeev Suraski wrote:
Changing the name from php to php-cli will break BC:
[root@saturnus php-4.2.3]# ./configure --enable-cli
[root@saturnus php-4.2.3]# make
[root@saturnus php-4.2.3]# sapi/cli/php -v
4.2.3
And the CGI is also
At 13:39 11/12/2002, Sebastian Bergmann wrote:
Zeev Suraski wrote:
I did not choose to raise the issue at this time, but I agree
completely with the opinion that it's a bad thing; It is my fault that
I haven't raised it a few months ago when I noticed this change, but as
you might have
At 14:20 11/12/2002, Shane Caraveo wrote:
3.) Why this late discussion of the issue? The name of the sapi/cgi
binary was changed months ago!
I did not choose to raise the issue at this time, but I agree completely
with the opinion that it's a bad thing; It is my fault that I haven't
At 15:37 11/12/2002, Marcus Börger wrote:
This does not work since then you will have pcnt in cgi and such
I don't see how that is a problem. You can build --with-pcntl or not.
Also there are many differences in the source which would require
a hughe amount of if-then-else.
That
Somehow it doesn't surprise me that the same people who wanted other
BC-breaking changes (minus perhaps Wez) are in favour of this change as well.
Just for the record, we never had a real vote on php-dev or any of the
other forums, and I don't think we'll start now. php-dev is an open forum
At 16:56 11/12/2002, Hartmut Holzgraefe wrote:
Hartmut Holzgraefe wrote:
and *PLEASE* make some space in your inbox before sending further questions
getting
E-mail Account: imprev is over the limit of 31457280 bytes.
auto-replies all the time is starting to get very annoying
sorry, should
At 15:44 08/12/2002, Marcus Börger wrote:
Looking into deep reveals that we must disallow overriding privates now.
That way the test private_007.phpt is illegal and all current tests i
developed
would pass (visibility tests are suspended of cause).
How do you arrive in that conclusion? The
At 19:50 09/12/2002, Marcus Börger wrote:
At 19:46 09.12.2002, Andrei Zmievski wrote:
On Mon, 09 Dec 2002, Andi Gutmans wrote:
ducking
Maybe phpsh would be a good idea for the name of the CLI? It wouldn't
confuse ppl as much as php-cli
/ducking
I'm really not that sure it makes sense to
At 19:46 09/12/2002, Andrei Zmievski wrote:
On Mon, 09 Dec 2002, Andi Gutmans wrote:
ducking
Maybe phpsh would be a good idea for the name of the CLI? It wouldn't
confuse ppl as much as php-cli
/ducking
I'm really not that sure it makes sense to rename the CGI from php to
php-cgi after
At 18:57 09/12/2002, John Coggeshall wrote:
ducking
Maybe phpsh would be a good idea for the name of the CLI? It wouldn't
confuse ppl as much as php-cli
/ducking
Why when I look at phpsh I think Sushi...
Is that good or bad? :)
--
PHP Development Mailing List http://www.php.net/
To
At 18:27 09/12/2002, Andi Gutmans wrote:
ducking
Maybe phpsh would be a good idea for the name of the CLI? It wouldn't
confuse ppl as much as php-cli
/ducking
I'm really not that sure it makes sense to rename the CGI from php to
php-cgi after such a long time. It's not as if we're breaking BC
At 23:11 09/12/2002, Frank M. Kromann wrote:
Please mention the name change at least in the NEWS file and maybe
php-cli
could even output a readable error when beeing called as cgi.
These are good points.
I think that's a bit like inventing problems and then trying to fix them.
Let's keep
At 01:27 10/12/2002, John Coggeshall wrote:
Please mention the name change at least in the NEWS file and
maybe php-cli could even output a readable error when beeing
called as cgi.
As I already said, we should put this in the message created at the end
of ./configure, in the release notes, in
This does appear to be a problem, we'll need to think about it.
At 13:32 10/12/2002, Marcus Börger wrote:
At 10:02 10.12.2002, Zeev Suraski wrote:
At 15:44 08/12/2002, Marcus Börger wrote:
Looking into deep reveals that we must disallow overriding privates now.
That way the test private_007
At 17:02 07/12/2002, Marcus Börger wrote:
Hi Zeev,
I have changed the test files and encountered some problems with the way
you modified my patch:
1) private_002.phpt fails with
004- Fatal error: Call to private method pass::show() from context 'fail'
in %s on line %d
004+ Fatal error: Call
Brian,
BC is an issue, always, but as the person who wrote both the original
version and the fix, I can tell you that the original behavior was not
intended to begin with, and because it couldn't be duplicated on any other
server than Apache, it was changed to both reflect the intended
How does this patch possibly fix something in this magnitude? It doesn't
appear to do anything crucial at all, or do these variables have some
far-reaching indirect effect?
Zeev
At 07:45 02/12/2002, Shane Caraveo wrote:
It's not a matter of php cgi just having a couple bugs, it was completely
Why not just use BEGIN_EXTERN_C() and END_EXTERN_C()?
Zeev
At 17:18 02/12/2002, J Smith wrote:
Taking a few comments into consideration, here's a new patch for adding C++
code-generating abilities to ext_skel. The new patch doesn't use a separate
skeleton.cpp file. Instead, it adds some lines
instance, BEGIN/END_EXTERN_C() aren't defined yet, as
they're in zend.h. The compiler would totally barf.
I had used BEGIN/END_EXTERN_C() in the first patch I sent out, but decided
to use one or the other in this one for the sake of consistency.
J
Zeev Suraski wrote:
Why not just use
At 02:50 28/11/2002, Marshall A. Greenblatt wrote:
Apologies in advance if this is the wrong mailing list. Please direct me to
a more appropriate mailing list if there is one :-)
When a PHP string variable is changed via a PHP script, such as:
$foo = 'new value';
what happens to the
At 07:27 27/11/2002, Andi Gutmans wrote:
At 04:41 PM 11/26/2002 -0500, Daniel Cowgill wrote:
So why do the conversion in arithmetic? This seems bizarrely inconsistent to
me:
?
print (int) 0xA + 0; // prints 0
print (int) (0xA + 0); // prints 10
?
I think it's reasonable to expect those
At 02:27 27/11/2002, Stig S. Bakken wrote:
Let's try being realistic, and focus on the quick wins first, such as
good error codes.
Go Stig.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
They should definitely be in the C code. Look at gettext as a pretty good
example.
Taking them out is seriously inferior to having them in - it makes
maintenance much tougher, and PHP itself less robust. Suddenly, if you
don't have some external file, errors would show up as stupid error
At 13:05 26/11/2002, Maxim Maletsky wrote:
Derick,
that's the price of usability. Open Source always suffered from that,
and forever will if the usability will not be considered as one of the
main benefits, especially for a programming language as PHP.
I agree on 110% that it will be harder to
At 13:11 26/11/2002, Maxim Maletsky wrote:
That sounds selfish of us, Derick.
No, it doesn't. If we're going to attempt at doing something that has a
high risk of screwing up PHP and slow down its QA and support, we should be
mature enough to know our limits. If we don't, the ones that
to make things clearer English would have been much better...
otiyot == latters
techidot == singles
asarot == tens
meot == hundreds
In short, there's a weight for every letter in the alphabet, and numbers
are generated from a combination of letters.
At 23:35 30/10/2002, moshe doron wrote:
Sorry for the Engrish - latters == letters
At 00:53 31/10/2002, Zeev Suraski wrote:
to make things clearer English would have been much better...
otiyot == latters
techidot == singles
asarot == tens
meot == hundreds
In short, there's a weight for every letter in the alphabet, and numbers
It should work fine, as long as you use the php_admin directives.
At 21:50 20/10/2002, Matus fantomas Uhlar wrote:
Hello,
I found out that it is not possible with current php stable version (4.2.3)
to define some configuration variables per virtual host - e.g.
upload_tmp_dir.
The
Shouldn't there be different settings? People may very well want html
errors off, but still keep the rest of PHP 'web enabled'...
At 08:58 29/10/2002, Derick Rethans wrote:
On Tue, 29 Oct 2002, Steve Alberty wrote:
why result the functions phpinfo() and phpcredits() as plain text
when i set
not buying into your reasoning, as reasonable as it may sound to you
personally.
Please revert.
Zeev
At 04:21 28/10/2002, Ilia A. wrote:
+1 to keep PHP-CLI with implicit_flush.
Ilia
On October 27, 2002 09:05 pm, Zeev Suraski wrote:
Thank you for the detailed explanation, I'm sure everybody
At 07:35 28/10/2002, Thies C. Arntzen wrote:
On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote:
TCA but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks
TCA against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor
TCA anytime before init_executor will
to get this over with).
Thanks!
Zeev
At 15:11 25/10/2002, Yasuo Ohgaki wrote:
Zeev Suraski wrote:
At 09:15 25/10/2002, Yasuo Ohgaki wrote:
Zeev Suraski wrote:
You print something, it doesn't print out. How is it trivial to solve
this? If you happen to know that there's IO buffering
At 15:29 25/10/2002, Yasuo Ohgaki wrote:
Are you going to set output_buffering=Off by default, too?
Since the obscurity still exists with output buffers.
It's even worse with broken output buffer function.
Huh? It IS off by default.
BTW, I don't object to have output_buffering=Off by default
At 18:37 27/10/2002, George Schlossnagle wrote:
+1 unless it is set as an INI_ANY, then +0.
It's already INI_ANY...
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
At 09:15 25/10/2002, Yasuo Ohgaki wrote:
Zeev Suraski wrote:
You print something, it doesn't print out. How is it trivial to solve
this? If you happen to know that there's IO buffering and that there's a
function called flush() then maybe it trivial, but then there are the
other million
I don't think that matters that much really. Even if it's 2%, and not 12%
or 50%, we're still talking about billions of lines of code...
Let's, please, give it a rest.
Zeev
At 11:13 24/10/2002, Kristian Koehntopp wrote:
We have heard a lot of anecdotal evidence about the usage of ? vs. ?php
This has nothing to do with academical correctness. Flushing or not
flushing is not a matter of right or wrong, it's a matter of choice.
There's one 'real language' that does automatic flushing, it's called PHP,
and it's going to stay that way. Why other languages chose not to do it
(maybe
At 10:01 24/10/2002, Yasuo Ohgaki wrote:
Melvyn Sopacua wrote:
At 02:51 24-10-2002, Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
Why?
Well - most 'average' (and below) PHP programmers when attempting to do
CLI programming, will get a serious WTF reaction from
At 12:23 24/10/2002, Yasuo Ohgaki wrote:
function prompt($prefix) {
echo $prefix;
flush();
}
is _TRIVIAL_ to write. People should have this kind of
function instead of enabling inefficient implicit flushing
since it's more efficient and reliable.
You print something, it doesn't print out.
We're not planning to add it at this time.
Zeev
At 14:42 23/10/2002, Adam Voigt wrote:
Ok, the other day a friend of mine showed me where you
could address a position in an array in perl, before you
even had the array returned. Essentially it would be
this in php:
echo
At 07:44 23/10/2002, Yasuo Ohgaki wrote:
Andi Gutmans wrote:
At 12:20 PM 10/23/2002 +0900, Yasuo Ohgaki wrote:
Jani Taskinen wrote:
Again..was this agreed upon?
I suppose so.
I didn't get any more objections.
It's not a big deal to me but I don't understand why this should need
At 11:21 23/10/2002, Yasuo Ohgaki wrote:
2. in the script with ini_set()
I've pointed out _MANY_ times that PG(implicit_flush)
is INI_SYSTEM|INI_PERDIR
That's a valid point. Note that you can still change it using
ob_implicit_flush().
However, it should be changed to INI_ALL so that it
At 07:33 22/10/2002, Terence Kearns wrote:
Agreed.
If short tags were disabled in v5, then there would be no such need for a
hack like this.
Right, we might as well switch to
?a_very_PHP_specific_tag_that_will_not_interfere_with_any_other_language
while we're at it, since nobody would use it
1 - 100 of 1188 matches
Mail list logo
