dylink (see code, docs) includes functionality that should help to make "old" code dynamically linkable. This means code that uses the deprecated Repy preprocessorinclude syntax and/or print statements (which are disallowed in RepyV2 and must be supplanted by calls to log).
The helper functions, _replace_include and _replace_print aren't all that helpful however, and crash on a number of opportunities. Here are a few triggers I found:
Fail (include on first line of source file, not found by dylink's _replace_include and thus virtual_namespace trips with syntax violation):
include foo.repy
Workaround:
# Add a first line to the source file. Even "\n" only is fine.
include foo.repy
Fail (_replace_include treats whatever follows "include " as the filename, resulting in filenames with invalid characters here; variations with whitespace / comments after the filename crash too)
include foo.repy
Fail (_replace_print detects "print >>" in comments and complains it can't turn redirected prints it into calls to log)
# print >>
Fail (_replace_print includes everything that follows "print " in log's arguments, including comments) --- ''was this meant in #1339?''
print "Hello world" # Comment of Death
The workarounds are pretty obvious (avoid the problematic idioms!). IMHO dylink need not try to fix code that's not valid RepyV2. include and print will raise errors during code safety checking, and the user should fix them correctly (rather than us fixing dylink to work in corner cases).
Also, we do not use the include syntax or print anymore. Let's get rid of the _replace_* functions, and make sure that our libraries don't rely on them.)
dylink(see code, docs) includes functionality that should help to make "old" code dynamically linkable. This means code that uses the deprecated Repy preprocessorincludesyntax and/orprintstatements (which are disallowed in RepyV2 and must be supplanted by calls tolog).The helper functions,
_replace_includeand_replace_printaren't all that helpful however, and crash on a number of opportunities. Here are a few triggers I found:Fail (
includeon first line of source file, not found bydylink's_replace_includeand thusvirtual_namespacetrips with syntax violation):Workaround:
Fail (
_replace_includetreats whatever follows"include "as the filename, resulting in filenames with invalid characters here; variations with whitespace / comments after the filename crash too)Fail (
_replace_printdetects "print >>" in comments and complains it can't turn redirectedprints it into calls tolog)Fail (
_replace_printincludes everything that follows "print " in log's arguments, including comments) --- ''was this meant in #1339?''The workarounds are pretty obvious (avoid the problematic idioms!). IMHO
dylinkneed not try to fix code that's not valid RepyV2.includeandprintwill raise errors during code safety checking, and the user should fix them correctly (rather than us fixingdylinkto work in corner cases).Also, we do not use the
includesyntax orprintanymore. Let's get rid of the_replace_*functions, and make sure that our libraries don't rely on them.)