27 Mar 2013 18:41
Re: Re: RuleDispatch incompatible with python2.6
On Wed, Mar 27, 2013 at 1:21 AM, alexander smishlajev <alex@...> wrote: >Starting with python2.6, "as" is keywords of the language, and cannot be >used as ordinary identifier. The dispatch module cannot be imported: This is now fixed in SVN for both legacy PEAK and RuleDispatch - the tests for both now run fully on Python 2.7, at least for me on Windows. As you said in private email, your earlier email did not get through to the list; you might try resubscribing if you didn't get a bounce message or anything.
>
>
> There are bigger fish to fry - the AddOns package (which is a
> dependency) fails all its tests because PyPy doesn't support
> non-string keys in type dictionaries. DecoratorTools' test suite also
> fails, but AFAICT it's all due to changes in repr() of various
> built-in types (unless PyPy doesn't support classic classes), and
> should be shallow. AddOns, however, is quite heavily used by
> PEAK-Rules.
>
> An important BytecodeAssembler test also fails: PyPy has a
> slightly-incompatible bytecode interpreter, and PEAK-Rules abuses a
> weak link in CPython's bytecode to implement a "computed goto"
> operation in generated bytecode. My guess is that the UnboundLocal
> errors are being caused by how PyPy handles (or more precisely,
> doesn't handle) the computed goto.
>
> The specific issue is this: in CPython, the END_FINALLY bytecode takes
> a "why" value on top of the stack, plus an extra value as a jump
> offset. PyPy, however, wants one value on the stack: a special
> interpreter-owned value (that's AFAICT can't be created directly in
> Python) that wraps the reason and the jump offset together.
>
> Unless there's some way to create these special SContinueLoop objects
> from Python (and I'm guessing there's not), I'd have to write a
> replacement code generator for PyPy that uses a linear search instead
> -- which ironically may make PyPy's predicate dispatch slower than
> CPython's in some cases, unless the JIT can optimize it out enough.
>
> [pause for some hacking]
>
> After hacking around a bit, I have a quick and dirty patch (attached)
> that makes most of the tests pass, by fixing up the __builtins__, and
> handling the END_FINALLY issue by using a linear search in the
> innermost dispatch loops. It isn't suitable for release at the
> moment, because it doesn't check for whether it's running under PyPy,
> and there are still some tests that fail due to shallow minor issues
> like the PyPy repr() differences and hash iteration differences. Let
> me know if it works for you, and maybe I'll clean it up for release.
I tested today several applications with predicates dispatch rules, for
web stuffs and complex business workflows and they all ran fine, without
any problem (I didn't yet benchmark them). That's really great, thanks.
Now I can only hope for an official release ;)
> Technically, AddOns and BytecodeAssembler need some fixes too, but the
> parts of them that don't work the same under PyPy don't actually get
> used by PEAK-Rules, at least not in the test suite.
Best regards,
Alain
).
Any ideas about where i could be going wrong?
Looking forward to hearing from you
Athanasios Anastasiou
RSS Feed