And now for something completely different:
Would not it make dramatically more sense to just finish the cppyy branch and
get a working extension-making scheme that actually works? I have a project
now that uses C++ extensions and python quite extensively, and the only thing
stopping me from mig
Great, that actually works.
torstai 07 kesäkuu 2012 15:34:33 wlavrij...@lbl.gov kirjoitti:
> Hi Alex,
>
> > With respect to build, I installed root from gentoo repository, and the
> > problem there is that headers are in /usr/include/root and the actual libs
> > are in /usr/lib/root, but the pypy
> If the goal
> is "only" to pass around PyObjects as black boxes, as fast as
> reasonably possible, then the easiest route would be to not use cpyext
> at all, but instead try to come up with your own mapping logic. This
> looks quite easier for experimentation purposes. And if you end up
> wit
Well, as far as I can see from where I am, the only real good that can come
from interfacing with PyObject is the capability to write container classes in
C++. On the other hand, it seems that it is not very often needed. For the
case when objects just need to be LINKED from the C++ code as refe
I think I've figured it with the missing classes. When supplied with multiple
headers, genreflex apparently only saves the last one of them...Obviously,
that can be worked around, but still seems like a bug or just me not finding
some manual.
BR,
Alex.
sunnuntai 03 kesäkuu 2012 16:44:19 wlavrij.
Okay, with respect to the SWIG + pypy, works for me, and about 4x slower then
cppyy or cpython ( which show same results more or less).
time cppyy ./cppyy_timings.py
real0m0.265s
user0m0.225s
sys 0m0.040s
time pypy ./pypy_timings.py
real0m2.424s
user0m2.338s
sys 0m0.0
Please, mention in the manual, for the mortals, that the reflection library
has to be linked with -lReflex, so that they do not have to figure that out on
their own=)
BR,
Alex.
sunnuntai 03 kesäkuu 2012 02:33:15 Alex Pyattaev kirjoitti:
> good you found a workaround, as using cpyext from cp
C++ classes. But, as
you have said, it is pre-alpha, so no SWIG as of now...
BR,
Alex.
sunnuntai 03 kesäkuu 2012 16:28:52 Armin Rigo kirjoitti:
> Hi Alex,
>
> On Sun, Jun 3, 2012 at 10:16 AM, Alex Pyattaev
wrote:
> > So, when would users be able to test it? I'd like to
So, when would users be able to test it? I'd like to compare the overhead with
ctypes and cppyy for instance. I also wonder if I'd be able to send Python
objects to the c++ domain for storage in a container (e.g. a vector).
BR,
Alex
keskiviikko 30 toukokuu 2012 18:00:16 Robert Zaremba kirjoitti:
keskiviikko 30 toukokuu 2012 18:52:25 wlavrij...@lbl.gov kirjoitti:
> Hi Alex,
>
> > So, cpp_class acts as a container for python objects, and it does not need
> > to know what kind of object is inside. I was able to make it work with
> > pypy through basic C API, using SWIG and typemaps by mappin
Hello,
I am considering trying cppyy on a large project, and I have a question.
I need to be able to add a reference to Python objects into the c++ classes.
In essence:
#Python code:
x="My python object"
inst = cpp_class()
inst.add_data(x)
inst.do_stuff()#This does not modify x in any way
z=inst
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
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
:
> >> Hi there
> >>
> >> Maciej Fijalkowski skrev 2011-10-17 10:30:
> >>> On Mon, Oct 17, 2011 at 10:17 AM, Alex
> >>> Pyattaev>
> > wrote:
> >>>> I have a fully-functional wireless network simulation tool written
>
I have a fully-functional wireless network simulation tool written in
pypy+swig. Is that nice? Have couple papers to refer to as well. If you want I
could write a small abstract on how it was so great to use pypy (which, in
fact, was really great)?
Alex.
On Friday 07 October 2011 20:17:01 Maciej
I've had a very similar stuff, as in something crashing only when run many
times when I had a bug in a container type implemented in C. Basically, I had
wrong refcount for the objets, which caused them to be freed by garbage
collectore while they have been still used. Maybe something similar hap
> If I use a Python debugger, can't I just step forward line by line, see
> where I get the crash, and then isolate the offending line?
The way pypy works - no you can not really do that. In Cpython it works
somewhat better, but not in PYPY. Basically you have to use C debugger to
locate the cras
Generally, any binary-level debugger such as gdb or MSVC should work with
pypy. At the very least you will find which operation crashed.
If it is something really specific, for example
sin/log/sign, it might be quite easy to map it back to python code. If it is
not, it will be nearly impossibl
1. Switch to linux. It helps.
2. To get a meaningful error log try to run the pypy from terminal. To do
copy-paste you will need 3-rd party terminal, i.e. power shell. Then you'll be
able to copy the error messages. Without them it is pretty much impossible to
identify the problem.
3. Another
pypy. IMHO
there is a bug somewhere, but I have not time ATM to find it. And yes, it
leaks memory like hell due to extra ref=(
On Wednesday 28 September 2011 11:11:07 Amaury Forgeot d'Arc wrote:
> 2011/9/28 Alex Pyattaev
>
> > Hi!
> > I have a quite sophisticated program
Hi!
I have a quite sophisticated program that can be summarized as follows:
1. Save a pypy object pointer inside C program. Here I call Py_XINCREF so that
it does not get deleted.
2. Do some logic, move this reference around C code.
3. Return a python tuple via typemap, here I am probably supposed
21 matches
Mail list logo
