Re: [Cython] Welcome to cython-devel@python.org
Stefan Behnel writes: > Hi everyone, > > 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"? Kind regards Berthold Höllmann -- Germanischer Lloyd SE Berthold Höllmann Project Engineer, CAE Development Brooktorkai 18 20457 Hamburg Germany Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: berthold.hoellm...@gl-group.com Internet: http://www.gl-group.com This e-mail and any attachment thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as total or partial copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc. Germanischer Lloyd SE, 115442 AG HH, Hamburg, Vorstand: Erik van der Noordaa, Dr. Joachim Segatz, Pekka Paasivaara, Vorsitzender des Aufsichtsrats: Dr. Wolfgang Peiner ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Welcome to cython-devel@python.org
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 already requested an address change last week but didn't get a response over the weekend. It seems that it's not enough to copy over their subscription address. Maybe they ignore e-mails to that address that are not directed at the specific mailing list address they know. I hope it'll get fixed up soon. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
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 overlapping. The latter may be considered an application of a more general control flow graph. Here is funny picture made with graphviz ;) http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ Nice one. One thing it's missing is the implicit return at the end of a function body. This is something that's needed in order to figure out what the return value of a function is. It would also make the graphs more readable, as you'd actually see what happens after a statement with no outbound arrows. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
On 02/14/2011 08:40 AM, Vitja Makarov wrote: Hi! In order to implement "reaching definitions" algorithm. I'm now working on control-flow (or data-flow) graph. Here is funny picture made with graphviz ;) http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ Cool! This will be useful for so much more. Dag Sverre ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in NULL handling introduced 0.14.1-1
On Mon, Feb 14, 2011 at 1:50 AM, Greg Ewing wrote: > Chris Colbert wrote: > >> changing the include definition to: >> >> cdef extern from "Python.h": >> int PyObject_GenericSetAttr(PyObject*, PyObject*, PyObject*) except -1 >> > > This suggests another possible workaround: > > > cdef extern from "Python.h": >int PyObject_GenericDelAttr "PyObject_GenericSetAttr" (object, object, > PyObject*) > > This creates an alias for PyObject_GenericSetAttr with a different > signature, which you then call as > > Awesome, I didn't know you could do this. Thanks. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in NULL handling introduced 0.14.1-1
On Mon, Feb 14, 2011 at 1:49 AM, Greg Ewing wrote: > Chris Colbert wrote: > >> The problem with delattr (and thus PyObject_DelAttr) arises when you >> define a __delattr__ method on your class. There is not easy way to then >> call back into the "normal" python delattr semantics, except by doing >> object.__delattr__ (which is not optimized by Cython). >> > > Hmmm, perhaps it should be? And similarly for all the other type > slots. > > > I would argue that there should be at least some way to pass a NULL >> pointer in Cython where a PyObject* is expected. >> > > The trouble is that supporting this in general both safely and > efficiently would require keeping track of which object references > are allowed to be NULL. Could be done, but might require quite a > lot of work. > > Maybe something more limited could be done such as allowing > a literal NULL to be passed to a function argument that is > specially marked as permitting this. > > I had the same kind of thoughts. Perhaps something like: cdef extern from "Python.h": PyObject_GenericSetAttr(object, object, object or NULL) ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] yield...
On Sun, Feb 13, 2011 at 9:55 PM, Vitja Makarov wrote: > 2011/2/14 Dan Stromberg : > > > > On Sun, Feb 13, 2011 at 5:17 PM, Dan Stromberg > wrote: > >> > >> On Sun, Feb 6, 2011 at 3:38 AM, Vitja Makarov > >> wrote: > >>> > >>> 2011/2/6 Dan Stromberg : > >>> > > >>> > On Sat, Feb 5, 2011 at 3:10 PM, Vitja Makarov < > vitja.maka...@gmail.com> > >>> > wrote: > >>> >> > >>> >> 2011/2/6 Vitja Makarov : > >>> >> > 2011/2/6 Dan Stromberg : > >>> >> >> > >>> >> >> Just a quick note to let you know I'm very eager to have working > >>> >> >> generators > >>> >> >> (yield) in Cython... ^_^ It's frequently the main thing that > >>> >> >> complicates > >>> >> >> moving my critical sections to Cython. > >>> >> >> -- > >>> >> >> Dan Stromberg > >>> >> >> > >>> >> > > >>> >> > Ok, you will see generators soon in cython))) the most important > >>> >> > part > >>> >> > is already implemented, but I'm not sure that's the importetant > >>> >> > one;) > >>> >> > > >>> >> > >>> >> now you can use my github repo at https://github.com/vitek/cython > >>> > > >>> > Hey, that's great. > >>> > I tried a little test program with it, and it worked great. I'll > >>> > likely > >>> > give it a try with a more real-world workload before long. > >>> > Does it pass all the tests you've thrown at it yet? > >>> > Thanks! > >>> > > >>> > >>> Hmm now it work as excepted. If you will find a case when it doesn't > >>> work, report it. > >>> See also tests at tests/run/generators.pyx > >>> > >>> -- > >>> vitja. > >> > >> Do you want e-mail, or a formal bug tracking entry? > >> In case you want e-mail: > >> + /usr/local/cpython-2.5/bin/python /usr/local/cpython-2.5/bin/cython > >> rolling_checksum_pyx_mod.pyx > >> Error compiling Cython file: > >> > >> ... > >> import os > >> import sys > >> #mport comma_mod > >> def min_max_chunker(file_handle): > >> ^ > >> > >> rolling_checksum_pyx_mod.pyx:9:0: Compiler crash in MarkClosureVisitor > >> ModuleNode.body = StatListNode(rolling_checksum_pyx_mod.pyx:4:0) > >> StatListNode.stats[2] = StatListNode(rolling_checksum_pyx_mod.pyx:9:0) > >> StatListNode.stats[0] = DefNode(rolling_checksum_pyx_mod.pyx:9:0, > >> doc = u'Make sure chunk sizes are above and below a pair of > >> thresholds', > >> modifiers = [...]/0, > >> name = u'min_max_chunker', > >> num_required_args = 1, > >> reqd_kw_flags_cname = '0') > >> Compiler crash traceback from this point on: > >> File "Visitor.py", line 173, in > >> Cython.Compiler.Visitor.TreeVisitor._visitchild > >> (Cython/Compiler/Visitor.c:3508) > >> File > >> > "/usr/local/cpython-2.5/lib/python2.5/site-packages/Cython/Compiler/ParseTreeTransforms.py", > >> line 1380, in visit_FuncDefNode > >> for i, yield_expr in enumerate(collector.yields, 1): > >> TypeError: enumerate() takes exactly 1 argument (2 given) > >> make: *** [rcms] Error 1 > >> > >> > >> The code that produced this is > >> at http://stromberg.dnsalias.org/svn/backshift/trunk/ - with make > target > >> "rcms". It expects to find a variety of cpython's at > >> /usr/local/cpython-x.y/bin/python . > > > > > > Oh, and of course, to eliminate some details for you, here's the > > (automatically generated via m4) file that's giving the compiler error > > (attached). > > I suspect this issue may just be because a 2.x-ism (x>5) with how > enumerate > > is used has crept into cython. > > Thanks! > > > Hi! > > It seems that you have old python version, 2.4? > It's 2.5. > Here is a fix: > > https://github.com/vitek/cython/commit/bb8cd8275bf910117750356845814d4d9d998d6e Thanks, but... How do I apply this? I tried git pull and git clone, but neither worked for me. I know SVN pretty well, but I haven't used git much yet. -- Dan Stromberg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
Vitja Makarov wrote: Here is funny picture made with graphviz ;) http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ Gives the term "spaghetti code" a whole new meaning! -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
2011/2/15 Vitja Makarov : > 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 funny picture made with graphviz ;) >>> >>> http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ >> >> Cool. Any plans on handling exceptions? >> > Ooops forget to CC cython-devel... Sure, but I don't have much time for this :( Linear block inside try...except body should be split by assignments and each subblock should point to exception handling entry point. As result I want to have set of possible assignments for each NameNode position. So handling of uninitialized variables, unused, unused results should be easy, later it may help to implement local variable deletion. And guess that could help type inference. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
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 funny picture made with graphviz ;) >>> >>> http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ >> >> Cool. Any plans on handling exceptions? >> > > Sure, but I don't have much time for this :( > > Linear block inside try...except body should be split by assignments > and each subblock should point to exception handling entry point. Would every possible failing sub-expression have to point to the exception handling point(s)? I suppose it depends on whether you'll be handling more than assignment tracking. > As result I want to have set of possible assignments for each NameNode > position. > > So handling of uninitialized variables, unused, unused results should be easy, > later it may help to implement local variable deletion. And guess that > could help type inference. Ye. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
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 funny picture made with graphviz ;) http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ Cool. Any plans on handling exceptions? Sure, but I don't have much time for this :( Linear block inside try...except body should be split by assignments and each subblock should point to exception handling entry point. Would every possible failing sub-expression have to point to the exception handling point(s)? Well, in most cases (especially the interesting ones), this will be the function exit point, so it'll be easy. And in some cases, we may be able to infer that a specific exception that an expression (e.g. arithmetics or a 'raise' statement) can raise will not get caught by a given except clause (although that's certainly a tricky optimisation). But in general, I think any subexpression that potentially raises an exception must point to the next exception handling point. I suppose it depends on whether you'll be handling more than assignment tracking. We *may* get away with a statement-level graph in that case, but I somehow doubt it already. For example, list comprehensions leak their variable in Py2 code, so it's important to know if they are executed or not, and they may appear in any kind of expression. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
