gevent-1.0a1 is available
Denis Bilenko
gevent-1.0a1 tarball and windows builds are now available for download
at http://code.google.com/p/gevent/downloads/list
Read the changelog here:
https://bitbucket.org/denis/gevent/src/tip/changelog.rst#cl-1
Please try it out and report any issues you have. Be sure to take a
look at the list of backward-incompatible changes.
If you use gevent in a commercial environment, I encourage you to make
a donation to support the development: http://gevent.org/sfc.html
Cheers,
Denis.
Equand
Congratulations!
0.13.6 is still in pypi...
also how will it work with setuptools easy_install under freebsd
(currently 0.13.6 is unable to find libevent and fails miserably
gevent/libevent.h:9:19: error: event.h: No such file or directory
gevent/libevent.h:38:20: error: evhttp.h: No such file or directory
gevent/libevent.h:39:19: error: evdns.h: No such file or directory
though
MD5 (/usr/local/include/evhttp.h) = ef8f28d8a12aadcd05f90bfc1455e22b
MD5 (/usr/local/include/evdns.h) = b26d40b3ff735a2f7e2767c85bc174fc
MD5 (/usr/local/include/event.h) = 243643d4b6eafabd6cf9d6eda2c40f26
)?
will it work right, or like previously I'll have to compile libev,
cares and compile gevent to get the paths on FreeBSD?
Kapil Thangavleu
the 1.0 alpha includes all c library dependencies, no prior installation needed, it should work fine on freebsd afaics.
the changelog looks awesome! i'm looking forward to trying out some of the new thread features for disk i/o worker pools.
cheers,
Kapil
Denis Bilenko
Get 1.0a2 from http://code.google.com/p/gevent/downloads/list
I just noted, that previously it was possible to have
JoinableQueue(0), now we don't have an alternative for that.
Also, in all versions of gevent join()/task_done() are not available
on PriorityQueue/LifoQueue.
Maybe task_done()/join() should be put directly on Queue and Channel?
JoinableQueue then becomes an alias for Queue.
On Wed, Aug 3, 2011 at 7:25 AM, Equand <equ...@gmail.com> wrote:
> Woahaaaa...
> Congratulations!
> 0.13.6 is still in pypi...
> also how will it work with setuptools easy_install under freebsd
it's alpha so it does not belong on PyPI.
> will it work right, or like previously I'll have to compile libev,
> cares and compile gevent to get the paths on FreeBSD?
no, just unpack the tarball and do "python setup.py build"
AnilG
> > cares and compile gevent to get the paths on FreeBSD?
> no, just unpack the tarball and do "python setup.py build"
I thought the bitbucket repo would be the same as the tarball?
I got a pristine fork of the repo
and ran python2.7 setup.py build on FreeBSD 8.2.
It broke on the FreeBSD m4 which doesn't support -P.
I installed GNU m4 with --prefix=/usr and re ran the setup build.
It broke with util/cython_ifdef.py:No such file or directory
which is weird because that file is right there.
I then got the tarball and ran a faultless build.
The tarball has differences; Makefile.ext instead of Makefile,
PKG-INFO and setup.cfg present.
I'm sorry I don't understand this.
I'm used to using bitbucket and I want to submit updates for Py3k.
I think I previously built cython core manually in 0.13.
I presume I can make a start because my repo setup.py is identical
to the tarball setup.py. Can anyone direct me? Thanks.
Denis Bilenko
>> Get 1.0a2 fromhttp://code.google.com/p/gevent/downloads/list
>> > will it work right, or like previously I'll have to compile libev,
>> > cares and compile gevent to get the paths on FreeBSD?
>> no, just unpack the tarball and do "python setup.py build"
No, tarball is bitbucket repo + generated C extensions.
In order to generate those you need unifdef, cython, m4, all recent versions.
Makefile is indeed renamed to Makefile.ext in tarball so that setup.py
won't try to run it.
Ralf Schmitt
> I installed GNU m4 with --prefix=/usr and re ran the setup build.
> It broke with util/cython_ifdef.py:No such file or directory
> which is weird because that file is right there.
cython_ifdef.py contains the shebang
#!/usr/bin/python
which you don't have. I think it should be changed to
#!/usr/bin/env python
----
cheers,
ralf
Denis Bilenko
I suppose this will also help:
https://bitbucket.org/denis/gevent/changeset/31ae9ffab85f
AnilG
> > #!/usr/bin/python
> > which you don't have. I think it should be changed to
> > #!/usr/bin/env python
> I suppose this will also help:https://bitbucket.org/denis/gevent/changeset/31ae9ffab85f
I did have GNU m4 and unifdef 2.6 but I had wrong install path.
So to make the repo build on FreeBSD 8.2:
1. Install GNU m4 using "./configure --prefix=/usr" instead
of FreeBSD m4 since Makefile uses m4 -P.
2. Install unifdef 2.6 using "make prefix=/usr install" instead
of FreeBSD unifdef since util/cython_ifdef.py uses unifdef -o.
3. Update cython_ifdef.py to use "#!/usr/bin/env python" instead
of "#!/usr/bin/python" since FreeBSD uses /usr/local/bin/
python.
* Are you interested in changing these details to make the build
compatible without additional installs?
* Is making a pull request the proper way to submit changes?
1.
Eliminate -P for m4 in Makefile by writing an include that *renames*
the builtins with an m4_ prefix.
I couldn't make this work yet. I presume it's possible.
2.
Eliminate -o for unifdef in util/cython_ifdef.py by using a redirect.
This worked for me:
Instead of: system_unifdef('unifdef -t -b %s -o %s %s' % (key,
options.sourcefile, tmpname))
Use: system_unifdef('unifdef -t -b %s %s > %s' % (key, tmpname,
options.sourcefile))
3.
I guess Ralf's env shebang for cython_ifdef.py would harm no one if it
was in the standard build?
Instead of: #!/usr/bin/python
Use: #!/usr/bin/env python
I presume Commit 31ae9ffab85f in Makefile 'python util/
cython_ifdef.py' would work too,
but it's not there in the repo now though.
I guess could also use sys.exec_prefix to determine the python path,
and pass it into Makefile somehow.
This would enable people like me with multiple python versions to say
python2.7 setup.py build.
Denis Bilenko
> 1.
> Eliminate -P for m4 in Makefile by writing an include that *renames*
> the builtins with an m4_ prefix.
> I couldn't make this work yet. I presume it's possible.
I don't want to have complicated m4 templates, but we can get rid of
m4 altogether
and use some small Python template engine that we could just put in
util/ as a single file.
> 2.
> Eliminate -o for unifdef in util/cython_ifdef.py by using a redirect.
> This worked for me:
> Instead of: system_unifdef('unifdef -t -b %s -o %s %s' % (key,
> options.sourcefile, tmpname))
> Use: system_unifdef('unifdef -t -b %s %s > %s' % (key, tmpname,
> options.sourcefile))
OK, pushed this.
> 3.
> I guess Ralf's env shebang for cython_ifdef.py would harm no one if it
> was in the standard build?
> Instead of: #!/usr/bin/python
> Use: #!/usr/bin/env python
>
> I presume Commit 31ae9ffab85f in Makefile 'python util/
> cython_ifdef.py' would work too,
> but it's not there in the repo now though.
It's in the repo:
https://bitbucket.org/denis/gevent/src/bc7be40cf648/Makefile#cl-10
> I guess could also use sys.exec_prefix to determine the python path,
> and pass it into Makefile somehow.
There's no need for that. It does not matter which Python version you
run cython_ifdef.py script with.
> This would enable people like me with multiple python versions to say
> python2.7 setup.py build.
You can do that now, no changes necessary.
AnilG
> > the builtins with an m4_ prefix.
> > I couldn't make this work yet. I presume it's possible.
> I don't want to have complicated m4 templates, but we can get rid of
> m4 altogether
> and use some small Python template engine that we could just put in
> util/ as a single file.
I've already installed GNU m4 on my FreeBSD.
I'm willing to write this if you want it, but I'm not looking for
extra work.
I'd rather get Py3k working first.
> > Eliminate -o for unifdef in util/cython_ifdef.py by using a redirect.
> OK, pushed this.
> > I presume Commit 31ae9ffab85f in Makefile 'python util/
> > cython_ifdef.py' would work too,
> > but it's not there in the repo now though.
> It's in the repo:https://bitbucket.org/denis/gevent/src/bc7be40cf648/Makefile#cl-10
*really* recently!
Thanks very much!
> > This would enable people like me with multiple python versions to say
> > python2.7 setup.py build.
> You can do that now, no changes necessary.
AnilG
I worked back through the changesets to find the first one that fails.
$ hg update -r 6d5ca7f4e331
This is the first changeset that fails to build for me:
changeset: 2041:6d5ca7f4e331
summary: loop.__repr__: actually know if 'activecnt' is present at
compile time
This is the trace of the build.
I don't get why WIN32 appears.
This is on FreeBSD 8.2 with latest GNU m4, unifdef 2.6, cython
0.15/0.14.1.
$ python setup.py build
running build
running build_py
creating build
creating build/lib.freebsd-8.2-RELEASE-i386-2.7
creating build/lib.freebsd-8.2-RELEASE-i386-2.7/gevent
copying gevent/__init__.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/backdoor.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/baseserver.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/coros.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/event.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/greenlet.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/hub.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/gevent
copying gevent/local.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/monkey.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/pool.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/pywsgi.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/queue.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/resolver_ares.py -> build/lib.freebsd-8.2-RELEASE-
i386-2.7/gevent
copying gevent/select.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/server.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/socket.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/ssl.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/gevent
copying gevent/thread.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/timeout.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/util.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/win32util.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
copying gevent/wsgi.py -> build/lib.freebsd-8.2-RELEASE-i386-2.7/
gevent
running build_ext
m4 -P gevent/core_.pyx > core.pyx && mv core.pyx gevent/
python util/cython_ifdef.py -o gevent.core.c gevent/core.pyx
gevent/core.pyx: found symbols: EV_STANDALONE, _WIN32
unifdef -t -b -UEV_STANDALONE -U_WIN32 -o gevent/core.pyx gevent/
core.pyx.saved.11552
cython -o gevent.core.c gevent/core.pyx
unifdef -t -b -UEV_STANDALONE -D_WIN32 -o gevent/core.pyx gevent/
core.pyx.saved.11552
cython -o gevent.core.c gevent/core.pyx
unifdef -t -b -DEV_STANDALONE -U_WIN32 -o gevent/core.pyx gevent/
core.pyx.saved.11552
cython -o gevent.core.c gevent/core.pyx
unifdef -t -b -DEV_STANDALONE -D_WIN32 -o gevent/core.pyx gevent/
core.pyx.saved.11552
cython -o gevent.core.c gevent/core.pyx
Merging (might take a while)
echo >> gevent.core.c
echo '#include "callbacks.c"' >> gevent.core.c
mv gevent.core.* gevent/
cython -o gevent.ares.c gevent/ares.pyx
mv gevent.ares.* gevent/
building 'gevent.core' extension
creating build/temp.freebsd-8.2-RELEASE-i386-2.7
creating build/temp.freebsd-8.2-RELEASE-i386-2.7/gevent
cc -fno-strict-aliasing -O2 -pipe -D__wchar_t=wchar_t -
DTHREAD_STACK_SIZE=0x20000 -fno-strict-aliasing -DNDEBUG -O2 -pipe -
D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -fno-strict-aliasing -
fPIC -DEV_STANDALONE=1 -DEV_COMMON= -DEV_STAT_ENABLE=0 -
DEV_CHECK_ENABLE=0 -DEV_CLEANUP_ENABLE=0 -DEV_EMBED_ENABLE=0 -
DEV_CHILD_ENABLE=0 -DEV_PERIODIC_ENABLE=0 -Ilibev -I/usr/local/include/
python2.7 -c gevent/gevent.core.c -o build/temp.freebsd-8.2-RELEASE-
i386-2.7/gevent/gevent.core.o
gevent/gevent.core.c: In function
'__pyx_pf_6gevent_4core_5timer_8priority_1__set__':
gevent/gevent.core.c:7911: error: '__pyx_k_tuple_34' undeclared (first
use in this function)
gevent/gevent.core.c:7911: error: (Each undeclared identifier is
reported only once
gevent/gevent.core.c:7911: error: for each function it appears in.)
gevent/gevent.core.c: At top level:
gevent/gevent.core.c:17669: error: '__pyx_k_28' undeclared here (not
in a function)
gevent/gevent.core.c:17678: error: '__pyx_k_30' undeclared here (not
in a function)
gevent/gevent.core.c:17679: error: '__pyx_k_32' undeclared here (not
in a function)
gevent/gevent.core.c: In function '__Pyx_InitCachedConstants':
gevent/gevent.core.c:17940: error: '__pyx_k_tuple_34' undeclared
(first use in this function)
gevent/gevent.core.c: In function 'initcore':
gevent/gevent.core.c:18408: error: '__pyx_n_s_41' undeclared (first
use in this function)
gevent/gevent.core.c:19570: warning: passing argument 2 of
'PyObject_SetAttr' from incompatible pointer type
error: command 'cc' failed with exit status 1
Ralf Schmitt
>
>> This would enable people like me with multiple python versions to say
>> python2.7 setup.py build.
>
> You can do that now, no changes necessary.
One still needs a python executable in PATH for this to
work. archlinux's python is python 3. util/cython_ifdef.py won't work
with that one. Some of the BSDs don't even ship with a python executable
(it's called python2.x). The current Makefile won't work for them.
The attached patch would solve these issues. However trying it with
python 2.5 I get another error:
,----
| /usr/local/bin/python2.5 util/cython_ifdef.py -o gevent.core.c gevent/core.pyx
| gevent/core.pyx: found symbols: EV_STANDALONE, _WIN32
| Traceback (most recent call last):
| File "util/cython_ifdef.py", line 412, in <module>
| main()
| File "util/cython_ifdef.py", line 397, in main
| for key in iter_configurations(symbols):
| File "util/cython_ifdef.py", line 272, in iter_configurations
| config = _bin(x, size)
| File "util/cython_ifdef.py", line 265, in _bin
| result = bin(number)[2:]
| NameError: global name 'bin' is not defined
| make: *** [gevent/gevent.core.c] Error 1
`----
----
Cheers,
Ralf
AnilG
> on FreeBSD 8.2 i386 with GNU m4, unifdef 2.6, cython 0.15/0.14.1.
In hg identify 6d5ca7f4e331+
in cdef public class loop
in def __repr__
build breaks with this:
#ifdef EV_STANDALONE
result += ' activecnt=%r' % self.activecnt
#endif
build also breaks with this:
#ifdef EV_STANDALONE
activecnt = getattr(self, 'activecnt', None)
result += ' activecnt=%r' % activecnt
#endif
but succeeds when commented out altogether:
#ifdef EV_STANDALONE
##activecnt = getattr(self, 'activecnt', None)
##result += ' activecnt=%r' % activecnt
##result += ' activecnt=%r' % self.activecnt
#endif
and works the old way of doing it too, without #ifdef EV_STANDALONE:
activecnt = getattr(self, 'activecnt', None)
if activecnt is not None:
result += ' activecnt=%r' % activecnt
The fix for me at the moment to make the tip build
is to remove #ifdef EV_STANDALONE at this point as above.
Doing so enables the current tip to build successfully.
Denis Bilenko
reports "0.15" and then
$ make clean && python setup.py build
?
AnilG
> reports "0.15" and then
> $ make clean && python setup.py build
When I install cython 0.15 it reports 0.14. That was bothering me.
Also, I don't understand the changes to care_build.h.
I'll aim to submit the Py3k changes only.
Please cancel the pull request.
I don't know if I'm misusing mercurial; I've been repeatedly forking.
I'll start again from a pristine copy, but I'll work from a clone
instead of a fork.
AnilG
> > reports "0.15" and then
> > $ make clean && python setup.py build
>
I installed cython when /usr/local/bin/python was python3.1.
I then copied python2.7 over to /usr/local/bin/python to test gevent.
I got the same build error as above.
But I noticed:
$ which cython
/usr/local/bin/cython
$ cython --version
Cython version 0.14.1
$ cp /usr/local/bin/python3.1 /usr/local/bin/python
$ cython --version
Cython version 0.15
I'm going to install cython *again* under python2.7
AnilG
> reports "0.15" and then $ make clean && python setup.py build
3.1. Cython still reports 0.14.1 under Python 2.7, but does report
0.15 under Python 3.1.3.
The upshot is I can now get successful Python 3.1.3 gevent build, but
not Python 2.7!
Immediately after installing Cython 0.15 under Python 2.7 I attempted
a pristine tip gevent build (42292da5c42a server: rename kill() method
to close()) and still got error: command 'cc' failed with exit status
1 although the build messages seem shorter this time. I've supplied
the build trace at the bottom of this post.
Since the 3.1.3 build *is* completing I've re-forked current pristine
denis/gevent tip and applied the changes that I am proposing. I've
made a new pull request to make those available.
I can't actually test that these build in Python 2, because of the
Cython issue on my Python 2 builds. But a clone of anil_g/gevent
should build anywhere that the standard denis/gevent tip builds.
Py3k commits are:
1. Add 2to3 call in setup.py to enable Py3k builds.
2. Provide custom fixer in util. Needs to be manually installed to
work.
3. Provided Damien Churchill socket.py changes to simultaneously
support Py3k.
4. Updated util/cython_ifdef.py usage to simultaneously support Py3k /
Python 2.
If you incorporate these changes then we'll have a Py3k build that
*completes* but doesn't *work*. This is at least a basis for
collaboration and much Py3k support can be added incrementally, with
the benefit that updates can continue to be tested in Python 2 and
Py3k builds.
I'll follow up on the Cython issue but I'm pretty stumped right now.
This is some of my output.
$ which m4
/usr/bin/m4
$ m4 --version
m4 (GNU M4) 1.4.16
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Rene' Seindal.
$ which unifdef
/usr/bin/unifdef
$ unifdef -V
Version: unifdef-2.6
Date: 2011-02-22 16:53:10 +0000
Author: Tony Finch (d...@dotat.at)
URL: http://dotat.at/prog/unifdef
# which cython
/usr/local/bin/cython
# cython --version
Cython version 0.14.1
# python -V
Python 2.7.1
# cp /usr/local/bin/python3.1 /usr/local/bin/python
# python -V
Python 3.1.3
# cython --version
Cython version 0.15
# cp /usr/local/bin/python2.7 /usr/local/bin/python
# cython --version
Cython version 0.14.1
$ make clean && python setup.py build
gevent.core.h gevent/core.pyx
rm -f gevent.ares.c gevent.ares.h gevent/gevent.ares.c gevent/
gevent.ares.h
running build
running build_py
m4 -P gevent/core_.pyx > core.pyx && mv core.pyx gevent/
python util/cython_ifdef.py -o gevent.core.c gevent/core.pyx
gevent/core.pyx: found symbols: EV_STANDALONE, _WIN32
gevent/core.pyx
cython -o gevent.core.c gevent/core.pyx
warning: gevent/core.pyx:458:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:622:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:746:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:854:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:962:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:1070:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1178:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1295:22: cdef variable '_flags' declared
after it is used
unifdef -t -b -UEV_STANDALONE -D_WIN32 gevent/core.pyx.saved.2433 >
gevent/core.pyx
cython -o gevent.core.c gevent/core.pyx
warning: gevent/core.pyx:458:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:622:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:746:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:854:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:962:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:1070:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1178:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1295:22: cdef variable '_flags' declared
after it is used
unifdef -t -b -DEV_STANDALONE -U_WIN32 gevent/core.pyx.saved.2433 >
gevent/core.pyx
cython -o gevent.core.c gevent/core.pyx
warning: gevent/core.pyx:458:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:622:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:746:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:854:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:962:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:1070:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1178:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1295:22: cdef variable '_flags' declared
after it is used
unifdef -t -b -DEV_STANDALONE -D_WIN32 gevent/core.pyx.saved.2433 >
gevent/core.pyx
cython -o gevent.core.c gevent/core.pyx
warning: gevent/core.pyx:458:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:622:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:746:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:854:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:962:22: cdef variable '_flags' declared after
it is used
warning: gevent/core.pyx:1070:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1178:22: cdef variable '_flags' declared
after it is used
warning: gevent/core.pyx:1295:22: cdef variable '_flags' declared
after it is used
echo >> gevent.core.c
echo '#include "callbacks.c"' >> gevent.core.c
mv gevent.core.* gevent/
cython -o gevent.ares.c gevent/ares.pyx
mv gevent.ares.* gevent/
building 'gevent.core' extension
DTHREAD_STACK_SIZE=0x20000 -fno-strict-aliasing -DNDEBUG -O2 -pipe -
D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x20000 -fno-strict-aliasing -
fPIC -DEV_STANDALONE=1 -DEV_COMMON= -DEV_STAT_ENABLE=0 -
DEV_CHECK_ENABLE=0 -DEV_CLEANUP_ENABLE=0 -DEV_EMBED_ENABLE=0 -
DEV_CHILD_ENABLE=0 -DEV_PERIODIC_ENABLE=0 -Ilibev -I/usr/local/include/
python2.7 -c gevent/gevent.core.c -o build/temp.freebsd-8.2-RELEASE-
i386-2.7/gevent/gevent.core.o
gevent/gevent.core.c:5128: error: '__pyx_k_19' undeclared (first use
in this function)
gevent/gevent.core.c:5128: error: (Each undeclared identifier is
reported only once
gevent/gevent.core.c:5128: error: for each function it appears in.)
gevent/gevent.core.c: In function
'__pyx_pf_6gevent_4core_7watcher___repr__':
gevent/gevent.core.c:6167: error: '__pyx_kp_s_26' undeclared (first
use in this function)
gevent/gevent.core.c: At top level:
gevent/gevent.core.c:21106: error: '__pyx_k_40' undeclared here (not
in a function)
gevent/gevent.core.c: In function 'initcore':
gevent/gevent.core.c:21740: error: '__pyx_n_s_56' undeclared (first
use in this function)
gevent/gevent.core.c:22902: warning: passing argument 2 of
in this function)
dcreemer
AnilG
> 3.1. Cython still reports 0.14.1 under Python 2.7, but does report
> 0.15 under Python 3.1.3.
that was causing the fail.
I removed them and I now get consistent cython version and successful
gevent python 2.7 build.
http://groups.google.com/group/cython-users/browse_thread/thread/ed90cafd2e1c6255
Denis Bilenko
The "-b" option was kind of important in order to generate nicer
(smaller) .c source.
Regardless, I've committed a better preprocessor script that no longer
needs unifdef. While I'm here I've also made it evaluate #defines, so
m4 is not used as well.
Here's the new script:
https://bitbucket.org/denis/gevent/src/44fbda89a33a/util/cythonpp.py
And here's how the source now looks like:
https://bitbucket.org/denis/gevent/src/44fbda89a33a/gevent/core.ppyx
Let me know if it works for you and if you spot any bugs.
Ralf Schmitt
>
> Regardless, I've committed a better preprocessor script that no longer
> needs unifdef. While I'm here I've also made it evaluate #defines, so
> m4 is not used as well.
nice!
>
> Here's the new script:
> https://bitbucket.org/denis/gevent/src/44fbda89a33a/util/cythonpp.py
> And here's how the source now looks like:
> https://bitbucket.org/denis/gevent/src/44fbda89a33a/gevent/core.ppyx
>
> Let me know if it works for you and if you spot any bugs.
building with 2.5 doesn't work, since python 2.5 doesn't have
itertools.product:
,----
| /usr/bin/python2.5 util/cythonpp.py -o gevent.core.c gevent/core.ppyx
| Traceback (most recent call last):
| File "util/cythonpp.py", line 677, in <module>
| process_filename(filename, options.output_file)
| File "util/cythonpp.py", line 56, in process_filename
| for configuration in get_configurations(filename):
| File "util/cythonpp.py", line 584, in get_configurations
| for configuration in get_selections(conditions):
| File "util/cythonpp.py", line 566, in get_selections
| return set([flat_tuple(sorted(set(x))) for x in itertools.product(items, repeat=len(items))])
| AttributeError: 'module' object has no attribute 'product'
`----
--
Cheers
Ralf
Ralf Schmitt
>
> I struck problems with the frozen app though (using py2exe)
> File "multiprocessing\process.pyc", line 88, in run
> File "Src\server\start.pyc", line 21, in start
> File "gevent\monkey.pyc", line 181, in patch_all
> File "gevent\monkey.pyc", line 106, in patch_thread
> File "gevent\monkey.pyc", line 62, in patch_module
> File "gevent\thread.pyc", line 28, in <module>
> File "gevent\lock.pyc", line 5, in <module>
> File "gevent\_semaphore.pyc", line 12, in <module>
> File "gevent\_semaphore.pyc", line 5, in __load
> AttributeError: 'module' object has no attribute 'path'
that's a problem in py2exe.
see https://github.com/surfly/gevent/issues/226 and
https://github.com/surfly/gevent/issues/181