Re: [PHP-DEV] P++: FAQ

I must admit that the first time I read Zeev’s email I got anxious... but it is frustrating that PHP has a WAY better runtime than Python and most other dynamic languages yet is falling out of fashion. It’s strange given how much better it actually runs (really being unbiased here). One reason i

Re: [PHP-DEV] [RFC] JIT

I think I heard some stat that over 50% of Azure now runs Linux (and I am sure PHP is primarily running on Linux). So given JIT probably helps 95% of production PHP installations I wouldn’t hold this back. If Windows ends up being important to folks some (and possibly msft) will contribute that.

Re: [PHP-DEV] [VOTE] UUID

eptember 3, 2017 10:30:53 AM To: Andi Gutmans Cc: PHP Internals List; Zeev Suraski Subject: Re: [PHP-DEV] [VOTE] UUID Why would it go under Spl? Spl is already bloated with loads of unrelated classes with no real logical grouping. On 3 Sep 2017 19:03, "Andi Gutmans" mailto:andigutm...@gm

Re: [PHP-DEV] [VOTE] UUID

Why would we not just add this under Spl? Feels like an appropriate place to put standard methods. I would definitely not make functionality like this a top level class/namespace both for BC reasons and it is a minor capability that fits in well into a standard library context. Get Outlook for

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

On 1/14/16, 7:47 AM, "stig.bak...@gmail.com on behalf of Stig Bakken" wrote: >I agree whole-heartedly with Zeev here! > >Anyone who has a clue about organizational psychology will tell you to >focus on what you want more of, not on what you want to eliminate. Heck, >anyone who is a parent tod

[PHP-DEV] Re: PHP 7 ?! :)

Never mind. It returned. Congratulations everyone! Amazing accomplishment. The Web is going to speed up 2x! Everyone here has made a huge impact. Thanks to the RMs. Thanks to Dmitry for leading such an amazing effort on the performance front. Andi On Thu, Dec 3, 2015 at 12:28 PM, Andi Gutmans

[PHP-DEV] PHP 7 ?! :)

What just happened? It was on php.net and now it's gone?

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Is there an update on the OpenSSL front...? Is this release of OpenSSL going to be binary compatible or just source compatible?

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

> On Dec 2, 2015, at 9:51 PM, Sebastian Bergmann wrote: > > Please do not get me wrong: I appreciate what Microsoft in general > and you, Anatol, as well as Pierre in particular have done for PHP. > But no vendor -- neither Microsoft nor Red Hat nor whoever else > rolls binary distributions of P

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

How’s it going? Are we golden? When do you plan on posting tomorrow? > On Dec 2, 2015, at 12:42 AM, Anatol Belski wrote: > > > >> -Original Message- >> From: Sebastian Bergmann [mailto:sebast...@php.net] >> Sent: Wednesday, December 2, 2015 9:01 AM >> To: internals@lists.php.net >> Sub

Re: [PHP-DEV] PHP 7 RTM date

> On Nov 10, 2015, at 8:53 AM, David Zuelke wrote: > > Sure: http://phpversions.info/paas-hosting/ > > The default PHP version in the absence of any explicit declaration on Heroku > will remain 5.6.latest for a while, but if you have a composer.json with a > bunch of requirements for package "

Re: [PHP-DEV] PHP 7 RTM date

