On Sat, Jan 10, 2015 at 9:16 AM, Pierre Joye wrote:
> On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei
> 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.
> >
> > F
On Sat, Jan 10, 2015 at 11:07 PM, François Laupretre
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 opcache but coul
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
> p
On Jan 11, 2015 11:38 AM, "François Laupretre" 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 and
> 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 Sat, Jan 10, 2015 at 9:12 AM, François Laupretre
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 opcode cache, a
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 opcode cache, as it exists now, can
understand this. Do you mean that opcode cach
On Jan 10, 2015 6:55 PM, "François Laupretre" wrote:
>
> > De : Pierre Joye [mailto:pierre@gmail.com]
> >
> > A proof of concept, IRC log, I am lazy :)
> >
> > benjamin, Derick
> > https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4
> > https://gist.github.com/pierrejoye/0859e3702ceb3bb65
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> A proof of concept, IRC log, I am lazy :)
>
> benjamin, Derick
> https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4
> https://gist.github.com/pierrejoye/0859e3702ceb3bb652b6
> https://gist.github.com/pierrejoye/544e60d8994094c55583
> too
On Sat, Jan 10, 2015 at 12:16 AM, Pierre Joye wrote:
> On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei 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 ex
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei 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 files" that a
On Jan 9, 2015 10:43 AM, "François Laupretre" 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 understand
> -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 shoul
On Thu, Jan 8, 2015 at 6:35 PM, François Laupretre 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 body here.
>
> 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 10:46 AM, Adam Harvey 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, Benjamin Eberlei
On Thu, Jan 8, 2015 at 9:56 AM, Fred Emmott wrote:
>
>> On Jan 7, 2015, at 2:18 AM, Pierre Joye 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
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 wrote:
<+1 on everything I snipped>
> Examples of good use-ca
> On Jan 7, 2015, at 2:18 AM, Pierre Joye 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 write the
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.
Quo
On Thu, Jan 8, 2015 at 1:08 PM, Remi Collet 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 library, provid
-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 th
On Thu, Jan 8, 2015 at 3:36 AM, Derick Rethans 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 don
On Thu, Jan 8, 2015 at 3:43 AM, Derick Rethans wrote:
> On Wed, 7 Jan 2015, Pierre Joye wrote:
>
>> On Wed, Jan 7, 2015 at 2:14 PM, François Laupretre
>> wrote:
>> >> De : Pierre Joye [mailto:pierre@gmail.com]
>> >>
>> >> ... here, it is proposed to bundle scripts that will be executed at
>>
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 s
On Wed, 7 Jan 2015, Pierre Joye wrote:
> On Wed, Jan 7, 2015 at 2:14 PM, 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 d
hi,
On Thu, Jan 8, 2015 at 3:41 AM, Benjamin Eberlei wrote:
>
>
> On Wed, Jan 7, 2015 at 11:14 PM, 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
>> > othe
On Wed, Jan 7, 2015 at 11:14 PM, 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 i
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 (
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
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 Wed, Jan 7, 2015 at 4:45 PM, Stanislav Malyshev 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
> should invent
hi François,
On Wed, Jan 7, 2015 at 2:14 PM, 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
>>
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 i
> 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
On Jan 7, 2015 5:15 PM, "Derick Rethans" 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 sol
Hi,
On Jan 7, 2015 5:02 PM, "Derick Rethans" 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
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 l
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 bette
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
On Jan 6, 2015 9:53 PM, "Benjamin Eberlei" wrote:
>
>
>
> On Tue, Jan 6, 2015 at 3:50 PM, Pierre Joye wrote:
>>
>>
>> On Jan 6, 2015 9:20 PM, "François Laupretre"
wrote:
>> The whole code to consider as part of an extension, whatever the
language, must be kept in sync. And the best way to achiev
On Tue, Jan 6, 2015 at 3:50 PM, Pierre Joye wrote:
>
> On Jan 6, 2015 9:20 PM, "François Laupretre" 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 s
On Jan 6, 2015 9:20 PM, "François Laupretre" 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 scripts in an
extensi
> 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
> w
On Tue, Jan 6, 2015 at 3:37 AM, Benjamin Eberlei 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 do think it is a
On Tue, Jan 6, 2015 at 3:24 AM, Derick Rethans 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 bundling
On Tue, Jan 6, 2015 at 12:24 PM, Derick Rethans 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 bun
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
On Mon, Jan 5, 2015 at 10:48 PM, Pierre Joye 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 can be implemented u
hi,
On Mon, Jan 5, 2015 at 8:21 PM, François Laupretre 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 differences:
>>
>> 1
> -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/et
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 th
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei 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
> part of every
On Mon, Jan 5, 2015 at 5:26 PM, Rowan Collins
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 explai
On Jan 5, 2015 10:41 PM, "Benjamin Eberlei" wrote:
>
>
> On Mon, Jan 5, 2015 at 3:02 PM, Pierre Joye wrote:
>>
>> Hi,
>>
>> On Jan 4, 2015 6:52 PM, "Benjamin Eberlei" wrote:
>> >
>> > Hey everyone,
>> >
>> > I want to open discussion on my RFC to strengthen the ability of
extensions
>> > to prov
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 pron
On Sun, Jan 4, 2015 at 12:52 PM, Benjamin Eberlei
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 files" that
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):
https://g
On Mon, Jan 5, 2015 at 3:02 PM, Pierre Joye wrote:
> Hi,
>
> On Jan 4, 2015 6:52 PM, "Benjamin Eberlei" 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.
> >
>
Hi,
On Jan 4, 2015 6:52 PM, "Benjamin Eberlei" 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 files" that
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 opcac
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 wrote:
> I like the idea, I have implemented a util [1] to help writing extensions
> wi
On Sun, Jan 4, 2015 at 1:36 PM, François Laupretre
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 extensions can
> 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 re
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.
---
[1
65 matches
Mail list logo
