On 01/29/2013 04:17 PM, Christopher Jones wrote:
> It would be useful to link to the current Optimizer+ doc from the RFC.
> I believe the link is
> http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf
Different beast. Something like this is more apt:
http://files.zend.com/help/pre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2013 02:49 PM, Ralf Lang wrote:
> The one thing apt-get/zypper saves is time. You eliminate the
> commit states which won't build at all, at least for the end users.
> Now they have more time to figure how they make their legacy code
> work wi
On 01/29/2013 01:12 PM, Rasmus Lerdorf wrote:
> I realize this is slightly more complicated than an apt-get, but
> pre-building packages that will work with all the combinations of
> libraries and things out there is a PITA. By building your own you get
> to choose everything by edi
On 01/29/2013 12:43 PM, Larry Garfield wrote:
> On 1/29/13 11:46 AM, Ralf Lang wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Am 29.01.2013 18:38, schrieb Pierre Joye:
>>> On Tue, Jan 29, 2013 at 6:24 PM, Attila Bukor
>>> wrote:
I think Ralf's idea is great. A lot of other p
On 01/29/2013 06:13 AM, Nikita Popov wrote:
> I'm not sure I fully understand this. The RFC claims that Optimizer+ is
> already *now* fully compatible with PHP 5.5. And that it was also
> compatible when PHP 5.4 was released. So they lack of a working and free
> opcode cache clearly wasn't the iss
On 01/29/2013 05:30 AM, Clint Priest wrote:
> 2) Isn't APC the standard? Is it in such bad shape it is not even being
> considered any longer?
As it currently stands from a developer participation standpoint it is
not viable. I outlined the issues in a previous post.
You also have to take into
On 01/29/2013 05:18 AM, Pierre Joye wrote:
> As far as I remember, we already do that for a couple of web servers.
> And in the long run, I will rather tell not to use FastCGI for
> dedicated hosting and the likes. That being said, I also met many ISPs
> which are not happy with the all-fastcgi, me
Please stop with these. We can't keep explaining why function aliases,
http://www.php.net/unsub.php
On 01/25/2013 01:39 PM, Marco Schuster wrote:
> Hi all,
>
> I'm currently writing a php-program to process certain special binary
> files, which include 32-bit offsets which I need to read and
> manipulate. The problem is that PHPs int type is only 31-bit because
> they have sign information. Sure
On 01/25/2013 10:55 AM, Seva Lapsha wrote:
> Well, how about renaming the functions, create aliases for BC and throw
> E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
> with the distribution to migrate to the new convention?
Throwing warnings on perfectly working code is r
On 01/25/2013 10:49 AM, Zeev Suraski wrote:
> Ok, I'll write up an RFC, and in parallel we'll try to figure out the
> mechanics of actually making it happen.
Commit to master maybe and we can work on cleaning it up for the 5.5 branch.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing
On 01/25/2013 08:25 AM, Zeev Suraski wrote:
> There's another option. We have the Optimizer+ component which is
> current, a bit faster than APC, worked with PHP 5.4 from the get go and
> already fully supports 5.5 - and now that it's been free for use for
> several years, we'd actually be happy
On 01/24/2013 11:56 PM, Ralf Lang wrote:
>> From what I understood from Rasmus the biggest challenge with merging APC
>> into core is the fact that the compiler currently isn't built to support
>> opcode caching. One of the challenges he pointed out was some of the
>> MAKE_NOP trickery that can mak
On 01/23/2013 02:35 PM, Clint Priest wrote:
>
> On 1/23/2013 3:17 PM, Levi Morrison wrote:
>> Clint: I'm sorry that you spent all that time without hearing feedback
>> from a lot of the "No" voters. Had they been participating all along
>> perhaps it could have been avoided. We'll never know.
>
>
On 01/23/2013 01:15 AM, Pierre Joye wrote:
> About opcode cache complexity, I think apc per se is full of things we
> should simplify or drop as features to make the code base much smaller
> and much easier to test and valid, we have discussed that already and
> we disagreed. But this is a topic I
On 01/22/2013 07:20 PM, Dmitri Ravazin wrote:
> hey, here's an idea. Let's drop class autoloading 'magic' as well,
> because it has all the same 'problems' that you've just described.
> It loads things at 'completely arbitrary' times, it's complicated, and
> it surely makes reading code 'too hard'.
On 01/22/2013 04:41 PM, Anthony Ferrara wrote:
> Rasmus,
>
> If you look at the split in voting you will notice it is
> pretty much split along the lines of the people who have to maintain
> this code vs. the people who would like a shiny new feature.
>
>
> I pulled some numbers, and
On 01/22/2013 03:18 AM, Clint Priest wrote:
>
> On 1/17/2013 12:20 PM, Clint Priest wrote:
>> I'm happy to say that Property Accessors is ready for a vote for
>> inclusion in 5.5 release.
>>
>> Nikita and I (as well as Stas a bit) have all been working hard to
>> make this happen for 5.5, voting a
Welcome back Ard. Looks good to me, but I don't have an ARM box to test
on. Go to http://php.net/git-php.php and fill in the form at the bottom
there and we will get you set up with a git account unless you already
have one. I did a quick search and couldn't find it.
-Rasmus
--
PHP Internals - P
On 01/16/2013 02:53 PM, Pascal Mathis wrote:
> When the Zend memory manager is turned on, everything is fine. Is this
> behavior intended?
We do have some intentional leaks where we rely on the pool allocator to
wipe things at the end of a request. So I am less concerned about things
you see at r
On 01/15/2013 09:07 PM, Dennis Clarke wrote:
> Number of tests : 12276 8329
> Tests skipped : 3947 ( 32.2%)
> Tests warned:0 ( 0.0%) ( 0.0%)
> Tests failed:2 ( 0.0%) ( 0.0%)
> Expected fail : 36 ( 0.3%) ( 0.4%)
> Tests passed: 8291 ( 67.5%) ( 9
On 01/15/2013 05:19 PM, Dennis Clarke wrote:
> I agree that Oracle has done the Solaris market no favours and were the
> result of the death of OpenSolaris however, having said all that, Solaris
> is a SUSv3 compliant commercial UNIX and thus one would think that
> open source code written to com
On 01/15/2013 05:03 PM, Dennis Clarke wrote:
> Really I would like to hear from the PHP folks on this as it seems as if PHP
> is
> quite fragile or perhaps simply mysterious.
I don't think any of us test on Solaris regularly, so you can expect the
odd test to fail, but in general it should buil
On 01/09/2013 11:48 AM, Anthony Ferrara wrote:
> Rasmus: "A general purpose scripting language with a focus on web
> development"
> You: "being simple and practical and focused on the web"
>
> While they both have "web" in them, they provide very different goals and
> metrics with which to gauge c
On 01/09/2013 09:45 AM, Anthony Ferrara wrote:
> PHP NEEDS a vision. It needs something to guide development. Not everyone
> will agree with it. And that's the point. It levels the playing field for
> contributions and discussions. Rather than every developer playing for
> themselves and saying "I
On 01/09/2013 09:03 AM, Anthony Ferrara wrote:
> Rasmus
>
>
> This is my worry as well. Especially when it comes to opcode cache
> support. Most of the patches I see these days completely ignore the
> opcode cache side of things which needs to change. For any large
> language-leve
On 01/09/2013 04:16 AM, Derick Rethans wrote:
> On Tue, 8 Jan 2013, Rafael Dohms wrote:
>> 1. The syntax is crap: this is solvable, let's find the right syntax
>
> Any extra syntax makes the PHP parser more complicated (and arguably
> slower). I don't want to have it slower/more complex for some
On 01/05/2013 03:43 PM, Kris Craig wrote:
> Granted, but other use-cases have already been presented as well.
> Obviously the one I suggested would no longer be useful if PHP adopts
> enums.
Actually, I didn't see any other cases. The fact that we have interned
immutable strings in PHP invalidate
On 01/05/2013 03:36 PM, Kris Craig wrote:
>
>
> On Sat, Jan 5, 2013 at 3:32 PM, Rasmus Lerdorf <mailto:ras...@lerdorf.com>> wrote:
>
> On 01/05/2013 03:29 PM, Kris Craig wrote:
>
> > In both cases, we really don't care what the actual values of
On 01/05/2013 03:29 PM, Kris Craig wrote:
> In both cases, we really don't care what the actual values of brown, black,
> and purple are. We just want it to be unique so we can reference each of
> them in a visually friendly way with minimal performance impact. That's
> where I could see a valid
On 12/21/2012 09:28 AM, Dmitry Stogov wrote:
> Hi,
>
> This is more or less final proposed patch for 5.4
>
> http://pastebin.com/ceiWWD4N
>
> It fixes implementation mistakes and makes the whole implementation much
> simpler.
> I hope I didn't introduce new bugs :)
> Of course I checked it with
On 12/20/2012 06:36 AM, Dmitry Stogov wrote:
> Hi Pierre,
>
> The following test may crash on the second request with opcode cache.
>
>
> trait THello {
>
> public function hello() { echo 'Hello'; }
> }
>
> class TraitsTest { use THello; }
>
> $test = new TraitsTest();
> $test->hello();
>
On 12/19/2012 03:27 PM, Stas Malyshev wrote:
> Hi!
>
>> I did come up with a problem in my server crashing with SIGBUS.
>> After long testing/tracing found:
>>
>> https://bugs.php.net/bug.php?id=52752
>
> Just tried to reproduce it on Centos 6.2 install (without APC), works
> just fine for me. I
On 12/19/2012 01:39 AM, Dmitry Stogov wrote:
> Hi,
>
> opcode caches support is one of the problem we have with current
> implementation.
> 5.4.10 seems just can't work with any cache at all.
> Of course, I'll care about it, and may give suggestions for necessary
> APC changes.
Do you have an exa
On 12/16/2012 03:20 PM, Lester Caine wrote:
> One gets the impression that it's all too late, so from the other side,
> should all of the core files be changed to follow the new de-facto
> standard? And YES I classify using different white space standards for
> different file formats as more of a
On 12/16/2012 12:27 PM, Lester Caine wrote:
> Anthony Ferrara wrote:
>> can we please keep superfluous discussions like coding standards
>> off-list? I
>> have no issue with representation of fig discussion, but whitespace
>> discussions
>> have no place on this list...
>
> The standards being dic
On 12/10/2012 12:59 PM, Tom Boutell wrote:
> Sure. I wasn't asking for myself but rather in the context of how
> close 5.3 is to being reasonable to deprecate.
APC is at the point now for 5.4 where I don't think there are any more
edge cases than we have in 5.3. Neither is perfect, but it is close
On 12/05/2012 05:02 PM, Sara Golemon wrote:
> It's been awhile since I last commited (pre git, in fact) and now I'm
> getting a failure during 'git push'. It asks for my password, I enter
> it, it asks again, I enter again, and I get a permission denied error.
> Do I need to do something to updat
On 11/30/2012 09:15 AM, Dmitry Stogov wrote:
> Hi,
>
> The NEWS and UPGRADING explains the details.
>
> http://pastebin.com/VC71Y8LV
>
> The patch is big, but actually quite simple.
> I'm going to commit it on Monday or Tuesday (if no objections).
>
> I'm going to look into the similar optimiza
On 11/26/2012 09:03 PM, Sara Golemon wrote:
> P.S. - I do disagree with Rasmus' statement about none of us looking
> at fitting a JIT into PHP. ;)
I think you misread my reply. I specifically said that a JIT is a
possibility, just not the HH approach.
-Rasmus
--
PHP Internals - PHP Runtime Dev
On 11/26/2012 05:24 PM, Raymond Irving wrote:
> Hello,
>
> I've being reading about HHVM and the numbers are looking great but I was
> just wondering if we will we ever see something like HHVM being added to
> the PHP core?
No, not likely. Maybe an LLVM-based JIT one day, but the HHVM approach
is
On 11/20/2012 09:51 PM, Adam Harvey wrote:
> On 21 November 2012 13:45, Stas Malyshev wrote:
>>> Proposal: I propose we revert this change. Future consideration might
>>
>> I see no reason to revert the change and keep dragging around the GUIDs.
>> Data URLs are much better and cleaner solution, a
On 11/17/2012 09:14 AM, Ángel González wrote:
> On 17/11/12 17:24, Rasmus Lerdorf wrote:
>> Being able to fire off your SQL query at the top of a page and then
>> instead of waiting around for the result continue building the page
>> until you get to the point where you nee
On 11/17/2012 07:19 AM, Ángel González wrote:
> On 16/11/12 17:03, Rasmus Lerdorf wrote:
>> So, I am curious, why are you waiting on us for this? Is it because
>> ext/mysql does everything you need and you simply have no need for any
>> of the new and obviously better featur
On 11/16/2012 09:32 AM, Patrick ALLAERT wrote:
> 2012/11/16 Rasmus Lerdorf :
>> On 11/16/2012 02:18 AM, Patrick ALLAERT wrote:
>>> In eZ Publish CMS, we have recently removed [1] support for the mysql
>>> handler in favour of the mysqli one and as such, we have no m
On 11/16/2012 02:18 AM, Patrick ALLAERT wrote:
> In eZ Publish CMS, we have recently removed [1] support for the mysql
> handler in favour of the mysqli one and as such, we have no more
> mysql_*() functions calls except for the above use case where we rely
> on mysql_escape().
I suppose you mean
On 11/16/2012 01:34 AM, Ryan McCue wrote:
> Pierre Joye wrote:
>> Wordpress lead developer statement is rather clear: Go ahead, we will follow.
>
> Indeed, we have patches written already [1], but they were low priority.
> The plan is to aim for landing these in the next major version, assuming
>
On 11/16/2012 12:51 AM, Patrick ALLAERT wrote:
> Rasmus,
>
> As per the RFC: adding E_DEPRECATED only in mysql_connect(),
> mysql_pconnect(). Which means only one error (normally) by request.
I still don't see the point of using E_DEPRECATED like this for an
entire extension. And I think it will
On 11/15/2012 11:27 PM, Pierre Joye wrote:
> hi Anthony,
>
> On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara wrote:
>
>>> Actually, no it wouldn't. You still get the overhead of the error, plus
any custom error handlers will be triggered regardless of the
error_reporting setting which
On 11/15/2012 05:52 PM, Sherif Ramadan wrote:
> This was the soft-deprecation notice that I believe was discussed
> before the actual steps were to be taken to officially deprecate
> ext/mysql. Yes, it's a suggestion, but a clearly worded suggestion,
> none-the-less. It has been around for a little
On 11/15/2012 04:18 PM, Sherif Ramadan wrote:
> On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara wrote:
>
>>
>>
>> If it wasn't that active open source projects still have ext/mysql as their
>> primary connection today, I would agree with you. But we still have open
>> source projects, major ones
On 11/15/2012 01:50 PM, Austen Hoogen wrote:
> The reason to depreciate and/or cease support for a feature (not the same
Pet peeve of mine. The word is deprecate. Depreciate is a financial term.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
On 11/15/2012 12:08 PM, Will Fitch wrote:
> On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf wrote:
> Actually, no it wouldn't. You still get the overhead of the error, plus
> any custom error handlers will be triggered regardless of the
> error_reporting setting which
On 11/15/2012 11:53 AM, Will Fitch wrote:
> On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev wrote:
>
>> Hi!
>>
>>> Again, though, this is a long way down the road: today's discussion is
>>> purely about deprecation.
>>
>> So these people using mysql-based code will have for years to live with
>> ap
On 11/12/2012 07:24 AM, Leigh wrote:
> Hi,
>
>> We put ext/mysql in a (security) bug fix maintenance mode only
>> years ago. Too many ignore those attempts to get rid of ext/mysql.
>
> Maybe it's time to put it into full non-maintenance mode then?
>
> I believe MySQL is one of the on-by-default
On 11/05/2012 08:41 AM, Jean-Sébastien Hedde wrote:
> On Mon, 05 Nov 2012 08:04:06 -0800, Rasmus Lerdorf
> wrote:
>>
>> I think the documentation is wrong on that. In Unicode mode [[:alnum:]]
>> actually becomes \p{Xan} which should match Unicode chars as well, but
>
On 11/05/2012 01:57 AM, Jean-Sébastien Hedde wrote:
> Hi,
>
> I'm facing an issue with preg_match and an UTF8 string.
>
> The pattern is : /^[[:alnum:]\s\-\'%]+$/u
> The string : Régis
>
> If I read the manual preg_match should return 0 ("In UTF-8 mode,
> characters with values greater than 128
On 10/29/2012 12:20 AM, Laruence wrote:
> Hey:
>is there any change to git box recently?
>
>I got a fail message like:
>
>Total 5 (delta 3), reused 0 (delta 0)
>remote: Shared object "libvpx.so.0" not found, required by "php"To
> g...@git.php.net:php-src.git
This is fixed now.
On 10/25/2012 08:53 AM, Anthony Ferrara wrote:
>> If there are no objections, I'll go ahead and draft an RFC for the
>> notice/docs idea later today. If anyone would like to co-author it with
>> me, please drop me an email and I'll send you the wiki link once I've
>> created the page.
>>
>
> Do
On 10/20/2012 01:59 PM, Nikita wrote:
> Hello, list. I want to propose generics. For those, who don't know what it
> is, here's example: say we have a Comment class, that has a method getBody.
> Also we have Collection class, that implements Traversable. Now, if I want to
> validate all insertio
On 10/18/2012 04:16 PM, David Strauss wrote:
> On Thu, Oct 18, 2012 at 4:06 PM, David Muir wrote:
>> Upstart support would be good to have too.
>
> I'm aware of Upstart having some basic socket activation support, and
> I'm happy to provide advice on the PHP-FPM/Linux side for integrating
> it in
On 10/18/2012 03:47 AM, Anatoliy Belsky wrote:
> Hi,
>
> as requested in the issue #63284, I've produced a patch for PCRE 8.31
> upgrade. Tests has passed for me on 5.3/5.4/master ts and nts, though
> anybody willing to perform additional tests is welcomed. More tests will
> be performed next days
On 10/16/2012 02:51 AM, Amaury Bouchard wrote:
> 2012/10/16 Stas Malyshev
>
public DateTime $date;
>>>
>>> This is *real* progress, even if under the hood all it does is wrap
>>
>> I think it's a movement in wrong direction. Again, it is an attempt to
>> make PHP a strongly typed language, w
On 09/18/2012 03:46 PM, Pádraic Brady wrote:
> Bear in mind the RFC, in userland (and likely any PECL ext) implements
> the ESAPI rules. They've been hacked on a lot over the years which is
> why I made sure they were followed exactly. It's very unlikely that a
> browser bug could scupper these unl
On 09/18/2012 03:28 PM, Pádraic Brady wrote:
> Hi Rasmus,
>
> On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf wrote:
>> If we want to add more filters for more specific purposes, I am not
>> completely against it, although the more specific they get the more
>> chur
On 09/18/2012 02:21 PM, Stas Malyshev wrote:
> Hi!
>
>> Filter has already gone down this road--I doubt the value added by having a
>> second, much
>> more verbose way to call htmlspecialchars()--but I don't see why we must
>> continue down
>> that path.
>
> So, you don't think there should b
On 09/18/2012 12:39 PM, Michael Shadle wrote:
> Also as there is also htmlspecialchars() which most people use for escaping
> this seems like a better, more centralized functionality and better
> nomenclature for escaping on output in general with options for various types
> (and should just be
On 09/17/2012 08:47 AM, Will Fitch wrote:
> I haven't seen a maintenance notification, and it appears git.php.net may
> be down. Anyone else able to reproduce this?
It is down at the moment yes. Slight mixup trying to add some firewall
rules.
-Rasmus
--
PHP Internals - PHP Runtime Development
On 09/10/2012 12:00 PM, Anthony Ferrara wrote:
> I chose it for that specific reason. The line is blurry if taken literally
> (which many do)...
It can't possibly be an absolute rule. If you take it completely
literally then we wouldn't be able to fix bugs either. Every change has
some effect tha
On 09/08/2012 12:26 PM, Lars Strojny wrote:
> That’s indeed a different topic but it would ease a lot of pain to have a
> fully compatible APC from day one.
The first step to that is to make sure all new language features include
the necessary changes to APC. And despite what Pierre thinks, it h
On 09/04/2012 12:20 PM, Jan Ehrhardt wrote:
> Now that you have changed the subject, I feel free to break in with a
> voice from userland.
>
> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 09:57:59 -0700):
>> Even with E_STRICT off (...)
>
> Sometimes it is not ea
On 09/04/2012 09:36 AM, Adam Richardson wrote:
> I think Ferenc is correct in that this sounds like there's a custom
> error handler somewhere. If the custom error handler collects error
> info and then throws an exception (as has been detailed in various
> blog posts as one manner of unifying the
On 09/03/2012 04:31 PM, Alex Aulbach wrote:
> 2012/9/4 Gustavo Lopes :
>>> Following this logic, we'd have to convert all E_NOTICE and E_STRICT to
>>> fatal errors or exceptions - they are usually produced by programming
>>> errors and aren't meant to be caught by surrounding code (actually,
>>> ca
On 09/01/2012 06:39 PM, Anthony Ferrara wrote:
> So, while I know there's some discontent about having the core raise
> exceptions, let me ask the question differently:
>
> Without moving to exceptions, how could the current error and error
> handling mechanisms be improved to make the scenario I
On 09/01/2012 05:44 PM, Gustavo Lopes wrote:
> More importantly, there is no other satisfactory solution (except a
> fatal error). foreach has no return value, so it has no other way to
> signal a failure. If we used a notice or a warning here what would
> happen is that code that used generators w
On 09/01/2012 04:51 PM, Gustavo Lopes wrote
> * In fact, if there is a unifying theme in the usage of exceptions in
> PHP, is that exceptions are used when OOP interfaces are involved (see
> Zend interfaces, SPL, DateTime and PDO -- though optional there). The
> core vs. non-core argument only loo
On 08/26/2012 06:48 PM, Lars Strojny wrote:
> Hi Gwynne,
>
> Am 27.08.2012 um 03:39 schrieb Gwynne Raskind :
>
>> (And
>> a side note on that, the requirement of C89 standard compliance in PHP
>> has less and less advantage these days, and handicaps those few
>> language features in the later fla
On 08/26/2012 06:34 PM, Kris Craig wrote:
>
>
> On Sun, Aug 26, 2012 at 6:22 PM, Rasmus Lerdorf <mailto:ras...@lerdorf.com>> wrote:
>
> On 08/26/2012 06:18 PM, Kris Craig wrote:
> > Short of killing ourselves rewriting it in C++, I'm not sure there
&
On 08/26/2012 06:18 PM, Kris Craig wrote:
> Short of killing ourselves rewriting it in C++, I'm not sure there
> is an ideal solution to this problem.
Because you think more people can grok C++ than C? That's not my
experience. C is essentially a subset of C++. Any strong C++ developer
(I think I
On 08/26/2012 02:57 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/8/27 Stas Malyshev :
>> Hi!
>>
>>> In PHP 6 we tried to introduce separate input, script and output
>>> encoding settings. Currently in 5.4 we don't have that, but we have
>>> those 3 separately for mbstring and for iconv:
>>>
>>> iconv.in
On 08/25/2012 12:59 PM, Ángel González wrote:
> I see. Thank you very much.
> Even worse, HTML5 doesn't seem to have any provision for that, as it works
> with characters. A user agent would have to protect himself from this by
> making
> those kind of utf-8 characters a hard error instead of tryin
On 08/25/2012 10:07 AM, Lester Caine wrote:
> Rasmus Lerdorf wrote:
>>> Andrew Faulds wrote:
>>>>> >>>Personally I have to live with real life, and just want to help
>>>>> >>>change that
>>>>> >>>situation.
>&
On 08/25/2012 09:11 AM, Lester Caine wrote:
> Andrew Faulds wrote:
>>> Personally I have to live with real life, and just want to help
>>> change that
>>> situation.
>> Me too. My code relies on out-of-date extensions and PHP features,
>> which is why
>> I'm *refactoring* and *rewriting* the parts
On 08/24/2012 02:23 PM, Ángel González wrote:
> El 23/08/12 18:06, Rasmus Lerdorf escribió:
>> htmlspecialchars(), htmlentities(), html_entity_decode() and
>> get_html_translation_table() all take an encoding parameter that used to
>> default to iso-8859-1. We changed the defa
On 08/23/2012 09:09 AM, Andrew Faulds wrote:
> Personally, I think you should have just two encodings: page_encoding
> and internal_encoding. The former is for form input and page output
> (could be latin-1, for instance), and internal_encoding is the internal
> representation (default to utf-8 - y
htmlspecialchars(), htmlentities(), html_entity_decode() and
get_html_translation_table() all take an encoding parameter that used to
default to iso-8859-1. We changed the default in PHP 5.4 to UTF-8. This
is a much more sensible default and in the case of the encoding
functions more secure as it p
On 08/22/2012 09:48 PM, Raymond Irving wrote:
> Hello Everyone,
>
> I've been reading that it's possible to encounter session id collisions
> with the default php configuration. It's also been said that PHP utilizes a
> cryptographically weak random number generator to
> produce session ID informa
On 08/21/2012 09:10 AM, Ivan Enderlin @ Hoa wrote:
> Hello,
>
> Some of my users & contributors have met an issue with files containing
> UTF-8 on certain Windows configurations (but they actually did not found
> the difference). Any idea why?
> The issue does not appear on Linux, BSD or Mac OS sy
On 08/20/2012 08:12 PM, Lester Caine wrote:
> Rasmus Lerdorf wrote:
>> On 08/20/2012 06:51 PM, Lester Caine wrote:
>>> >Ferenc Kovacs wrote:
>>>> >>why is this an internals question?
>>> >Because no one answered on general:(
>>> >But
On 08/20/2012 06:51 PM, Lester Caine wrote:
> Ferenc Kovacs wrote:
>> why is this an internals question?
> Because no one answered on general :(
> But since the core code base does not compile it seems internal to me
> anyway.
The bundled extensions are not designed to be built standalone using
ph
On 08/20/2012 03:47 PM, Adi Mutu wrote:
> Hello,
>
> I'm trying to compile php 5.3 as php-fpm using the following configure command
>
>
> ./configure --enable-debug --enable-maintainer-zts --enable-fpm
> --enable-fastcgi
>
> and i get this
>
> "
> Thank you for using PHP.
>
> Notice: Follow
On 08/20/2012 07:56 AM, Ángel González wrote:
> On 20/08/12 02:01, Rasmus Lerdorf wrote:
>> I would still like to understand what this generator keyword would
>> actually do. I don't see how it would work. Would a function marked
>> generator somehow not be allowed to re
On 08/19/2012 07:07 PM, Stas Malyshev wrote:
> Hi!
>
>> I am against this. This is even more magic in PHP. Is it really that
>> difficult to have to mark the function with a different keyword, such as
>> "generator":
>
> You have a point here, but "public static final generator function
> foo()
On 08/19/2012 10:29 AM, Raymond Irving wrote:
> Hello,
>
> What could have cause PHP to start out so great but then slows to a crawl?
> Could it be the GC?
>
> Number of iterations Node.js PHP
> ---
> 100 2.00
On 08/18/2012 10:12 AM, les...@lsces.co.uk wrote:
> Since this is yet another area where 'one does not have to use it if one
> does not want to' ... FLAGGING to the other users that a function is a
> 'special one' rather than just a normal function with a generator function
> seems to me just a nec
On 08/17/2012 05:35 PM, Rasmus Schultz wrote:
> Most other languages have more than one collection-type... since PHP has
> only the single, hybrid array-type which acts both as a hash and as an
> array, something like this ought to be available.
>
> I don't know why everyone is so eager to jump up
On 08/17/2012 05:21 PM, Rasmus Schultz wrote:
>>
>> if(($key = array_search($del_val, $messages)) !== false) {
>> unset($messages[$key]);
>> }
>>
>> Nothing horrible here.
>>
>
> I disagree - this is (or should be) a simple, atomic operation...
> yet, you've got a function-call, an intermediar
Our pull request queue is getting a bit backed up:
https://qa.php.net/pulls/#repo=php-src
We have a few people looking at these. stas, laruence, nikic, reeze and
a couple of others, but it would be good to get more eyeballs to test
the changes and comment on them. And I suspect some people here d
On 08/09/2012 11:31 AM, Lester Caine wrote:
> Rasmus Lerdorf wrote:
>> On 08/09/2012 11:10 AM, Levi Morrison wrote:
>>> >On Thu, Aug 9, 2012 at 8:51 AM, Rob
>>> Richards wrote:
>>>> >>Whats the status of 5.3? I have some changes that need t
On 08/09/2012 11:10 AM, Levi Morrison wrote:
> On Thu, Aug 9, 2012 at 8:51 AM, Rob Richards wrote:
>> Whats the status of 5.3? I have some changes that need to get into a couple
>> of the xml based extensions in order for them to work with the next libxml2
>> release next month. Should I be puttin
301 - 400 of 1854 matches
Mail list logo