> On Nov 8, 2015, at 5:35 PM, Rasmus Lerdorf wrote: > > On 11/08/2015 05:16 PM, Anatol Belski wrote: >> Exactly, the relevant patches are going into RC7 which is then out on 12th >> instead of GA. The next closest release slot were then Nov 26th, either for >> GA or for RC8 (but better not try to

Re: [PHP-DEV] Undefined variables undefined order

> On May 11, 2015, at 9:05 PM, Sara Golemon wrote: > >> On Mon, May 11, 2015 at 5:12 PM, Matt Wilmas wrote: >> - Original Message - >> From: "Stanislav Malyshev" >> Sent: Monday, May 11, 2015 >> argument. I'd like to propose making the order of evaluation defined by splitting

Re: [PHP-DEV] PDO Oracle driver

> On Apr 22, 2015, at 10:50 PM, christopher jones > wrote: > > The current state is that we will be looking at PDO_OCI and OCI8 for > PHP 7 in a short while. Our good intentions got delayed as we have > been working on drivers for other languages > (https://github.com/oracle/node-oracledb and >

Re: [PHP-DEV] 7.0 Release Management

On Sun, Apr 5, 2015 at 12:05 AM, Ferenc Kovacs wrote: > Hi, > > bumping the thread as we should start the release steps (branching out 7.0, > tagging the first alpha or more likely beta) if we wanna keep up with > https://wiki.php.net/rfc/php7timeline > I definitely think we should roll a packag

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

On Fri, Apr 3, 2015 at 11:57 AM, Anthony Ferrara wrote: > All, > > I spent a little bit of time today trying to debug an issue with 7 > that Drupal 8 was facing, specifically regarding an array index not > behaving correctly ($array["key"] returned null, even though the key > existed in the hash

Re: [PHP-DEV] Proposal to delay 7.0 timeline

> On Mar 21, 2015, at 9:05 AM, Rasmus Lerdorf wrote: > >> On 03/21/2015 08:52 AM, François Laupretre wrote: >> Now, after more calls from many of you to delay it, and as Zeev himself >> seemed to consider it as more acceptable, I am proposing again to delay 7.0 >> feature freeze to May, 15 (2 mon

Re: [PHP-DEV] [RFC] Basic Scalar Types

> On Mar 11, 2015, at 2:28 PM, Bob Weinand wrote: > > Hi all, > > after all, some people are not happy with the current proposals about scalar > types. So, they both still possibly may fail. > > Thus, I'd like to come up with a fallback proposal in case both proposals > fail: > > https://wi

Re: [PHP-DEV] Zend JIT Open Sourced

> On Feb 27, 2015, at 11:36 AM, Anthony Ferrara wrote: > > Dmitry, > >>> That's not to say there's anything wrong with this approach, nor that >>> there isn't a ton we can learn from it. I think it's a fantastic >>> research effort and plan on digging through it myself. Thank you for >>> open so

Re: [PHP-DEV] Re: Zend JIT Open Sourced

> On Feb 27, 2015, at 7:12 AM, Anthony Ferrara wrote: > > Dmitry and Zend, > > Thank you for sharing your code. I look forward to playing with it. > > Perhaps after 7 stabilizes (and ships) you could write up your > thoughts around it? Why decisions were made and the findings that you > have?

Re: [PHP-DEV] [VOTE] Scalar Type Hints

> On Feb 7, 2015, at 7:52 PM, Rasmus Lerdorf wrote: > > On 02/07/2015 09:51 PM, Andrea Faulds wrote: >>> tan(1); >>> echo strstr("test", "est", 1); >> >> Banning int->float and float->int is both a pain point and sometimes a >> life-saver. It’s annoying that tan(1) doesn’t work. On the other ha

Re: [PHP-DEV] [VOTE] Scalar Type Hints

ere too plus a small minority of total voters who can't really move the needle much. Let's keep the conversation pragmatic. I will try and refrain from any humor. Andi > Stelian > >> On Fri, Feb 6, 2015 at 12:57 AM, Andi Gutmans wrote: >> The folks who really want

Re: [PHP-DEV] [VOTE] Scalar Type Hints

+1 > On Feb 5, 2015, at 5:23 PM, Adam Harvey wrote: > > On 6 February 2015 at 04:14, Andrea Faulds wrote: >> At long last, I’m going to put the RFC to a vote. It’s been long enough - I >> don’t think there needs to be, or will be, much further discussion. > > True, and I probably won't respon

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 5, 2015 at 4:05 PM, Andrea Faulds wrote: > Hi Andi, > > > On 5 Feb 2015, at 23:57, Andi Gutmans wrote: > > > > The folks who really want all this great strict typing should head over > to Oracle.com and download free open-source Java? I hear it

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Thu, Feb 5, 2015 at 3:53 PM, Andrea Faulds wrote: > Hi Andi, > > > On 5 Feb 2015, at 23:50, Andi Gutmans wrote: > > > > I am not sure. > > > > I think we need to explicitly vote on a weak type hinting option. > > Andrea, I think this should be an opt

Re: [PHP-DEV] [VOTE] Scalar Type Hints

OK. But maybe that's why PHP is better than those languages :) On Thu, Feb 5, 2015 at 3:49 PM, Rowan Collins wrote: > On 5 February 2015 23:22:26 GMT, Andi Gutmans wrote: > > >having such a declare(…) syntax will be ridiculed by the broader app > >dev community until

Re: [PHP-DEV] [VOTE] Scalar Type Hints

ust have another RFC running in parallel but I think that would do a disservice to the good work you've done. Andi On Thu, Feb 5, 2015 at 3:47 PM, Andrea Faulds wrote: > Hi Andi, > > > On 5 Feb 2015, at 23:22, Andi Gutmans wrote: > > > > I have to say I’m pretty disa

Re: [PHP-DEV] [VOTE] Scalar Type Hints

hink the consensus is not so far away. > As far as I understand the rules, it is possible to vote yes and put up a > new RFC to remove strict-declare after the voting ends? > > Regards > Thomas > > Andi Gutmans wrote on 06.02.2015 00:22: > > > I have to say I’m pretty disappoin

Re: [PHP-DEV] [VOTE] Scalar Type Hints

I have to say I’m pretty disappointed at the opening of the vote. We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it. This has now been morphed into something very hard to swallow and IMO having such a decl

Re: [PHP-DEV] Warnings in zend_alloc.h

Can you provide more info re: operating system and version? Compiler version? Thanks. Sent from my iPhone > On Jan 24, 2015, at 11:57 PM, Sebastian Bergmann wrote: > > Nut sure whether this is an issue or not but I see it a lot while > compiling master: > > Zend/zend_alloc.h:57:236: warning

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

> On Jan 15, 2015, at 6:51 AM, Andrea Faulds wrote: > > > I’m not really sure this is true. I agree that strict types aren’t entirely > in keeping with the “PHP way”. However, there are plenty of people who are > against them not for that reason, but simply because they don’t work well for >

Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)

> On Jan 9, 2015, at 5:10 PM, Sara Golemon wrote: > >> On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye wrote: >> The fact that hhvm implements a significant part of the extensions (or >> other areas) using PHP+additional syntax as well as adding cleaner >> APIs or mechanisms for the C parts only co

Re: [PHP-DEV] [VOTE][RFC] PHP 5.7

> On Dec 30, 2014, at 12:26 AM, Stanislav Malyshev wrote: > > Hi! > >> I’m going to put the PHP 5.7 RFC to a vote, since it’d been 2 weeks. >> I’m not entirely certain myself whether it’s a good idea, but I’d >> like it for us to vote on it so we can settle the matter. If people >> vote against

Re: [PHP-DEV] [VOTE] Abstract Syntax Tree

gt; > > On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote: > Hi Nikita, > > I reviewed the AST RFC on my way to vote but there was something that wasn’t > clear to me. > This patch introduces some semantic/behavioral changes in addition to the AST. > Are these as a sid

Re: [PHP-DEV] [VOTE] Abstract Syntax Tree

Hi Nikita, I reviewed the AST RFC on my way to vote but there was something that wasn’t clear to me. This patch introduces some semantic/behavioral changes in addition to the AST. Are these as a side-effect of how AST was implemented? Or are they unrelated to the AST patch? I think some of them

Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP (again)

> On Jul 23, 2014, at 11:23 AM, Kris Craig wrote: > >> On Wed, Jul 23, 2014 at 7:39 AM, Ferenc Kovacs wrote: >> >>> On Wed, Jul 23, 2014 at 4:32 PM, Andrea Faulds wrote: >>> >>> On 23 Jul 2014, at 15:21, Ferenc Kovacs wrote: I also think that it would be reasonable to have

Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP

On Jul 20, 2014, at 8:39 AM, Peter Cowburn wrote: > > As for the PHP 7 section, this is by far the dominant part of the RFC. Both > in terms of physical presence, but also points and counter-points. > > It also contains, IMO unnecessarily, light-hearted and jokey comments not > befitting an RFC

RE: [PHP-DEV] Disabling the GC during shutdown

>-Original Message- >From: Stas Malyshev [mailto:smalys...@sugarcrm.com] >Sent: Thursday, June 20, 2013 8:20 PM >To: Anthony Ferrara >Cc: Laruence; internals@lists.php.net >Subject: Re: [PHP-DEV] Disabling the GC during shutdown > >> However, that's not really fixing the situation either, a

[PHP-DEV] PHP 5.5 Upgrade Notes Question

Hi, Just reading the excellent PHP 5.5 Upgrades Notes - https://raw.github.com/php/php-src/php-5.5.0beta1/UPGRADING Some questions: - Dropped support for Windows XP & 2003: o Was this an RFC? At what point was it decided? (I may have missed it in that case I’d just appreciate a p

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

>-Original Message- >From: Anthony Ferrara [mailto:ircmax...@gmail.com] >Sent: Thursday, March 07, 2013 1:58 PM >To: Philip Olson >Cc: David Soria Parra; internals@lists.php.net >Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP >distribution > >Philip, > >Shouldn't we

RE: [PHP-DEV] 6.0 And Moving Forward

It is absolutely related to how the PHP project approaches things. As a project we have always valued backwards compatibility and migration path. That focus and approach is one of the reasons why PHP is so pervasive. It is sometimes more fun to break (fix) everything but the reality is that while

RE: [PHP-DEV] PHP 5.4 Benchmarks

Absolutely. Will gather those and send them over... Andi >-Original Message- >From: Johannes Schlüter [mailto:johan...@schlueters.de] >Sent: Wednesday, February 01, 2012 10:49 AM >To: Andi Gutmans >Cc: internals@lists.php.net >Subject: Re: [PHP-DEV] PHP 5.4 Benchmarks

RE: [PHP-DEV] PHP 5.4 Benchmarks

hat others are seeing. Thanks, Andi >-Original Message- >From: Pierre Joye [mailto:pierre@gmail.com] >Sent: Wednesday, February 01, 2012 10:37 AM >To: Andi Gutmans >Cc: internals@lists.php.net >Subject: Re: [PHP-DEV] PHP 5.4 Benchmarks > >hi! > >I could a

RE: [PHP-DEV] PHP 5.4 Benchmarks

Cache results are of course important. Memory usage would be great too. Thanks!! Andi >-Original Message- >From: Pierre Joye [mailto:pierre@gmail.com] >Sent: Wednesday, February 01, 2012 10:19 AM >To: Andi Gutmans >Cc: internals@lists.php.net >Subject: Re:

[PHP-DEV] PHP 5.4 Benchmarks

Hi, As many of you know we made huge improvements in PHP 5.4 memory usage (enabling higher concurrency) and runtime performance. We've done our own benchmarks but it'd be great to hear from others re: what you're seeing with your real-world apps. If you have any experiences to share please do.

RE: [PHP-DEV] E_STRICT in production

>-Original Message- >From: Pierre Joye [mailto:pierre@gmail.com] >Sent: Saturday, July 23, 2011 3:22 PM >To: Stas Malyshev >Cc: PHP Internals >Subject: Re: [PHP-DEV] E_STRICT in production > >hi Stas, > >The idea of E_STRICT when we introduced it was to help developers. So I >tend to th

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

>-Original Message- >From: Pascal COURTOIS [mailto:pascal.court...@nouvo.com] >Sent: Thursday, June 16, 2011 12:28 AM >To: Lester Caine >Cc: PHP internals >Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > >Le 16/06/2011 09:19, Lester Caine a écrit : > >>>when you have a bu

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

ailto:dukeofgam...@gmail.com] Sent: Wednesday, June 15, 2011 7:36 PM To: Andi Gutmans Cc: Pierre Joye; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) Hi, I think that -in any context- the "if it aint broke don't fix it" is

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

>-Original Message- >From: Pierre Joye [mailto:pierre@gmail.com] >Sent: Wednesday, June 15, 2011 2:33 AM >To: Andi Gutmans >Cc: Derick Rethans; PHP Developers Mailing List >Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > >On Wed, Jun 15, 2011

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

Hi Derick and all, I think we have had some reasonable additions to the language in PHP 5.3 + will have a couple of good ones in PHP 5.4. That said, I do agree we should have a strong bias against language feature creep unless there is a really strong compelling reason. I do think that an incre

[PHP-DEV] Bundling "modern" extensions

Hi, I've been getting quite a few inquiries re: PHP's "lack" of support for modern technologies such as NoSQL databases (for lack of better term). There is some (mistaken) perception that PHP is behind on this front. I think one of the problems is that in the past we always ensured that the e

RE: [PHP-DEV] Re: [RFC] Improved parser error message

Hi Felipe, Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and agreed to keep it as a historical landmark. Let's not have the discussion yet again within the same year. Google it just to see the # of mentions. What we could do as a compromise between history and improving ma

RE: [PHP-DEV] 5.4 again

>-Original Message- >From: Stas Malyshev [mailto:smalys...@sugarcrm.com] >Sent: Sunday, May 08, 2011 4:41 PM >To: PHP Internals >Subject: [PHP-DEV] 5.4 again > >Hi! > >I would like to propose the following process (of course, dates can be moved >around, etc. - I consider phase lengths be mo

RE: [PHP-DEV] 5.4 again

>-Original Message- >From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] >Sent: Monday, May 09, 2011 10:51 AM >To: Andi Gutmans >Cc: Christopher Jones; internals@lists.php.net >Subject: Re: [PHP-DEV] 5.4 again > >Hi Andi, > >That'

RE: [PHP-DEV] 5.4 again

> -Original Message- > From: Christopher Jones [mailto:christopher.jo...@oracle.com] > Sent: Monday, May 09, 2011 10:28 AM > To: internals@lists.php.net; Guilherme Blanco > Subject: Re: [PHP-DEV] 5.4 again > > > > On 05/09/2011 07:44 AM, > guilhermebla...@gmail.com

RE: [PHP-DEV] annotations again

> -Original Message- > From: Marcelo Gornstein [mailto:marce...@gmail.com] > Sent: Monday, May 09, 2011 10:20 AM > To: Stas Malyshev > Cc: guilhermebla...@gmail.com; PHP Internals > Subject: Re: [PHP-DEV] annotations again > > mm i don't remember saying anything like that :) i dont want to

RE: [PHP-DEV] 5.4 again

> -Original Message- > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > Sent: Sunday, May 08, 2011 4:41 PM > To: PHP Internals > Subject: [PHP-DEV] 5.4 again > > Hi! > > I has been almost a month since we did our routine talk about 5.4, so here it > goes again. The patch for t

RE: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)

