"Dmitry Stogov" wrote in message
news:4dd63c03.3090...@zend.com...
> The main idea of the patch is inlining and I don't know how can I inline
> from external file.
via #include and macros, as many others do.
see longlong.h in GNU libgcrypt-1.4.6/libgcrypt-1.4.6/mpi/
just my 2c
--
PHP In
> All,
>
> I have cross-compiled php-cgi for a MIPS device (mediaplayer), but the
> binary is quite large, more than 3MB. I'm using:
>
> ./configure --prefix=../result/php-5.3.5 --host=i686-pc-linux-gnu
> --target=mipsel-linux-gnu --build=mipsel-linux-gnu --enable-cgi
> --disable-all --without-pear
"Stas Malyshev" wrote
> Hi!
>
>> An example of non-thread safe is gettext it relies on the locale which is
>> per process and not per-thread.
>>
>> PHP itself at the core is thread safe. As Johannes said most common
>> modules are too.
>
> ICU btw has some global stuff too.
I think it's clear t
> "Scott MacVicar" wrote in message:
> >
> >
> > Do you think any locking function is implemented in openssl php
> > extension?
> >
> In PHP a SSL_CTX is per thread and is not shared across other threads so
> it isn't an issue. We don't need to implement any openssl locking
> functions.
It doe
>> No. Php if we talk about php with all its extensions is not threadsafe
>> at
>> all. Many of the extensions allocate static data and inherently
>> non-thread-safe.
>
> PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
> some extensions might not be thread safe, but basically
"Israel Ekpo" wrote in message
news:aanlkti=ixwqkkovkyuluqckdvklqy2nyeyg6pjfza...@mail.gmail.com...
> In multi-process environments, such as FastCGI, Apache Prefork MPM etc,
> PHP
> needs to execute the MINIT and MSHUTDOWN functions for all loaded
> extensions
> on every request.
You're not co
>
> Yes, there is a reason:
>
> As it was explained before, lemon would not display token names but
> actual token "values". So instead of "Unexpected T_PAABLAH" it would say
> "Unexpected '::' ..."
>
hello,
value of some tokens is not what would be expected either. Think a bit about
T_STRING for
> > Until version 5.3.2 this worked fine, starting from version 5.3.3
>> parent::getFoo() calls __callStatic() instead of __call().
>>
>> This is a really bad BC change which i thought you decided to accept only
>> in minor versions change and not patch-level versions change.
>>
>> Anyway, I would
>> Rasmus meant (include|requrie)_once, where the same files should be
>> caught
>> indeed.
>> As of file_exists(), why would it need realpath's logic at all?
>
> In case open_basedir is enabled we have to do some more verifications,
> as we have to resolve the true base.
>
> johannes
>
>
Good poi
> Hi.
>
> This was discussed before.
> see
> http://www.mail-archive.com/internals@lists.php.net/msg37211.html
>
> Tyrael
>
Rasmus meant (include|requrie)_once, where the same files should be caught
indeed.
As of file_exists(), why would it need realpath's logic at all?
-jv
--
PHP Internals
>"Scott MacVicar" wrote:
>Yeah because /* */ has a clear end where // and # doesn't.
>
>- S
Shouldn't the end of the line be always considered as a true end of the
one-line comment?
In other words, I think it always has a clear end too.
Similarly, lexer always regognizes the strings - their star
> Parsing ends with ?> regardless if its a comment or not but its not
> context sensitive. It can't understand that its within a string.
>
> - S
Not exactly, it's only // comment style does not comment the tag while /* */
does.
The following script outputs its 'afafa':
'; */
echo 'afaf
>> Competition between opcode caches for php will definitely be reduced by
>> adding APC into the core,
>> so the market will shrink, of course.
>
>
> i think this is a likely outcome indeed. it might also be phrased in a
> more
> positive tone in that likely efforts will be joined. for example ma
>> Then is there any reason not to add all code compatible in php license
>> terms
>> into php core?
>
> What are you talking about? Who said that we have to add any php
> licensed code to the core? I only said that the license is a critical
> part of the decision. Nothing else.
APC can be added
> This bug is not APC specific.
>
In this case you can easily point out to another module suffering from this
bug, don't you?
>> License argument does not work at all.
>
> It does, more than ever.
Then is there any reason not to add all code compatible in php license terms
into php core?
If no
>> keep on the topic pls, which is the inclusion of potentially buggy and
>> poorly maintained APC.
>
> I'm on topic. You seem to be able to fix this bug very easily, I only
> told you how to provide patches.
I do not care of bugs in APC unless this module is NOT in php core.
If they appear in php
>>>
>>> By the way, including APC in the core is actually likely to fix this
>>> problem because it has to do with the order the rshutdown functions are
>>> called. Read Christian's excellent description of the problem here:
>>>
>>> http://news.php.net/php.internals/46999
>>>
>>> -Rasmus
>>
>> conc
>> This is an unfixed PHP bug. There have been a number of threads about
>> the object destruction order on internals. It isn't just APC that is
>> affected by this. Other extensions are affected as well.
>
> I understand that this effect is caused by the fact that APC destroys PHP
> classes ea
"Rasmus Lerdorf" wrote in message
news:4c1ed90d.2030...@lerdorf.com...
> On 6/20/10 7:44 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> Can you elaborate? What "average user"-facing features are non-obvious?
>>> We should document them if nothing else.
>>
>> This recently caught my attention:
>> http://
>
> "Ilia Alshanetsky" wrote in message
> news:aanlktilzlbbfucuv-jtmkm-qljl1il7wsqy0fyhn3...@mail.gmail.com...
> Including into core of PHP has no impact on other opcode caches, if
> they do a better job then APC, people can definitely (and should) use
> them. The main purpose of including APC wo
"Ilia Alshanetsky" wrote in message
news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org...
> Several reasons:
>
> 1) APC is well maintained, by the same people who work on PHP.
>
> 2) The license does not preclude it's inclusion into the base version.
>
> 3) most people don't use any opcode cas
>>
>> For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
>> another php.ini flag (sorry!) to choose the behaviour.
>
>-1 from me.
>I don't think we need to keep backward compatibility for this. PHP-6 is a
>major release, after all.
>
>It would be absolutely enough to add optional var-
> On Wed, Jan 20, 2010 at 02:29:27PM -0800, Rasmus Lerdorf wrote:
>> Well, that conversion still needs to happen somewhere, since plenty of
>> apps call extract() on those superglobals, but with register_globals
>> entirely gone in PHP 6, I suppose that conversion can be moved to the
>> extract() c
> as far as I see, the changes depends on how many work has to be done,
> to preserve something.
I see the same.
> posix functions like split, and so could have been modified to work
> with the unicode strings, but nobody cared enough.
Because this work is not in the TODO (milestones).
-jv
>> > We are letting you know that you need to start thinking about
>> > migrating your code away from non-Unicode aware functions like
>> > ereg() and split().
>>
>> Well, this filled up my php logs with some million records telling me
>> this! Do you think it's safer to keep thinking and have an o
> Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for _fun_ by core developers and brought
headache
to people developing in php.
> We are letting you know that you need to start thinking about migrating
> your code away from non-Unicode aware functions like ere
> jvlad wrote:
>>> $a = array(1);
>>> $b = 0;
>>> $c = &$b;
>>> foreach($a as $c);
>>> Now you are arguing that $b should not be 1?
>>> The two pieces of code are identical
>>
>> It's just a nightmare example. I wonder
>
> No chance. No .ini settings, and I still maintain it is inconsistent.
>
> So, if I write this:
>
> $a = array(1);
> $b = 0;
> $c = &$b;
> $c = $a[0];
>
> Would you agree that $b should be 1 at this point? If so, just because
> I rewrite that code like this:
>
> $a = array(1);
> $b = 0;
> $c =
"Rasmus Lerdorf" wrote in message
news:4b3785ac.2000...@lerdorf.com...
> We can't just randomly reset variables based on their scope in this one
> specific case. If we are going to "fix" this, it should be done by
> introducing a way to do proper local scope variables. Resetting a
> reference s
> Hi Pierre,
>
>
>> slow (as you noticed). However it can't be done in 5.3 as it will
>> break the ABI.
>>
>
> I noticed that a recent fix (http://bugs.php.net/bug.php?id=49936)
> added TSRMLS_DC to an API in 5.3.
> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/streams/php_stream_cont
ively. So, still no problems. ID clearly indicates whether an
extension
can be used with particular php core distribution. It's only necessary to
add CPU :)
-jvlad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ted and
what module among hunderd others to pick and install. So, you usee it's not
a way to dictate
the loader what to load. It's a way for installer to be wise enough.
-jvlad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
VERSION,HOST,CPU
for example:
Windows Seven,6.1.0.7600,MyHostName,x86_64
and btw, it should be clear that Architecture is compile-time thing,
not run-time, so there is one more reason to move it to id-string.
-jvlad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
dled together in the same
> binary, and, a binary built 2 ways [i386 and PPC or i386 and x86_64 or
> even 4 ways for that matter] can work on any of these archs. How do you
> suggest to handle that?
>
> May the source be with you,
> Best regards,
> Jess Portnoy
>
>
>
would like to add
>> it in the "php -v" output as well. I'm not sure how we can safely rely
>> on this info on other platforms but that's definitively something we
>> should try to do.
>>
>> Cheers,
>> On Sun, Nov 29, 2009 at 11:29 AM, jvlad wrote:
verything). Why not to add what
phpinfo() shows in Architecture, to the id string? Are there any reasons not
to do this?
-jvlad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> The problem with the segfault in memcpy from bug 50207 was that the
> pointer result->value.str.val is a 64 bit unsigned integer, and of
> course result->value.str.len is a signed 32 bit integer. The value of
you're right, len is declared as int and it's indeed 32bit under 64bit
Linux.
It must
> Hi folks,
>
> after discussing the idea with various PHP developers
> I now felt safe enough that it's not a completely stupid
> idea to post an RFC for it. The idea is to add support
> the registration of > custom factories which are
> responsible for instantiating certain classes.
>
> Here is
> Code:
> $s = str_repeat('A', pow(2,30));
> $t = $s.str_repeat('B', pow(2,30));; // fails with segfault
> printf("strlen: %u last-char: %s", strlen($s), substr($s, pow(2,30)-1));
> ?>
> ---
> Result:
> ./sapi/cli/php -d memory_limit=-1 a2.php
>
> Fatal error: Out of memory (allocated 2148270080)
"Mathieu Suen" wrote in message
news:4af91f92.4000...@easyflirt.com...
>
> Why isn't a mater of pushing the function call statement into a valuable
> statement?
>
> I guess something like this:
>
> statement :
> | value
> | function_call;
>
>
> value :
> | valriable
> | array_access
> | method_s
>>> I have filed a bug (suggestion) at http://bugs.php.net/bug.php?id=50003
>>> What do you think about enabling such a constructions in future
>>> versions of
>>> php?
>>On Nov 9, 2009, at 1:41 AM, David Zülke wrote:
>> It's already on the list for PHP6:
>>
>> http://wiki.php.net/summits/pdmnot
>> If you care not to waste userland with new names, use namespaces,
>> that's the way intruduced by php, and it is not javascript after all.
>>
>>
>
> I'm so old school in my coding, I've not got my head around namespaces
> yet. I'm just old.
>
There is nothing really "new" in namespaces.
For exam
>>
>>
>
> Whilst you are all thinking about this, how about ...
>
> $value = (function(){return $x;})();
>
> Being able to call an anonymous function inline would certainly be a
> useful mechanism. Allowing calls without creating dummy user land vars
> would be consistent with func()[0].
>
If you
""melfar"" wrote in message
news:0f.f6.03668.ad206...@pb1.pair.com...
> Hey,
>
> Yep, I think there might be some caveats to that change.
> The original patch did not work on methods, so I've fixed that and also
> made the return value an rvalue, so that you can't attempt to modify the
> tempora
> Hi,
>
> This is not allowed since declaration values should be resolvable at
> compile time. I.e. they can not be an expression, but only a value
> literal.
>
> While technically expression folding is possible, it's not implemented in
> any part of the PHP engine (AFAIK), and I don't think it'
>>> I'm wondered why the shebang line support was removed from scanner.
>>
>> Because it didn't make any sense for other SAPIs. You could ask Ilia more
>> about it:
>>
>> -
>> r273178 | iliaa | 2009-01-09 19:21:12 +0200 (Fri,
> Hi,
> Can this snippet of shebang checking be removed for php 5.3.+, 6?
> Its for external FPM project.
>
> cgi_main.c:
> php_fopen_primary_script(&file_handle TSRMLS_CC);
>
> if (CGIG(check_shebang_line) && file_handle.handle.fp &&
> (file_handle.handle.fp != stdin)) {
> /* #!php support */
> c
From: "Richard Quadling"
Newsgroups: php.internals
Sent: Monday, September 07, 2009 3:44 PM
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0
2009/9/7 jvlad :
> And for windows, the shebang line is not used. So becomes part of the
> output - no matter what SAPI is used.
>
&
> If this is indeed a use-case for CGI then I think it's a valid argument
> and we are probably better off supporting it. I did not remember shebang
> works for real CGI.
> There are still plenty of use-cases for running CGI (as opposed to
> FastCGI) in the industry.
> Question now is whether this
"Jani Taskinen" wrote in message
news:4a9bb132.6080...@iki.fi...
> On 08/31/2009 12:06 AM, Pierre Joye wrote:
>> Hi,
>>
>> While trying to fix some tests, I found that display_startup_errors is
>> ignored by some startup errors like deprecated ini settings. Using:
>>
>> php -d display_startup_e
l 10, Bus error.
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
5371INIT_PZVAL_COPY(tmp, array_ptr);
(gdb) bt
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_
> can you run the custom gdb dumpbt so we can see which line of
> install-pear-nozlib.phar is triggering the error?
>
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/ext/phar/phar.php:10
--
PHP Internals - PH
m building php on this machine since php version 4.2.0,
always quite successfull, except php 5.3 :)
> You might try using gdb, start it up, and run with:
>
> -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir=
> -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0
> install-pear-no
>Or it could be possibly fixed by including , like
>"win32/php_stdin.h" is included on Windows thrus no compilation error
>here. Let me know if the following patch fixes your problem:
>
>Index: php_spl.h
>===
>RCS file: /repository/php
d suggestion, but can hardly be followed.
Even the most recent OpenBSD (ver 4.5) comes with gcc 2.95 and 3.3.5 (see
http://www.openbsd.org/45.html#new)
Ver4 is no an option under this platform.
I just tried on another hardware with 1GB RAM. It successfully passed
ext/fileinfo/libmagic/apprenti
>
>> Is it a known problem?
>> Is this requirement specified somewhere?
>> Can it be fixed or improved?
>
> Try compiling with -O0
unfortunately, it did not help (tried with fresh sources):
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-dep
>>> Generating phar.php
>>> *** Error code 138
>>> make: Fatal error: Command failed for target `ext/phar/phar.php'
>>>
>>
>> next run of "make install" produces:
>>
>> $ make install
>> Generating phar.phar
>> make: *** [ext/phar/phar.phar] Bus Error (core dumped)
>
> System information, compiler,
>>> As of php5.3-200906221030, the problem under *BSD platforms that I'm
>>> talking
>>> about is still the same.
>>
>> I see no compile failure bug reports against FreeBSD in the bugtracker...
>>
>> I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
>> 3hours ago, you'll have to
>> Did you hear about crashes under Solaris and MacOSX, and compiler
>> failures
>> under all *BSD systems?
>> They were posted against RC3 and the problems are still the same in RC4.
>
> We fixed several compile failures recently (both FreeBSD related and
> GCC2), it probably didn't make it into
>> In other words, I see two bugs there:
>> 1. PHP depends on the system-wide installed pear and tries to run it.
>> 2. One or many files are missed in the package producing the "Archive.php
>> class file not found" error.
>
> 1. you're wrong, PHP does not depend on system-wide installed pear, it
>
> >
> > 1. you're wrong, PHP does not depend on system-wide installed pear, it
> > will simply use it if present
> > 2. nothing is missing. see http://pear.php.net/PHP_Archive
> >
> > If installed, phar.phar will function (partially) without the phar
> > extension being present.
> >
> > In other w
>> php5.3-200906221030 make produces suspecious output under FreeBSD
>> 6/amd64:
>>
>> Generating phar.php
>> Generating phar.phar
>> pear: not found
>>
>> Pear package PHP_Archive or Archive.php class file not found.
>>
>
> This is not
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.
>>>
>>> We fixed several compile failures recently (both FreeBSD related and
>>> GCC2), it probably d
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.
>>>
>>> We fixed several compile failures recently (both FreeBSD related and
>>> GCC2), it probably d
> I see no compile failure bug reports against FreeBSD in the bugtracker...
>
> I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
> 3hours ago, you'll have to be slightly more specific.
>
NetBSD 3/x86 crashed:
/bin/sh
/home/jvlad/php/php5.3-200906221030/l
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.
>>>
>>> We fixed several compile failures recently (both FreeBSD related and
>>> GCC2), it probably d
""jvlad"" wrote in message
news:38.7a.20019.c9d6f...@pb1.pair.com...
>>> Did you hear about crashes under Solaris and MacOSX, and compiler
>>> failures
>>> under all *BSD systems?
>>> They were posted against RC3 and the problems a
>> Did you hear about crashes under Solaris and MacOSX, and compiler
>> failures
>> under all *BSD systems?
>> They were posted against RC3 and the problems are still the same in RC4.
>
> We fixed several compile failures recently (both FreeBSD related and
> GCC2), it probably didn't make it into
> Hi,
>
> It looks like nothing critical has popped up since RC4.
> So it looks like we will be sending the final stable release to the
> mirrors next Wednesday and announce the release on Thursday barring any
> critical issues emerging in the next days. In the mean time test test
> test. If i
>> If the bug #48583 can't be accepted through bugs.php.net, I think it
>> makes
>> sense to discuss it here.
>
> It's not a bug but "chicken'n'egg'" issue. Errors are displayed by default
> (IIRC) so if the ini file does not get parsed an error is outputted which
> IS
> --Jani
I don't agree,
If the bug #48583 can't be accepted through bugs.php.net, I think it makes
sense to discuss it here.
In short the question is:
Should display_errors and the other error-routing settings work or not?
I belive they are very important and should always work.
Just my 2cents.
Long story:
display_er
>> Core was generated by
>> `/export/home/jvlad/php/php-5.3.0RC3/sapi/cli/php -n -dshort_open_tag=0
>> -dsaf'.
>
> What's the full command line and the script being executed?
I'm not sure how to check it.
> Best would be to reduce the script to the
>
> On Wed, 2009-06-17 at 13:49 +0400, jvlad wrote:
>> solaris2.8/sparc 32bit (it's 32bit, not 64bit as I mentioned before):
>
> yes, I used 32bit on the niagara box, too.
>
>> $ uname -a
>> SunOS qu1 5.8 Generic_108528-11 sun4u sparc SUNW,UltraSPARC-IIi-cEn
>> solaris2.8/sparc 32bit (it's 32bit, not 64bit as I mentioned before):
>
> yes, I used 32bit on the niagara box, too.
>
>> $ uname -a
>> SunOS qu1 5.8 Generic_108528-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
>
> I used a similar machine from our lab now and did some tests and
> couldn't reproduc
un-Fire-T200 Solaris
>
> Can you give more details on your configuration? (compiler, configure
> flags, )
>
> johannes
>
solaris2.8/sparc 32bit (it's 32bit, not 64bit as I mentioned before):
$ make install
Installing PHP SAPI module: cgi
Installing PHP CGI binary:
> Plan to share any of these errors with us? We don't have all platforms
> available for testing.
>
> Scott
/bin/sh
/home/jvlad/php/php-5.3.0RC3/libtool --silent --preserve-dup-deps
--mode=compile
gcc -I/home/jvlad/php/php-5.3.0RC3/ext/fileinfo/libmagic -Iext/fileinfo/
-I/h
>> Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/
>> amd64,
>> NetBSD 3.1/x86, and OpenBSD 4.1/x86?
>> Under these platforms gcc hangs in
>> php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo
>> produces
>> further errors in spl and date.
>> Under Solaris 2
>
>> Under windows php crashes in fastcgi...
>
> Pardon? where?
Pardon, threre:
http://bugs.php.net/bug.php?id=48563
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi All,
Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/amd64,
NetBSD 3.1/x86, and OpenBSD 4.1/x86?
Under these platforms gcc hangs in
php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo produces
further errors in spl and date.
Under Solaris 2.8/Sparc/Sparc6
>
> How does one do the equivalent of Makefile.frag for the windows build?
>
AFAIK only config.w32 files are used under Windows and they are used only
when buildconf.js creates configure.js in the root directory of the sources.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
>> Recently I faced with one funny problem in PHP. Seems there is no way to
>> run
>> a sub-process using exec() (or backticks), and pass there specially
>> crafted environment without affecting all running threads. As soon as I
>> update the environment, all other threads see the change. It's
>>
Hi all,
Recently I faced with one funny problem in PHP. Seems there is no way to run
a sub-process using shell_exec() (or backticks), and pass there specially
crafted environment without affecting all running threads. As soon as I
update the environment, all other threads see the change. It's
""William A. Rowe, Jr."" wrote in message
news:49cb613b.4070...@rowe-clan.net...
> Rathnakar Konda wrote:
>> after observing lots of core dumps from apache, we got a different
>> segfault and its back trace is given bellow
>>
>> #0 0x2aaab1c46688 in ZEND_FETCH_DIM_RW_SPEC_VAR_UNUSED_HANDLER
"Rasmus Lerdorf" wrote:
> shire wrote:
>> I agree for the general case, in our development environment though this
>> might cause some pains. But we could always start there and see how it
>> goes. I agree that Xdebug isn't really a use case we always need to
>> optimize for.
>
> Is it ever a ca
> Hi!
>
> Attached is the patch implementing build ID. Please comment. If no
> objections are raised I'm going to commit it tomorrow.
...
>+ fprintf(stderr, "Cannot load %s - it was build with configuration %s,
>whereas running engine is %s\n",
Why not to call zend_error instead?
It would make mo
> I meant "readable" :)
>
>> Do you mean this?
>> fprintf(stderr, "%s requires Zend Engine API version %d.\n"
>> "The Zend Engine API version %d which is installed, is
>> outdated.\n\n",
>> new_extension->name,
>> First of all, php error_log may not get this message because it's thrown
>
>>> Not much work - I think I can do it in 1 day.
>>
>> Please don't forget to add human-readable error message when the IDs
>> don't
>> match.
>> Better to have different errors for different mismatching parts.
>> It's important because not all administrators are good with understanding
>> realte
>> how much work will this be?
>
> Not much work - I think I can do it in 1 day.
Please don't forget to add human-readable error message when the IDs don't
match.
Better to have different errors for different mismatching parts.
It's important because not all administrators are good with understan
>> seems you're flying too high.
>> RHEL5 still ships php5.1.6 and it has this option and it undefines
>> ZEND_USE_ZEND_ALLOC.
>
> PHP 5.2.0 has been released more than 2 (two) years ago, which should be
> enough for a distro to catch up, don't you think so?
Perhaps. But what they ship with RHEL5
> ZMM does never release memory to the system.
my appologies, "never" is a too strong word for that. I'd use "almost
never".
Indeed ZMM does release segment to the OS if all the memory blocks in it are
freed.
I'd only add that with an average script, it won't happen.
jv
--
PHP Internals - P
> On 11.01.2009 03:21, jvlad wrote:
>> Almost.
>> Try to compile your very-own-version of php, using configure argument
>> --disable-zend-memory-manager
>
> There is no such configure option since ages.
seems you're flying too high.
RHEL5 still ships php5.1
> Since I use a MySQL connection, Syslog and many classes, I wanted to let
> the script run a while before restarting. So the scripts had lines like:
>
> $i = 1000;
> while( --$i )
> {
> while( run() ); // run returns false if there are no pending jobs
> gc_collect_cycles();
> // echo get_memory
>>> For those that do not understand very well the explanation of jvlad...
>>>
>>> He's suggesting to change the class struct to be an scope struct, and
>>> have a property that tells if it's a namespace or a class, and reuse
>>> the impleme
> > > So as prevoius speaker suggested, and I personaly got to conclusion in
> > > other thread that ":" is ideal. Short, isn't taken.
> >
> > $a = $b?A:B:C:D;
>
> Will _you_ write such code? No. Will anybody from this list write such
> code?
You may want to write
$a = $b?A:B:C
and how would php
> Adding support for functions, constants and even variables is actually
> quite do-able with the solution I suggested (different separator between
> namespace name and function/constant/variable name) and can be added
> easily.
> Adding support for functions, constants and even variables is actu
I share your thoughts and yes namespaces are needed and wanted, but what's
implemented at the moment is quite far from what I'd call a namespace. I
need and want to see there all language entities including variables,
constants, classes, interfaces, and functions. Want to see them all
supported
>
> or just leave the organization of things to classes (with long class
> names with a nice prefix to prevent collissions) and leave it to
> class_alias() (and equivalent features for functions .. also with the
> option of a compile time aliasing) to handle the aliasing.
>
> this removes the ne
""Steph Fox"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> For those that do not understand very well the explanation of jvlad...
>
> Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out
> there. It has
""Guilherme Blanco"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> For those that do not understand very well the explanation of jvlad...
>
> He's suggesting to change the class struct to be an scope struct, and
> have a property tha
Hello all,
May I suggest something in this area?
I hope it will resolve some problems related to namespaces and classes
ambiguity.
Let's first take a look at the classes.
In-general they represent two things: scope and data.
Scope is a thing that can't be changed without compiler efforts and con
1 - 100 of 103 matches
Mail list logo
