On 07/20/2013 08:00 AM, Sherif Ramadan wrote:
> While this is very true it's also a matter of discretion, because the
> language doesn't clearly define a lot of things. In fact, one can argue
> that there is no language definition at all since PHP doesn't even have a
> spec. Though I'm trying to ta
Hey Johannes, could you take a look at:
https://gist.github.com/anonymous/6143477
You can reproduce in 5.5 with:
sapi/cli/php ext/mysqli/tests/mysqli_poll_kill.php
main/streams/cast.c:306 is:
if (php_stream_is_filtered(stream)) {
but php_stream_is_filtered is just a macro that isn't expecting
On 08/05/2013 03:32 AM, Andrey Hristov wrote:
> I just tried the combo PHP 5.5 (git) with MySQL 5.6 (13-dev) without
> segfault. What's your setup?
This is on my Ubuntu 13.04 laptop. mysql Ver 14.14 Distrib 5.5.32 with
PHP 5.5 git just running make test. I get a core every time on that test
in th
Looking at https://bugs.php.net/bug.php?id=65463
My brain is foggy on why we call zend_destroy_modules() before
zend_hash_destroy(GLOBAL_CLASS_TABLE) in zend_shutdown(). Anyone
remember the reason?
I have verified the issue described in 65463. On a SIGTERM to Apache
mid-request, the extension end
On 09/10/2013 12:27 AM, Nikita Popov wrote:
> Yes, throwing an error during the signature validation is the "right" thing
> to do from a theoretic point of view. The issue is just that it breaks old
> code which didn't make sure that parameter names between parent and child
> lined up. "Break" is
On 09/11/2013 10:39 AM, Andrea Faulds wrote:
> As something of a response to "Wake up", perhaps some sort of "forum"
> system for discussion would beat the mailing list. We wouldn't eradicate
> the mailing list, but discussions could also take place there if people
> wished to.
You are free to set
On 09/11/2013 05:34 PM, Florin Patan wrote:
> - lack of a clear roadmap: as I said earlier, can someone really tell
> what's in the next two versions of php from now
That's never going to happen. We don't have paid developers that we can
assign tasks to. We have volunteers who work on things they
On 09/22/2013 11:39 PM, Joe Watkins wrote:
> https://wiki.php.net/rfc/anonymous_classes
>
> I'd like to hear thoughts regarding the addition of anonymous
> classes, patch included.
I am having a hard time picturing a real-world use-case for this.
-Rasmus
--
PHP Internals - PHP Runtime
Mikko Koppanen wrote:
> Hi,
>
> is there any objection on supporting multiple paths separated by path
> separator in PHP_INI_SCAN_DIR value? The patch seems to be quite trivial
> change in main/php_ini.c. Is this acceptable for 5.3 after the commit freeze
> is over?
ok by me
--
PHP Internals -
I have been looking through the curl changes. Nothing really jumps out
at me though. Jani's curl handle change perhaps? Doesn't seem like
that would cause this.
Anyway, here is a standalone little test case:
http://slowgeek.com/test.xml';
$cfile = '/var/tmp/test_'.$prefix.md5($url).'.xml';
$ch
Lukas Kahwe Smith wrote:
> Exactly.
> I will do my best to track things that need to be merged. Best is to
> note if something needs to be merged.
>
> But if you all feel it's such a huge burden then you can of course
> insist on putting the burden on the RMs. The fact of the matter is that
> our
Pierre Joye wrote:
> On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf wrote:
>> Lukas Kahwe Smith wrote:
>>> Exactly.
>>> I will do my best to track things that need to be merged. Best is to
>>> note if something needs to be merged.
>>>
>>> Bu
Pierre Joye wrote:
> On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorf wrote:
>> Lukas Kahwe Smith wrote:
>>> Exactly.
>>> I will do my best to track things that need to be merged. Best is to
>>> note if something needs to be merged.
>>>
>>> Bu
Just to keep the list in synch with the irc discussion. I pointed out
that this is only half of the fix. The refcount still prevents fclose
from flushing the data, so if you do:
$url = 'http://slowgeek.com/test.xml';
$cfile = 'out.xml';
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_FILE, $fp =
Ilia Alshanetsky wrote:
> After some conversations with Rasmus on IRC i've come up with the
> following patch:
>
> http://ilia.ws/patch/curl.txt
>
> This basically forces flush() on the header & output streams right after
> curl_exec(), this ensures that the data retrieved by curl is synched to
>
Mark Karpeles wrote:
> http://php.magicaltux.net/browse/ (lots of memleaks reported on 5.3 &
> HEAD, seems to be glibc-related and not real memleaks, and this is not
> up-to-date as I didn't run the tests for a while and didn't automate it
> because it takes a lot of cpu)
Wondering why you did thi
Roman Borschel wrote:
> Some new 5.3 features like closures and the :? operator still cause bus
> errors with APC though. For the former there is already an open ticket
> since february. So I dont think APC is really 5.3 compatible yet but I'm
> sure it wont take long until these issues are fixed n
Xyntrix wrote:
> Congratulations on the 5.3 milestone!
>
> Packaging the 5.3.0 stable release into an RPM (linux) will error as the
> bin/phar symlink is created using the build-time path variable. This has been
> submitted as bug:
>
> http://bugs.php.net/bug.php?id=48740
>
> Patch:
>
> --- p
Ilia Alshanetsky wrote:
> Last week or so there was a fairly detailed discussion on the internals
> list regarding type hinting based on my original patch. Since then the
> patch has been revised to address the major concerns that were
> identified (breakage of binary compatibility) as well extende
Paul Biggar wrote:
> - the RFC process has been wilfully ignored (despite multiple requests)
For me it is pretty hard to take a major feature for 5.3 RFC seriously
when it comes a week after we finally get 5.3 out the door.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To un
uot; phase to
> "stabilization" phase.
>
>
> On 7-Jul-09, at 7:14 PM, Rasmus Lerdorf wrote:
>
>> Paul Biggar wrote:
>>> - the RFC process has been wilfully ignored (despite multiple requests)
>>
>> For me it is pretty hard to take a major fe
One of the benefits of svn is that we can do cross-branch commit pretty
easily now and thus avoid multiple similar commits with annoying MFH/MFB
commit log messages that are hard to track.
Please don't attempt to check out all of php/php-src or pecl. I made
the mistake of checking out all of pecl
Greg Beaver wrote:
> Rasmus Lerdorf wrote:
>> One of the benefits of svn is that we can do cross-branch commit pretty
>> easily now and thus avoid multiple similar commits with annoying MFH/MFB
>> commit log messages that are hard to track.
>>
>> Please don'
Matt Wilson wrote:
> I agree, however there are certain aspects of PHP's errors that leave a
> lot to be desired. For instance, a failed fopen or a failed socket will
> often result in an uncatchable warning from php. Sure, you can add a @
> to the line but that's slow and doesn't tell you anything
We have talked about this before, and the conclusion was that if we are
going to have an invalid PI, we might as well make it For the sake of the heck of it, I'm gonna offer up this tiny patch I'm
> using in one of my projects. I don't really care if it gets included in
> anything or not, just tho
Moriyoshi, or someone who knows CP932 and EUC-JP, could you please have
a look at ext/iconv/tests/bug16069.phpt
It is failing in all the branches, so I am assuming the expected output
listed in the test is wrong, but I am a bit lost in figuring out how to
tell what is going wrong at byte 113 into
Moriyoshi Koizumi wrote:
> Incorporating the changes and merges across the branches into one
> commit under a sparse-layouted local copy doesn't do the book-keeping
> against svn:mergeinfo. That's why I suppose it is not a good idea.
I don't think a merge will work the way we use branches though.
Bharat Nagwani wrote:
> Hello,
>
> We are facing early session timeouts in php 5.2.3 on bsd unix. This happens
> even more frequently when multiple users are logged in.
>
> Googling I found http://bugs.php.net/bug.php?id=42135
> and was wondering if this could the related bug for this problem. If
Bharat Nagwani wrote:
> Agreed we need an upgrade. But upgrade on a large application (1000+ pages)
> can be expensive.
Going from 5.2.3 to 5.2.10 shouldn't be expensive at all. At least no
more so than trying to hand-patch your PHP to a non-standard version.
-Rasmus
--
PHP Internals - PHP Ru
Jani Taskinen wrote:
> Dan Zoltak wrote:
>> Jani Taskinen wrote:
>>> [snip]
>>> There is a bug in 5.2.10 that might cause this, try latest SVN
>>> checkout of PHP_5_2 branch, it should be fixed now.
>> I've download and tested the latest snap (php5.2-200908020630) and I
>> am still having the same
dan...@zoltak.com wrote:
> Quoting Jani Taskinen :
>> # tar zxfv php5.2-x.tar.gz
>> # mkdir php_5_2
>> # cd php_5_2
>> # ../php5.2-x/configure --disable-all --enable-debug > of relevant options here>
>> # make
>> # make install
>
> Well I have flex-2.5.4 installed. Not sure why it requires
Juliano Buzanello wrote:
> Boa noite a todos.
>
> Estou concluindo minha graduação em Sistemas de Infomação e estou
> fazendo um estudo sobre PHP e estou precisando materia sobre o
> funcionamento do nucleo do PHP (Zend Engine) mas não estou encontrando
> nada.
>
> Em minhas pesquisas encontrei u
Stanislav Malyshev wrote:
> I was recently working on fixing some things in HEAD in
> ext/standard/strings.c and when I tried to run tests to check if my
> fixes are OK I discovered that huge amount of strings tests now fail -
> out of ~800 tests we have 420 fails! Most of them seem to be some
> tr
I think we should do something along the lines of what Stas is
suggesting. The current approach of allocating and sprintf'ing all
messages regardless of whether they will ever be used for anything is
painful and a huge impediment to adding informative E_NOTICE and
E_STRICT messages in the future.
Lukas Kahwe Smith wrote:
>
> On 24.08.2009, at 23:42, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> Quite boring to read this thread where two persons argue about
>>> something abstract. Stas, can you give a real life example where your
>>> patch is necessary..?
>>
>> Any code where you either use @
Lukas Kahwe Smith wrote:
>
> On 25.08.2009, at 00:54, Greg Beaver wrote:
>
>> 1) if a tree falls in the forest and there is no one there to hear it,
>> do we still have to put up with the performance loss?
>> 2) as long as the patch does not break any backwards compatibility
>> (error logging sti
Derick Rethans wrote:
> On Tue, 25 Aug 2009, Stanislav Malyshev wrote:
>
>>> Considering that there shouldn't be any errors in the first place, this
>> You must be kidding me. Any fopen of non-existing file, and loading of
>> non-perfect XML from third party produces errors.
>
> You can test for
Lukas Kahwe Smith wrote:
>
> On 28.08.2009, at 23:09, Stanislav Malyshev wrote:
>
>> As I already noted, the masking - in most cases and definitely in
>> recommended cases - would happen for errors that are NOT SEEN. Not
>> reported. Not logged. Before the patch. Which means, whatever
>> advantag
Guys, what was the reasoning behind the mmap in
php_stream_open_for_zend_ex()? Especially for small files, I don't see
a speedup here, and because of some rather sub-optimal fstat behaviour
it seems like this has slowed things down quite a bit.
See http://bugs.php.net/49383
We now have 3 fstats
This has been discussed before. See:
http://news.php.net/php.internals/44476
http://news.php.net/php.internals/44480
http://news.php.net/php.internals/44484
http://news.php.net/php.internals/44485
Basically it comes down to figuring out whether to extend the existing
FastCGI SAPI to support the p
The real answer is that there is no Unicode support in the ereg
functions, and like it or not, the world is going Unicode.
-Rasmus
Guilherme Blanco wrote:
> It was fat, slow and everything that you can do with POSIX regex you
> can easily do with PCRE regex, which is faster.
>
> It is a decision
Lack of Unicode support is enough of a problem in that PHP6 will be all
Unicode all the time, so these functions simply won't work as they are
today. It would take someone sitting down and figuring out how to
emulate this stuff in a way that makes sense in a Unicode world for them
to come back, an
Richard K Miller wrote:
> On Oct 22, 2009, at 1:42 AM, Antony Dovgal wrote:
>
>> On 22.10.2009 05:37, Richard K Miller wrote:
>>> Is this a bug in PHP?
>>
>> Search the bug DB before asking such questions.
>>
>> http://bugs.php.net/bug.php?id=29992
>> http://bugs.php.net/bug.php?id=39307
>> http:/
Richard K Miller wrote:
>> It is one of these things that make perfect sense when you think about
>> it a little bit. Yes, it catches some people, just like strpos()
>> returning character position 0 on a first-char match catches some
>> people. There is no way to fix things like these without co
Stanislav Malyshev wrote:
> Hi!
>
>> Alternatively include() could be extended to allow resources, so the
>> above would turn info
>>
>> if ($fp = @fopen($file, 'r', true)) {
>> include($fp);
>> fclose($fp);
>> }
>
> This would break security distinction between file ops and include ops,
A couple of notes.
You make it sound like this happens on all includes. It is only
include_once/require_once that have this problem. Regular
include/require do not.
This has been addressed in APC by overriding the opcode and providing
our own opcode handler for this case. See
http://svn.php.ne
Samuel ROZE wrote:
> Hello,
>
> I'm working on two classes, Interval and IntervalList which describe
> an interval and a list of intervals. These intervals are defined using
> the Interval class:
>
> $interval = new Interval((int) $from, (int) $to);
> ?>
>
> These intervals can be stored in a l
Alban wrote:
> Le Sat, 21 Nov 2009 09:48:10 +0100, Lukas Kahwe Smith a écrit :
>
>> On 21.11.2009, at 06:12, Alban wrote:
>>
>>> This is not a big problem but if a solution exists, this would be so
>>> cool ! Especialy when we have to check existance of twenty or more key
>>> in array. Code would
Alban wrote:
> Le Sat, 21 Nov 2009 10:21:18 -0800, Rasmus Lerdorf a écrit :
>> The ternary isn't meant to solve the isset thing you are talking about.
>> It is simply a shortcut to normal ternary operations. The most common
>> case where you don't know if a va
Michael Maclean wrote:
> Hi,
> Gwynne pointed me at the clang static analyser earlier on today, and so
> I've run it against current PHP_5_3. In the course of messing with it,
> it noticed a potential null dereference in ext/ftp - I've attached a
> one-liner to fix it.
Thanks, committed.
--
PHP
Seems like a no-brainer for 5.3 and trunk. You will have to discuss
with Ilia for 5.2. It seems a bit late in the game for that branch to
get this.
-Rasmus
Rob Richards wrote:
> The openssl extension is way to restrictive in the algorithms it
> supports, i.e. no support for SHA265 which is star
Sebastian Bergmann wrote:
> Rasmus Lerdorf wrote:
>> rasmus Wed, 25 Nov 2009 01:30:06 +
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=291283
>>
>> Log:
>> Someone strap down Jani and give him a s
Jess Portnoy wrote:
> Hello,
>
> clang is indeed a great tool but since it does a lot more than just
> static analysis.
> For those cases where one wants source code analysis, especially
> security oriented, I'd recommend flawfinder
> [http://www.dwheeler.com/flawfinder].
I find that flawfinder i
Jani Taskinen wrote:
> This is caused by the divert() patch Rasmus committed. Nice work.
> I'll try figure out how to do it properly.
The easy way would be to get rid of the diverts completely. They don't
do anything in autoconf2.13 anyway, so I don't really see why they were
added in the first p
Jani Taskinen wrote:
> This is caused by the divert() patch Rasmus committed. Nice work.
> I'll try figure out how to do it properly.
Getting rid of just the diverts in ext/standard/config.m4 fixes this for
me. There is still an unrelated libtool/autoconf-2.13 issue related to
finding ld though.
Jani Taskinen wrote:
> 1. Why are you constantly not merging stuff to HEAD?
> 2. Isn't this related to bug #50231 and why are you not using the proper
> commit message then? Hint: - Fixed bug..
>
> It's getting quite annoying that some people (Rasmus included) tend to
> ignore that we have a devel
Jani Taskinen wrote:
> Rasmus Lerdorf wrote:
>> Jani Taskinen wrote:
>>> 1. Why are you constantly not merging stuff to HEAD?
>>> 2. Isn't this related to bug #50231 and why are you not using the proper
>>> commit message then? Hint: - Fixed bug..
>
I'm seeing some GC-related segfaults in current PHP_5_3. I haven't had
time to dive into it very far. All I have is a couple of bts and the
request that triggers it, but it is a gallery2 request and there is a
lot of code there. I'll see if I can get it down to something
manageable. The first b
Can anyone think of a situation where you actually want our current
ignore_user_abort=false setting for the cli sapi?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
No, ignore_user_abort has no effect on what the process does when it
receives a SIGHUP, so that isn't relevant.
-Rasmus
Tjerk Anne Meesters wrote:
> Maybe to make it respond to SIGHUP signals? Not exactly sure whether
> that would constitute as user_abort though.
>
> On 12/23/0
Richard Quadling wrote:
> 2009/12/23 Rasmus Lerdorf :
>> Can anyone think of a situation where you actually want our current
>> ignore_user_abort=false setting for the cli sapi?
>
> I would say that the default setting is pretty important as pressing
> CTRL+C (at least on
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 simply because it is convenient in this one case would be
completely inconsistent.
jvlad wrote:
> "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
>> int
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 have you ever see anything like this
> in real life?
> Could you please let me see it to
jvlad wrote:
> Meanwhile I see that php core developers and Evangelist propose the way of
> evolving difficulties.
> For example, I used split() for many many years. Now it throws a warning and
> it appears
> that this function will be removed soon. I have to rewrite all my scripts
> and replace
Hans-Peter Oeri wrote:
> Hi!
>
> Christian Schneider wrote:
>
>> leads to another inconsistency: Depending on the hosting provider and/or
>> frameworks/modules used you'd have to write different error handlers.
>
> I understand there are widely differing applications for php, that's why
> I thin
Raphael Geissert wrote:
> However, we would like to contribute in the quest to make applications stop
> using short_open_tag. To do so, we have decided to throw an E_DEPRECATED
> warning when an application makes use of short_open_tag. The current
> implementation can be found at [1].
>
> How d
Alain Williams wrote:
> On Wed, Jan 13, 2010 at 10:25:01AM -0500, Graham Kelly wrote:
>> Hi,
>>
>> Optimizations such as 5+7 into 13 really don't get you much. ZEND_ADD (and
>> other basic opcodes) are not in any way a slow point in a program. And
>> unfortunately to be able to optimize these you w
Richard Quadling wrote:
> Hello.
>
> In looking at numer vs string comparison, I think I've found an oddity.
>
> You can successfully compare hex strings ...
>
> var_dump(255 == '0xff');
>
> but not octal strings ...
>
> var_dump(63 == '077');
>
>
> Is this a bug (lack of octal support) or a
Tim Starling wrote:
> Given this, sometimes it's easy to forget that PHP is pathologically
> memory hungry, to the point of making simple tasks difficult or
> impossible to perform in limited environments. It's the worst language
> I've ever encountered in this respect. An array of small strings wi
Alain Williams wrote:
> On Wed, Jan 13, 2010 at 07:48:17AM -0800, Rasmus Lerdorf wrote:
>> Alain Williams wrote:
>
>>> Unfortunately: APC does not work with PHP 5.3 -- I have a site where I would
>>> love to use it but I cannot. I use APC to great effect elsewher
Raphael Geissert wrote:
> Rasmus Lerdorf wrote:
>
>> Raphael Geissert wrote:
>>> However, we would like to contribute in the quest to make applications
>>> stop using short_open_tag. To do so, we have decided to throw an
>>> E_DEPRECATED warning when an
Tim Starling wrote:
> Rasmus Lerdorf wrote:
>> For me, working in super high-load environments, this was never an issue
>> because memory was always way more plentiful than cpu. You can only
>> slice a cpu in so many slices. Even if you could run 1024 concurrent
>>
Stanislav Malyshev wrote:
> Hi!
>
>> Says 93.2482 for me. Should be even less since string generated by
>
> On 64-bit I get about 170 bytes for 5.2, don't have 5.3 build handy on
> 64-bit.
178.4972 5.3 non-debug 64-bit Linux
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To u
Tim Starling wrote:
> Some other operations, like deleting items from the middle of the array
> or adding items past the end (leaving gaps) would also have to trigger
> conversion. The point would be to optimise the most common use cases for
> integer-indexed arrays.
I still say this isn't somethi
Tim Starling wrote:
> class C {
> var $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10;
> }
>
> $m = memory_get_usage();
> $a = array();
> for ( $i = 0; $i < 1; $i++ ) {
> $a[] = new C;
> }
> print ((memory_get_usage() - $m) / 1) . "\n";
> ?>
>
> 1927 bytes (I'll use 64-bit from
Tim Starling wrote:
> For Mr. "everyone has 8GB of memory and tiny little data sets" Lerdorf,
> I could point out that reducing the average zend_op size and placing
> strings close to other op data will also make execution faster, due to
> the improved CPU cache hit rate.
Nice twist there. I simp
Raphael Geissert wrote:
> I'm still looking for a way to warn about the use of open_short_tag not
> being explicitly enabled on the PERDIR level. Otherwise the only thing I see
> would make applications change would be when the default is Off and they
> break.
But why do you want them to change
Raphael Geissert wrote:
> Rasmus Lerdorf wrote:
>
>> Raphael Geissert wrote:
>>> I'm still looking for a way to warn about the use of open_short_tag not
>>> being explicitly enabled on the PERDIR level. Otherwise the only thing I
>>> see would make appl
Raphael Geissert wrote:
> Patrick ALLAERT wrote:
>
>> 2010/1/13 Derick Rethans :
>>> On Tue, 12 Jan 2010, Raphael Geissert wrote:
>> [snip]
>>
>>> Would it be possible to force short_open_tag to a specific value for
>>> those applications alone? Perhaps through an .htaccess file? That way,
>>> Deb
Raphael Geissert wrote:
> Can you tell me what exactly we are breaking? divert calls should only be
> used internally by autoconf and the, apparently useless, usage of them in
> php makes it fail to build with any other autoconf.
Have a look in the archives. I tried getting the divert stuff wor
Jani Taskinen wrote:
> On 01/17/2010 05:19 AM, Raphael Geissert wrote:
>> Jani Taskinen wrote:
>>
>>> 16.1.2010 20:10, Raphael Geissert wrote:
Some of the other patches include:
libdb_is_-ldb
>>>
>>> Why? Potentially breaks things when you assume db/ being correct place..
>>
>> Do you hav
Raphael Geissert wrote:
> Gwynne Raskind wrote:
>> Though I thought the use of high-numbered diversions was
>> actually a supported thing - or was that only in 2.13?
>>
>
> That argument is not supported by the autoconf manual. Please see the
> discussion at
> http://bugs.debian.org/cgi-bin/bugre
Rasmus Lerdorf wrote:
> Raphael Geissert wrote:
>> Gwynne Raskind wrote:
>>> Though I thought the use of high-numbered diversions was
>>> actually a supported thing - or was that only in 2.13?
>>>
>> That argument is not supported by the autoconf manual
Eddie Drapkin wrote:
> On Tue, Jan 19, 2010 at 11:05 AM, Stanislav Malyshev wrote:
>> The second was next on my list, while the first seems to me kind of exotic -
>> why create object only to call one method and immediately drop it? Why this
>> method is not static then?
>
>
> Why would this imp
Eddie Drapkin wrote:
> On Tue, Jan 19, 2010 at 12:02 PM, Rasmus Lerdorf wrote:
>> Eddie Drapkin wrote:
>>> On Tue, Jan 19, 2010 at 11:05 AM, Stanislav Malyshev wrote:
>>>> The second was next on my list, while the first seems to me kind of exotic
>>>>
Stanislav Malyshev wrote:
> Hi!
>
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
>
> What it means is that if foo() returns callable value (which probably
> should be function name or closure) then it would be called. Parameters
> and more than two sets of () work
Stan Vassilev wrote:
Dots and spaces in variable names are converted to underscores. For
example becomes $_POST["a_b"].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
I'm also using dots for this reason, so I feel your pain. What I ended
Stan Vassilev 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() call.
-Rasmus
Hi,
I'm not sure it needs to happen
steve wrote:
>> Having 8 cores with only 1G of ram would be a weird server config.
>
> A single socket quad-core with hyper-threading and 2GB RAM for a
> 32-bit webserver is not weird. Not everyone is Yahoo where you can
> just throw money around.
Hyperthreading doesn't come anywhere near making
I think some of this discussion has been from very different interesting
angles. Let me explain how I see and use PHP.
PHP is the frontend of your backend. It is not your backend in any
sizable system. By that I mean that PHP is not the place to play around
with large data sets. Databases, Cas
Tim Starling wrote:
> That's not the world I live in. I work on a pure-PHP application which
> is widely used on servers where the installing user does not have the
> ability to change their php.ini or to install extensions or middleware.
> The same application (with a few small extensions in C/C++
Karsten Dambekalns wrote:
> Why is that advisable? Any pointers to background information welcome.
The gc code when combined with apc is still a bit shaky in 5.3. I
haven't figured out why yet. And my motivation for figuring it out is
pretty low as code that relies on gc is slow.
-Rasmus
--
You can now use https://svn.php.net/respository for your authenticated
checkouts to keep your svn account safer. You can switch an existing
checkout using:
svn switch --relocate http://svn.php.net/repository
https://svn.php.net/repository
If you get any sort of ca-root errors, install the cacert
Ah, Jani went a little crazy today in his typical style to force a
decision. The real decision is not whether to have a version 5.4 or
not, it is all about solving the Unicode problem. The current effort
has obviously stalled. We need to figure out how to get development
back on track in a way t
On 03/11/2010 12:20 PM, Jani Taskinen wrote:
> The main focus should be that we actually start working. And not wait
> for someone to do something miraculous on their own. I'm just sick and
> tired of the cloak and dagger style and secret meetings and committees.
> So please, do the talking openly
On 03/13/2010 08:57 AM, Derick Rethans wrote:
> On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:
>
>> So I think Lukas and others are right, let's move the PHP 6 trunk to a
>> branch since we are still going to need a bunch of code from it and
>> move development to trun
On 03/13/2010 08:55 AM, Keryx Web wrote:
> Hi again
>
> Trying to drive home this message I am starting a new thread.
>
> Mini-summary: The next *major* edition of PHP must be 7, not 6.
>
> Summary:
>
> A. There seem to be universal agreement that the up until last week
> branch of PHP called t
On 03/16/2010 10:40 AM, dreamcat four wrote:
> As for text files on disk, if they are unicode, they are most commonly
> utf-8 too. So then, why use utf-16 as internal unicode representation
> in Php? It doesn't really make a lot of sense for most regular people
> who want to use Php for their web a
On 03/16/2010 12:05 PM, dreamcat four wrote:
> On Tue, Mar 16, 2010 at 6:32 PM, Rasmus Lerdorf wrote:
>> On 03/16/2010 10:40 AM, dreamcat four wrote:
>>> As for text files on disk, if they are unicode, they are most commonly
>>> utf-8 too. So then, why use
901 - 1000 of 1854 matches
Mail list logo
