On Sat, Jan 10, 2015 at 9:16 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
Hey everyone,
I want to open discussion on my RFC to strengthen the ability of
extensions
to provide functionality to developers in both
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei kont...@beberlei.de wrote:
Hey everyone,
I want to open discussion on my RFC to strengthen the ability of extensions
to provide functionality to developers in both C **and** PHP code.
For this extensions can add PHP files to a list of prepend
On Sat, Jan 10, 2015 at 12:16 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei kont...@beberlei.de wrote:
Hey everyone,
I want to open discussion on my RFC to strengthen the ability of extensions
to provide functionality to developers in both C
On Jan 10, 2015 6:55 PM, François Laupretre franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
A proof of concept, IRC log, I am lazy :)
Pierre benjamin, Derick
https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4
De : Pierre Joye [mailto:pierre@gmail.com]
A proof of concept, IRC log, I am lazy :)
Pierre benjamin, Derick
https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4
https://gist.github.com/pierrejoye/0859e3702ceb3bb652b6
https://gist.github.com/pierrejoye/544e60d8994094c55583
Pierre
On Sat, Jan 10, 2015 at 9:12 AM, François Laupretre
franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
Opcache is why I think we should have a list registered names. A simple hash
exists and the cache will know what to do.
Sorry, I am not sure I understand how the
De : Pierre Joye [mailto:pierre@gmail.com]
Sorry, I am not sure I understand how the opcode cache, as it exists now,
can understand this. Do you mean that opcode cache code would need to be
modified ?
Yes and no. Yes if we want them to do not even try to update files
that are
On Jan 11, 2015 11:38 AM, François Laupretre franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
Sorry, I am not sure I understand how the opcode cache, as it exists
now,
can understand this. Do you mean that opcode cache code would need to be
modified ?
Yes
De : Pierre Joye [mailto:pierre@gmail.com]
Say we do support builtin scripts, an opcache will simply load them on minit
or on the first request and flag them as
permanent. Yes, it means we need to change opcache but could be way easier
than trying to hack the engine to support
On Sat, Jan 10, 2015 at 11:07 PM, François Laupretre
franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
Say we do support builtin scripts, an opcache will simply load them on minit
or on the first request and flag them as
permanent. Yes, it means we need to change
On Jan 9, 2015 10:43 AM, François Laupretre franc...@tekwire.net wrote:
-Message d'origine-
De : Pierre Joye [mailto:pierre@gmail.com]
Is there a technical problem with code located outside of
definitions, or is it
just a convention (PSR already contains this rule) ? I
On Thu, Jan 8, 2015 at 9:56 AM, Fred Emmott f...@fredemmott.co.uk wrote:
On Jan 7, 2015, at 2:18 AM, Pierre Joye pierre@gmail.com wrote:
That's very much the case. One extension, one install. It doesn't
matter whether some of the extension is written in C, and other parts in
PHP. HHVM is
De : Pierre Joye [mailto:pierre@gmail.com]
We solved some of the other problems by only allowing definitions, no
side-effects - classes, constants, namespaces etc. We do not allow code
outside of a function body here.
Yes, we will have to do that, no matter what we choose. I am
On Thu, Jan 8, 2015 at 6:35 PM, François Laupretre franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
We solved some of the other problems by only allowing definitions, no
side-effects - classes, constants, namespaces etc. We do not allow code
outside of a function
On Thu, Jan 8, 2015 at 10:46 AM, Adam Harvey ahar...@php.net wrote:
I'm going to be a bit hazier than normal in this e-mail, for which I
apologise. People who know who I work for, you can probably guess the
parameters of the NDA I'm trying not to break here.
On 8 January 2015 at 04:38,
-Message d'origine-
De : Pierre Joye [mailto:pierre@gmail.com]
Is there a technical problem with code located outside of definitions, or
is it
just a convention (PSR already contains this rule) ? I understand the
problems it poses in HHVM, but I don't see why we should check
On Wed, 7 Jan 2015, Stanislav Malyshev wrote:
There is currently no way to install an extension and a PHP library
package at the same time. pecl can't install PHP libraries, and
Why it needs to be at the same time? I don't see any use case where
it would matter if you run one command or
On Wed, Jan 7, 2015 at 11:14 PM, François Laupretre franc...@tekwire.net
wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
... here,
it is proposed to bundle scripts that will be executed at runtime like
any
other script, except that nothing can be done with them, not even disable
On Wed, 7 Jan 2015, Pierre Joye wrote:
On Wed, Jan 7, 2015 at 2:14 PM, François Laupretre franc...@tekwire.net
wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
... here, it is proposed to bundle scripts that will be executed at
runtime like any other script, except that nothing
You are not forced to use the glue code, its just always available. That is
what an extension is about, always available code. An option would of
course be to not use the extension if you don't need it.
Developers can feel free to use the low level API just like PHP also ships
high and low level
On Thu, Jan 8, 2015 at 3:43 AM, Derick Rethans der...@php.net wrote:
On Wed, 7 Jan 2015, Pierre Joye wrote:
On Wed, Jan 7, 2015 at 2:14 PM, François Laupretre franc...@tekwire.net
wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
... here, it is proposed to bundle scripts that will
On Thu, Jan 8, 2015 at 3:36 AM, Derick Rethans der...@php.net wrote:
On Wed, 7 Jan 2015, Stanislav Malyshev wrote:
There is currently no way to install an extension and a PHP library
package at the same time. pecl can't install PHP libraries, and
Why it needs to be at the same time? I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 04/01/2015 12:52, Benjamin Eberlei a écrit :
https://wiki.php.net/rfc/extension_prepend_files
Sorry but definitively seems a bad idea.
If you want a pure-php library, provide as one.
If this library need an extension, just describe this in
On Wed, 7 Jan 2015, François Laupretre wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
... here,
it is proposed to bundle scripts that will be executed at runtime like any
other script, except that nothing can be done with them, not even disable
them if not required (like using
hi,
On Thu, Jan 8, 2015 at 3:41 AM, Benjamin Eberlei kont...@beberlei.de wrote:
On Wed, Jan 7, 2015 at 11:14 PM, François Laupretre franc...@tekwire.net
wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
... here,
it is proposed to bundle scripts that will be executed at runtime
On Thu, Jan 8, 2015 at 1:08 PM, Remi Collet r...@fedoraproject.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 04/01/2015 12:52, Benjamin Eberlei a écrit :
https://wiki.php.net/rfc/extension_prepend_files
Sorry but definitively seems a bad idea.
If you want a pure-php
On 08/01/15 00:50, Pierre Joye wrote:
What is not clear to me is the question of packaging/versioning/deployment.
If you consider the PHP glue code is modified more often than the C code,
which will be the most frequent case, how do you version/distribute partial
packages ? or do you
On Jan 7, 2015, at 2:18 AM, Pierre Joye pierre@gmail.com wrote:
That's very much the case. One extension, one install. It doesn't
matter whether some of the extension is written in C, and other parts in
PHP. HHVM is *all* about this. Making use of C where you need it, and
otherwise just
Quoting Benjamin Eberlei :
To be honest, I don't see the use case of shipping optional PHP code inside
an extension. As the user of an extension I want all the functions/classes
to be available all the time, no matter if the extension developer wrote
everything in C or in PHP.
Quoting
I'm going to be a bit hazier than normal in this e-mail, for which I
apologise. People who know who I work for, you can probably guess the
parameters of the NDA I'm trying not to break here.
On 8 January 2015 at 04:38, Benjamin Eberlei kont...@beberlei.de wrote:
+1 on everything I snipped
On Tue, 6 Jan 2015, François Laupretre wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
2. We have no easy way to actually release and deploy adhoc scripts,
used by a given extension
For 2., it is one of the thing I can imagine implementing in pickle.
Or even better add it a s
On Tue, 6 Jan 2015, Stanislav Malyshev wrote:
But, if we consider the PHP code as an integral part of the
extension, this should be avoided, as C and PHP code need to be kept
in sync.
Again, there is a multitude of solutions for this, all in the realm of
packaging. It's not like
Hi,
On Jan 7, 2015 5:02 PM, Derick Rethans der...@php.net wrote:
On Tue, 6 Jan 2015, François Laupretre wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
2. We have no easy way to actually release and deploy adhoc scripts,
used by a given extension
For 2., it is one of the
On Jan 7, 2015 5:15 PM, Derick Rethans der...@php.net wrote:
On Tue, 6 Jan 2015, Stanislav Malyshev wrote:
But, if we consider the PHP code as an integral part of the
extension, this should be avoided, as C and PHP code need to be kept
in sync.
Again, there is a multitude of
Hi!
There is currently no way to install an extension and a PHP library
package at the same time. pecl can't install PHP libraries, and
Why it needs to be at the same time? I don't see any use case where it
would matter if you run one command or two commands to install it. In
fact, if it's
hi François,
On Wed, Jan 7, 2015 at 2:14 PM, François Laupretre franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
... here,
it is proposed to bundle scripts that will be executed at runtime like any
other script, except that nothing can be done with them, not even
On Wed, Jan 7, 2015 at 4:45 PM, Stanislav Malyshev smalys...@gmail.com wrote:
composer can't install extensions. And even if it did, keeping the
versions in sync is not easy at all. Only way to solve this properly is
It seems to me you're reinventing packaging systems. I don't see why we
De : Pierre Joye [mailto:pierre@gmail.com]
... here,
it is proposed to bundle scripts that will be executed at runtime like any
other script, except that nothing can be done with them, not even disable
them if not required (like using its own glue codes).
I agree. Bundling scripts in
On Mon, 5 Jan 2015, Stanislav Malyshev wrote:
2) Embedded text sections. It's possible to place the raw PHP code
into the compiled .so/.dylib/.dll file and fetch it out for
compilation at runtime. This enables easy bundling of the loaded
I guess it is possible, but why - what's wrong
On Tue, Jan 6, 2015 at 12:24 PM, Derick Rethans der...@php.net wrote:
On Mon, 5 Jan 2015, Stanislav Malyshev wrote:
2) Embedded text sections. It's possible to place the raw PHP code
into the compiled .so/.dylib/.dll file and fetch it out for
compilation at runtime. This enables easy
On Tue, Jan 6, 2015 at 3:24 AM, Derick Rethans der...@php.net wrote:
On Mon, 5 Jan 2015, Stanislav Malyshev wrote:
2) Embedded text sections. It's possible to place the raw PHP code
into the compiled .so/.dylib/.dll file and fetch it out for
compilation at runtime. This enables easy
On Tue, Jan 6, 2015 at 3:37 AM, Benjamin Eberlei kont...@beberlei.de wrote:
The general plan seems to be to have a way to embed PHP code into the
shared object, for example using Autoconf Macros (like the embed extension
mentioned above does)
Just for the record, stated it before but... :)
I
De : Pierre Joye [mailto:pierre@gmail.com]
2. We have no easy way to actually release and deploy adhoc scripts,
used by a given extension
For 2., it is one of the thing I can imagine implementing in pickle.
Or even better add it a s part of the build scripts and macros. Either
will
On Jan 6, 2015 9:20 PM, François Laupretre franc...@tekwire.net wrote:
The whole code to consider as part of an extension, whatever the language,
must be kept in sync. And the best way to achieve this is to store it in a
single file.
I would rather say in a single release and package. Built in
On Jan 6, 2015 9:53 PM, Benjamin Eberlei kont...@beberlei.de wrote:
On Tue, Jan 6, 2015 at 3:50 PM, Pierre Joye pierre@gmail.com wrote:
On Jan 6, 2015 9:20 PM, François Laupretre franc...@tekwire.net
wrote:
The whole code to consider as part of an extension, whatever the
language, must
On Tue, Jan 6, 2015 at 3:50 PM, Pierre Joye pierre@gmail.com wrote:
On Jan 6, 2015 9:20 PM, François Laupretre franc...@tekwire.net wrote:
The whole code to consider as part of an extension, whatever the language,
must be kept in sync. And the best way to achieve this is to store it in a
Hi!
The first reason is that, if we consider a released extension as a
conceptual unit, the best way to protect its integrity is to store it
as a single file. Storing it as separate files brings a lot of
potential issues : files can be renamed, deleted, etc. Offline tools
Yet people have
hi,
On Mon, Jan 5, 2015 at 8:21 PM, François Laupretre franc...@tekwire.net wrote:
-Message d'origine-
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
So, I've been meaning to propose something *like* this, but with a few
key implementation detail
On Mon, Jan 5, 2015 at 10:48 PM, Pierre Joye pierre@gmail.com wrote:
For example HHVM provides a neat one, which is simply PHP for simple
cases. Complex cases allow advanced the native support is also
supported. See https://github.com/facebook/hhvm/wiki/Extension-API.
... Complex cases
Hi,
On Jan 4, 2015 6:52 PM, Benjamin Eberlei kont...@beberlei.de wrote:
Hey everyone,
I want to open discussion on my RFC to strengthen the ability of
extensions
to provide functionality to developers in both C **and** PHP code.
For this extensions can add PHP files to a list of prepend
Benjamin Eberlei wrote on 04/01/2015 13:00:
Files must be either in the PHP include path, or via absolute path, for
example by putting them right next to the shared object (.so) files and
using the extension_dir path inside the code, see the following for an
example (a hacked approach):
On Jan 5, 2015 10:41 PM, Benjamin Eberlei kont...@beberlei.de wrote:
On Mon, Jan 5, 2015 at 3:02 PM, Pierre Joye pierre@gmail.com wrote:
Hi,
On Jan 4, 2015 6:52 PM, Benjamin Eberlei kont...@beberlei.de wrote:
Hey everyone,
I want to open discussion on my RFC to strengthen the
On Sun, Jan 4, 2015 at 12:52 PM, Benjamin Eberlei kont...@beberlei.de
wrote:
Hey everyone,
I want to open discussion on my RFC to strengthen the ability of extensions
to provide functionality to developers in both C **and** PHP code.
For this extensions can add PHP files to a list of
Julien Pauli wrote on 05/01/2015 16:19:
Hello.
Can't this be already done somehow ? In RINIT stage obviously.
I don't understand why to change our API to add a feature we already can
use ?
Julien.P
The RFC explains the motivation reasonably clearly. In particular:
Using RINIT is error
On Mon, Jan 5, 2015 at 5:26 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Julien Pauli wrote on 05/01/2015 16:19:
Hello.
Can't this be already done somehow ? In RINIT stage obviously.
I don't understand why to change our API to add a feature we already can
use ?
Julien.P
The RFC
-Message d'origine-
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
So, I've been meaning to propose something *like* this, but with a few
key implementation detail differences:
1) Create the notion of Persistent User Functions/Classes/Constants/etc
2)
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei kont...@beberlei.de wrote:
I want to open discussion on my RFC to strengthen the ability of extensions
to provide functionality to developers in both C **and** PHP code.
For this extensions can add PHP files to a list of prepend files that are
On Mon, Jan 5, 2015 at 3:02 PM, Pierre Joye pierre@gmail.com wrote:
Hi,
On Jan 4, 2015 6:52 PM, Benjamin Eberlei kont...@beberlei.de wrote:
Hey everyone,
I want to open discussion on my RFC to strengthen the ability of
extensions
to provide functionality to developers in both C
Hi!
1) Create the notion of Persistent User
Functions/Classes/Constants/etc This is an important perf item
as reloading a prepend file on EVERY request is costly. Less costly
with an opcache, sure, but still costly. Making the entries
persistent lets us deal with this once in the
I like the idea, I have implemented a util [1] to help writing extensions
with PHP, I try the approach HHVM adopted by embedding PHP scripts to the
binary file of extension, maybe it is what you want. I do like it been
supported in core. I would like to implement the RFC if others like it.
---
On Sun, Jan 4, 2015 at 1:36 PM, François Laupretre franc...@tekwire.net
wrote:
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
I want to open discussion on my RFC to strengthen the ability of
extensions
to provide functionality to developers in both C **and** PHP code.
For this
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
I want to open discussion on my RFC to strengthen the ability of extensions
to provide functionality to developers in both C **and** PHP code.
For this extensions can add PHP files to a list of prepend files that are
part of every request
Hey reeze,
This looks like a fantastic approach. Can you explain how you compile the
PHP code into the Shared Object? The README doesnt explain much.
greetings
Benjamin
On Sun, Jan 4, 2015 at 1:33 PM, reeze re...@php.net wrote:
I like the idea, I have implemented a util [1] to help writing
Hi Benjanmin,
I didn't try to cache opcode myself, I try it before, but I think it
should be done by opcaches (avoid duplication and opcache will optimize the
compiled opcode), so I use the method @François mentioned, I use a stream
wrapper to take advantage of opcaches. there is a problem
64 matches
Mail list logo
