Hi,
Here's a function definition :
#PHP proto: int newt_centered_window ( int $width , int $height [,
string $title=null ] )
return_type: int
arguments:
width:
type: int
height:
type: int
title:
type:
On Jan 9, 2015, at 5:10 PM, Sara Golemon poll...@php.net wrote:
On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye pierre@gmail.com wrote:
The fact that hhvm implements a significant part of the extensions (or
other areas) using PHP+additional syntax as well as adding cleaner
APIs or
On Wed, Jan 14, 2015 at 8:10 AM, Andi Gutmans a...@zend.com wrote:
On Jan 9, 2015, at 5:10 PM, Sara Golemon poll...@php.net wrote:
On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye pierre@gmail.com wrote:
The fact that hhvm implements a significant part of the extensions (or
other areas) using
De : Pierre Joye [mailto:pierre@gmail.com]
Also I am really not a fan of yamlco to generate C code but having critical
parts in C and everything else in straight php :)
I don't use yaml to generate C, just to define metadata, like extension name,
arguments/return value characteristics,
On Mon, Jan 12, 2015 at 9:29 AM, Sara Golemon poll...@php.net wrote:
On Mon, Jan 12, 2015 at 4:58 AM, François Laupretre
franc...@tekwire.net wrote:
I am not crazy about it either, I just want to generate code for
argument parsing (removing every access to zval, dealing with
'mixed' type,
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
Okay, but why even generate code for argument parsing? Why not just
pass the arguments/return-values as their concrete type?
Because I am beyond what macros can do. Actually, I don't see how I can do what
I have in
On Mon, Jan 12, 2015 at 4:58 AM, François Laupretre
franc...@tekwire.net wrote:
I am not crazy about it either, I just want to generate code for
argument parsing (removing every access to zval, dealing with
'mixed' type, checks...), return value (convert to zval, maybe a
pair of checks), and
On 11/01/15 04:08, Sara Golemon wrote:
My idea is to cover *most* (but not all) extensions with a narrower,
simplified API. As you say, many interactions fall into the marshal
this engine value to a C type as needed. This can cater to the
bread-and-butter of PHP extensions very well.
Having
De : Pierre Joye [mailto:pierre@gmail.com]
More than adding a new layer, I would love to see something similar to
hhvm or Zephir available by default. If C is used, then only the
relevant parts have to be implement by the developers, skipping all
the over complicated data mangling,
On Sat, Jan 10, 2015 at 11:18 PM, Pierre Joye pierre@gmail.com wrote:
More than adding a new layer, I would love to see something similar to
hhvm or Zephir available by default. If C is used, then only the
relevant parts have to be implement by the developers, skipping all
the over
On Sun, Jan 11, 2015 at 9:08 AM, Pierre Joye pierre@gmail.com wrote:
Ideally I like to include that in pickle, so one can package a release
from the PHP files/repo to generate the resulting extension package.
I need to be more clear here :)
I like to have this in pickle, so the same
On Sun, Jan 11, 2015 at 2:24 AM, Lester Caine les...@lsces.co.uk wrote:
On 11/01/15 04:08, Sara Golemon wrote:
My idea is to cover *most* (but not all) extensions with a narrower,
simplified API. As you say, many interactions fall into the marshal
this engine value to a C type as needed.
On Sun, Jan 11, 2015 at 8:40 AM, Sara Golemon poll...@php.net wrote:
On Sat, Jan 10, 2015 at 11:18 PM, Pierre Joye pierre@gmail.com wrote:
More than adding a new layer, I would love to see something similar to
hhvm or Zephir available by default. If C is used, then only the
relevant parts
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
And this is one of the things I love about HHVM's current extension
API, so yeah I'd like to bring some elements of that in if possible.
At one extreme it means changes to the lexer/parser, and the other end
it might
De : François Laupretre [mailto:franc...@tekwire.net]
If you agree, I propose this as a base to refine:
- Extension exposes only PHP functions and constants (no OO),
- Each PHP function argument must accept a scalar, an array, or both ('mixed'
case).
- one or more PHP function arguments
On Jan 12, 2015 4:42 AM, François Laupretre franc...@tekwire.net wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
I have a working proof of concept using something like:
?php
function u_foo() {
}
?
native
void foo()
{
printf(Hello from native!);
}
?
?php
De : Pierre Joye [mailto:pierre@gmail.com]
I have a working proof of concept using something like:
?php
function u_foo() {
}
?
native
void foo()
{
printf(Hello from native!);
}
?
?php
... some other codes.
?
In your example, I don't see how you execute the foo() C
On Jan 12, 2015 10:44 AM, François Laupretre franc...@tekwire.net wrote:
De : François Laupretre [mailto:franc...@tekwire.net]
If you agree, I propose this as a base to refine:
- Extension exposes only PHP functions and constants (no OO),
- Each PHP function argument must accept a
On Sun, Jan 11, 2015 at 7:44 PM, François Laupretre
franc...@tekwire.net wrote:
- Extension exposes only PHP functions and constants (no OO),
- Each PHP function argument must accept a scalar, an array, or both ('mixed'
case).
- one or more PHP function arguments can be optional
- PHP
Hi Sara,
Obviously a great idea that would make a lot of people's life easier all
around.
One question though? How would api extensions be handled on both sides and
would it be at all possible to keep the APIs consistent across hvvm / php
versions?
I imagine that there would need to be
Hi!
Funny to see you mention this. I literally just pulled together a
meeting today to discuss HHVM's admittedly unstable extension API.
One idea to emerge from this was to design a new extension API
agnostic of underlying implementation. An API which, if done right,
What extensions do
On Sat, Jan 10, 2015 at 2:39 PM, Stanislav Malyshev smalys...@gmail.com wrote:
So I think it would be useful to define what exactly would be covered
and what not, i.e. which APIs are supported, which can be supported,
which can not. Right now we don't even have the API as such for the
engine
On Sat, Jan 10, 2015 at 8:08 PM, Sara Golemon poll...@php.net wrote:
On Sat, Jan 10, 2015 at 2:39 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
So I think it would be useful to define what exactly would be covered
and what not, i.e. which APIs are supported, which can be supported,
which
On Fri, Jan 9, 2015 at 5:41 PM, Andrea Faulds a...@ajf.me wrote:
Three APIs for TheFacebook under the sky,
Seven for the Zend-lords in their halls of stone,
Nine for the Engines doomed to die,
One for the Dark Lord on his dark throne,
In the Land of Native where the Undefined Behaviours lie.
On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye pierre@gmail.com wrote:
The fact that hhvm implements a significant part of the extensions (or
other areas) using PHP+additional syntax as well as adding cleaner
APIs or mechanisms for the C parts only confirms me one thing: the
very 1st problem
Hey Sara,
On 10 Jan 2015, at 01:10, Sara Golemon poll...@php.net wrote:
Funny to see you mention this. I literally just pulled together a
meeting today to discuss HHVM's admittedly unstable extension API.
One idea to emerge from this was to design a new extension API
agnostic of
On 10 Jan 2015 01:10, Sara Golemon poll...@php.net wrote:
On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye pierre@gmail.com wrote:
The fact that hhvm implements a significant part of the extensions (or
other areas) using PHP+additional syntax as well as adding cleaner
APIs or mechanisms for
On Fri, Jan 9, 2015 at 5:48 PM, Paul Dragoonis dragoo...@gmail.com wrote:
Somewhat Pie in the sky but at the same time also achievable with good
planning and design. I'd support this definitely and this abstraction layer
would solve constant maintainability of extensions by not having to update
28 matches
Mail list logo
