Re: [PHP-DEV] Travis CI migration?
Hi! The exception being the PHP-7.3 branch, which in security mode. Unless we add GH CI for that branch as well, switching to travis-ci.com seems to be useful. Maybe we get enough free credits for the relatively rare builds? I don't think it's possible to migrate only one branch, but if we migrate the whole repo and use cron-only builds for upper branches, and request OSS credits if we run out of free ones, I think we should be OK. Given that we have 7.3 still which aren't supported by Azure as I understand, I think we should migrate the repo but not invest too much into making it work for 8.x, just make it work for more infrequent 7.x builds. I'm not sure how credits work there yet, but I think we could ask enough of them to have 7.3 and maybe even 7.4 supported and not worry too much about the rest. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
Hi Rowan and all, I apologize in advance for the wall-of-text; the short questions lead to long answers. > On Jan 2, 2021, at 12:56, Rowan Tommins wrote: > > On 01/01/2021 20:31, Paul M. Jones wrote: > >> The complaints against the incomplete and inconsistent immutability of PSR-7 >> have merit. > > The big mistake of PSR-7, in my view, is mixing immutable objects with > streams, which are inherently mutable/stateful. (/me nods along) Streams were noted as the one explicit exception to immutability in PSR-7. Looking back on it, that should have been a sign to us that immutability should not have been a goal. (Re: PSR-7 but not re: immutability, there is at least one more mistake born of the original intent, that seemed reasonable at the time but in hindsight was another poor decision: it combines the concerns of the HTTP message with the concerns of middleware communication. This observation is attributable to [deleted] at Reddit ... https://www.reddit.com/r/PHP/comments/5ojqr0/q_how_many_psr7_implementations_exist_a_zero/dcjxtxl/ ... stating "[T]he true intent of PSR-7 [is] not to be an HTTP message standard, but to be middleware IO standard, which happens to be mostly (but not only) an HTTP message." It's an accurate assessment.) > I wonder if there are any lessons to be learned there in terms of what kinds > of immutability the language should encourage / make easy. I think there are; I wrote about at least some of them here ... https://paul-m-jones.com/post/2016/09/06/avoiding-quasi-immutable-objects-in-php/ ... in which I conclude that, if you want to build a truly immutable object in PHP, it appears the best approach is the following: - Default to using only scalars and nulls as properties. - Avoid streams as properties; if a property must be a stream, make sure that it is read-only, and that its state is restored each time it is used. - Avoid objects as properties; if a property must be an object, make sure that object is itself immutable. - Especially avoid arrays as properties; use only with extreme caution and care. - Implement __set() to disallow setting of undefined properties. - Possibly implement __unset() to warn that the object is immutable. I put those conclusions (and other resulting from that article) into an implementation described here: http://paul-m-jones.com/post/2019/02/04/immutability-package-for-php/ > is it better to constrain entire objects to be immutable rather than > individual properties? I would say that the entire object ought to be immutable, for reasons that are difficult for me to articulate. > And should there be restrictions on what you can declare as immutable, since > "immutable resource" is largely nonsensical? I think so, and I note some of those restrictions above. In particular, the immutability package ValueObject further inspects arrays to restrict their values to immutables as well. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Configurable callback to dump results of expressions in `php -a`
On Sun, Dec 20, 2020 at 11:36 PM tyson andre wrote: > Hi internals, > > I've created a new RFC > https://wiki.php.net/rfc/readline_interactive_shell_result_function > adding a way to configure a callback to be called to dump the value of > single-expression statements from `php -a` > (and an ini setting that can be disabled to prevent that callback from > being called). > > Many REPLs (Read-Eval-Print Loops) for other programming languages that > I'm familiar with > print a (possibly truncated) representation of the result of expressions, > but PHP doesn't. > It would be useful to allow users to extend the functionality of the > default interactive php shell (php -a), > possibly with auto_prepend_file or through use of command > wrappers/aliases, or after loading the shell. > Prior to this RFC, there was no way to extend the interactive php shell in > this way. > (I've seen https://github.com/bobthecow/psysh mentioned as an alternative > for php -a while investigating this, > but that's a shell written from scratch, and doesn't have some > functionality from php -a such as tolerance of fatal errors) > > Because PHP's interactive shell is written in C, adding new features or > bug fixes is inconvenient - it would require a lot > of time getting familiar with C programming, PHP's internals and memory > management, > and with PHP's internal C ast representation. > It would be easier and more accessible to extend PHP's interactive shell > through code written in PHP rather than code written in C. > > This was among the proposed enhancements I brought up in > https://externals.io/message/111073 . > An earlier version of the implementation was also created months ago - > https://github.com/php/php-src/pull/5962 > Reading through the linked earlier mail, you have quite a few additional hooks in mind, which might need a significant amount of additional userland code (such as a parser implementation) to usefully implement. At that point I'm wondering what the benefit of this hybrid approach is, relatively to a userland implementation like psysh. That is: a) Assuming all the hooks have been implemented, what additional functionality is the interactive shell implementation itself actually providing? b) Is it possible to go the other way around, and expose that additional functionality to userland instead? You do mention fatal error tolerance as one distinguishing feature -- is there anything beyond that? Regards, Nikita
Re: [PHP-DEV] Travis CI migration?
On 02.01.2021 at 22:43, Nikita Popov wrote: > On Sat, Jan 2, 2021 at 6:51 AM Stanislav Malyshev > wrote: > >> Today I noticed the message on travis-ci.org: >> >> Please be aware travis-ci.org will be shutting down in several weeks, >> with all accounts migrating to travis-ci.com. Please stay tuned here for >> more information. >> >> As far as I know, our repo is still not migrated. Anybody looked into it? >> >> Also, as I understand, the .com builds will be managed used credits >> system, with OSS getting allocated credits: >> >> https://docs.travis-ci.com/user/billing-faq#what-if-i-am-building-open-source >> but this has to be done manually. I can reach out to them but wanted to >> ask first in case somebody already did. >> >> Looks like we need to take care of it pretty soon or we risk losing >> access to the CI. > > We haven't been using Travis as our primary CI for a while already. We use > AppVeyor for Windows testing and Azure Pipelines for everything else. The > only thing Travis is still used for is a daily cron job that tests PHP on > "exotic" architectures like aarch64 and s390x. Having those builds is a > nice to have, but not particularly critical. The exception being the PHP-7.3 branch, which in security mode. Unless we add GH CI for that branch as well, switching to travis-ci.com seems to be useful. Maybe we get enough free credits for the relatively rare builds? Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
2021-01-02 21:25 GMT, Larry Garfield : > On Sat, Jan 2, 2021, at 12:56 PM, Rowan Tommins wrote: >> On 01/01/2021 20:31, Paul M. Jones wrote: >> > The complaints against the incomplete and inconsistent immutability of >> > PSR-7 have merit. >> >> >> The big mistake of PSR-7, in my view, is mixing immutable objects with >> streams, which are inherently mutable/stateful. I wonder if there are >> any lessons to be learned there in terms of what kinds of immutability >> the language should encourage / make easy. >> >> For instance, is it better to constrain entire objects to be immutable >> rather than individual properties? And should there be restrictions on >> what you can declare as immutable, since "immutable resource" is largely >> nonsensical? >> >> Or is it rather a reflection that building purely immutable >> implementations is hard, and the language needs other facilities >> (monads? ownership?) to mix in those parts that don't fit? >> >> Regards, > > I rarely hear that called out as a PSR-7 complaint specifically, in > practice, but moving on... > > IMO, it's better to put the focus on immutable properties. There are use > cases where you want only some properties to be immutable, but not the whole > class. If you do want the whole class, then marking all the properties > immutable is effectively the same thing. > > Though, again, in practice, at least in PHP, I don't think immutable > properties should be the goal. Asymmetric visibility lets us built safely > immutable-from-the-outside objects that are "up to you" on the inside. I > think that gives us a better end result given the nature of PHP. In other > languages that wouldn't make as much sense, but PHP is what it is. > > Copy on write makes "immutable data structures" not something we need to > build explicitly; we get "close enough" for free. If you really wanted to > micro-optimize the memory and CPU usage further than that... go build it in > Rust instead. Correct me if I'm wrong, but copy-on-write is only beneficial with values, not references to values (objects)? When you clone with a `with` method, you always write, so you always have to copy. And objects are already free to pass around without any copying happening automatically (as is the case with arrays, which have value semantics, which is why copy-on-write was implemented to not copy needlessly when an array is only read from). Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Improving PRNG implementation.
Unfortunately, there is not much feedback on this proposal. To remedy the situation, we have updated the RFC and implemented it. https://wiki.php.net/rfc/object_scope_prng https://github.com/php/php-src/pull/6568 Currently, it seems to work generally as expected, although it has failed to be tested on Windows. However, I am not sure if it is correctly with the new serialize / unserialize mechanism of PHP. (Of course we've tested the behavior) 2020年12月16日(水) 23:46 zeriyoshi : > Nice to meet you, internals. > > PHP 8.0 has been released. With the inclusion of JIT, PHP is about to be > extended beyond the web. > > So I'd like to make a few suggestions. > > First , PHP has the historical Mersenne Twister PRNG. However, this > implementation keeps its state in a global and cannot be handled as an > object like other languages (e.g. Java). > > So, I created a PHP Extension and proposed it to PECL. > > https://marc.info/?l=pecl-dev=160795415604102=2 > https://github.com/zeriyoshi/php-ext-orng > > But, Then I looked at the mailing list archives and noticed that a similar > proposal had been made before. > > https://externals.io/message/98021#98130 > > I feel that this suggestion is needed now to expand PHP beyond the web. > > Second suggestion is to stop using the Combined LCG as the default seed > value for each function. > > PHP's Combined LCG only uses PID (or ZTS Thread ID) and time as entropy. > https://github.com/php/php-src/blob/master/ext/standard/lcg.c#L72 > > With the development of container technology, this problem seems to be > getting more serious. So I think we should use the random numbers provided > by the OS (getrandom on Linux) if available. > > I would like to hear your opinions. > > Regards > Go Kudo >
Re: [PHP-DEV] Travis CI migration?
On Sat, Jan 2, 2021 at 6:51 AM Stanislav Malyshev wrote: > Hi! > > Today I noticed the message on travis-ci.org: > > Please be aware travis-ci.org will be shutting down in several weeks, > with all accounts migrating to travis-ci.com. Please stay tuned here for > more information. > > As far as I know, our repo is still not migrated. Anybody looked into it? > > Also, as I understand, the .com builds will be managed used credits > system, with OSS getting allocated credits: > > https://docs.travis-ci.com/user/billing-faq#what-if-i-am-building-open-source > but this has to be done manually. I can reach out to them but wanted to > ask first in case somebody already did. > > Looks like we need to take care of it pretty soon or we risk losing > access to the CI. > Hi Stas, We haven't been using Travis as our primary CI for a while already. We use AppVeyor for Windows testing and Azure Pipelines for everything else. The only thing Travis is still used for is a daily cron job that tests PHP on "exotic" architectures like aarch64 and s390x. Having those builds is a nice to have, but not particularly critical. Regards, Nikita
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
On Sat, Jan 2, 2021, at 12:56 PM, Rowan Tommins wrote:
> On 01/01/2021 20:31, Paul M. Jones wrote:
> > The complaints against the incomplete and inconsistent immutability of
> > PSR-7 have merit.
>
>
> The big mistake of PSR-7, in my view, is mixing immutable objects with
> streams, which are inherently mutable/stateful. I wonder if there are
> any lessons to be learned there in terms of what kinds of immutability
> the language should encourage / make easy.
>
> For instance, is it better to constrain entire objects to be immutable
> rather than individual properties? And should there be restrictions on
> what you can declare as immutable, since "immutable resource" is largely
> nonsensical?
>
> Or is it rather a reflection that building purely immutable
> implementations is hard, and the language needs other facilities
> (monads? ownership?) to mix in those parts that don't fit?
>
> Regards,
I rarely hear that called out as a PSR-7 complaint specifically, in practice,
but moving on...
IMO, it's better to put the focus on immutable properties. There are use cases
where you want only some properties to be immutable, but not the whole class.
If you do want the whole class, then marking all the properties immutable is
effectively the same thing.
Though, again, in practice, at least in PHP, I don't think immutable properties
should be the goal. Asymmetric visibility lets us built safely
immutable-from-the-outside objects that are "up to you" on the inside. I think
that gives us a better end result given the nature of PHP. In other languages
that wouldn't make as much sense, but PHP is what it is.
Copy on write makes "immutable data structures" not something we need to build
explicitly; we get "close enough" for free. If you really wanted to
micro-optimize the memory and CPU usage further than that... go build it in
Rust instead.
Wrapping immutable behavior around IO is... ugly, gross, and disgusting. :-)
Even supposedly Twue Pure languages like Haskell don't actually do that; it
just hides the IO mutability in the engine and whistles innocently while
muttering "monad" under its breath. :-)
At least in the abstract, immutability and IO would require IO primitives that
returned both a read value and a new stream pointer, possibly consuming and
destroying the old one. If a stream is seekable, you could conceptually do
something like:
$fp = file_open('foo.txt');
[$line, $fp2] = read_line($fp);
In which $fp2 and $fp refer to the same file stream on disk, but their stream
pointers are different. In practice you'd likely use $fp as the second
parameter and lose the old reference, which is good enough. That's a bit
clumsy, though, and where one might use something monad-based to make the code
a bit simpler. I don't know off hand what that would look like, though.
[$line1, $fp2] = read_line($fp);
[$line2, $fp2] = read_line($fp);
[$line3, $fp2] = read_line($fp);
[$line4, $fp2] = read_line($fp);
In the above example, since $fp is never overwritten, all 4 $line variables are
the same thing.
If a stream is not seekable, then it would have to consume and destroy $fp in
the process (unset it). So:
[$line1, $fp2] = read_line($fp);
[$line2, $fp2] = read_line($fp);
The second line would throw an error that $fp "has been consumed" or something
like that. But even that still creates potential for
spooky-action-at-a-distance if $fp was passed into a function, gets read in
that function, and then the parent call scope has a broken $fp lying around.
IO is inherently impure and mutable, and always will be. I don't think it's
realistic for us to fix that, certainly not in PHP. Instead we should be
making it easy to encapsulate the IO into safe corners where you can guard it
carefully and keep everything else as pure as reasonable.
All of which is why the scope I'm looking at is not how to make PHP
Haskell-esque pure. It's how do we make it more ergonomic for developers to
build stateless code in those places where it's reasonable to do so. It's a
much less ambitious, but therefore more achievable, scope.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
On 01/01/2021 20:31, Paul M. Jones wrote: The complaints against the incomplete and inconsistent immutability of PSR-7 have merit. The big mistake of PSR-7, in my view, is mixing immutable objects with streams, which are inherently mutable/stateful. I wonder if there are any lessons to be learned there in terms of what kinds of immutability the language should encourage / make easy. For instance, is it better to constrain entire objects to be immutable rather than individual properties? And should there be restrictions on what you can declare as immutable, since "immutable resource" is largely nonsensical? Or is it rather a reflection that building purely immutable implementations is hard, and the language needs other facilities (monads? ownership?) to mix in those parts that don't fit? Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
On 31/12/2020 14:04, Olle Härstedt wrote: Yes, of course you can find use-cases where immutability is a better choice, just like I can find use-cases where (constrained) mutability is better. The point is not to replace one tool with another, but rather adding another tool to the toolbox. The web dev discourse is one-sided with regard to immutability, I think. Wish I had time to implement a PR to Psalm to show something more concrete... Again, if you only have a hammer, everything looks like a nail. :) Certainly, I didn't mean to say that immutability was always the perfect choice. I think it's popular because it's an easy hammer to borrow from the fashionable Functional Programming toolbox - you can get a lot of its advantages without much support from the language, and it genuinely fits a lot of use cases encountered in high-level programming. Where ownership concepts seem to shine is where immutability is either impossible (e.g. consuming from a network stream or an event queue) or otherwise undesirable (e.g. working with large amounts of data, or tightly optimised code). I read a bit about Uniqueness Attributes in Clean [1] and it seems they are implemented there so that the *user* can treat everything as immutable, but the *compiler* can safely mutate underlying structures. So in that implementation at least, a "mutable record" would in fact be implemented with the equivalent of "clone ... with", so that it appeared *from the outside* to return a new instance each time. It's certainly an interesting concept, particularly for the I/O case (where immutability is genuinely not an option) but how easy it would be to retro-fit to a dynamic language like PHP I'm not sure. [1] https://cloogle.org/doc/#_9 Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
On Fri, Jan 1, 2021, at 5:51 PM, Olle Härstedt wrote:
> >> The web dev discourse is
> >> one-sided with regard to immutability,
> >
> > Yes, if you've heard any of the regular whining about PSR-7 being an
> > immutable object you'd think it's one-sided in favor of mutability. ;-)
> >
> > As you say, the point here is to add tools. Right now, doing immutability
> > in PHP in syntactically clumsy and ugly. We want to fix that, and that has
> > to include some means of "give me a new value based on this existing value
> > but with some difference." (aka, exactly what with-er methods do, although
> > I agree entirely that if you have the option of less generic names, use
> > them).
> >
> > So, can we get back to the original post, which is proposing specifics of
> > the tools to make that happen? :-) (Asymmetric visibility and clone-with,
> > specifically.)
> >
>
> OK!
>
> I like that you connect higher level design patterns with language
> design. This is the way to go, IMO. Personally, I'd prefer support for
> the Psalm notation `@psalm-readonly`, which is the same as your
> initonly. Clone-with makes sense too, as this construct is already
> supported in multiple languages. The exact notation doesn't matter
> that much - my personal choice is OCaml {record with x = 10} over JS
> spread operator, but OCaml is pretty "wordy" in notation in contrast
> to the C tradition that PHP is part of.
>
> Reintroducing "objects that pass by value" is a hard pass from me. The
> way forward is immutability and constrained mutability (ownership,
> escape analysis, etc). Psalm also supports array shapes - maybe this
> can be investigated as an alternative? Since PHP has no tuples.
>
> I'm not convinced the added complexity of asymmetric visibility is
> powerful enough to motivate its existence. Feel free to prove me
> wrong. :) My choice here would be namespace "internal" (also supported
> by Psalm already), but this requires implementation of namespace
> visibility, a PR that was abandoned.
>
> And also, happy new year!
Happy New Year!
I agree that "objects, but passing by value" would not be the right solution. I
used to think that would be a good part of the solution, but eventually
concluded that it would introduce more complexity, not less. Eventually,
everything people wanted to do with objects they'd want to do with "Records"
(for lack of a better term), and if they pass by value but are still mutable
then you have a weird situation where sometimes changes propagate and some
don't (depending on if you have a record or object). Making it easier to use
objects in a value-esque way will get us closer to the desired end state.
I think the tldr of my post is this: A single "immutable" flag (whatever it's
called) on a class or property would require having lots of holes poked in it
in order to make it useful in practice (mostly what "initonly" would do), but
those holes would introduce other holes we don't want (cloning an object from
the outside when you shouldn't).
Asymmetric visibility, however, doesn't give us true immutability but allows a
class author to more easily emulate it "close enough", while also supporting
various other use cases. Its gap is the class author, not the entire rest of
the programming industry. That makes it much safer, and gets us to objects
that are effectively immutable from the outside, which is what's important.
(If they're mutable from the inside, either there are use cases for that or
rely on the good behavior of just the class author, who is in the best position
to know if the object should be internally immutable or not.)
Pairing that with an easy clone-with-change syntax would allow class authors to
easily construct something that is immutable-in-practice fairly easily, even if
it's not Twue Immutability(tm).
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Configurable callback to dump results of expressions in `php -a`
Hi internals, > I've created a new RFC > https://wiki.php.net/rfc/readline_interactive_shell_result_function > adding a way to configure a callback to be called to dump the value of > single-expression statements from `php -a` > (and an ini setting that can be disabled to prevent that callback from being > called). > > Many REPLs (Read-Eval-Print Loops) for other programming languages that I'm > familiar with > print a (possibly truncated) representation of the result of expressions, but > PHP doesn't. > It would be useful to allow users to extend the functionality of the default > interactive php shell (php -a), > possibly with auto_prepend_file or through use of command wrappers/aliases, > or after loading the shell. > Prior to this RFC, there was no way to extend the interactive php shell in > this way. > (I've seen https://github.com/bobthecow/psysh mentioned as an alternative for > php -a while investigating this, > but that's a shell written from scratch, and doesn't have some functionality > from php -a such as tolerance of fatal errors) A reminder that I plan to start the vote on https://wiki.php.net/rfc/readline_interactive_shell_result_function on 2021-01-03 Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