> -Original Message- > From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf > Of Adam Harvey > Sent: Monday, April 18, 2011 8:26 AM > To: internals Mailing List > > Is there any thought that we might stop throwing things into trunk soon and > start thinking about some s

RE: [PHP-DEV] RFC: built-in web server in CLI.

I really like the idea. Just to be clear though I'd change: Server is listening on localhost:8000... Press CTRL-C to quit. To something like: PHP Development Server is listening on localhost:8000... Press CTRL-C to quit. I think that makes it very clear this is for development and enhancements wi

RE: [PHP-DEV] PHP for embedded device: reduce size

HI Martin, Is it only file size you worry about or also memory footprint? I assume it'd also be the latter. If so, we can share a patch we've worked on which could allow you to reduce the memory footprint at compile time somewhat more (on the expense of performance, ...). We were going to send

RE: [PHP-DEV] RFC - MACRO

> -Original Message- > From: Mathias Grimm [mailto:mathiasgr...@gmail.com] > Sent: Wednesday, December 22, 2010 9:12 AM > To: internals@lists.php.net > Subject: [PHP-DEV] RFC - MACRO > > I want to request a C/C++ feature that i think is good. > > MACRO > > MACRO('PF','private function _

RE: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())

rom: Ilia Alshanetsky [mailto:i...@prohost.org] > Sent: Thursday, November 25, 2010 4:16 PM > To: Pierre Joye > Cc: Jonah H. Harris; Andi Gutmans; internals@lists.php.net > Subject: Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, > serialize()) > > Just read over th

