gmane.comp.python.pypy

Re: Problems in connecting C++ and python with cppyy

Xia Xin — 2013-05-25T02:02:14

Hi, Wim

I tried, but when I use the automatic class loader, the problem still exists.

HERE is the error.

1.

$ echo $LD_LIBRARY_PATH
/home/GeV/work/hello/v1/src:/opt/root/lib/root

$ ls /home/GeV/work/hello/v1/src
libMyClassDict.rootmap  libMyClassDict.so  MyClass.h         MyClass_rflx.cpp

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: <class '__main__.::'> object has no attribute
'MyClass' (details: '<class '__main__.::'>' has no attribute
'MyClass')

2. TRY explicit load statements, Just as that Armin told me, It's OK,
works perfectly

$ echo $LD_LIBRARY_PATH
/opt/root/lib/root

42

3. Use LD_LIBRARY_PATH to clarify the path to libMyClassDict.so, still error

$ echo $LD_LIBRARY_PATH
/home/GeV/work/hello/v1/src:/opt/root/lib/root

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: libMyClassDict.so: cannot open shared object file: No
such file or directory


I don't understand why the LD_LIBRARY_PATH did not work well on my P

Re: Problems in connecting C++ and python with cppyy

2013-05-24T17:08:16

Hi,


yes, or add '.' to LD_LIBRARY_PATH. The call is basically just a dlopen:
internally, it uses libffi.CDLL().

Note that if the automatic class loader is used, the same rules apply, as
.rootmap files available through LD_LIBRARY_PATH are used for auto-loading.

I've clarified this in the documentation.

Thanks,
      Wim

Re: Problems in connecting C++ and python with cppyy

Armin Rigo — 2013-05-24T08:58:41

Hi,

On Fri, May 24, 2013 at 8:45 AM, Xia Xin <xiaxinx< at >gmail.com> wrote:

I believe that you need to say "./libMyClassDict.so".  Otherwise it's
searching for the .so in the system's standard places, which do not
include ".".


A bientôt,

Armin.

Problems in connecting C++ and python with cppyy

Xia Xin — 2013-05-24T06:45:20

Hi,

When I use cppyy to connect the C++ with the python, I got a failure.
Following this page, https://pypy.readthedocs.org/en/improve-docs/cppyy.html

Define a new class

$ cat MyClass.h
class MyClass {
public:
    MyClass(int i = -99) : m_myint(i) {}

    int GetMyInt() { return m_myint; }
    void SetMyInt(int i) { m_myint = i; }

public:
    int m_myint;
};

then compile it.
$ genreflex MyClass.h
$ g++ -fPIC -rdynamic -O2 -shared -I$REFLEXHOME/include
MyClass_rflx.cpp -o libMyClassDict.so -L$REFLEXHOME/lib -lReflex
$ ls
libMyClassDict.so       MyClass.h         MyClass_rflx.cpp

BUT, when I tried to load it in pypy-c, error occurred.
$ pypy-c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: libMyClassDict.so: cannot open shared object file: No
such file or directory

Help me please? Thanks.

Re: Python 3 ...

Massa, Harald Armin — 2013-05-24T06:26:54

which goes great with indention, you shall use 4 spaces to indent, never 3.

Harald

Re: Fail to compile psycopg2

Steve Kieu — 2013-05-24T05:48:46

Thanks, It install cleanly (have not tried to test by making some
connection etc.. but hopefuly all good)

The MySQL-python works though

cheers


On Fri, May 24, 2013 at 3:40 PM, Alex Gaynor <alex.gaynor< at >gmail.com> wrote:

Re: Fail to compile psycopg2

Alex Gaynor — 2013-05-24T05:40:59

Hi Steve,

In general you probably want to avoid C-extensions when running under PyPy.
In this case I reccomend using psycopg2cffi instead:
https://pypi.python.org/pypi/psycopg2cffi it's basically a drop-in
replacement and works well under PyPy.

Alex


