Hi Maciej,
Can you think about a blogpost describing what you did and how to use it
accompanying the merge?
yes, that was the intention: I had actually already started drafting a blog
post, but got distracted. For the how-to, I'd link directly to the docs:
http://doc.pypy.org/en/latest/cppy
On Wed, May 9, 2012 at 10:16 AM, wrote:
> Hi Armin,
>
>
> I think that Fijal's suggestion was to merge the branch anyway, but
>> keep cppyy turned off by default. I would also welcome this, but it's
>> up to you if you prefer to keep it in a separate branch.
>>
>
> I feel better about merging n
Hi Armin,
I think that Fijal's suggestion was to merge the branch anyway, but
keep cppyy turned off by default. I would also welcome this, but it's
up to you if you prefer to keep it in a separate branch.
I feel better about merging now that I've created a standalone version of
Reflex. Howeve
Hi Wim,
On Fri, May 4, 2012 at 8:16 AM, wrote:
>> Quick question - if it's mature, why not merge it to default? I presume it
>> should be turned off, since there is a sizeable dependency, but still
>> having it in default can be good.
>
> I have a standalone version of Reflex now and made a few
Hi Maciej,
On Mon, 23 Apr 2012, Maciej Fijalkowski wrote:
Quick question - if it's mature, why not merge it to default? I presume it
should be turned off, since there is a sizeable dependency, but still
having it in default can be good.
I have a standalone version of Reflex now and made a few
Hi Alex,
Distro is latest gentoo, amd64 with sse2 and sse3 (core i5).
there's an older version of (Py)ROOT distributed with gentoo:
http://packages.gentoo.org/package/sci-physics/root
Do you want to use that package, or pick up a more recent version (doesn't
matter for Reflex, I think, as
Distro is latest gentoo, amd64 with sse2 and sse3 (core i5).
libssl is in 2 versions:
dev-libs/openssl-0.9.8u:0.9.8
dev-libs/openssl-1.0.0h:0
so pick one that suits you better. Anyway, default binary pypy works fine.
Currently i have only one typemap in my *.i file for swig, and it allows
PyObje
Hi Alexander,
An important question from userland - would it be benefitial to switch from
SWIG to the new interface? When can that be done?
there are no many major differences between SWIG and this on the Python side
(nothing that can't be captured in a compatibility layer). I'm thinking of
su
Leonard,
Addendum: apparently, clang even provides python bindings.
http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/
yes, but AFAIK it's C only and in any case, those are bindings to CLang,
rather than bindings to the code parsed from CLang. You'll run into the
same prob
Well, I have never been able to isolate it, and the project where it is
triggered is rather close-sourced.
long story short - make up a SWIG object inside a function, pass it as a
pointer to the swig-wrapped function, then call gc.collect(). After that swig
calls object's destructor and if the
Addendum: apparently, clang even provides python bindings.
http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/
On Mon, Apr 23, 2012 at 11:17 AM, Leonard Ritter wrote:
> (sorry, that was also supposed to go to the ML)
>
> Awesome work, keep it up!
>
> But: I showed the reflex
(sorry, that was also supposed to go to the ML)
Awesome work, keep it up!
But: I showed the reflex library you're using to friends and they both
suggested clang to parse C++ headers instead. What do you think about
that?
Cheers,
Leonard
On Mon, Apr 23, 2012 at 7:08 AM, wrote:
> Hi,
>
> as det
2012/4/23 Alexander Pyattaev
> Right now the main problem with SWIG is the object ownership, i.e. with
> pypy one has to set thisown=False for all objects to avoid crashes related
> to GC code. The problem occurs only for long-living objects though.
Do you have a sample code for this issue?
--
An important question from userland - would it be benefitial to switch from
SWIG to the new interface? When can that be done?
Right now the main problem with SWIG is the object ownership, i.e. with pypy
one has to set thisown=False for all objects to avoid crashes related to GC
code. The proble
Hi Maciej,
It'll at the very least run tests nightly so we'll make sure we don't break
it (we can install reflex on tannit).
that, to me, sounds great!
Best regards,
Wim
--
wlavrij...@lbl.gov--+1 (510) 486 6411--www.lavrijsen.net
On Mon, Apr 23, 2012 at 8:42 AM, wrote:
> Hi Maciej,
>
>
> Quick question - if it's mature, why not merge it to default? I presume it
>> should be turned off, since there is a sizeable dependency, but still
>> having it in default can be good.
>>
>
> the dependency is the main issue: for it to b
Hi Maciej,
Quick question - if it's mature, why not merge it to default? I presume it
should be turned off, since there is a sizeable dependency, but still
having it in default can be good.
the dependency is the main issue: for it to build, it requires headers and
libs from Reflex. Completely
On Mon, Apr 23, 2012 at 7:08 AM, wrote:
> Hi,
>
> as detailed in a couple of blog posts in the past (*), for some time now we
> have been working on making C++ bindings through the Reflex package
> available
> on PyPy, in the form of the "cppyy" module. Software is never done, and
> that
> is tru
Hi,
as detailed in a couple of blog posts in the past (*), for some time now we
have been working on making C++ bindings through the Reflex package available
on PyPy, in the form of the "cppyy" module. Software is never done, and that
is true also in this case, but it has reached a level of matur
19 matches
Mail list logo
