September 2016 - armedbear-devel - mailman3.common-lisp.net

disabling debugger in production
by Vibhu Mohindra 26 Apr '17

26 Apr '17

I'm bundling up a program for distribution to customers. I don't want it to ever enter the debugger. I want it to raise Java exceptions instead. What I've written to achieve this follows. I've observed it working. However, there are still times when my program enters the debugger. I can't tell why, and want to prevent it entirely. Does anybody know? Does anyone on this list distribute ABCL applications to end users, and how do you disable the debugger? /* disable the debugger. raise a RuntimeException instead */ static void installDebuggerHook() { Symbol.DEBUGGER_HOOK .setSymbolValue(new Function() { public LispObject execute(LispObject c, LispObject h) { throw translateCondition(c);}}); } static RuntimeException translateCondition(LispObject c) { return new RuntimeException( c instanceof Condition ? String.format("%s: %s", c.princToString(), ((Condition) c).getConditionReport()) : c.princToString()); } My program is really a Lisp library that people will use via a thin Java layer. I have a hunch that the above takes care of errors that occur in: interpreter.eval("...") but not errors that occur in: someSymbol.execute(...) Thanks in advance, Vibhu

1 2

Assorted patches
by Olof-Joachim Frahm 15 Oct '16

15 Oct '16

Hi list, attached are some patches (from [1]) that have been sitting around for a while; one is more of a work in progress, but it would still be great to know if it's at least going in the right direction. - 0001 Fixes an annoying issue I had where imported nested classes (with the dollar sign in their name) weren't found via JSS. - 0002 Adds the `external-only` option as seen in SBCL to `apropos`, because it's convenient. - 0005 Adds support for setting the `file-position` on `string-output-stream`s. Might be somewhat obscure, but I stumbled upon it in some situation. The next one could use some comments as well, but I consider it pretty well working: - 0003 Adds a hook and simple machinery to support multiple internal disassembler backends. At the moment I've added the ObjectWeb ASM one and kept the existing JAD call. Should this somehow add an ASDF system to support loading of those libraries via Maven? At the moment a user has to have the matching JARs in their classpath for it to work. Now the one that is not nearly done is 0004 which attempts to fix some of the issues with `jnew-runtime-class`, in particular working custom constructors. Now I've noticed that that's a *big* topic, so this is just a starting point. I'm deliberating ways of supporting a direct `super` call too, that includes fixing the supermethod calls that are still in the code. Let me know what you think, best regards, Olof [1]: https://github.com/Ferada/abcl/tree/patch-submissions

3 5

run-program patch / better UIOP support
by Olof-Joachim Frahm 07 Sep '16

07 Sep '16

Hi again, after Elias mentioned his work on UIOP I've produced a small patch that improves compatibility with regards to process spawning quite a bit, see attached (or from [1]). Missing is the option to pass in custom streams (which some other implementations support), as that's quite a bit more work with the `ProcessBuilder` interface and would require shuffling data back and forth in a separate thread perhaps. For Windows compatibility (for `process-pid`) I'm a bit stumped how that'd work with standard Java, thus it's currently unsupported. Best regards, Olof [1]: https://github.com/Ferada/abcl/tree/run-more-programs

2 1

IO bug
by Vibhu Mohindra 04 Sep '16

04 Sep '16

Hallo, I've got a file open for IO. Only writing to it works okay. But if I also try to read from it, then things start going wrong. I've attached a test case that should return NIL but instead raises an error in ABCL (1.3.3, on OSX). The problem is with the call to #'write-sequence on line 21. In fact, from some other tests, I believe that replacing that call to #'write-sequence with a call to a function that does the same thing but by repeatedly setting the file-position and writing a byte, for each byte in the sequence, fixes things. That means something about #'write-sequence is broken. Maybe I misunderstand the file level functions in Common Lisp, and my test doesn't use them correctly. However, the test passes in: CLISP, CCL, CMUCL, SBCL, ECL. So I thought I'd report this, just in case it is a bug in ABCL. Also, removing the last three lines of code in #'main, which read one byte, makes the test run without errors. Vibhu

3 6

Moved to github?
by Robert P. Goldman 03 Sep '16

03 Sep '16

I see that there are now active github repositories for ABCL. But the common-lisp.net homepage for ABCL still suggests that we get ABCL source from SVN. Should this be changed? thx, r

4 4