Re: [Cython] Control flow graph
On 02/15/2011 08:21 AM, Robert Bradshaw wrote: 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. I'm thinking that transforming NameNode + various assignment/lookup nodes into "opcode nodes" such as SetLocalNode, GetLocalNode, SetGlobalNode, GetAttributeNode and so on would be a natural step to make such code cleaner. Then (after an isolated transform doing this) the logic would just need to act on individual nodes, not combination of nodes. Just an idea. Dag Sverre ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
2011/2/15 Stefan Behnel : > 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)? > Not sure here as now graph node is list of NameNode ref and AssignmentNode. I'm not sure but it seems that every sub-expression could raise exception now, is there any flag? > 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. > Right, and each exception handling point should have reference to the next one or function exit 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. > This should be special case for scoped expression node. Now I build graph "from scratch" it include only name node references and assignments, and positions marks to draw gv. May be node tree should be translated into graph and then local variables graph could be created from it. On the other hand CreateAbstractGraph transformation could be used to create specialized graph. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython builds on various Debian platforms
[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 supports ;) I don't really hope for major surprises, but it sure would be great to support those platforms. BTW, I assume the build results are publicly available somewhere? SURE! as for packages: ftp://ftp.debian.org/debian/pool/main/c/cython/ but more interesting -- logs http://packages.qa.debian.org/c/cython.html is the top page for 'Debian developer information' on cython (you might like to subscribe to the package tracking -- lower left corner). for builds across platforms go to the link "buildd: logs": https://buildd.debian.org/pkg.cgi?pkg=cython so 0.14.1-1 was already built ok across platforms seems to me ;) 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. I am a bit surprised that each platform compiles the Cython modules several times according to the logs. Is that intended? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Control flow graph
2011/2/15 Stefan Behnel : > 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. > Hmm... both python and codespeaks in the thread Here is my commit it's mostly broken now but anyway https://github.com/vitek/cython/commit/5579b23c3c1c06981331b6427a73e5cb19980b8a -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Fwd: Re: Cython builds on various Debian platforms
[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't include the test runs yet, but it would be really great if you could get those running. great to hear to be on the same page ;) the only additional concern I see is the duration -- it might torture build boxes for old/exotic architectures quite a bit... there are no timeouts (like with ctest platform -- got bitten by them a few times already) among your tests, aren't there? (just want to make sure) I am a bit surprised that each platform compiles the Cython modules several times according to the logs. Is that intended? should build once per each supported python version (currently 2.5 and 2.6) and for debug builds of those supported versions... looking into the log, indeed building seems to be invoked twice though -- I guess my fault with build/cython.1: build where build is a PHONY. I will look into it for the next upload: $> wget -O- -q https://buildd.debian.org/fetch.cgi\?pkg\=cython\;ver\=0.14.1-1\;arch\=hurd-i386\;stamp\=1297731063 | grep -B2 -A2 setup.py for buildver in 2.5 2.6; do \ cd /build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1 && cd . && \ python$buildver setup.py clean \ -a; \ done -- set -e; for buildver in 2.5 2.6; do \ cd /build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1 && cd . && \ python$buildver setup.py build \ --build-base="/build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1/./build"; \ done -- set -e; for buildver in 2.5 2.6; do \ cd /build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1 && cd . && \ python$buildver setup.py build \ --build-base="/build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1/./build"; \ done -- set -e; for buildver in 2.5 2.6; do \ cd /build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1 && cd . && \ python$buildver setup.py install \ --root="/build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1/debian/cython" \ --install-purelib=/usr/lib/python$buildver/site-packages/ \ -- dh_installdirs -pcython-dbg for i in 2.5 2.6; do \ python$i-dbg ./setup.py install --prefix=/usr --no-compile -O0 \ --root /build/buildd-cython_0.14.1-1-hurd-i386-fJZAFo/cython-0.14.1/debian/cython-dbg; \ done -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Fwd: Re: Cython builds on various Debian platforms
[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 that everything passes and all necessary dependencies are there. So, there is that failing one I have mentioned before: ,--- | == | FAIL: test_embed (__main__.EmbedTest) | -- | Traceback (most recent call last): | File "runtests.py", line 886, in test_embed | "make PYTHON='%s' LIBDIR1='%s' test > make.output" % (sys.executable, libdir)) == 0) | AssertionError `--- what could be done about it or should it be excluded? -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
