dylink's module cache doesn't work under repyportability

[aaaaalbert]

dylink caches modules that have already been imported in (the same or another) source file so that ciruclar imports don't become a problem, see SeattleTestbed/seattlelib_v2#127. This works as expected when running Repy, but fails under repyportability.
Here's a test case that shows what happens. (I'll make a unit test out of it too). testlib1 just defines an error class, which is imported and raised in a function of testlib2, which in turn is called by the main program, where we try to catch that exception.

# This is testlib1.r2py
class Lib1Error(Exception):
  """The exception we are trying to catch."""

##################################
# This is testlib2.r2py
lib1 = dy_import_module("testlib1.r2py")

def raise_lib1error():
  raise lib1.Lib1Error

################################
# This is the main program
lib1 = dy_import_module("testlib1.r2py") # defines the exception
lib2 = dy_import_module("testlib2.r2py") # raises it

try:
  lib2.raise_lib1error()
except lib1.Lib1Error:
  # Branch taken in Rep
  log("Could catch!\n")
except Exception, e:
  # Branch taken under Repyportability
  log("Nargh, caught", repr(e), "and not", repr(lib1.Lib1Error()))

To check the repyportability behavior, add this to the main program:

from repyportability import *
add_dy_support(locals())

The issue is related to #27 and possibly Seattle's #1422, SeattleTestbed/seattlelib_v2#125, SeattleTestbed/repy_v2#22 (why's that a RepyV2 issue btw?), and SeattleTestbed/repy_v2#55.

[JustinCappos]

We seem to have a bunch of problems with dylink. Someone needs to clean
up this module...

On Fri, Jun 20, 2014 at 5:44 AM, aaaaalbert [email protected]
wrote:

dylink caches modules that have already been imported in (the same or
another) source file so that ciruclar imports don't become a problem, see
SeattleTestbed/seattlelib_v2#127
SeattleTestbed/seattlelib_v2#127. This works
as expected when running Repy, but fails under repyportability.

Here's a test case that shows what happens. (I'll make a unit test out of
it too). testlib1 just defines an error class, which is imported and
raised in a function of testlib2, which in turn is called by the main
program, where we try to catch that exception.

This is testlib1.r2py

class Lib1Error(Exception):
"""The exception we are trying to catch."""

##################################

This is testlib2.r2py

lib1 = dy_import_module("testlib1.r2py")

def raise_lib1error():
raise lib1.Lib1Error

################################

This is the main program

lib1 = dy_import_module("testlib1.r2py") # defines the exception
lib2 = dy_import_module("testlib2.r2py") # raises it

try:
lib2.raise_lib1error()
except lib1.Lib1Error:

Branch taken in Rep

log("Could catch!\n")
except Exception, e:

Branch taken under Repyportability

log("Nargh, caught", repr(e), "and not", repr(lib1.Lib1Error()))

To check the repyportability behavior, add this to the main program:

from repyportability import *
add_dy_support(locals())

The issue is related to #27
#27 and possibly
Seattle's #1422, SeattleTestbed/seattlelib_v2#125
SeattleTestbed/seattlelib_v2#125,
SeattleTestbed/repy_v2#22
SeattleTestbed/repy_v2#22 (why's a RepyV2
issue btw?), and SeattleTestbed/repy_v2#55
SeattleTestbed/repy_v2#55.

—
Reply to this email directly or view it on GitHub
#28.

[aaaaalbert]

Two unit tests are available to check the behavior of the module cache now:

• SeattleTestbed/seattlelib_v2@8ae85a4 has a Repy version of the test, and shows the correct behavior (the imported exception can be caught)
• 61fd57e adds repyportability to the RepyV2 test, and exhibits the problem described above