Hi everyone,
welcome to the new mailing list at python.org that replaces the original
list cython-...@codespeak.net.
Stefan
PS: this mail is mostly for testing the list and archive connections.
___
cython-devel mailing list
cython-devel@python.org
h
Rod Montgomery, 12.02.2011 14:59:
Stefan Behnel wrote, on 11 Feb 2011 13:57:56 +0100:
>...given that we have a separate cython-users mailing list anyway.
Is there indeed a separate cython-users mailing list?
If there is, would someone please tell me *where* it is?
I only added the "
Berthold Hoellmann, 14.02.2011 09:08:
Stefan Behnel writes:
welcome to the new mailing list at python.org that replaces the original
list cython-...@codespeak.net.
Will this list also be made avaliable via gmane as newsgroup
"gmane.comp.python.cython.devel"?
I've alrea
Vitja Makarov, 14.02.2011 08:40:
In order to implement "reaching definitions" algorithm.
I'm now working on control-flow (or data-flow) graph.
Cool. Another good topic for the workshop. I've added it to the list on the
wiki page. Note that it's related to the NameNode graph, but not completely
Robert Bradshaw, 15.02.2011 08:21:
On Mon, Feb 14, 2011 at 9:49 PM, Vitja Makarov wrote:
2011/2/15 Robert Bradshaw:
On Sun, Feb 13, 2011 at 11:40 PM, Vitja Makarov wrote:
Hi!
In order to implement "reaching definitions" algorithm.
I'm now working on control-flow (or data-flow) graph.
Here is
[CC-ing cython-devel here]
Yaroslav Halchenko is Cython's current maintainer for Debian.
Yaroslav Halchenko, 15.02.2011 19:50:
Stefan Behnel, 15.02.2011 18:54:
Yaroslav Halchenko, 14.02.2011 21:38:
I guess it might bring us
surprises while building on those exotics platforms Debian sup
[forwarding to the list, from Yaroslav Halchenko]
Hi,
I am a member of Python Applications Packaging Team in Debian. So now me,
later some other members could chime in to provide fresh uploads.
On Tue, 15 Feb 2011, Stefan Behnel wrote:
Cool. That looks good. As you mentioned, it doesn&#
[forwarding to the list, from Yaroslav Halchenko]
On Tue, 15 Feb 2011, Stefan Behnel wrote:
Cool. That looks good. As you mentioned, it doesn't include the test
runs yet, but it would be really great if you could get those
running.
ok - added testing during build, so now need to assure
W. Trevor King, 17.02.2011 14:51:
The `hg export` on the cython-devel page [1] should probably be
changed to (or additionally list) `git format-patch`, now that
Cython's versioned in Git. Keeping the `hg export` reference might be
useful for Mercurial lovers using hg-git.
[1]: http://mail.pytho
Lisandro Dalcin, 17.02.2011 15:32:
Stefan, what do you think about the patch below? This hunk is part of
a series of fixes required to get numpy-dev working under Python 3.2.
The root of the issue is that __cythonbufferdefaults__ keys&values
end-up being "bytes" (this coercion is triggered in Int
Hi,
I still didn't get a response from Gmane, but this article doesn't look
promising:
http://article.gmane.org/gmane.discuss/13987
So I guess we'll have to request a new group. Very unfortunate.
Stefan
___
cython-devel mailing list
cython-devel@py
Chris Colbert, 18.02.2011 03:23:
What is the rule of thumb when declaring functions from python's C-api when
comes to ref counting?
The general rule is to not declare them yourself. Instead, cimport them
from the cpython package. (See Cython/Includes/)
If I define a test case like so:
cde
Robert Bradshaw, 18.02.2011 00:54:
Forgot reply-all... didin't we have this discussion before about
making that the default for this list as it is by-far the most common
desired behavior?
Yes we did. And I guess it would be "the default" for mailing lists if it
was just that: a default, not so
Lisandro Dalcin, 17.02.2011 17:24:
On 17 February 2011 12:16, Stefan Behnel wrote:
Lisandro Dalcin, 17.02.2011 15:32:
Stefan, what do you think about the patch below? This hunk is part of
a series of fixes required to get numpy-dev working under Python 3.2.
The root of the issue is that
Reply sent to cython-users.
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Thomson, 18.02.2011 10:10:
I tried to add a statement to Python, but I don't know how to update
the grammar header files such as graminit.c&graminit.h after I updated
the grammar file (Garmmar/Garmmar). It seems pgenmain.c could do this,
but these is no pgen.exe in the build output of Visual Stud
Lisandro Dalcin, 18.02.2011 15:38:
On 18 February 2011 02:19, Stefan Behnel wrote:
Lisandro Dalcin, 17.02.2011 17:24:
OK, I've found an alternative workaround. What do you think?
diff --git a/Cython/Compiler/Interpreter.py
b/Cython/Compiler/Interpreter.py
index 83cb184..9fb5fe5 1
Robert Bradshaw, 18.02.2011 23:08:
On Thu, Feb 17, 2011 at 8:38 PM, W. Trevor King wrote:
On Thu, Feb 17, 2011 at 3:53 PM, Robert Bradshaw wrote:
On Thu, Feb 17, 2011 at 3:12 PM, W. Trevor King wrote:
Compilation is an issue. I think that .pxd files should be able to be
cythoned directly, sin
Stefan Behnel, 18.02.2011 05:50:
I still didn't get a response from Gmane, but this article doesn't look
promising:
http://article.gmane.org/gmane.discuss/13987
So I guess we'll have to request a new group. Very unfortunate.
They've updated the group subscription. Tur
W. Trevor King, 20.02.2011 00:31:
On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote:
On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote:
It is unclear to me what `cdef public struct` means. I think it
should mean "Python bindings can alter this struct's definition",
which does
W. Trevor King, 20.02.2011 03:32:
On Sat, Feb 19, 2011 at 04:41:27PM -0800, Robert Bradshaw wrote:
On Sat, Feb 19, 2011 at 3:31 PM, W. Trevor King wrote:
I think it's better to keep cdef meaning "backed by C data", not
necessarily "written using C syntax", since you're trying to do more
with Cy
Greg Ewing, 20.02.2011 21:13:
Robert Bradshaw wrote:
BTW, the "public" keyword is the wrong thing to use here, as that
actually controls name mangling and (c-level) symbol exporting. The
fact that means a different thing for members than for top-level
symbols isn't ideal, but at least it's unam
Robert Bradshaw, 21.02.2011 19:11:
On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel wrote:
W. Trevor King, 20.02.2011 00:31:
On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote:
On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote:
It is unclear to me what `cdef public struct
Greg Ewing, 21.02.2011 22:12:
Stefan Behnel wrote:
With "preferred way", I was suggesting that we could *deprecate*
cdef public int x
cdef readonly object y
for cdef class properties in favour of
cpdef int x
cpdef readonly object y
I think I've just realised one of the rea
W. Trevor King, 22.02.2011 18:55:
I've been working on a more explicit parser that removes the ambiguity
behind the various visibilities. This will help me ensure proper
impolementation of my cdef-ed enums/structs/..., and make it easier to
update visibility syntax in the future. Take a look an
Vitja Makarov, 20.02.2011 18:23:
2011/2/16 Vitja Makarov:
Hmm... both python and codespeaks in the thread
Yes, we should keep it to cython-devel only. Sorry for mixing it up.
Here is my commit it's mostly broken now but anyway
https://github.com/vitek/cython/commit/5579b23c3c1c06981331b6427
Lisandro Dalcin, 22.02.2011 21:41:
Take a look here: http://bugs.python.org/issue9666
'hasattr' default behaviour should be changed to suppress only
AttributeError exceptions. Other should pass through.
+1, I think I even faintly recall that discussion. What a lengthy thread...
http://mail.p
Lisandro Dalcin, 23.02.2011 01:59:
On 22 February 2011 19:09, Lisandro Dalcin wrote:
On 22 February 2011 18:21, Stefan Behnel wrote:
Lisandro Dalcin, 22.02.2011 21:41:
I'm inclined to fix the behavior for ALL Python
versions to suppress only AttributeError.
How? Would you implem
Lisandro Dalcin, 23.02.2011 16:43:
Should we try to support Py_LIMITED_API for Py>=3.2?
I asked the same question a while ago. I think we should, but it won't be
easy. That API is pretty restricted compared to what Cython currently uses,
including the internals of builtin types that we use in
W. Trevor King, 22.02.2011 21:02:
On Tue, Feb 22, 2011 at 08:18:21PM +0100, Stefan Behnel wrote:
I also doubt that Cython allows you to call an attribute "cdef", you'll
need to change that.
It seems to work for me:
>>> import Cython.Compiler.Parsing as P
&g
Lisandro Dalcin, 28.02.2011 17:33:
Bringing up this old post...
On 21 June 2010 15:41, Robert Bradshaw wrote:
On Jun 17, 2010, at 9:31 AM, Lisandro Dalcin wrote:
If we special case a __dict__ attribute in extension types, i.e:
cdef class Foo:
cdef dict __dict__
and fill type->tp_dictoff
Dag Sverre Seljebotn, 02.03.2011 11:20:
c) Somehow provide more than one module in the same compilation unit.
Again, this requires the build to work correctly, but seems less dangerous,
and also has the advantage of *allowing* static linking of the Fortran
library, if one wants to.
But is someth
Dag Sverre Seljebotn, 02.03.2011 11:54:
On 03/02/2011 11:48 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:20:
c) Somehow provide more than one module in the same compilation unit.
Again, this requires the build to work correctly, but seems less dangerous,
and also has the
Dag Sverre Seljebotn, 02.03.2011 16:37:
On 03/02/2011 04:11 PM, Lisandro Dalcin wrote:
On 2 March 2011 08:35, Stefan Behnel wrote:
Dag Sverre Seljebotn, 02.03.2011 11:54:
Problem is that Fortran code often has...interesting...programming
practices. Global variables abound, and are often
Lisandro Dalcin, 03.03.2011 05:38:
On 2 March 2011 21:01, Greg Ewing wrote:
Stefan Behnel wrote:
you'd call "cython" on a package and it would output a directory with a
single __init__.so that contains the modules compiled from all .pyx/.py
files in that package. Importing th
mark florisson, 03.03.2011 10:32:
On 3 March 2011 07:43, Stefan Behnel wrote:
Lisandro Dalcin, 03.03.2011 05:38:
On 2 March 2011 21:01, Greg Ewing wrote:
Stefan Behnel wrote:
you'd call "cython" on a package and it would output a directory with a
single __init__.so th
Vitja Makarov, 03.03.2011 10:48:
To share common sources is a good idea, we can also share "code" in
libcython-.so
But then we should handle ABI compatibility problems.
There is little constant code overlap between modules, and putting that
into a separate library would lead to performance reg
Ryan Schmidt, 06.03.2011 23:12:
There are two different files called Cython-0.14.1.tar.gz -- one in
http://www.cython.org/release/ and a different one in
http://pypi.python.org/packages/source/C/Cython/:
Intersting. Do you mean "different" as in "different content" (i.e. sources
etc.), or j
Ryan Schmidt, 07.03.2011 08:25:
I went back to check the 0.13 distfiles as well. The contents there are clearly
different as well; the distfile on www.cython.org is 630K while the one on
pypi.python.org is 808K. Here, the difference is that the distfile on
pypi.python.org contains these additi
Vitja Makarov, 08.03.2011 11:01:
Hi!
Here is example code:
def foo(seq):
cdef int x
return any(x for x in seq)
Here inner x have type int, how does cdef affects nested scope?
Is that correct?
Yes, that's intended. Otherwise there'd be no way to assign types to
variables used in gene
Sturla Molden, 08.03.2011 16:10:
once Cython has closures working properly.
Could you elaborate what you are referring to here?
Cython does have closure support. Maybe you are missing closures for cdef
functions? Or is it block level closures that you want? That could be done
as well, just l
mark florisson, 08.03.2011 17:10:
But how useful is it to parallelize CPU-bound code while holding GIL?
Or do you mean to run the CPU-intensive section in a 'with nogil'
block and when you need to do locking, or when you need to deal with
Python objects you reaqcuire the GIL?
You don't need the
Sturla Molden, 08.03.2011 17:50:
Den 08.03.2011 17:04, skrev Stefan Behnel:
Could you elaborate what you are referring to here?
Nothing, except my own ignorance :-)
Now that we've settled that... ;)
What about writing up a little "parallel computing with Cython closures"
mark florisson, 08.03.2011 18:00:
What I meant was that the
wrapper returned by the decorator would have to call the closure for
every iteration, which introduces function call overhead.
[...]
I guess we just have to establish what we want to do: do we
want to support code with Python objects (an
Francesc Alted, 08.03.2011 20:16:
A Tuesday 08 March 2011 18:50:15 Stefan Behnel escrigué:
mark florisson, 08.03.2011 18:00:
What I meant was that the
wrapper returned by the decorator would have to call the closure
for every iteration, which introduces function call overhead.
[...]
I guess
Sturla Molden, 08.03.2011 20:18:
We still need sychonization and scheduling primitives similar to those in
OpenMP. For example a special 'range' function that will share the workload
of a for loop. But this is not a major programming task.
... but that could be put into a builtin Cython library
Vitja Makarov, 08.03.2011 20:12:
What is the right way to handle cdefed unbounds?
cdef object foo
print foo
cdef int foo
print foo
Fail with a compile error.
And how buffers and arrays should be handled? Now I'm skipping
buffers, arrays and structs.
There are some examples in test suite:
Greg Ewing, 09.03.2011 00:27:
Stefan Behnel wrote:
You *can* use Python references inside of nogil blocks, even if there's a
lot of stuff that you can't do with them, ... But you can access cdef
> attributes on them,
Strictly speaking it's not even safe to do that, unles
Robert Bradshaw, 11.03.2011 01:46:
On Tue, Mar 8, 2011 at 11:16 AM, Francesc Alted wrote:
A Tuesday 08 March 2011 18:50:15 Stefan Behnel escrigué:
mark florisson, 08.03.2011 18:00:
What I meant was that the
wrapper returned by the decorator would have to call the closure
for every iteration
Dag Sverre Seljebotn, 11.03.2011 08:56:
Basically, I'm +1 to anything that can make me
pretend the GIL doesn't exist, even if it comes with a 2x performance hit:
Because that will make me write parallell code (which I can't be bothered
to do in Cython currently), and I have 4 cores on the laptop
Sturla Molden, 11.03.2011 12:13:
OpenMP is a specification, not a particular implementation. Implementation
for Cython should either be compiler pragmas or a library.
I'd like it to be a library, as it should also be usable from Python. I
have made some progress on the library route, depending o
Hi,
ticket 654 describes a code generation problem where the arguments to a
cdef function are not being evaluated in the order they are written down in
the code.
http://trac.cython.org/cython_trac/ticket/654
This introduces problems when the arguments have side effects or are not
simple, e.
Vitja Makarov, 11.03.2011 15:04:
2011/3/11 Stefan Behnel:
Personally, I think it would be nice to keep up Python's semantics, but when
I implemented this I broke quite some code in Sage (you may have noticed
that the sage-build project in Hudson has been red for a while). There are
things
Sturla Molden, 11.03.2011 15:19:
Den 11.03.2011 12:43, skrev Stefan Behnel:
What's your use actual case for this?
Just avoid different syntax inside and outside nogil-blocks. I like this style
with openmp.critical:
better than what is currently legal with nogil:
openmp.critical
Stefan Behnel, 11.03.2011 15:08:
Vitja Makarov, 11.03.2011 15:04:
2011/3/11 Stefan Behnel:
Personally, I think it would be nice to keep up Python's semantics, but
when
I implemented this I broke quite some code in Sage (you may have noticed
that the sage-build project in Hudson has bee
Greg Ewing, 12.03.2011 23:57:
mark florisson wrote:
Have we ever thought about supporting 'with gil' as an actual
statement instead of just as part of a function declaration or
definition?
That's the way I was originally going to do it in Pyrex, but
it turned out to be problematic, because th
mark florisson, 16.03.2011 13:28:
On 16 March 2011 13:01, mark florisson wrote:
Another feedback is that I wonder whether we should put the "gil" and
"nogil" psuedo-context managers both in cython namespace, and sort of
deprecate the "global" nogil, rather than introduce yet another name that
ca
Dag Sverre Seljebotn, 16.03.2011 11:58:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch applied Cython wil issue an error when you have e.g.
with n
Dag Sverre Seljebotn, 16.03.2011 13:37:
On 03/16/2011 12:54 PM, mark florisson wrote:
On 16 March 2011 11:58, Dag Sverre Seljebotn wrote:
I think we should make nested nogil-s noops, i.e.
with nogil:
with nogil: # => if True:
This is because one may want to change "with nogil" to "with gi
mark florisson, 16.03.2011 11:33:
The PyCharm IDE (http://www.jetbrains.com/pycharm/) has granted the
Cython project a free Open Source license, which means that anyone
developing Cython may freely use PyCharm to develop Cython.
Looks like they don't support Cython code, though:
http://youtrac
Robert Bradshaw, 11.03.2011 19:33:
On Fri, Mar 11, 2011 at 9:36 AM, Stefan Behnel wrote:
Stefan Behnel, 11.03.2011 15:08:
Vitja Makarov, 11.03.2011 15:04:
2011/3/11 Stefan Behnel:
Personally, I think it would be nice to keep up Python's semantics, but
when
I implemented this I
mark florisson, 16.03.2011 11:28:
I implemented the 'with gil:' statement
[...]
The 'with gil:' statement can now be used in the same way as 'with
nogil:'. Exceptions raised from GIL blocks will be propagated if
possible (i.e., if the return type is 'object'). Otherwise it will
jump to the end of
mark florisson, 16.03.2011 15:29:
On 16 March 2011 15:07, Stefan Behnel wrote:
mark florisson, 16.03.2011 13:28:
On 16 March 2011 13:01, mark florisson wrote:
Another feedback is that I wonder whether we should put the "gil" and
"nogil" psuedo-context managers both in c
Dag Sverre Seljebotn, 17.03.2011 08:38:
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way to
handle exceptions, so simply jumping out of them because an inner 'with
gil' bloc
Robert Bradshaw, 17.03.2011 05:05:
On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel wrote:
I'm actually leaning towards not guaranteeing the order of execution if C
doesn't do it either. If this is really required, it's easy to work around
for users, but it's severely hard
Robert Bradshaw, 17.03.2011 22:26:
On Thu, Mar 17, 2011 at 2:25 PM, Stefan Behnel wrote:
Robert Bradshaw, 17.03.2011 05:05:
On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel wrote:
I'm actually leaning towards not guaranteeing the order of execution if C
doesn't do it either. If this
Greg Ewing, 18.03.2011 01:18:
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- the code in the finally clause would
be subject to the same nogil restrictions as the rest of
the nogil block.
My point is that as
mark florisson, 18.03.2011 10:52:
On 18 March 2011 07:07, Stefan Behnel wrote:
Greg Ewing, 18.03.2011 01:18:
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- the code in the finally clause would
be subject
Dag Sverre Seljebotn, 18.03.2011 12:07:
On 03/18/2011 11:10 AM, Stefan Behnel wrote:
Actually, I think I still find it more convenient to not provide *any*
special exception paths through nogil code, i.e. to not let exceptions in
"with gil" blocks exit from outer "nogil"
Stefan Behnel, 18.03.2011 13:36:
We shouldn't forget that basically all Python operations can at least raise
a MemoryError or a KeyboardInterrupt etc. Most users won't think of these
cases. I think it would help users in writing safer code if the need to
handle exceptions in nogil
Vitja Makarov, 21.03.2011 11:45:
Now error/warning messages are stored in global variables at
Cython.Compiler.Errors
Pyrex legacy. Even the visible warning level is a global variable
("LEVEL"). That's a very bad interface.
I think it's much better to move error handling into some object,
M
uido van Rossum, 22.03.2011 00:04:
On Mon, Mar 21, 2011 at 3:44 PM, "Martin v. Löwis" wrote:
Am 21.03.2011 11:58, schrieb Stefan Behnel:
Guido van Rossum, 21.03.2011 03:46:
Thanks for the clarifications. I now have a much better understanding
of what Cython is. But I'm not sold. For o
Stefan Behnel, 22.03.2011 07:10:
there seems to be quite some interest in a project to get parts of CPython
and specifically its stdlib rewritten in Cython.
[...] I gave it a try with difflib and it turned out to be quite easy.
http://blog.behnel.de/index.php?p=155
BTW, given how short that
Robert Bradshaw, 22.03.2011 08:14:
On Mon, Mar 21, 2011 at 11:10 PM, Stefan Behnel wrote:
there seems to be quite some interest in a project to get parts of CPython
and specifically its stdlib rewritten in Cython. [...]
In short, we have strong supporters, but Guido has understandable doubts
Robert Bradshaw, 23.03.2011 00:54:
On Tue, Mar 22, 2011 at 4:09 PM, Dan Stromberg wrote:
I think it's a good idea, but I think it'd be better to use pure mode to get
code that runs either way, or some sort of preprocessor (I've used m4 with
good luck for this, though it doesn't syntax highlight
Craig Citro, 23.03.2011 08:11:
We have a clear 1.0 goal, being able to compile the full Python
language. We're not there yet, but very close. It may make sense at
that point to also clean up any cruft we don't want to continue
supporting forever. I agree, until that point, there's no way we would
Vitja Makarov, 23.03.2011 17:25:
File "/home/vitja/tmp/cython-my-git/Cython/Compiler/Parsing.py",
line 2307, in p_c_arg_decl
if 'pxd' in s.level:
AttributeError: 'PyrexScanner' object has no attribute 'level'
Yes it does:
"""
# Cython/Plex/Scanners.pxd
cdef class Scanner:
[...]
Vitja Makarov, 23.03.2011 17:25:
def f():
return lambda x=0: x
f()()
Gives me this bogus code at function entry:
Py_ssize_t kw_args = PyDict_Size(__pyx_kwds);
PyObject* values[1] = {0};
values[0] = ((PyObject *)0); // <<< !!!
Looks like the default value is considered an
Vitja Makarov, 23.03.2011 20:11:
2011/3/23 Stefan Behnel:
Vitja Makarov, 23.03.2011 17:25:
File "/home/vitja/tmp/cython-my-git/Cython/Compiler/Parsing.py",
line 2307, in p_c_arg_decl
if 'pxd' in s.level:
AttributeError: 'PyrexScanner' object has no a
Stefan Behnel, 22.03.2011 08:59:
Robert Bradshaw, 22.03.2011 08:14:
On Mon, Mar 21, 2011 at 11:10 PM, Stefan Behnel wrote:
Reimplementing existing C modules in Cython might, however, be more
interesting for python-dev, but also be a larger undertaking. So a GSoC
might be worth running on that
Vitja Makarov, 24.03.2011 19:15:
2011/3/24 Stefan Behnel:
Vitja Makarov, 23.03.2011 20:11:
2011/3/23 Stefan Behnel:
Vitja Makarov, 23.03.2011 17:25:
File "/home/vitja/tmp/cython-my-git/Cython/Compiler/Parsing.py",
line 2307, in p_c_arg_decl
if 'pxd' in s.l
Robert Bradshaw, 24.03.2011 20:18:
On Thu, Mar 24, 2011 at 10:42 AM, Stefan Behnel wrote:
Stefan Behnel, 22.03.2011 08:59:
Robert Bradshaw, 22.03.2011 08:14:
On Mon, Mar 21, 2011 at 11:10 PM, Stefan Behnel wrote:
Reimplementing existing C modules in Cython might, however, be more
Robert Bradshaw, 24.03.2011 21:03:
On Thu, Mar 24, 2011 at 12:58 PM, Stefan Behnel wrote:
Robert Bradshaw, 24.03.2011 20:18:
Anyone else willing to
mentor? I haven't pushed on GSoC much this year yet because no one's
stepped up to mentor, but there's still ample time on our side
Sturla Molden, 25.03.2011 14:03:
Den 24.03.2011 20:38, skrev Robert Bradshaw:
I started a list at http://wiki.cython.org/Unsupported . I'd say we
can be as compatible as Jython/IronPython is, and more than CPython is
between minor versions. I would be happy with a short, well-justified
list of d
Robert Bradshaw, 29.03.2011 02:09:
I don't see re-implementing
working C modules written, though probably valuable from a maintenance
point of view, as compelling of a use case.
It would be rather helpful for CPython, though. Many stdlib modules lack
dedicated maintainers, and it's likely easi
Yunfan Jiang, 30.03.2011 05:33:
hi, i used to ask some string process question here, and found a bug, it
seems you guys fix the bug but not use it
Not sure what you mean by "not use it".
and this time , my problem is about the performance,
i need to wrote a filter which search sorts of key
Arthur de Souza Ribeiro, 29.03.2011 09:11:
Hello everybody,
My name is Arthur de Souza Ribeiro and I'm a fourth-year student of Computer
Science in Federal University of Campina Grande, Brazil. I'm a python
programmer and have knowledge of other languages too, like Java, C, C++, Qt,
Grails and A
Hi Arthur,
Arthur de Souza Ribeiro, 02.04.2011 03:52:
HI Stefan, thank you very much for responding my e-mail to cython's list.
About the proposal, I'd be very happy in helping the cython community doing
the task 'rewrite modules in CPython's standard library in Cython that are
currently writte
Dag Sverre Seljebotn, 04.04.2011 12:17:
CEP up at http://wiki.cython.org/enhancements/prange
"""
Variable handling
Rather than explicit declaration of shared/private variables we rely on
conventions:
* Thread-shared: Variables that are only read and not written in the
loop body are sha
Dag Sverre Seljebotn, 04.04.2011 13:53:
On 04/04/2011 01:23 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 04.04.2011 12:17:
CEP up at http://wiki.cython.org/enhancements/prange
"""
Variable handling
Rather than explicit declaration of shared/private variables we rely
mark florisson, 05.04.2011 10:26:
On 5 April 2011 09:21, Dag Sverre Seljebotn wrote:
Justification for Cython-specific syntax: This is something that is really
only useful if you can release the GIL *outside* of the loop. So I feel this
is an area where a custom Cython solution is natural, sort
mark florisson, 05.04.2011 10:44:
On 5 April 2011 10:34, Stefan Behnel wrote:
mark florisson, 05.04.2011 10:26:
On 5 April 2011 09:21, Dag Sverre Seljebotn wrote:
Justification for Cython-specific syntax: This is something that is
really
only useful if you can release the GIL *outside* of
mark florisson, 04.04.2011 21:26:
For clarity, I'll add an example:
def f(np.ndarray[double] x, double alpha):
cdef double s = 0
cdef double tmp = 2
cdef double other = 6.6
with nogil:
for i in prange(x.shape[0]):
# reading 'tmp' makes it firstprivate i
René Rex, 07.04.2011 09:12:
Agreed. Perhaps you could post the desired BibTeX citation text for
the official version and a link to the official version right next to
the preprint?
BibTeX entry for your convecience:
@article{bradshaw2010cython,
title={{CYTHON: THE BEST OF BOTH WORLDS}},
a
Dag Sverre Seljebotn, 07.04.2011 07:54:
On 04/07/2011 02:12 AM, Robert Bradshaw wrote:
On Wed, Apr 6, 2011 at 4:40 PM, Zak Stone wrote:
Researchers: Please consider citing this paper if Cython helps your
research in non-trivial ways.
Is this the canonical citation reference for Cython now? If
=OuterLinkColor,
menucolor=OuterLinkColor,urlcolor=OuterLinkColor,
citecolor=InnerLinkColor,
pdfauthor={Stefan Behnel, Robert Bradshaw, Craig Citro, Lisandro
Dalcin, Dag Sverre Seljebotn, Kurt Smith},
pdftitle={Cython: The best of both worlds},
pdfkeywords={Cython language, Cyt
Hi,
I just noticed that the CPython pyregr tests have jumped up from ~14
minutes for a run to ~4 hours when we added generator support.
https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-pyregr-py26-c/buildTimeTrend
I currently have no idea why that is (well
Stefan Behnel, 07.04.2011 13:46:
I just noticed that the CPython pyregr tests have jumped up from ~14
minutes for a run to ~4 hours when we added generator support.
https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-pyregr-py26-c/buildTimeTrend
I currently
[fixed up the citation order]
Romain, 07.04.2011 22:36:
2011/4/7 Carl Witty
On Thu, Apr 7, 2011 at 9:06 AM, Dag Sverre Seljebotn wrote:
This seems similar to Carl Witty's port of Cython to .NET/IronPython. An
important insight from that project is that Cython code does NOT specify
an
ABI, o
Robert Bradshaw, 08.04.2011 01:08:
On Thu, Apr 7, 2011 at 2:31 PM, Arthur de Souza Ribeiro wrote:
I've submitted to google the link
is:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/arthur_sr/1#
It would be really important if you could give me a feedback to my
proposal...
1 - 100 of 1422 matches
Mail list logo