RE: [PHP-DEV] Re: Hold off 5.4

> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Thursday, November 25, 2010 10:46 AM > To: Andi Gutmans > Cc: Ilia Alshanetsky; Johannes Schlüter; da...@php.net; PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > > Yes

RE: [PHP-DEV] Re: Hold off 5.4

> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Thursday, November 25, 2010 10:26 AM > To: Ilia Alshanetsky > Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP > Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 &

[PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())

Hi, Completely different topic :) I've been looking a bit into performance around json encoding, hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled and often transmitted over the wire. I know there have been some high-end apps that have benefited from some custom s

RE: [PHP-DEV] Re: Hold off 5.4

> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Thursday, November 25, 2010 9:27 AM > To: Johannes Schlüter > Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > Looking through

RE: [PHP-DEV] Re: Hold off 5.4

> -Original Message- > From: Johannes Schlüter [mailto:johan...@schlueters.de] > Sent: Thursday, November 25, 2010 9:21 AM > To: Andi Gutmans > Cc: Jani Taskinen; da...@php.net; PHP Internals > Subject: RE: [PHP-DEV] Re: Hold off 5.4 > > On Thu, 2010-11-25 at 1

RE: [PHP-DEV] Re: Hold off 5.4

> -Original Message- > From: Jani Taskinen [mailto:jani.taski...@iki.fi] > Sent: Thursday, November 25, 2010 12:25 AM > To: da...@php.net > Cc: PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > Who says it has to be 5.4? People seem to be a bit fixated on the version > there. >

