On Wed, Jan 5, 2011 at 3:02 PM, Martin Hepperle Martin.Hepperle@mh-aerotools.de wrote:

Hello all,

hope you had  good start into 2011.

ABCL via JSR-223 is almost perfect now, but I have two things which do not work perfectly:

Hello,

thanks for reporting! Comments follow.

A) How to handle path names with spaces?

When my Java application is installed in a path with spaces (which should be no problem nowadays in 2011), I receive the following error when the ABCL engine is created:

ERROR placeholder called with arguments: #<ERROR {590510}> "Failed to find loadable system file in boot classpath 'jar:file:/D:/Programme/MH%20AeroTools/PROPPY/bin/languages/abcl.jar!/org/armedbear/lisp/boot.lisp'"

The spaces have been encoded by "%20", but obviously ABCL does not understand this boot path.

I'm not sure this is related to JSR-223 specifically; which version of ABCL are you using? I recall there have been problems with paths and spaces a while ago, but IIRC those should be fixed now.

B) How to redirect I/O of the script engine? If I want to use a scripting engine in my application, the user may make mistakes. OK. For this purpose I have to

1. catch errors in Java, which works by placing the following two lines into

"abcl-script-config.lisp" (in-package :abcl-script) (setq *use-throwing-debugger* nil)

Actually, this does the exact opposite: it uses the standard ABCL debugger that handles errors in Lisp and falls back to the REPL if no restart is invoked programmatically. The throwing debugger is active by default and wraps all unhandled Lisp conditions in Java exceptions that are thrown to the caller of JSR-223 methods.

2. catch standard error and standatd output.  While JSR provides an

interface for this vi "setWriter" and "setErrorWriter", I discovered that most JSR-223 engines do not implement this correctly. So I resorted to redirect the system streams via "System.setOut" and "System.setErr", which worked for all JSR-223 implementations so far ... except ABCL.  I always reveive error mesages, as well as the initialization message (...ABCL: configured ) on standard output, possibly bypassing the system streams?

The initialization messages have been suppressed on trunk; they were basically debug information that has no place in a production release. As for redirecting I/O, you need to use setWriter and setErrorWriter because ABCL wraps System.in and System.out at some point during startup and keeps a reference to those streams, so if you change them later ABCL won't be affected. Another option is to call System.setOut before initializing ABCL.

Hope this helps.

Best regards, Alessio