June 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

ABCL and Truffle
by Alessio Stalla 24 Jun '16

24 Jun '16

Hi list, is anyone aware of Truffle/Graal from Oracle? Here some insightful slides: https://lafo.ssw.uni-linz.ac.at/pub/papers/2016_PLDI_Truffle.pdf Since there's been talk about rewriting the ABCL compiler which is old, messy and not very optimizing, I wonder if Truffle can be a useful technology to base a new compiler on. Not as the default because it requires Java 9 (or perhaps 8), but at least as a future-proof solution. It seems to me that getting started is not hard - just map the Lisp S-expression based AST to a Truffle AST; optimizations can follow incrementally. What do you think? I don't have the resources to work on it anytime soon, I'm letting my own projects slip sadly - it would be great to work on it. Still, maybe someone else is interested. I can contribute some design and code reviews, if need be, but little actual coding. Peace Alessio

2 1

#'asdf-jar:add-to-asdf use-jar-fasls is ineffective
by Vibhu Mohindra 24 Jun '16

24 Jun '16

Hi, I've got #'asdf-jar:package to create a jar file containing lisp sources and fasls. With abcl-1.0.1, (asdf:operate 'asdf:load-op ...) uses the fasls from the jar, whereas with abcl-1.1.0 onwards those fasls are ignored and the jarred sources are compiled into ~/.cache/... again. Is this a bug, or is it a feature (as easyE seems to think it is, in the last two sentences at: http://stackoverflow.com/questions/4763910/abcl-compilation-and-primitives )? If it's a bug, here is how far I've got in my diagnosis. (asdf-jar:add-to-asdf "wispym.jar") shows this in abcl-1.0.1 ((#P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*" T) (#P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*" #P"jar:file:/Users/vibhu/t3/wispym-all.jar!/**/*.*") (#P"/Users/vibhu/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/vibhu/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<TRANSLATE-JAR-PATHNAME {2B63F8AD}>) (T #P"/Users/vibhu/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86/**/*.*")) but this in abcl-1.3.2, ((#P"/**/*.*" T) (#P"/**/*.*" #P"/**/*.*") (#P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<TRANSLATE-JAR-PATHNAME {4F340027}>) (T #P"/Users/vibhu/.cache/common-lisp/abcl-1.3.2-fasl42-macosx-x64/**/*.*")) I think these are asdf output-translations, each specifying a source directory and a corresponding destination directory. The first two entries are significantly different between abcl-1.0.1 and abcl-1.3.2. ---- The reason I'd like to use the jarred fasls is that I'm distributing my program to customers. I don't want to spew fasls around their hard disks. I also don't want to get into having to explain to them to clear caches. (I do have to do this locally on occasion, e.g. when timestamps on files confuse the cache). But most importantly, I've got a large cl-yacc grammar that takes ages to macroexpand and compile. I don't want them to wait so long even though it's just on the first load. ---- Any tips for where I should look next will be much appreciated. ASDF, ABCL, ABCL contrib? Thanks for reading. Vibhu

2 2

merge-pathnames bug with :back component
by Vibhu Mohindra 15 Jun '16

15 Jun '16

CLHS for merge-pathnames specifies that, "This removal of redundant :back keywords is repeated as many times as possible." abcl-1.3.2 The first expression below evaluates correctly, but the second produces an error. FCFS(34): (merge-pathnames (make-pathname :directory '(:relative "a" "b" :back)) (make-pathname :directory '(:absolute "root"))) #P"/root/a/" FCFS(35): (merge-pathnames (make-pathname :directory '(:relative "a" "b" :back :back)) (make-pathname :directory '(:absolute "root"))) #<THREAD "interpreter" {43B4AF3C}>: Debugger invoked on condition of type FILE-ERROR Unsupported directory component BACK. Restarts: 0: TOP-LEVEL Return to top level. For what it's worth, CCL also produces an error. CLISP, ECL, SBCL correctly produce: #P"/root/" (That said, I'm far from a pathname expert and could be completely wrong.) Vibhu

2 1

publish system::expand-deftype ?
by Massimiliano Ghilardi 13 Jun '16

13 Jun '16

Hello, for my library https://github.com/cosmos72/cl-parametric-types I need the function introspect-environment:typexpand, which expands DEFTYPE'd types, similarly to what CL:MACROEXPAND does for macros. Even though introspect-environment does not support ABCL, I found that system::expand-deftype does exactly what I need, yet I am wary of using a non-exported symbol from ABCL. Is system::expand-deftype stable enough to be published as an ABCL extension to ANSI CL and to be used to implement introspect-environment:typexpand ? Regards, Massimiliano

2 1

function documentation patch
by Alan Ruttenberg 01 Jun '16

01 Jun '16

When a function object is given to describe function documentation is not shown (it's shown on the symbol). Because of this, the slime function documentation doesn't show it either. Index: src/org/armedbear/lisp/describe.lisp =================================================================== --- src/org/armedbear/lisp/describe.lisp (revision 14850) +++ src/org/armedbear/lisp/describe.lisp (working copy) @@ -89,7 +89,13 @@ (setf plist (cddr plist)))))) (FUNCTION (%describe-object object stream) - (describe-arglist object stream)) + (describe-arglist object stream) + (let ((function-symbol (nth-value 2 (function-lambda-expression object)))) + (when function-symbol + (let ((doc (documentation function-symbol 'function))) + (when doc + (format stream "Function documentation:~% ~A~%" doc))) + ))) (INTEGER (%describe-object object stream) (format stream "~D.~%~

2 2