RE: [PHP-DEV] git anyone?

> -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Wednesday, November 24, 2010 5:47 PM > To: PHP internals > Subject: [PHP-DEV] git anyone? > > hi, > > We have moved not too long ago and for what I see it gave some opportunities > to many of us to see what are

RE: [PHP-DEV] [RFC] Release Process

> -Original Message- > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > Sent: Wednesday, November 24, 2010 9:39 PM > To: Derick Rethans > Cc: Felipe Pena; internals > Subject: Re: [PHP-DEV] [RFC] Release Process > > Hi! > > >> With the recent chaos in the way we begin and ended relea

RE: [PHP-DEV] Adding path_len to all stream functions in trunk

> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Monday, November 15, 2010 9:25 PM > To: Andi Gutmans > Cc: Stas Malyshev; internals > Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk > > Well, it changes the si

RE: [PHP-DEV] Adding path_len to all stream functions in trunk

> -Original Message- > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > Sent: Monday, November 15, 2010 8:21 PM > To: Rasmus Lerdorf > Cc: internals > Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk > > Hi! > > > Ok, I went through all the 5.3 code. This shou

RE: [PHP-DEV] Adding path_len to all stream functions in trunk

Hi Rasmus, Hope I understood the problem correctly. If not, this answer won't make sense :) I do not see a major problem in passing path_len but wonder how much it'd actually solve as we end up calling OS APIs that do not accept path_len, no? I assume we don't want to start searching all these s

