Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

On Sep 18, 2019, at 8:29 PM, Bishop Bettini wrote: > would you be willing to transfer your knowledge to our documentation? Absolutely! And thank you. I am traveling this week so I can't start until next week, but email me off list and we can coordinate? -Mike

Re: [PHP-DEV] Handling over sized keys on OpenSSL

On Sat, Aug 31, 2019 at 11:34 PM Leo Cavalcante wrote: > ... > Yeah, I was using a 256-bit length key with AES-128-CBC then trying to > decrypt it in another program never works. > > And in fact, its better to throw or even warn/notice about it instead of > silently allowing it, *what you

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

On Wed, Sep 18, 2019 at 7:31 PM Mike Schinkel wrote: > > ... I tried to get PHP compiled and working locally, and I failed > miserably. I decided I would participate on the list for a while and maybe > after some time I could ask for help getting it compiled on my Mac and in a > Docker

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

Hi Nikita, I am really happy to read your email. As you may have noticed I recently started participating on this list. About that time I tried to get PHP compiled and working locally, and I failed miserably. I decided I would participate on the list for a while and maybe after some time I

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

Den 2019-09-15 kl. 20:49, skrev Nikita Popov: Hi, Our build instructions in https://github.com/php/php-src#building-php-source-code are currently a bit bare... they show the basic "./buildconf && ./configure && make" cycle, but everyone who actually tries this will quickly find out that there

Re: [PHP-DEV] Re: [RFC] Union Types v2

Den 2019-09-18 kl. 15:33, skrev Nikita Popov: On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov wrote: Hi internals, I'd like to start the discussion on union types again, with a new proposal: Pull Request: https://github.com/php/php-rfcs/pull/1 Rendered Proposal:

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

Den 2019-09-18 kl. 21:44, skrev Claude Pache: Le 18 sept. 2019 à 18:28, Nikita Popov a écrit : I just realized that I missed one notice here, because it is generated from a different location: "Constant %s already defined" (The define/const will be ignored and the previous value used.) It

[PHP-DEV] Within 2 weeks, everything In PHP internals questioned

