July 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

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

#'directory likely bug
by Vibhu Mohindra 01 Jul '16

01 Jul '16

In a directory containing files and directories, (directory (make-pathname :directory '(:relative :wild))) lists only the directories, in CCL, SBCL, CLISP, ECL, but in ABCL (1.3.2) produces this error: #<THREAD "interpreter" {71225B71}>: Debugger invoked on condition of type TYPE-ERROR The value NIL is not of type (OR PATHNAME STRING FILE-STREAM SYSTEM:JAR-STREAM SYSTEM:URL-STREAM). This is triggered by the existence of a file in OSX named ./.android/adbkey , or in general by the existence of: $ mkdir .d1 $ touch .d1/f1 [CMUCL seems wrong. It lists contents of subdirectories of current directory (but not their subdirectories).] Vibhu

1 0