RE: [PHP-DEV] GPU Acceleration

> -Original Message- > From: Scott MacVicar [mailto:sc...@macvicar.net] > Sent: Friday, November 12, 2010 8:22 AM > To: Stefan Marr > Cc: Kenan Sulayman; PHP internals > Subject: Re: [PHP-DEV] GPU Acceleration > > What's not constructive about it? Seems pretty constructive to me. The >

RE: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

The first google entry when you search for it gives you the answer. It is actually unbelievably easy to find the answer via search. If a new PHP developer can't find it then maybe they shouldn't be writing code. This is a piece of history from the PHP 3 days and think it adds some character, a

RE: [PHP-DEV] Strict typing (was: Typehints)

I wouldn't mind living with neither but I think it's two separate discussions. > -Original Message- > From: Ilia Alshanetsky [mailto:i...@prohost.org] > Sent: Wednesday, August 11, 2010 3:52 AM > To: Zeev Suraski > Cc: Stas Malyshev; Johannes Schlüter; Kalle Sommer Nielsen; Internals; > D

RE: [PHP-DEV] Strict typing (was: Typehints)

> -Original Message- > From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] > Sent: Wednesday, August 11, 2010 5:19 AM > To: rquadl...@googlemail.com > Cc: Zeev Suraski; Ilia Alshanetsky; Stas Malyshev; Johannes Schlüter; Kalle > Sommer Nielsen; Internals; Derick Rethans > Subject: Re: [PH

Re: [PHP-DEV] APC in trunk

Can we deduct from that a 6 version number for trunk? :) just kidding I am also +1 on bundle but not on default. I think we should also reach out to other OSS caches to ensure they know they still have a place in our Eco system. Some are preferred by certain use cases. On Jun 21, 2010, at 9

