That would be nice. If all memory, even the stuff allocated by functions, is
freed at the end of the request, I can see where the problem is. It would be
very useful if this memory really would be freed at the moment all
references to it disappear. This would be a lot better for the CLI
environment
After a discussion between Andi and myself, with his blessing I am
assuming the 5.1 RM role. The passing along of the RM mantle will
hopefully permit us to revitalize the 5.1 release process and get this
thing outta the door.
So, here is the plan [tm] :-)
I would like to release RC2 within week,
Hi Edin,
Thanks for the work done with pecl4win. Are you planning on
committing the pecl4win website to CVS?
Regards
--jm
On 9/29/05, Edin Kadribasic <[EMAIL PROTECTED]> wrote:
> Hi,
>
> For those of you that I didn't already bother with the news :)
>
> There is a new site for downloads of prec
On Oct 6, 2005, at 10:56 AM, Derick Rethans wrote:
I am thinking that we're doing something with the unicode
implementation and
that's that we're now getting duplicate implementations of quite some
things:
functions, internal functions, hash implementations, two ways for
storing
identifiers...
There was some mail about the memory handling some time ago on
this list..something about making it better in these cases..
Try search the archives for this. (I can't find it right now)
IIRC, there even was a patch..
--Jani
On Thu, 6 Oct 2005, J. Allen Dove wrote:
Unset()
Need to patch a few more files:
On Oct 6, 2005, at 1:34 PM, Brian J. France wrote:
The following patch is need if phpize is going to be used to build
ext/gd with the bundled libgd library.
Otherwise HAVE_GD_BUNDLED will not be set for the bundled lib so it
will not build with the php_gd_ pref
Unset() != free() is the bummer in the CLI env. :-( Def could use that
to help shape the performance contour in a daemon env since the
"request" never ends unless you self-terminate. Even then it can be
tricky to get that lifetime right if your loads change, etc.
-- AD
> "leak", which honestly
On Thu, 6 Oct 2005, J. Allen Dove wrote:
"leak", which honestly surprised me. We even explicitly unset the vars
but that doesn't guarantee the GC kicks off for them near-time?
unset() != free(). The memory allocated is still freed during
the request shutdown (where GC actually kicks in
The following patch is need if phpize is going to be used to build
ext/gd with the bundled libgd library.
Otherwise HAVE_GD_BUNDLED will not be set for the bundled lib so it
will not build with the php_gd_ prefix, but the extension will have
HAVE_GD_BUNDLED defined and expecting the php_gd_ pr
This "fast-and-loose" behavior was what we figured would happen with
resources in PHP, especially if you do things in a lower scope that do
not get passed back/referenced to a higher scope. Since the concept of
scope gets a little gray in PHP we explicitly close the resource in the
"scope" it was o
Thanks! That was very useful information. Had to go with the #3a solution
as I need to be compatible with PHP4.
I still have some problems with my extension though. The extension
maintains a module global C++ std::map allocated in my MINIT function and
deallocated in my MSHUTDOWN function. Thi
Hello Derick,
Thursday, October 6, 2005, 7:56:34 PM, you wrote:
> Hello!
> I am thinking that we're doing something with the unicode implementation and
> that's that we're now getting duplicate implementations of quite some things:
> functions, internal functions, hash implementations, two ways
Hello Andrei,
transparent == doesn't really matter. And if you insist, will you write
all the tests and maintain them?
marcus
Thursday, October 6, 2005, 7:21:31 PM, you wrote:
> It has nothing to do with the encoding. var_dump() outputs the value
> type, which is 'string' for native strings
There was once (can't remember when exactly, so it must be a long time
ago)
here on PHP CLI scripts in which it came forward that one should not rely
on
such a script to run forever. And it's true; the scripts sometimes
magically
and suddenly die. Now I have no clue where this instability (for
Hello!
I am thinking that we're doing something with the unicode implementation and
that's that we're now getting duplicate implementations of quite some things:
functions, internal functions, hash implementations, two ways for storing
identifiers... only because we need to support both IS_STRING
Marcus Boerger wrote:
execution (e.g. unicode_semantics=on). The easy way out is to have var_dump
not print 'unicode' for namely values but instead use 'string' always. Since
the encoding is meant to be transparent anyway there shouldn't be a problem.
And in case we have tests where the differen
Re: the cause of the cause, our speculation based on an occasional error
message had to do with the process running out of the "special" unix
file handles. The processes open and close lots of files (and yes, we
are explicitly closing files) and it seems for no rhyme or reason after
the processes r
It has nothing to do with the encoding. var_dump() outputs the value
type, which is 'string' for native strings and 'unicode' for Unicode
strings. I don't see why we should merge the two.
-Andrei
On Oct 5, 2005, at 4:14 PM, Marcus Boerger wrote:
Hello guys,
i had a chat with Dmitry this m
> FWIW
A lot :) Thanks for the response. It's good to see it is possible.
> However, a process running for a long time (yes, even on
> Linux) will also just "die" for no reason. We have a few hints as to
> what causes the deaths but don't know what causes the cause. To solve
> the problem we creat
FWIW, we have been running a number of very high-volume PHP CLI daemons
for the last 18-20 months with great success. That is not to say it
wasn't a challenge to get them as "stable" as a C++ daemon but we have.
PHP 4.x CLI seemed to have a mem leak somewhere, PHP 5.x seems to have
resolved that. H
Edin Kadribasic wrote:
> Hi Jani,
>
> Your commit r 1.16 to ext/date/lib/timelib_structs.h broke the build on
> Windows platform.
>
> -#include "timelib_config.h"
> +#include
>
> Why was this change neccessary and if it's not really, would you please
> revert it?
After strugling to get an anwe
I've had PHP scripts die after weeks or months on Linux without an obvious
reason, and honestly I'm a little bit puzzled on how to debug the situation.
Any suggestions?
Ron
"James Aylett" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> On Thu, Oct 06, 2005 at 12:33:16PM +0200, Pe
On Thu, Oct 06, 2005 at 12:33:16PM +0200, Peter Brodersen wrote:
> Jani mentioned in http://bugs.php.net/bug.php?id=34483 : "Running a
> PHP for 24 hours (under windows) is REALLY not supported or suggested.
> It's definately nothing to do with PHP but your OS." (and "Try this on
> a real OS, like
On Thu, 6 Oct 2005 10:48:51 +0200, in php.internals [EMAIL PROTECTED]
("Ron Korving") wrote:
>There was once (can't remember when exactly, so it must be a long time ago)
>here on PHP CLI scripts in which it came forward that one should not rely on
>such a script to run forever. And it's true; the
Hi,
On Thu, 6 Oct 2005 12:26:30 +0300 (IDT), in php.internals
[EMAIL PROTECTED] (Stanislav Malyshev) wrote:
>The subtle differences are mostly because many of the developers don't
>care for the BC. This leads to a state when if you code runs on x.y.z
>version of PHP, you can't really be sure it
Derick Rethans wrote:
On Wed, 5 Oct 2005, Greg Beaver wrote:
...
I do believe that:
#ifdef PHP_WIN32
#include "timelib_config.h"
#else
#include
#endif
should fix the windows build without ruining the patch.
No, can't do that as PHP_WIN32 is not defined for the standalone
library.
Not s
HH>>So i'm all for keeping the $this-> prefix even though it adds some
HH>>extra typing ...
Socond that also.
I see no reason to change this for the sake of typing 6 characters.
>
> --
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.1
This one time, at band camp, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> HH>>So i'm all for keeping the $this-> prefix even though it adds some
> HH>>extra typing ...
>
> Just a thought - we could have compromise solution, i.e. some syntax sugar
> to mean $this->foo - for example $.foo or s
JC>>> I am quite getting tired of having to maintain BC for *every* little
JC>>> stupid thing we ever did. I think it's time to start with a clean slate
JC>>> as it's all getting way to annoying to maintain (and know what subtle
JC>>> differences there are between PHP versions).
The subtle dif
On Thu, 6 Oct 2005, Stanislav Malyshev wrote:
HH>>So i'm all for keeping the $this-> prefix even though it adds some
HH>>extra typing ...
Just a thought - we could have compromise solution, i.e. some syntax sugar
to mean $this->foo - for example $.foo or something like that. This way we
have c
HH>>So i'm all for keeping the $this-> prefix even though it adds some
HH>>extra typing ...
Just a thought - we could have compromise solution, i.e. some syntax sugar
to mean $this->foo - for example $.foo or something like that. This way we
have clear visual difference between locals and prope
Hi,
There was once (can't remember when exactly, so it must be a long time ago)
here on PHP CLI scripts in which it came forward that one should not rely on
such a script to run forever. And it's true; the scripts sometimes magically
and suddenly die. Now I have no clue where this instability (for
Thanks! That was very useful information. Had to go with the #3a
solution as I need to be compatible with PHP4.
I still have some problems with my extension though. The extension
maintains a module global C++ std::map allocated in my MINIT function
and deallocated in my MSHUTDOWN function. Thi
33 matches
Mail list logo
