[PHP-DEV] turkish documentation
Hello,
I would like to translate some of the 7.4 documentation into turkish. It
seems like wiki username and password does not work for documentation. I
could not find the list of language mail lists as well. (it says
doc-{LANG}@lists.php.net but where?)
Any ideas?
Thanks,
Midori
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
On Sat, Jan 11, 2020, at 6:40 AM, Robert Hickman wrote:
> With PHP having recently introduced preloading, i have been thinking
> about the possibility of adding a system whereby arbitrary php code
> can run during this step. Essentially, this would serve the same
> function as 'compile time execution' in many programming languages. It
> should be noted that my thoughts below are mostly inspired by the
> in-development language JAI, demos of which are included at the end of
> this email.
>
> While PHP is an interpreted language, code is first parsed which
> generates an AST, and this AST is then used to generate bytecode that
> is stored in opcache. With preloading, the generation of this bytecode
> is done only once on server startup. Compile time code would run
> during this stage as a 'shim' between parsing and bytecode generation,
> allowing arbitrary modifications to the AST.
>
> I can think of numerous examples of ways this could be advantageous.
> For one, frameworks often want to store configuration data in a
> database or some other external source, and accessing it every request
> is needless overhead, given that data tends to never change in
> production. So you could do something like the following which runs
> once during preload, and caches the constant in opcache.
>
>
>
> static_run {
> $link = mysqli_connect("127.0.0.1", "my_user", "my_password", "my_db");
> $res = mysqli_query ($link, 'select * from sometable');
>
> $array = [];
> while($row = mysqli_fetch_assoc($res)) {
> $array[]= $row;
> }
>
> define('CONST_ARRAY' = $array);
> }
>
>
> static_run being a new keyword that allows an expression to be
> evaluated at compile time.
>
> I foresee this being able to do far more than simply define constants
> though. In my opinion, it should be able to allow arbitrary
> modifications to the AST, and arbitrary programmatic code generation.
> For example, static code could register a callback which receives the
> AST of a file during import:
>
>
>
> static_run {
> on_file_load(function($file_ast){
>
> // Do something with the ast of the file
>
> return $file_ast;
> });
> }
>
>
> As noted above, I can think of numerous things that this could do, and
> as a flexible and far reaching facility, I am sure many more things
> are possible that I have not considered. To give a few examples:
>
> * Choose a database interface once instead of during every request.
>
> * Check the types defined in an orm actually match the database.
>
> * Inverting the above, programmatically generate types from a database table.
>
> * Compile templating languages like twig into PHP statically,
> eliminating runtime overhead
>
> * Convert syntactically pretty code into a more optimised form.
>
> * Statically generate efficient code for mapping URLs to handler functions
>
> * Validate the usage of callback systems such as wordpress 'shortcodes'.
>
> * Arbitrary code validation, such as to implement corporate
> programming standards.
>
>
> Why not a preprocessor?
>
> While things like this can be implemented as a preprocessor, I can see
> considerable advantages of implementation as a native feature of the
> language itself. A big one is that it would be aware of the semantics
> of the language like namespaces, and scope, which is a big downside of
> rudimentary preprocessors like the one in C/C++. Implementing it into
> the language runtime also eliminates the need for a build step, and
> means that everyone using the language has access to the same tools.
>
> I also think that given that these data structures already exist
> during compilation to bytecode, why not just give programmers access
> to them?
>
> This concept is not that unusual and python for example, allows python
> code to modify the AST of files as they are being loaded. However
> directly modifying the AST won't be very user friendly. Due to this,
> syntax could be created which allows the more common operations to be
> done more easily. Rust has a macro system that is based on this kind
> of idea, and JAI has recently introduced something comparable. While
> it should be obvious from the above, i am not talking about macros in
> the C sense. These should be 'hygienic macros'.
>
>
> How it runs
>
> On the web, compile time code is ran during preloading. When running
> php code at the CLI, compile time code could just be run every time,
> before run time code. Cacheing the opcodes in a file and automatically
> detecting changes and recompiling this as python does, could be a
> worthwhile optimisation.
>
>
> Inspirations
>
> The general idea with this was inspired by the in development
> programming language JAI, which has full compile time execution.
> Literally, the entire programming language can be run at compile time
> with very few restrictions. See the following to videos for a
> demonstration of what it
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
> Once you are in a live environment you want a read-only file system, for > security and auditability. Code generation at that point is then impossible. > Moving that code gen to a preloader wouldn't help with that. My proposal has no impact on the file system. It would modify the AST, and thus would be entirely in RAM as opcache is also in ram. No source files involved at all. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bump required libcurl version to 7.17.1
On Sat, Jan 11, 2020 at 4:57 AM Olumide Samson wrote: > > Why not the most recent and stable version? > > I'm thinking modern version has many bugs fixed and many vulnerabilities > fixed, even with improvements that make things more faster and lighter... Using the most recent version would make it more difficult for people on supported but not cutting edge operating systems to build from source. IMO, it should be buildable on all major Linux operating systems in regular support using their native packaging system. The oldest supported OS and version I can even conceivably care about is RHEL/CentOS 6 (which is in extended security mode), which appears to use curl 7.19; after that RHEL/CentOS 7 uses curl 7.29. In other words, I recommend against *requiring* the latest curl version and but do recommend bumping the minimum up to at least v7.19. Unless we really need something from newer versions (which it doesn't look like we do), anything newer than 7.29 would just cause friction for people building from source. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bump required libcurl version to 7.17.1
On Sun, 12 Jan 2020 at 23:33, Levi Morrison via internals < internals@lists.php.net> wrote: > On Sat, Jan 11, 2020 at 4:57 AM Olumide Samson > wrote: > > > > Why not the most recent and stable version? > > > > I'm thinking modern version has many bugs fixed and many vulnerabilities > > fixed, even with improvements that make things more faster and lighter... > > Using the most recent version would make it more difficult for people > on supported but not cutting edge operating systems to build from > source. IMO, it should be buildable on all major Linux operating > systems in regular support using their native packaging system. The > oldest supported OS and version I can even conceivably care about is > RHEL/CentOS 6 (which is in extended security mode), which appears to > use curl 7.19; after that RHEL/CentOS 7 uses curl 7.29. > > In other words, I recommend against *requiring* the latest curl > version and but do recommend bumping the minimum up to at least v7.19. > Unless we really need something from newer versions (which it doesn't > look like we do), anything newer than 7.29 would just cause friction > for people building from source. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > As this is targeting PHP 8 I would say 7.29 would be better IMHO as RHEL/CentOS 6 EOL is November 30, 2020 [1] [2] which means it would be EOL just after PHP 8 is released (if PHP 8 is release on the yearly schedule). My two cents Best regards George P. Banyard [1] https://endoflife.software/operating-systems/linux/centos [2] https://access.redhat.com/discussions/2399461
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
> On Jan 12, 2020, at 1:57 PM, Larry Garfield wrote: > > Most notably, *not all code will be run in a preload context*. Can you give some concrete examples here? > Language features that only sometimes work scare me greatly. Do you have some examples of language features, from PHP or another language, that only work sometimes and that are known to be problematic. and why they are problematic? > Doing one-time optimizations in preload that make the code faster, that's > great. Though I think this proposal may need to be fine-tuned, I can envision many frameworks and CMSes written in PHP could improve both performance, robustness and user-experience using preloading. One of the ways most useful would be to run code that ensures the framework/CMS APIs are being used correctly. If this code is included today in frameworks and CMSes, it must run for every page load (on the web) when it could be run once when OpCode is generated. This could potentially improve performance significantly, depending on how much checking it implemented. It could also improve performance of building data-driven structures at runtime. I know that in the past I have had data driven structures that were definitely very time-consuming on each page load. The WordPress admin does tons of it. > Preload optimizations that make the code behave differently, that's extremely > dangerous. Can you give some concrete examples where you fear this could happen? > "I changed one character and now I have to restart my webserver to see if it > did anything" is a bad place for PHP to be. As I envision it preloaded code of this nature would not be handled on server reboot, but when the files have had their time stamps updated. If I am not mistaken, PHP already does this (but I could be mistaken as I don't have expertise in PHP OpCodes.) Whatever the case I think this could easily be handled with a simple API call to flush preloaded code which for debugging could be one of the first things a developer would call in their codebase. > I am highly skeptical about allowing arbitrary preload/compile time behavior > as it makes development harder and bifurcates the ecosystem. Given the copious performance and robustness benefits that preloading could provide, I would think we should try and identify specific concrete concerns rather than allow unidentified concerns from blocking a potentially great improvement to the language. So what specific concrete concerns can we identify? > To your specific examples, many are already possible today. Code generation > in a pre-execute build step is increasingly common; the Symfony ecosystem > does a ton of it, I've implemented a compiled version of a PSR-14 Event > Dispatcher, etc. Am I understanding correctly that requires a _build_ process, and not something that a PHP developer can depend upon having available on any hosted PHP server? > Code generation at that point is then impossible. Moving that code gen to a > preloader wouldn't help with that. As Robert stated, he is not proposing any code generation. His preloading concept would modify classes by manipulating the AST, which, IMO would require an additional API. And I do think it is probably orthogonal to the idea of preloading code although I do think it would also have great benefit too, but that preloading is probably a prerequisite. > I appreciate the intent here, but in practice I'd much rather we limit > preload optimization to things the engine can do for us, and reliably know > that it can do so without changing behavior. Limiting in that manner would effectively eliminate the possibility of serendipity that can occur when userland developers are empowered vs only those who can sufficient agreement to add features to PHP. IOW, tiny subset of problems could be solved if we limit vs. the number of problems developers could solve for themselves and offer to the open-source to the community if userland developers are given more control over preloading. > For example, there's a ton of optimizations that can be done that rely on > working with pure functions only, but the engine today cannot know if a > function is pure. (Or I don't think it's able to figure it out for itself, > anyway.) I'd be fully in favor of ways that we could indicate to the engine > "this is safe to do more computer-science-y optimizations on, do your thing", > and then implementing those optimizations in the engine rather than in user > space. There are more innovations that can occur in computer science than just those that depend on pure functions. Why must we limit ourselves to only consider problems that can be solved with pure functions? There are a lot of details we would need to work through to have a viable proposal for userland preloading (vs. preloading a sysadmin can control), but I assert we'd be better off optimisitically exploring the concept instead of prematurely stifling expl
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
I would say that my proposal is more about compile-time meta programming, and thus would not actually depend on preloading. It could also be ran during page requests and would be cached by opcache in the same way. However running it in that way could make the initial request before the opcodes are cached much slower. Hence why combining it with preloading would be advantageous. On Mon, 13 Jan 2020 at 00:45, Mike Schinkel wrote: > > > On Jan 12, 2020, at 1:57 PM, Larry Garfield wrote: > > > > Most notably, *not all code will be run in a preload context*. > > Can you give some concrete examples here? > > > Language features that only sometimes work scare me greatly. > > Do you have some examples of language features, from PHP or another > language, that only work sometimes and that are known to be problematic. and > why they are problematic? > > > Doing one-time optimizations in preload that make the code faster, that's > > great. > > Though I think this proposal may need to be fine-tuned, I can envision many > frameworks and CMSes written in PHP could improve both performance, > robustness and user-experience using preloading. > > One of the ways most useful would be to run code that ensures the > framework/CMS APIs are being used correctly. If this code is included today > in frameworks and CMSes, it must run for every page load (on the web) when it > could be run once when OpCode is generated. This could potentially improve > performance significantly, depending on how much checking it implemented. > > It could also improve performance of building data-driven structures at > runtime. I know that in the past I have had data driven structures that were > definitely very time-consuming on each page load. The WordPress admin does > tons of it. > > > Preload optimizations that make the code behave differently, that's > > extremely dangerous. > > Can you give some concrete examples where you fear this could happen? > > > "I changed one character and now I have to restart my webserver to see if > > it did anything" is a bad place for PHP to be. > > As I envision it preloaded code of this nature would not be handled on server > reboot, but when the files have had their time stamps updated. If I am not > mistaken, PHP already does this (but I could be mistaken as I don't have > expertise in PHP OpCodes.) > > Whatever the case I think this could easily be handled with a simple API call > to flush preloaded code which for debugging could be one of the first things > a developer would call in their codebase. > > > I am highly skeptical about allowing arbitrary preload/compile time > > behavior as it makes development harder and bifurcates the ecosystem. > > Given the copious performance and robustness benefits that preloading could > provide, I would think we should try and identify specific concrete concerns > rather than allow unidentified concerns from blocking a potentially great > improvement to the language. > > So what specific concrete concerns can we identify? > > > To your specific examples, many are already possible today. Code > > generation in a pre-execute build step is increasingly common; the Symfony > > ecosystem does a ton of it, I've implemented a compiled version of a PSR-14 > > Event Dispatcher, etc. > > Am I understanding correctly that requires a _build_ process, and not > something that a PHP developer can depend upon having available on any hosted > PHP server? > > > Code generation at that point is then impossible. Moving that code gen to > > a preloader wouldn't help with that. > > As Robert stated, he is not proposing any code generation. > > His preloading concept would modify classes by manipulating the AST, which, > IMO would require an additional API. And I do think it is probably orthogonal > to the idea of preloading code although I do think it would also have great > benefit too, but that preloading is probably a prerequisite. > > > I appreciate the intent here, but in practice I'd much rather we limit > > preload optimization to things the engine can do for us, and reliably know > > that it can do so without changing behavior. > > Limiting in that manner would effectively eliminate the possibility of > serendipity that can occur when userland developers are empowered vs only > those who can sufficient agreement to add features to PHP. IOW, tiny subset > of problems could be solved if we limit vs. the number of problems developers > could solve for themselves and offer to the open-source to the community if > userland developers are given more control over preloading. > > > For example, there's a ton of optimizations that can be done that rely on > > working with pure functions only, but the engine today cannot know if a > > function is pure. (Or I don't think it's able to figure it out for itself, > > anyway.) I'd be fully in favor of ways that we could indicate to the > > engine "this is safe to do more computer-science-y optim