RE: [PHP-DEV] Type hinting

So which RFC should I be reviewing? Does this RFC reflect what Ilia's patch does? I just want to be sure we are talking about the same thing and can review and comment on it in detail. We've had many discussions on this topic over the years and different people had different things in mind so we ne

RE: [PHP-DEV] [RFC] Performance improvements

Benjamin, Thanks for testing and sharing the data. These are great results and validate the progress made. Glad to see you're also seeing the improved memory usage which means that the runtime is not only faster but you can typically run more concurrent PHP instances. Andi > -Original Mes

RE: [PHP-DEV] trunk is alive and open

> -Original Message- > From: Johannes Schlüter [mailto:johan...@schlueters.de] > Sent: Tuesday, April 27, 2010 9:40 AM > To: Pierre Joye > Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe > Smith; Andi Gutmans; Derick Rethans; PHP Developers Mail

RE: [PHP-DEV] On constructors: BC Break and Class compiler Improvements

> -Original Message- > From: Stanislav Malyshev [mailto:s...@zend.com] > Sent: Thursday, April 01, 2010 12:34 PM > To: Pierre Joye > Cc: Ralph Schindler; internals > Subject: Re: [PHP-DEV] On constructors: BC Break and Class compiler > Improvements > > Hi! > > > Well, I think the question

RE: [PHP-DEV] php and multithreading (additional arguments)

Hi, I think that if we were ever to implement threading we would be best off to enable spawning worker threads that have their own context with no shared data (and therefore no requirement for locking). We could then have a message passing API between the threads. Advantages: - Real multi-threadin

RE: [PHP-DEV] trunk is alive and open

> -Original Message- > From: Derick Rethans [mailto:der...@php.net] > Sent: Tuesday, March 23, 2010 9:05 AM > To: PHP Developers Mailing List > Subject: [PHP-DEV] trunk is alive and open > > Hello, > > I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to > expli

RE: [PHP-DEV] PHP 6

> -Original Message- > From: Olivier Hill [mailto:olivier.h...@gmail.com] > Sent: Saturday, March 13, 2010 10:15 AM > To: Derick Rethans > Cc: PHP Developers Mailing List > Subject: Re: [PHP-DEV] PHP 6 > > We need to focus on Unicode more than what some says, whether this > means descoping

RE: [PHP-DEV] PHP 5.4 branch and trunk

> -Original Message- > From: Antony Dovgal [mailto:t...@daylessday.org] > Sent: Wednesday, March 17, 2010 2:25 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk > > On 03/16/2010 07:13 PM, Derick Rethans wrote: > >> + merge php-fpm branch? > > > > Can't see

RE: [PHP-DEV] About optimization

