repyportability may not correctly expose some calls in Repy V2...

[choksi81]

The getresources() call is not correctly mapped into the namespace. All calls (except the Lind specific ones) should be mapped in.

[choksi81]

Author: mkaplan I wrote a simple shell script that attempts to run all of the unit tests through repyportability to get an idea of what's broken.

#!/bin/sh
tests=`ls | grep "ut_repyv2api" | grep "py$"`
for i in $tests ; do
  echo "\nTest:" $i
  python -c "import repyhelper; repyhelper.translate_and_import('$i')"
done

Based on the results, getresources() is not available, and file.close() does not work properly.

[choksi81]

Author: mkaplan ut_repyv2api_createlockblocks.py appears to fail because it accesses _context, the dictionary of available methods.

_context may need to be made available to the generated program. It is supposed to be accessible, based on repyportability line 158. However, because repyportability is imported with from repyportability import *, variables with a leading underscore are not accessible.

One possible method to fix this would be to set a dummy variable with the value from _context, and then copy it over to _context in the header of the autogenerated code.

[choksi81]

Author: mkaplan A (slightly nicer) approach is to add from repyportability import _context to the header.

However, this does not fix a second issue, that generated code for ut_repyv2api_createlockblocks.py fails with a KeyError on attempting to access _context["lock"]

[choksi81]

Author: mkaplan The following keys are missing from _context in repyportability: 'callfunc', 'timeout', 'thread', 'callargs'

[choksi81]

Author: justinc Replying to mkaplan:

ut_repyv2api_createlockblocks.py appears to fail because it accesses _context, the dictionary of available methods.

_context may need to be made available to the generated program. It is supposed to be accessible, based on repyportability line 158. However, because repyportability is imported with from repyportability import *, variables with a leading underscore are not accessible.

One possible method to fix this would be to set a dummy variable with the value from _context, and then copy it over to _context in the header of the autogenerated code.

Since it's Python, I'm sure there is a hack for this using introspection. For example, perhaps using the traceback module you can walk up the stack to get the caller's module definition. Then it's easy to place the _context variable in the right place.

(Obviously this will need to be explained well in comments.

[choksi81]

Author: mkaplan virtualnamespace-eval-broken.py appears to be broken on: Ubuntu 11.04: Python 2.6, 2.7.1 Windows 7 (x86): Python 2.5, 2.7.2

[choksi81]

Author: mkaplan Fixed in r5007.

[choksi81]

Author: sportzer The change:

safe._builtin_destroy = _do_nothing

breaks, among other things, dylinkrun.py. The reason for this is because safe._builtin_destroy() is responsible for calling _builtin_init(), which in turn is necessary for code executed by virtual namespaces to have access to built-in functions.

[choksi81]

Author: sportzer Fixed in r5037. I'm not aware of a better way of handling this, so repyportability just allows all built-ins to be used.