I use graceful restart quite often.
Frankly, I have no idea why it may fail to work :)
Indeed, when you request a graceful restart, apache will start next set of
children processes and all existing processes will stop getting and
processing any new requests so they will exit as soon as they finis
Hi,
what's about sample below?
in other words, why to introduce such a new thing as trait instead of using
classes and trait'ing them?
just my two cents.
-j
"Gregory Beaver" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> Here is a slightly clearer syntax for trait in
"Stefan Marr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> jvlad schrieb:
>> in other words, why to introduce such a new thing as trait instead of
>> using classes and trait'ing them?
> I've introduced it as a separate
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
""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
""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
>
> 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
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
> 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
> > > 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
>>> 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
> 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
> 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
> 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
>> 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
>> 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
>>> 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
> 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
>
> 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
"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
""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
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
>> 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
>>
>
> 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
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
>
>> 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
>> 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
> 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
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:
>> 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
>
> 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
>> 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
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
>> 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,
> 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
>> 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
""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 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
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
>> 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
> >
> > 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
>> 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
>
>> 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
>>> 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
>>> 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,
>
>> 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
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
>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
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
> 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
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_
"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
> 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
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.
>
&
> 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
>>> 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,
>
> 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'
""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
>>
>>
>
> 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
>> 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
>>> 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
"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
> 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)
> 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
> 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
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
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:
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
>
>
>
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
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
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
> 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
"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
>
> 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 =
> 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
> 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
>> > 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
> 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
> 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
>>
>> 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-
"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
>
> "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
"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://
>> 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
>>>
>>> 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
>> 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
> 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
>> 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
>> 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
> 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
>"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
> 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
>> 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
> > 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
>
> 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
"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
>> 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
> "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
1 - 100 of 103 matches
Mail list logo
