At 21:15 18/08/2002, Thies C. Arntzen wrote:
On Sun, Aug 18, 2002 at 09:00:25PM +0300, Zeev Suraski wrote:
At 20:54 18/08/2002, Thies C. Arntzen wrote:
BTW: the code we're talking about is neither magic nor very
complex. andi, sorry i you felt me stepping on your feet;-)
And yet
At 22:20 18/08/2002, Xavier Spriet wrote:
As long as there is momentum on the development process and on the QA
process when needed,
I don't think release momentum matters that much.
Right. Since the first part of the sentence does not stand in reality, the
direct result is that momentum
At 21:58 18/08/2002, Wez Furlong wrote:
Generally speaking, and please don't take offense, I think that one
of the problems with ZE2 is that development is slow. I understand
that there are several very good reasons for that, but the real
problem is that there aren't enough people with enough
]]
Sent: Sun 18/08/2002 4:21 PM
To: Xavier Spriet; Zeev Suraski
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PHP-QA] Re: [PHP-DEV] 4.2.3
As long as there is momentum on the development process and on
the QA
process
.
-Rasmus
On Sat, 17 Aug 2002, Zeev Suraski wrote:
Just wondering - why are we even using atime? I think lots of filesystems
don't support it, but regardless of that - as far as I recall from reading
the session code, if a session is opened for reading - it is also going to
be rewritten
() and give people the option to switch it to atime.
-Rasmus
On Sat, 17 Aug 2002, Zeev Suraski wrote:
Just wondering - why are we even using atime? I think lots of filesystems
don't support it, but regardless of that - as far as I recall from reading
the session code, if a session is opened
I'd like to raise the option of releasing 4.2.3 again. I believe that it
would be quite a while before 4.3.0 is out, and there are quite a few fixes
in the 4.2 branch that should make the userbase as soon as possible,
especially the Windows userbase.
I think that releasing 4.2.3 can be done
as accessing it on an
atime-enabled filesystem, I think. This would give us the best of both worlds.
Zeev
At 13:39 17/08/2002, Zeev Suraski wrote:
Ok, that makes sense. I like the idea of being able to configure whether
you want to use mtime or atime, so that non atime-compliant filesystems
of it is fixes to bugs.
And I still think the Tru64/AIX issues will need to be solved as well.
On Sat, 17 Aug 2002, Zeev Suraski wrote:
I'd really like to avoid waiting this time, though (the enemy of good is
better...). Even if we release 4.2.3 as it is in the branch, without any
further
At 16:41 17/08/2002, Sebastian Nohn wrote:
Why release a RC for a software that has some known bugs not fixed.
PHP x.y.z has known bugs that are not fixed, for any given x, y and z,
since forever, and until the of time. Realize that, and decisions become
much simpler.
Releasing a new version
At 16:54 17/08/2002, James E. Flemer wrote:
Would it be difficult to just add a dirty flag somewhere,
Not really, because today people can modify the session data by simply
changing $_SESSION. We have no way of detecting whether $_SESSION was
changed, as it's just a regular variable (for that
into them (ext/java still being
a bastard).
On Sat, 17 Aug 2002, Zeev Suraski wrote:
I think it makes good sense to release 4.2.3 as-is (after a short QA cycle,
that will ensure we didn't introduce any new bugs). If 4.2.3 becomes a
larger project, with more pre-requisites, I don't see
At 17:52 17/08/2002, Sebastian Nohn wrote:
No! This simply confuses users! Someone reported a bug n weeks ago, this bug
has been fixed in CVS n-x weeks ago. Now there is a new release an WOW!
this bug is'nt fixed! Fixed in CVS means fixed in CVS and the user expects
this bug to be fixed in the
are piling up in CVS. Stig, could you give
us a status report? Do you still have time to push this release?
-R
On Sat, 17 Aug 2002, Zeev Suraski wrote:
Ok then, I retract my suggestion to release 4.2.3.
Zeev
At 17:59 17/08/2002, Dan Kalowsky wrote:
I disagree that it should go out
At 22:28 17/08/2002, Xavier Spriet wrote:
This is quiteconcerning.
It appears the PHP release process is not suited to the way PHP is
developed anymore
and this can lead in severe inconsistencies.
What seemed to have happened is that several bugfixes were fixed in CVS
instead of the bugfix
At 22:58 17/08/2002, Sascha Schumann wrote:
64-bit fixes (for whatever reason), I think that's quite alright. 64-bit
support is a major thing, which people, especially businesses, will not
really expect to be implemented in a bug-fix release.
64-bit support has worked for years in
Nope, that's not a valid patch. zval_dtor() is not supposed to pay any
attention to refcount's. It should be fixed at a different level, I'll
check into it.
Zeev
At 22:58 17/08/2002, Ilia A. wrote:
Since there is no check if there is a refcount before freeing an object there
is a segv if
At 00:18 18/08/2002, Sascha Schumann wrote:
I've had at a look at the bug reports Sebastian Nohn pointed
out. None of these are major issues. Annoying, but nothing
which would qualify PHP as being buggy as hell. Still,
having these fixes in 4.2.3 would be a definitive
At 17:43 16/08/2002, Brad LaFountain wrote:
--- Zeev Suraski [EMAIL PROTECTED] wrote:
At 14:21 16/08/2002, Dan Hardiker wrote:
Hi,
As php user's requests are getting closer and closer to what ZE2 is
offering (eg: back tracing, private/protected classes, extra inheritance
At 18:26 16/08/2002, Dan Hardiker wrote:
2. When is it expected to be available in a development (experimental)
or production release?
It already is - go to www.php.net, and search for 'alpha'.
http://www.php.net/do_download.php?download_file=php-4.3.0-dev-zend2-alpha2.tar.gz
Forgive
Just wondering - why are we even using atime? I think lots of filesystems
don't support it, but regardless of that - as far as I recall from reading
the session code, if a session is opened for reading - it is also going to
be rewritten at the end of the session. So, it should be quite safe
Any chance you're using output buffering?
Zeev
At 12:25 14/08/2002, Joost Lek wrote:
Hello everyone,
I am new to this list, but urgently in need of a solution for a problem i
am currently facing.
First, i'll give a description of my current platform:
Linux 2.4.18 (origninally slackware,
+1
(as long as it's always #if 0_KALOWSKY :)
At 18:31 11/08/2002, Dan Kalowsky wrote:
Hello list,
Looking over the commit by Marcus on gd I noticed the #if 0 section on
some code.
I'd like to propose that the coding standard be updated to NOT do this,
but to do something like #if 0_KALOWSKY
The best sample is the CGI or CLI modules themselves. Just look at
./sapi/cli/php_cli.c or ./sapi/cgi/cgi_main.c.
Zeev
At 16:46 09/08/2002, Roland Bromann wrote:
I'm searching for a documentation or sample code to be able to use the
php4ts.dll in Windows client software. The purpose is, to be
I don't think it's identical. Casting to long truncates, which means you
may have an answer which is off by one.
At 11:28 03/08/2002, Andi Gutmans wrote:
I think this is a good question.
I'm not quite sure that casting dval to long is the same as multiplying
the two longs.
Anyone know the
Fixed (it had nothing to do with the script).
Zeev
At 04:14 31/07/2002, Dan Kalowsky wrote:
Hi,
Building PHP and running a test script with the CGI or CLI on my MacOSX
machine results in a a Bus Error upon script completion.
I have made a fresh checkout, built clean (with a cvsclean and
It's gone for me.
At 18:05 31/07/2002, Dan Kalowsky wrote:
Zeev,
It's still there... same bt, same spot. That crazy Bus Error... on debug.
---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~dank
FWIW, I don't see why releasing it should take 5 weeks. I think releasing
it can take pretty much as long as we decide it should take. I think we
just got used to have slow-moving, lingering release processes.
At 15:06 27/07/2002, Yasuo Ohgaki wrote:
[EMAIL PROTECTED] wrote:
I'm +1 for
At 14:20 24/07/2002, Yasuo Ohgaki wrote:
I don't think breaking compatibility is not needed now. However,
I'm not against to raise fatal error in PHP5. PHP5 breaks scripts
in many ways. Why don't we save it for PHP5?
Without paying attention to the specific issue, please snap out of this
state
I think it would be fair to say that we don't yet know anything
concrete. Anything you hear is just personal opinions of the people you're
talking to, or the ones of the people they talked to... With the 2nd alpha
out, I think it's reasonable to assume that the engine will be finalized by
At 06:53 PM 7/9/2002, Andre Gildemeister wrote:
hi,
in PHP5 it shall be possible to integrate own extensions (written in PHP),
called Packages. a package consists of functions and classes,
encapsulated in
an namespace. to make the package-elements available in an program, the
package
must
At 07:17 PM 7/9/2002, Melvyn Sopacua wrote:
At 17:05 9-7-2002, Zeev Suraski shared with all of us:
Basically, the Zend Engine 2 will allow the use of nested classes. So,
classes will be able to contain other classes, as well as constants in
addition to variables and methods.
That's already
At 08:00 PM 7/9/2002, Melvyn Sopacua wrote:
class foo {
//some code
require('class_bar.php');
}
Will that work?
No, that won't work.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
(Options FollowSymlinks). It would be nice to have the code
included in PHP.
Thanks in advance, Timo Weingärtner
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: Samstag, 6. Juli 2002 16:55
To: Timo Weingärtner
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] FEATURE REQUEST
At 02:44 PM 6/30/2002, Sascha Schumann wrote:
typedef struct {
char *line; /* If you allocated this, you need to free it yourself */
uint line_len;
long response_code; /* long due to zend_parse_parameters compatibility */
} sapi_header_line;
typedef enum { /*
Thanks for the clarifications. IMHO the advantage does not outweigh the
disadvantages (slower, more cumbersome to use, will require everyone to
implement two interfaces), so personally, I'm -1.
Zeev
At 06:30 PM 6/30/2002, Sascha Schumann wrote:
How is it better than add_header_ex()?
At 06:54 PM 6/30/2002, Sascha Schumann wrote:
On Sun, 30 Jun 2002, Zeev Suraski wrote:
Thanks for the clarifications. IMHO the advantage does not outweigh the
disadvantages (slower, more cumbersome to use, will require everyone to
implement two interfaces), so personally, I'm -1
At 02:29 AM 6/11/2002, Aaron Bannert wrote:
On Tue, Jun 11, 2002 at 12:38:44AM +0300, Zeev Suraski wrote:
There should be a way of doing that within the framework of flex by
redefining YY_INPUT and hacking around flex.
I'd love to see this built in to SAPI so that any module could take
At 10:19 AM 6/11/2002, Sebastian Bergmann wrote:
Alex Black wrote:
class foo aggregates bar {
}
I think that is a nice solution.
It's not, because it's static. Multiple iheritance is flawed, because
it's static.
That's hardly considered a flaw almost anywhere, even in the studies
At 11:23 AM 6/11/2002, Sebastian Bergmann wrote:
This way, an object of Foo can dynamically change behaviour in a very
elegant way.
I'm well aware of the strategy design pattern, but it existed before 'Lava'
(I use it in Java all the time)... You can just as easily do this by
creating a
At 09:03 AM 6/10/2002, Sander Striker wrote:
Why is PHP even using its own memory allocation scheme? It would be much
easier to just use pools and point out where it doesn't work for you.
Because we don't want it depend on any underlying services which aren't
available in all servers. We can
At 07:29 PM 6/10/2002, Aaron Bannert wrote:
On Mon, Jun 10, 2002 at 11:46:46AM +0300, Zeev Suraski wrote:
What we need for efficient thread-safe operation is a mechanism like the
Win32 heaps - mutexless heaps, that provide malloc and free services on a
(preferably) contiguous pre-allocated
If they end up in a circular reference (in this particular case they do,
they usually don't) then you're leaking memory.
Zeev
At 12:10 AM 6/11/2002, brad lafountain wrote:
I use parent members all the time.. w/zend1
- Brad
--- Markus Fischer [EMAIL PROTECTED] wrote:
Hi,
that's
There should be a way of doing that within the framework of flex by
redefining YY_INPUT and hacking around flex.
You can, by the way, provide a char * string, that already works today
(look at zend_eval_string() or zend_prepare_string_for_scanning()).
Zeev
At 12:23 AM 6/11/2002, Justin
I believe this has been discussed in the past and not ack'd, please read
the php-dev archives...
Zeev
At 10:19 PM 6/9/2002, Ivan Ristic wrote:
Several days ago I posted a simple patch to the Zend Engine,
to support automatic class loading. The code is almost completely
copied from the existing
PHP has its own buffering mechanism which can take care of this. Try
output_buffering = 4096 in your php.ini.
Zeev
At 08:33 PM 6/8/2002, Brian Pane wrote:
Looking at some more syscall call traces, I'm seeing that
the flush buckets used by php_apache_sapi_ub_write() are
causing very small
At 12:55 AM 6/9/2002, Brian Pane wrote:
I just looked through zend_alloc.c. It looks like the HeapCreate only
happens once, at startup--did I get that right?
It's called on the per-thread startup (start_memory_manager(), which is
called from alloc_globals_ctor(), which is the per-thread
At 02:57 AM 6/9/2002, Brian Pane wrote:
In the httpd, we've done two things to minimize the fragmentation:
* Memory for these heaps is almost always allocated in chunks of
a fixed size, 8KB.
Hmm, but doesn't that mean that the largest contiguous block this heap will
be able to provide is
At 05:46 PM 6/7/2002, Joseph Tate wrote:
How much of C has been reused, and reused and reused again? There is no oo
in stdlib.
Exactly. C is one of the easiest languages for code reuse, but it totally
depends on your programming habits and skill. As a matter of fact, I find
Java to be one
At 06:14 PM 6/7/2002, Jason T. Greene wrote:
True, I hear it is even possible to reuse code in COBOL : )
I believe that the ease of maintenance depends purely on the language.
i.e. using a strictly procedural language for a large framework can be
quite messy. Have you ever seen large libraries
There are two reasons we repeat the 'PHP is not Java mantra':
(a) Many of those requesting these changes actually DO want to see PHP as a
Java with PHPish syntax.
(b) Java is (so far) the best implemented OO language out there that's
actually being used. It symbolizes the extreme OO world, if
Brian,
We're on the job. I generally think you're right, we have to do some more
thinking but chances are we will change the shutdown order to be
reversed. Sorry for not ack'ing earlier.
Zeev
At 09:44 PM 6/7/2002, Brian France wrote:
Zend Engine unloading extension in the wrong order!
At 07:01 PM 6/6/2002, brad lafountain wrote:
Please don't reply to this email saying Use Java... Because php is different
than java and always will be even with these new features.
Brad, I beg you, there's nothing anybody can say on this list that would
lead this to closure. Nothing. I
At 07:00 PM 6/6/2002, Sebastian Bergmann wrote:
A user posted [1] a benchmark today in the German PHP Newsgroup [2]
stating that Apache 2.0 and PHP (current HEAD) are about 20% slower
than Apache 1.3.
Are there any official benchmarks out there? I can't quite believe
this...
Why
At 08:26 PM 6/6/2002, brad lafountain wrote:
--- Zeev Suraski [EMAIL PROTECTED] wrote:
At 07:01 PM 6/6/2002, brad lafountain wrote:
Please don't reply to this email saying Use Java... Because php is
different
than java and always will be even with these new features.
Brad, I beg you
Aggregation sometimes involves delegation. The 'parent' object delegates
requests to the right aggregated objects (in other cases, the 'parent'
object returns its aggregated objects and you use them directly).
Zeev
At 10:43 PM 6/6/2002, Sebastian Bergmann wrote:
Andi Gutmans wrote:
The
At 12:34 PM 6/4/2002, Sebastian Bergmann wrote:
Kristian Koehntopp wrote:
Peace through superior firepower? That's a trademarked american
concept at the moment, I think.
Pax Americana replaced Pax Romana a while ago :)
'cept there's no pax...
--
PHP Development Mailing List
At 09:48 AM 6/3/2002, Björn Schotte wrote:
more complexity to the language itself.
Why would making PHP more complex be a good thing?
Because not every web designer and semi-programmer could
then work with PHP - this lacks the image of PHP. (PHP
ist only good for guestbooks and very
John,
Whether we end up having private methods or not, it's way beyond their
scope to address the issue of security, and protecting data from someone
who has access to their code. It's always possible to work around that
level of 'security', whether it's in C++, Java or any other
language.
At 12:28 PM 6/3/2002, Kristian Koehntopp wrote:
I think that PHP should be only as newbie hostile as security
dictates (register_globals off and similar stuff). It should be
as convenient and easy to use as possible.
It should also provide hooks and means to reconfigure it
manually for those
At 04:28 PM 6/3/2002, [EMAIL PROTECTED] wrote:
I am curious, besides some language quarks, like multidimentional
arrays, what sorts of things can you do in Java which can not be done
in PHP?
I'm actually curious about the multidimensional arrays point. Exactly
what do you mean? PHP
At 06:03 PM 6/3/2002, Lukas Smith wrote:
(I wonder why none of them read this
list and said that they want to make PHP Enterprise ready ...)
You're kidding, right? (it doesn't mean that that's what we're going to do).
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe,
At 06:43 PM 6/3/2002, Sebastian Bergmann wrote:
Zeev Suraski wrote:
Amen to that!
Why does Kristian recieve an Amen to that! for saying the same things
I did? :-)
Hmm, because he's bigger? :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http
At 05:21 PM 6/2/2002, Sebastian Bergmann wrote:
Jani Taskinen wrote:
I'm not that familiar with Java..so it would be nice to hear
what Java offers that PHP doesn't?
Private members and methods, interfaces, Application Servers, Beans,
Enterprise Beans.
Seriously, Sebastian, if the only
At 09:13 PM 6/2/2002, Sebastian Bergmann wrote:
Andi Gutmans wrote:
Are you aware how complex and expensive it is to create a Java
application server solution?
Probably not. But I know that Derick et al. are doing a good job adding
Application Server-like functionality to the PHP
At 09:23 PM 6/2/2002, Björn Schotte wrote:
* Jani Taskinen wrote:
Could you explain in more detail what exactly these needs
would be?
As Sebastian mentioned (sorry I couldn't reply earlier,
we are currently moving PHP-Center/PHP-Conference to a
new machine) things like Application
At 12:13 AM 6/3/2002, Sebastian Bergmann wrote:
But, as I said before, I don't understand why simplicity should mean in
its consequence that software designs you find these days in the Java
World cannot be done with PHP. The essence (in one sentence) of what I
would like to see:
At 12:45 PM 6/1/2002, Christian Stocker wrote:
I believe that bundling at the makedist level makes the most sense,
because:
(a) Synchronization is trivial
(b) We get to choose what libxml we use, so our libxml-dependent code
doesn't have to support the zillion different libxml's out
At 02:23 PM 6/1/2002, Christian Stocker wrote:
If not - I see no problem in always using the bundled library,
regardless of what's already installed - on the contrary, I see a fairly
big advantage.
I see really no advantage in this approach (more memory needed for
example, maybe symbol
At 05:05 PM 6/1/2002, Sebastian Bergmann wrote:
Marko Karppinen wrote:
It seems to me that PHP is increasingly being modeled for a largely
imaginary audience of purists. I say imaginary because I just can't
see how droves of purists would've become involved with PHP in the
first place.
At 07:12 PM 6/1/2002, Björn Schotte wrote:
* Sebastian Bergmann wrote:
I don't want to see changes (like those you mention later in your
posting) in PHP to attract new users, but more to bind people that
already use PHP, but are about to outgrow it.
If you (and others) want PHP
Why not have a --bare (or equivalent) switch of that kind, to disable
literally EVERYTHING that's not mandatory? I believe the issue is that for
every 'purist' that cares about bloat, it's safe to say there's more than
one user (*) that prefers stuff to 'just work', and not mess with
I agree with every word.
Zeev
At 12:25 AM 6/2/2002, Shane Caraveo wrote:
I think PHP can be both powerful and easy to use, and I think I have an
example of that in my own experience. I've got code I wrote on PHP 2
years ago, that has gone through a couple face lifts and modifications to
At 07:16 PM 5/30/2002, Stig S. Bakken wrote:
On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote:
On Thu, 30 May 2002, brad lafountain wrote:
The 2M size has alot of stuff that we wouldn't need. Im sure we can
get it
down to under 500K.
I still think 500kb is too much for
At 07:08 PM 5/30/2002, [EMAIL PROTECTED] wrote:
On Thu, 30 May 2002, brad lafountain wrote:
The 2M size has alot of stuff that we wouldn't need. Im sure we can get it
down to under 500K.
I still think 500kb is too much for something the most ppl already have
installed.
How do you figure
At 11:39 PM 5/30/2002, Dan Kalowsky wrote:
On Thu, 30 May 2002, brad lafountain wrote:
I personally will take responsiblity for bundling and upgrading it.
As Rasmus stated earlier the reason the MySQL stuff is bundled is due to
an assurance from the MySQL developers to keep it updated.
I
Just an overall reply to a point you're making - yes, making the user
download and build something if he wants to use XML is really a con, in my
opinion.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
At 11:19 PM 5/31/2002, Andi Gutmans wrote:
At 13:12 31/05/2002 -0700, brad lafountain wrote:
Ok,
I think we are split in two about what to do here. Ill try and list the
different ideas that have been proposed.
1) don't include at all
pros:
No need to worry about auto install or
Guys,
Unless somebody strongly objects, I suggest we drop the discussion about
how horrible it would be to import libxml2 into our CVS. I believe it's
well established that it's a Bad Thing to do, there's no point hashing it.
I believe the question on the table is whether libxml2 is
Did you conduct a survey about that?
I believe there's at least one company that effectively proved that the
opposite is true, there are probably many others. I don't see a problem in
having core technologies enabled by default. Purists can turn them off,
but there are a hell of a lot more
As I told Stig yesterday, I think the main problem with PECL right now is
that when an extension is moved to PECL, its author gets the feeling as if
it was banished to Siberia, and that has to be changed.
I think that the moving of extensions to PECL was supposed to address the
problem of
At 00:08 24/05/2002, Rasmus Lerdorf wrote:
I really don't like the term Web Services. SOAP is an RPC mechanism and
has nothing to do with the web despite what M$ would like to have you
think.
I think that's kind of like saying HTML has nothing to do with the web, but
anyway, perception is
At 01:39 24/05/2002, Rasmus Lerdorf wrote:
Well, HTML is an intrical part of the Web and I don't see how that can be
compared to SOAP at all. In order for SOAP to be part of the Web it needs
to conform to the HTTP protocol and to the concepts that defines the Web.
It doesn't do that at all
Wild guess, but did you load an extension using dl() in the file that crashed?
Zeev
At 15:23 21/05/2002, Dave Brotherstone wrote:
Hi,
I've got a particular script that seg-faults when certain parts of it run
(tested with 4.1.0 and 4.2.1, both CGI and Apache module).
I've done a back trace,
EX(function_state).function is supposed to be a pointer to the op_array
that you passed to execute().
Any chance the op_array is somehow deleted by mistake? Did you try looking
at EX(function_state) and EX(function_state).function to understand why
it's dying?
At 03:02 PM 5/19/2002, Wez
At 04:38 PM 5/13/2002, Jason T. Greene wrote:
I do, for two simple reasons:
- Misperception about what it's supposed to do - it does NOT secure your
environment, people expect it to. That's a 'marketing' issue, but we
should realize that these kinds of issues are at least as important
php_version - Can be:
rem 1) A real PHP version, e.g. 4.0.3pl1, in which case
remphp-4.0.3pl1 will be used as the PHP source tree
rem 2) cvs, in which case the 'php4' directory will be used
rem 3) cvsup, which is like cvs, except the CVS repository
remwill be updated first
rem
rem Author: Zeev
At 08:53 PM 5/17/2002, Robert Cummings wrote:
Let's say I do:
zval *newVar;
MAKE_STD_ZVAL( newVar );
ZEND_SET_SYMBOL( EG(symbol_table), varKey, newVar );
and then I do:
MAKE_STD_ZVAL( newVar );
ZEND_SET_SYMBOL( EG(symbol_table), varKey, newVar );
This will overwrite
At 09:04 PM 5/17/2002, Robert Cummings wrote:
To be honest I'm passing the return_value into my recursion
Not sure what you mean by that - return_value is handled by the engine as
soon as you return from your function implementation, if that's what you're
asking. If you're using it
If you're adding elements to a hash you created using array_init(), and
you're using the standard macros (which apparently you are) - then yes, the
engine will take care of garbage collection for you.
At 09:27 PM 5/17/2002, Robert Cummings wrote:
Zeev Suraski wrote:
At 09:04 PM 5/17/2002
zval strings must be NULL terminated, even if they contain binary
data. The str.val.len property represents the length of the string w/o the
terminating NULL.
Zeev
At 16:39 14/05/2002, Robert Cummings wrote:
brad lafountain wrote:
Well i do believe that the zval string SHOULD be null
Jason,
He has a point in the sense that it's trivially easy to starve a PHP based
web server from within, safe mode enabled or not. What you describe as the
automated way in which the web server will overcome this attack is not
realistic - pretty quickly, the web server would hit the maximum
At 11:42 13/05/2002, veins wrote:
He has a point in the sense that it's trivially easy to starve a PHP based
web server from within, safe mode enabled or not. What you describe as
the
automated way in which the web server will overcome this attack is not
realistic - pretty quickly, the
We already tried our best to optimize most of the functions that show up in
profiling. Not surprisingly, they are mostly the infrastructure functions...
What profiler are you using? If it's under Linux, chances are it's
*extremely* inaccurate. Profiling under Linux is horrible.
Zeev
At
or less the same).
Zeev
At 18:43 13/05/2002, Rasmus Lerdorf wrote:
I did specify the profiler on line 4 of the message. And it is a pretty
good one actually.
On Mon, 13 May 2002, Zeev Suraski wrote:
We already tried our best to optimize most of the functions that show up in
profiling
At 23:59 13/05/2002, Stig S. Bakken wrote:
Seeing that the single most time-consuming function is zend_parse, it
would be interesting to see where the bottleneck moves when using
ZendAccelerator or another caching product. Did you try that setup with
NuMega's profiler?
It still stays in the
Hmm, then it could be fixed, but we shouldn't introduce a new implementation.
Assuming you refer to the large number of output calls, they can be saved
using output buffering - implementing localized buffering in every place is
not a good way to go by. I'm not sure output buffering was already
At 17:43 12/05/2002, Sascha Schumann wrote:
I've just noticed that you have kicked out the premier
implementation of the same functionality in favor of the dog
slow old one.
I almost missed those idyllic descriptions :)
Note that relying on output buffering alone is
At 17:58 12/05/2002, Sascha Schumann wrote:
What inherent flaws? So far, the only difference between them that I could
spot was that php_html_puts() was buggy, and did not convert series of
spaces into nbsp;'s. Otherwise, the only difference was the use of
buffering. I may have missed
At 18:24 12/05/2002, Sascha Schumann wrote:
- it is buffering as you already noted without having to rely
on the huge output-buffering infrastructure. I have not
benchmarked it, but I do assume that it is noticably slower
than php_html_puts.
- it is faster due to
201 - 300 of 1188 matches
Mail list logo