Hi Zeev, Not trying to be a distraction(I shouldn't even have messaged), but I guess you might be waking everyone up to some facts these recent days(probably in the wrong way, and to some; positive). Why did i write this? I've been following closely lately and have seen you(Zeev Suraski)

Re: [PHP-DEV] Improving productivity of internals mailing list

On Wed, Sep 18, 2019 at 8:33 PM Dan Ackroyd wrote: > # Problem 3 - Newcomers to the mailing list aren't following our > etiquette. # Problem 4 - Senior project members aren't following our email etiquette. This too isn't directed so much at Dan, but rather the list at large. Some facts

Re: [PHP-DEV] Improving productivity of internals mailing list

On Wed, Sep 18, 2019 at 1:33 PM Dan Ackroyd wrote: > > ... > > # Problem 1 - It's really hard to see what is being or could be worked on. > > People sometimes announce things that they think could be worked on > through the internals list, in the hope that people might want to help > them do

[PHP-DEV] Re: Constant propagation inside same compilation unit

On 9/18/19 7:18 PM, Nikita Popov wrote: > On Wed, Sep 18, 2019 at 5:10 PM Benjamin Coutu > wrote: > > Hello, > > During performance testing of the (awesome) PHP 7.4 preloading > feature I stumbled upon a lost opportunity I'd like to point out >

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

> Le 18 sept. 2019 à 18:28, Nikita Popov a écrit : > > I just realized that I missed one notice here, because it is generated from > a different location: "Constant %s already defined" (The define/const will > be ignored and the previous value used.) > > It would be great to have that as an

[PHP-DEV] Re: Improving productivity of internals mailing list

On Wed, 18 Sep 2019 at 18:33, Dan Ackroyd wrote: > > As an experiment I'm going to attempt to keep a list of items that > could be worked on over at > https://github.com/Danack/RfcCodex/project_coordination.md Apologies, the link should have been:

Re: [PHP-DEV] Improving productivity of internals mailing list

On Wed, Sep 18, 2019 at 1:33 PM Dan Ackroyd wrote: > Hi Internals, > > I've been thinking about how "non-productive" our internals mailing > list has been, both for many years, and particularly the last couple > of weeks. I've come to at least one conclusion; using only an email > based mailing

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

On Wed, Sep 18, 2019 at 12:51 PM Nikita Popov wrote: > On Wed, Sep 18, 2019 at 6:32 PM guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > > > Nikita, > > > > I'd suggest to wait until the current vote ends and then open a new > > RFC to vote this one, otherwise it'll be

[PHP-DEV] Improving productivity of internals mailing list

Hi Internals, I've been thinking about how "non-productive" our internals mailing list has been, both for many years, and particularly the last couple of weeks. I've come to at least one conclusion; using only an email based mailing list as the main project management tool for a project the size

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

On Wed, Sep 18, 2019 at 6:32 PM guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Nikita, > > I'd suggest to wait until the current vote ends and then open a new > RFC to vote this one, otherwise it'll be disrupting. > Err, to be clear, I'm not suggesting to change the RFC under

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

Nikita, I'd suggest to wait until the current vote ends and then open a new RFC to vote this one, otherwise it'll be disrupting. Cheers, On Wed, Sep 18, 2019 at 12:29 PM Nikita Popov wrote: > > On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote: > > > Hi internals, > > > > I've opened the

[PHP-DEV] Re: [VOTE] Reclassifying engine warnings

On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov wrote: > Hi internals, > > I've opened the vote on //wiki.php.net/rfc/engine_warnings. > > There are 4 votes, all of them independent. The first 3 are for specific > cases that were controversial during the discussion, the last one is for > the

[PHP-DEV] Re: Constant propagation inside same compilation unit

On Wed, Sep 18, 2019 at 5:10 PM Benjamin Coutu wrote: > Hello, > > During performance testing of the (awesome) PHP 7.4 preloading feature I > stumbled upon a lost opportunity I'd like to point out (though this has > nothing to do with preloading per se). > > Please consider the following

Re: [PHP-DEV] Re: State of mhash?

On Wed, Sep 18, 2019 at 6:39 AM Christoph M. Becker wrote: > > On 17.09.2019 at 16:25, Nikita Popov wrote: > > Should these functions be deprecated? Should this compatibility layer be > > kept indefinitely? > > The documentation[1] states for more than ten years now: > > | This extension is

[PHP-DEV] Constant propagation inside same compilation unit

Hello, During performance testing of the (awesome) PHP 7.4 preloading feature I stumbled upon a lost opportunity I'd like to point out (though this has nothing to do with preloading per se). Please consider the following snippet: const TEST = 14; function d() { echo TEST; } The function

Re: [PHP-DEV] Changing PECL signup flow.

On September 18, 2019 3:32:38 PM GMT+02:00, "Christoph M. Becker" wrote: >On 18.09.2019 at 15:22, Johannes Schlüter wrote: > >> The Windows builds are also a relevant factor in the discussions >> regarding the PECL site. Afaik (Anatoliy and others know better than >> me) packages uploaded to

Re: [PHP-DEV] Evolving PHP

On Wed, Sep 18, 2019 at 9:43 AM Claude Pache wrote: > > > > Le 16 sept. 2019 à 21:32, Nikita Popov a écrit : > > > > * Discussion threads on this mailing list have been very unpleasant > > recently. I am unwilling to actively participate in them in this form. > This > > is bad for everyone, but

Re: [PHP-DEV] Evolving PHP

> Le 16 sept. 2019 à 21:32, Nikita Popov a écrit : > > * Discussion threads on this mailing list have been very unpleasant > recently. I am unwilling to actively participate in them in this form. This > is bad for everyone, but particularly for opponents of proposals. It means > that we cannot

[PHP-DEV] Re: [RFC] Union Types v2

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov wrote: > Hi internals, > > I'd like to start the discussion on union types again, with a new proposal: > > Pull Request: https://github.com/php/php-rfcs/pull/1 > Rendered Proposal: >

Re: [PHP-DEV] Changing PECL signup flow.

On 18.09.2019 at 15:22, Johannes Schlüter wrote: > The Windows builds are also a relevant factor in the discussions > regarding the PECL site. Afaik (Anatoliy and others know better than > me) packages uploaded to the pecl site are being built in the same > setup as our official PHP runtime

Re: [PHP-DEV] Changing PECL signup flow.

On Mon, 2019-09-16 at 11:13 +0200, Christoph M. Becker wrote: > > For the record, there is already > , but that project looks like > it has fallen asleep. > Right and contrary to the old PECL/PEAR tool this can also fetch the precompiled Windows

[PHP-DEV] Re: State of mhash?

On 17.09.2019 at 16:25, Nikita Popov wrote: # > I just noticed that the hash extension has a default-disabled --with-mhash > option, that enables a couple of additional mhash_* functions. From what I > was able to gather, mhash was an old extension that was superseded by hash, > and hash provides

Re: [PHP-DEV] Adding return types to internal methods (PHP 8)

I am not a voting member, but I agree with Sara Golemon. This is just too big a BC break. I had similar questions in my own projects, and always chose to find a solution that does not break BC. The strategy was: - Keep existing classes and interfaces stable. - Introduce new classes or interfaces

Re: [PHP-DEV] Adding return types to internal methods (PHP 8)

Hi internals, I appologise for writing here without warning, and without being an active member of Internals. But I did not find any other public way to fairly contribute to the conversation: externals.io, though is claim ("opening #internals to the outside") is actually closed, and writing a