I would be honored for consideration, however there are at least two
complications:
I am still awaiting formal approval from my full-time employer to allow
me to take on a second
part-time job for the Software Conservancy Foundation, a process
that will take
until mid-August at the ea
On 10/07/12 01:04, wlavrij...@lbl.gov wrote:
provide a prioritized list of what's still missing for you? I'm following a
more or less random walk otherwise, with most work going into the CINT
backend
at the moment.
Do jitted callbacks work?
My main use case has to do with sqlite UDFs written i
2012/7/10 Eleytherios Stamatogiannakis :
> On 10/07/12 01:04, wlavrij...@lbl.gov wrote:
>>
>> provide a prioritized list of what's still missing for you? I'm following
>> a
>> more or less random walk otherwise, with most work going into the CINT
>> backend
>> at the moment.
>
>
> Do jitted callbac
On 10/07/12 13:45, Amaury Forgeot d'Arc wrote:
A callback called from C cannot be jitted, unless it has a loop in Python code.
The loop in the sqlite library does not count. The JIT needs a
complete understanding of all operations in the loop...
-- Amaury Forgeot d'Arc
From what i understand y
On Tue, Jul 10, 2012 at 12:45 PM, Amaury Forgeot d'Arc
wrote:
> 2012/7/10 Eleytherios Stamatogiannakis :
> > On 10/07/12 01:04, wlavrij...@lbl.gov wrote:
> >>
> >> provide a prioritized list of what's still missing for you? I'm
> following
> >> a
> >> more or less random walk otherwise, with most
I am trying to translate a pypy sandbox on RHEL 6.
I am having problems because I think libffi-devel is not available in the
EPEL repo.
Has anyone had any success / build instructions on RHEL 6 ? Or do I really
have to revert to RHEL 5 ?
Thanks.
___
pypy-
On Tue, 2012-07-10 at 10:55 -0500, Naveen Garg wrote:
> I am trying to translate a pypy sandbox on RHEL 6.
> I am having problems because I think libffi-devel is not available in
> the EPEL repo.
> Has anyone had any success / build instructions on RHEL 6 ?
I build PyPy for RHEL 6 within the EPEL r
Hi all,
On Tue, 10 Jul 2012, Maciej Fijalkowski wrote:
Amaury - not true, we can JIT functions from the start. However, they would
still accept wrapped arguments. I can think about a simple way to enable
jitting from the start without the need though.
if the JITted function still requires wrap
2012/7/10 :
> Generating such a C function by the backend then requires a C-API for the
> calls
> to do the wrapping. That PyPy C-API is a long awaited project. :)
Do you have an idea what this API would look like?
Then I can help with the implementation :)
--
Amaury Forgeot d'Arc
_
wlavrij...@lbl.gov, 10.07.2012 19:38:
> On Tue, 10 Jul 2012, Maciej Fijalkowski wrote:
>> Amaury - not true, we can JIT functions from the start. However, they would
>> still accept wrapped arguments. I can think about a simple way to enable
>> jitting from the start without the need though.
>
> i
Hi Stefan,
There's no reason it would require wrapped arguments.
that completely depends on how it is generated, of course, and in the context
of calls within Python (pypy-c), it makes sense to have the entry point of
the function expect wrapped arguments, and have the exit point re-wrap.
Th
wlavrij...@lbl.gov, 10.07.2012 20:10:
>> There's no reason it would require wrapped arguments.
>
> that completely depends on how it is generated, of course, and in the context
> of calls within Python (pypy-c), it makes sense to have the entry point of
> the function expect wrapped arguments, and
Hi Stefan,
On Tue, 10 Jul 2012, Stefan Behnel wrote:
wlavrij...@lbl.gov, 10.07.2012 20:10:
that completely depends on how it is generated, of course, and in the context
of calls within Python (pypy-c), it makes sense to have the entry point of
the function expect wrapped arguments, and have the
wlavrij...@lbl.gov, 10.07.2012 20:37:
> On Tue, 10 Jul 2012, Stefan Behnel wrote:
>> wlavrij...@lbl.gov, 10.07.2012 20:10:
>>> that completely depends on how it is generated, of course, and in the
>>> context
>>> of calls within Python (pypy-c), it makes sense to have the entry point of
>>> the fun
Hi Stefan,
Ok, then in the case of a callback, the runtime could simply start with
totally stupid code that packs the low-level arguments into Python
arguments, attaches the low-level type information to them and then passes
them into the function. The JIT should then see in its trace what types
Hi Amaury,
On Tue, 10 Jul 2012, Amaury Forgeot d'Arc wrote:
2012/7/10 :
Generating such a C function by the backend then requires a C-API for the
calls to do the wrapping. That PyPy C-API is a long awaited project. :)
Do you have an idea what this API would look like?
Then I can help with the
wlavrij...@lbl.gov, 10.07.2012 21:02:
>> Ok, then in the case of a callback, the runtime could simply start with
>> totally stupid code that packs the low-level arguments into Python
>> arguments, attaches the low-level type information to them and then passes
>> them into the function. The JIT sho
2012/7/10 :
> I'm trying to resist the urge to say that it should be the Python C-API,
> with all PyObject*'s replaced by PyPyObject*'s. :)
I don't think it's a good idea to use pointers with a moving GC.
But I may be wrong. In any case, we need a memory model compatible with C.
--
Amaury Forge
Hi Amaury,
I don't think it's a good idea to use pointers with a moving GC.
then make it (the moral equivalent of) a PyPyObject**. Like in Smalltalk.
Best regards,
Wim
--
wlavrij...@lbl.gov--+1 (510) 486 6411--www.lavrijsen.net
__
Hi Stefan,
The question is if a conversion from low-level types to Python types can be
seen and handled by the JIT, but I'd be surprised if it couldn't, since it
generates this kind of code itself anyway.
this is beyond my expertise, but one way of making the wrapping visible, is
to generate t
2012/7/10 :
> Sounds like something I could do today, but still feels like a square peg /
> round hole kind of solution, since the code to trigger that C stub
> generation would (in cppyy's case) start in RPython to begin with.
> Makes me wish I could generate RPython (after translation, that is).
21 matches
Mail list logo