On Fri, May 24, 2013 at 1:36 AM, Steve Kieu <msh.computing< at >gmail.com> wrote:

Fail to compile psycopg2

Steve Kieu — 2013-05-24T05:36:51

Hello All,

I tried to install psycopg2 but failed with the following message


building 'psycopg2._psycopg' extension

cc -O2 -fPIC -Wimplicit -DPSYCOPG_DEFAULT_PYDATETIME=1
-DPSYCOPG_VERSION="2.5 (dt dec pq3 ext)" -DPG_VERSION_HEX=0x090109
-DPSYCOPG_EXTENSIONS=1 -DPSYCOPG_NEW_BOOLEAN=1 -DHAVE_PQFREEMEM=1
-I/home/stevek/pypy/include -I. -I/usr/include/postgresql
-I/usr/include/postgresql/9.1/server -c psycopg/psycopgmodule.c -o
build/temp.linux-x86_64-2.7/psycopg/psycopgmodule.o
-Wdeclaration-after-statement

In file included from psycopg/psycopgmodule.c:38:0:

./psycopg/error.h:32:5: error: unknown type name ‘PyBaseExceptionObject’

error: command 'cc' failed with exit status 1


Looks like the python header from pypy does not declare
PyBaseExceptionObject

Any way to fix this?

Thanks in adanvace,

Re: Python 3 ...

Alexander Belopolsky — 2013-05-24T02:29:51



.. or 2 :-)
_______________________________________________
pypy-dev mailing list
pypy-dev< at >python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: Python 3 ...

Paulo Köch — 2013-05-23T23:21:25

I'll save a google search to a lot of people.

http://docs.python.org/dev/library/constants.html#Ellipsis
http://stackoverflow.com/questions/772124/what-does-the-python-ellipsis-object-do
_______________________________________________
pypy-dev mailing list
pypy-dev< at >python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Python 3 ...

Armin Rigo — 2013-05-23T23:00:49

Hi all,

Unrelated to everything, a comment about Python 3's unrivalled syntax.
You can now be hesitant in your programs!  Try it out:

    if len(x) > 0 and... and... and x[0] == 5:

More seriously, I'm used to type "..." somewhere to mean "fix me
first!".  I didn't move to Python 3 so far, but if I had to pick a
reason, this one would be high on the list.  Now the program will
associate a useless meaning to my "..." and try to execute it.  Even
worse, in the usual case (a line containing only "...") it will work:
the line is completely ignored!  You can write this:

    def foo():
        x = ...
        ...

and actually execute foo() without getting any error.  Likely you'll
end with a crash later because this call to foo() didn't have the
expected effect, which you did not implement so far.  Same with
"assert...", which just passes.  Great!

I guess I just have to remember: use 4 dots, never 3.

</rant>


Armin

PyPy logo update

Arseniy Terekhin — 2013-05-22T15:04:45

Hi!

Let's update the logo to have `PyPy` instead of `pypy`.
Too see my idea go to http://pypy.org and execute this javascript
(Ctrl+Shift+J for Chrome, Ctrl+Shift+K for Firefox):