> -Original Message- > From: Tim Starling [mailto:tstarl...@wikimedia.org] > Sent: Wednesday, January 13, 2010 7:19 PM > To: Stas Malyshev > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] About optimization > > Stanislav Malyshev wrote: > > > > opcodes can be cached (bytecode caches

RE: [PHP-DEV] shebang skipping in 5.3.0

> -Original Message- > From: Tom Boutell [mailto:t...@punkave.com] > Sent: Saturday, September 05, 2009 6:30 AM > To: Marco Tabini > Cc: Pierre Joye; jani.taski...@iki.fi; Andi Gutmans; Joey Smith; > internals@lists.php.net > Subject: Re: [PHP-DEV] shebang skipp

RE: [PHP-DEV] shebang skipping in 5.3.0

Shebang is for command line scripts (php-cli). It does not make sense to support it for Web server scripts. It just adds unnecessary code/complexity to that code base. Removing the support from php-cgi was really a remnant of the old days when cli and cgi were the same SAPI. I think we are better o

RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/TSRM/tsrm_win32.c trunk/TSRM/tsrm_win32.c

You may want to look at pcntl_exec() which is the UNIX equivalent of what you want to do. It does not use sh and the pcntl extension is not supported on Windows. A Windows implementation may not fit this function signature but it's a good place to start. Andi > -Original Message- > From:

RE: [PHP-DEV] one RM to rule them all

Hi Lukas, Thanks for stepping up and helping Johannes make the PHP 5.3 release come together. Your tracking skills are definitely an asset :) Andi -Original Message- From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Sent: Thursday, July 09, 2009 11:06 AM To: PHP internals Subject: [P

RE: [PHP-DEV] RE: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/file bug41874.phpt bug47767.phpt link_win32.phpt TSRM tsrm_virtual_cwd.c

ot a patch that should go in at a late RC stage or even at any stage in an RC as they take some time to stabilize. Andi -Original Message----- From: Andi Gutmans [mailto:a...@zend.com] Sent: Monday, June 15, 2009 10:37 PM To: Pierre-Alain Joye Cc: internals@lists.php.net Subject: [PHP-DEV] RE

[PHP-DEV] RE: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/file bug41874.phpt bug47767.phpt link_win32.phpt TSRM tsrm_virtual_cwd.c

This really does not look like a very safe commit at this point in the RC cycle. These kind of patches are very challenging and can affect behavior of applications. They are affected by many things incl. user permissions, CIFS, applications that move files, and more... I am sure you have tested it

RE: [PHP-DEV] Notes from the PDM in Chicago

> -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Wednesday, June 03, 2009 11:50 PM > To: Andi Gutmans > Cc: Elizabeth M Smith; internals@lists.php.net > Subject: Re: [PHP-DEV] Notes from the PDM in Chicago > > > Btw, this is also

RE: [PHP-DEV] Notes from the PDM in Chicago

> -Original Message- > From: Elizabeth M Smith [mailto:auroraeosr...@gmail.com] > Sent: Wednesday, June 03, 2009 2:43 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Notes from the PDM in Chicago > yes Hannes - interfaces for userland implemented streams would help > people trying

RE: [PHP-DEV] RFC: Removing the Zend API

Hi Paul, This is something I have considered in the past esp. as it would also reduce dependency of extensions on PHP runtime and make it easier for 3rd parties to distribute PHP extensions which don't have to be rebuilt per-PHP version. This is similar to JNI. There are some real challenges t

RE: [PHP-DEV] Stream chunk size

I don't see a fundamental issue why it could not be arbitrary. The only challenge which may be an issue is that this code clearly allocates the buffer on the stack for what are probably performance reasons. If you allow arbitrary chunk size and use alloca() (do_alloca()) for stack allocation you

RE: [PHP-DEV] removing zend_dynamic_array.c from HEAD

It can be removed. It's something I started a long time ago for a new hash implementation and I never ended up using it. Andi > -Original Message- > From: David Soria Parra [mailto:d...@php.net] > Sent: Sunday, February 22, 2009 1:19 PM > To: internals@lists.php.net > Subject: [PHP-DEV] r

RE: [PHP-DEV] 5.3 todos

> -Original Message- > From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com] > Sent: Saturday, February 14, 2009 6:04 PM > To: Andi Gutmans > Cc: shire; Lukas Kahwe Smith; PHP Internals List > Subject: Re: [PHP-DEV] 5.3 todos > > And you are? > CTO of some

RE: [PHP-DEV] 5.3 todos

> -Original Message- > From: shire [mailto:sh...@tekrat.com] > Sent: Thursday, February 12, 2009 11:02 AM > To: Lukas Kahwe Smith > Cc: PHP Internals List > Subject: Re: [PHP-DEV] 5.3 todos > > > Seeing as I have an interest in this getting in 5_3, I'll work up a patch for > this unless s

  1   2   3   4   5   6   7   8   9   10   >