$('#header').prepend('<h1 class="title" style="position:
fixed;font-size: 350%;margin-top: 31px;margin-left: 152px;background:
white;width: 300px;height: 40px;color:black;">PyPy</h1>');

Any objection? If no then I'll make a pull request.

--
Best regards,
Arseniy Terekhin

Re: Killing OOType? (was Re: Translating pypy on FreeBSD with CLI backend)

William ML Leslie — 2013-05-22T06:23:03

Nobody is working on any of the OO backends at the moment.

It might be worthwhile to document what we mean by 'from scratch',
too.  Graphs that haven't been rtyped actually have most of the
information that oo-style or untyped backends might care about, the
most significant things missing probably involve dealing with
constants as well as the extregistry.

--
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely may reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to deny you those rights would be illegal without
prior contractual agreement.

Re: Killing OOType? (was Re: Translating pypy on FreeBSD with CLI backend)

James Lan — 2013-05-22T06:11:30

I really wish pypy is able to support jvm, cli and dalvik, so that it is
possible to write core business logic in python which runs everywhere.

Is there any plan to implement a better ootype as well as OO backends?


On Thu, May 9, 2013 at 2:19 AM, Armin Rigo <arigo< at >tunes.org> wrote:

_______________________________________________
pypy-dev mailing list
pypy-dev< at >python.org
http://mail.python.org/mailman/listinfo/pypy-dev

PyPy 2.0.2 released

Armin Rigo — 2013-05-21T09:27:11

Hi all,

The bugfix PyPy 2.0.2 has been released (on all platforms but OS/X
which should come later in the day).


=========================
PyPy 2.0.2 - Fermi Panini
=========================

We're pleased to announce PyPy 2.0.2.  This is a stable bugfix release
over 2.0 and 2.0.1.  You can download it here:

    http://pypy.org/download.html

It fixes a crash in the JIT when calling external C functions (with
ctypes/cffi) in a multithreaded context.

What is PyPy?
=============

PyPy is a very compliant Python interpreter, almost a drop-in replacement for
CPython 2.7. It's fast (pypy 2.0 and cpython 2.7.3 performance comparison:
http://speed.pypy.org) due to its integrated tracing JIT compiler.

This release supports x86 machines running Linux 32/64, Mac OS X 64 or
Windows 32.  Support for ARM is progressing but not bug-free yet.

Highlights
==========

This release contains only the fix described above.  A crash (or wrong
results) used to occur if all these conditions were true:

- your program is multit

Re: Is cpyext dead forever?

Maciej Fijalkowski — 2013-05-18T19:57:13

In a way it should not have happened at all. But also in a way I would
argue cpyext is broken (annotation-wise) and my changes merely exposed
brokenness. It's still my duty to fix it though ;-)

Cheers,
fijal

Re: Is cpyext dead forever?

Matti Picus — 2013-05-18T19:49:42

_______________________________________________
pypy-dev mailing list
pypy-dev< at >python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: Is cpyext dead forever?

Maciej Fijalkowski — 2013-05-18T19:45:36

It's disabled because I broke it. I'll unbreak it some time soon, it's
just that issue is involved. I'm sorry about that, but there was no
goal to deprecate it any time soon.

Cheers,
fijal

Is cpyext dead forever?

Matti Picus — 2013-05-18T18:51:00

cpyext is currently disabled on default. Is there a branch to revive it?
Or are we expecting cffi to replace all interaction with external c code?
I'm not sure what will be more painful, getting the world to rewrite all 
modules or supporting cpyext, both seem non-trivial.
(I'm opening the discussion here since I'm not sure if everyone was 
heard in the discussion on IRC)
Matti

Re: pypy performance on fractal terrain generator.

Maciej Fijalkowski — 2013-05-18T18:10:29

Cool, thanks for sharing!

Cheers,
fijal

PS. No, it's not a spam message despite looking like one, genuinely thanks

pypy performance on fractal terrain generator.

sean riley — 2013-05-18T18:03:47

FYI. Performance comparison of pypy and CPython using a fractal terrain
generator and writing out a png file. Pypy is 6-11x faster on my Ubuntu
Intel system.


For 1024x1024 map:

sriley< at >xxxy:/data/src/cityserver$ time pypy map.py
real 0m0.656s
user 0m0.596s
sys 0m0.052s

sriley< at >xxx:/data/src/cityserver$ time python map.py
real 0m4.189s
user 0m4.132s
sys 0m0.044s

For 4096x4096 map:

sriley< at >xxx:/data/src/cityserver$ time pypy map.py
real 0m6.511s
user 0m6.152s
sys 0m0.328s

sriley< at >xxx:/data/src/cityserver$ time python map.py
real 1m7.641s
user 1m7.124s
sys 0m0.324s


Sean.
_______________________________________________
pypy-dev mailing list
pypy-dev< at >python.org
http://mail.python.org/mailman/listinfo/pypy-dev