armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

difficulties building abcl 1.5 from source distribution
by Guenther Thomsen 11 Oct '17

11 Oct '17

So far I wasn't able to build abcl release 1.5 under Linux (Ubuntu 16.04.3 which comes at this time with ant 1.9.6 and openjdk 1.8.0_131) from the distributed source [1]. The (ant) build completes (reportedly) successful even though there are errors: --8<-- [java] ; (DEFMACRO DIAG ...) [java] ; (DECLAIM (FTYPE # ...)) [java] ; (DEFUN VERIFY-LOAD ...) [java] ;SYSTEM:%MAKE-CONDITION triggers autoloading of org.armedbear.lisp.make_condition ... [java] ; Autoloaded org.armedbear.lisp.make_condition (0.001 seconds) [java] 2.081 seconds real time [java] 6753524 cons cells [java] FORMAT-ERROR: error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] Maximum error depth exceeded (11 nested errors) with '#<FORMAT-ERROR {67090C23}>'. [java] CL-USER(2): abcl.compile: [echo] Compiled ABCL with Java version: 1.8.0_131 abcl.version.src.0: abcl.version.src.1: abcl.version.src.2: abcl.version.src.3: abcl.version.src: abcl.stamp.version.uptodate: abcl.stamp.version.generate: abcl.stamp.version.0: abcl.stamp.version.1: abcl.stamp.version.2: abcl.stamp.version: [echo] ABCL implementation version: 1.5.0 abcl.stamp.hostname: [echo] abcl.hostname: slab abcl.stamp: abcl.jar.uptodate: abcl.contrib: abcl-contrib.jar: abcl.jar: [jar] Building jar: /home/tho/Downloads/src/abcl-src-1.5.0/dist/abcl.jar abcl.wrapper.unix: abcl.wrapper.windows: abcl.wrapper: [copy] Copying 1 file to /home/tho/Downloads/src/abcl-src-1.5.0 [echo] Created executable ABCL wrapper in 'abcl' [echo] N.B. This wrapper requires '/home/tho/Downloads/src/abcl-src-1.5.0/dist/abcl.jar' not be moved. BUILD SUCCESSFUL -->8-- Then the executable cannot be run: --8<-- $ ./abcl Armed Bear Common Lisp 1.5.0 Java 1.8.0_131 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.173 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads-gen' in boot classpath. Failed to find loadable system file 'autoloads-gen' in boot classpath. Exception in thread "interpreter" org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) -->8-- Meanwhile I cloned the git repository and the HEAD as well as a branch off of commit 3e92245341ef07dd0915d1f7f59fa335626330db (release 1.5 [a tag would be nice, imho]) build and run successful, as far as I can tell. I noticed that the files in the zip archive are DOS formatted, which _shouldn't_ cause any such issue (making comparison with the files in the git repository a bit more cumbersome though). I haven't investigated further, as I got now a working abcl, but wanted to have mentioned it, as I couldn't find any hint regarding above error online. hth ~ Guenther [1] abcl-src-1.5.0.zip from https://common-lisp.net/project/armedbear/releases/1.5.0/abcl-src-1.5.0.zip

1 1

ASDF 3.3 is released
by Robert Goldman 07 Oct '17

07 Oct '17

Today we release ASDF 3.3. The most substantial change is to the build planning process, which has been reformed by François-René Rideau so that DEFSYSTEM-DEPENDS-ON now behaves correctly. There are a number of other improvements, and we are indebted to Daniel Kochmanski, Rommel Martinez, and Chun Tian for contributions. Thanks again to Anton Vodonosov and Dave Cooper for support in testing, and new thanks to Martti Halminen, Jens K. Loewe, and Jason Miller. I would like to dedicate this ASDF release to the late Elias Pipping. On a technical level, Elias made great improvements in some of the most challenging ASDF internals, notably the RUN-PROGRAM component of UIOP, a place where implementations are not constrained by the language specification, diverge radically from each other, and are poorly documented. On a personal level, Elias was very supportive to me as ASDF maintainer, and while I was going through an illness. He did all these things despite being gravely ill with the cancer that eventually killed him. He will be greatly missed, Z'chrono L'vracha. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.3.0 at their earliest convenience. The improvements offered in this release will substantially improved the reliability and predictability of ASDF use. Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Here is the changelog entry for 3.3: cl-asdf (2:3.3.0-1) unstable; urgency=low New milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. -- Robert P. Goldman <rpgoldman(a)sift.net> Sun, 20 August 2017 21:00:00 -0500

1 0

Compiler error during compile of TAGBODY and CATCH
by Paul Dietz 06 Oct '17

06 Oct '17

(compile nil '(lambda () (tagbody (catch 'c 17)))) ==> COMPILE-TAGBODY: tag not found: 17 [Condition of type SIMPLE-ERROR]

2 1

Compiler fail: Stack inconsistency detected in <unknown> at index 40: found 2, expected 0.
by Paul Dietz 06 Oct '17

06 Oct '17

(defparameter *abcl1* '(lambda (a) (declare (optimize (debug 0) (compilation-speed 1) (speed 2) (space 3) (safety 1))) (ash 0 (bit #*0100 (catch 'ct7 a))))) (defun test1 () (let ((fn (compile nil *abcl1*))) (mapcar fn '(0 1 2 3)))) (test1) ==> ; Caught ERROR: ; Stack inconsistency detected in <unknown> at index 40: found 2, expected 0.

2 1

It appears that ABCL is not ready for Java 9
by Gregory Baryza 28 Sep '17

28 Sep '17

I tried compiling it and was presented with the following error: .... [java] ; Loading C:/Downloads/Armed_Bear_Lisp/abcl-src-1.5.0/build/classes/org/armedbear/lisp/abcl-contrib.abcl ... [java] [java] ; Compilation unit finished [java] ; The following functions were used but not defined: [java] ; SYSTEM::SOURCE [java] [java] 311.988 seconds real time [java] 249904041 cons cells [java] JAVA-EXCEPTION: Java exception 'java.lang.NoSuchMethodException: No applicable method named getURLs found in java.lang.ClassLoader or jdk.internal.loader.ClassLoaders$AppClassLoader'. BUILD FAILED C:\Downloads\Armed_Bear_Lisp\abcl-src-1.5.0\build.xml:280: The following error occurred while executing this line: C:\Downloads\Armed_Bear_Lisp\abcl-src-1.5.0\build.xml:299: Java returned: -1 Total time: 6 minutes 11 seconds It compiled successfully under JDK_1_8_0_144. Has anyone else seen this?

4 6

Towards save-world for ABCL
by Alan Ruttenberg 14 Sep '17

14 Sep '17

A limiting factor in uptake and wider-scale use of ABCL, and java applications in general, has been startup time. Some native lisps have a save-world or save-image facility <https://stackoverflow.com/questions/39133421/how-to-properly-save-common-li…> that lets you create a snapshot of a running lisp which can then quickly resumed. I've long wanted something like this for ABCL - loading the system I work on (LSW <https://github.com/alanruttenberg/lsw2>) takes maybe 15 seconds on my reasonably fast laptop. This makes it annoying to run for short tasks, or to run in a pipe with non-lisp tooks. I also work with OWL ontologies that can take 10s of minutes to classify. I'd very much like to save that work so that I can fire off quick query, or reduce development time turnaround. Recently I've started to play with docker <https://www.docker.com/community-edition> and found that there is starting to be support for CRIU <https://github.com/xemul/criu>, which allows one to save the state of linux processes/containers and then restart them. I've just run a first successful test of this and I wanted to share the recipe, see if others have poked at this, see if there is interest in thinking about / implementing more transparent support for this for ABCL, and in case it is useful, as is, for someone. 1. You may need to install support for CRIU into docker. I had to do this with docker for mac <https://www.docker.com/docker-mac>, which is what I'm running. I think it's built into docker for linux, and am not sure about docker for windows. To install the mac support I followed instructions at https://hub.docker.com/r/boucher/criu-for-mac/ run: *docker run --rm -it --privileged --pid=host boucher/criu-for-mac* 2. Start a container that loads up ABCL and give it enough time to load (about 20 seconds in my case) *docker run -id lsw2/devel /home/lsw/repos/lsw2/bin/lsw* Note that the shell prompt returns immediately. There's no automatic way, at the moment, to see when the lisp has finished loading. In this case lsw2/lisp is my image built according to instructions at https://github.com/alanruttenberg/lsw2/tree/owlapiv4/virtual-machine /home/lsw/repos/lsw2/bin/lsw is the command that runs ABCL and loads my system inside the container. Replace these with your own, or use Mark Evenson's easye/abcl as an image to try (or use his Dockerfile <https://github.com/armedbear/abcl/blob/master/Dockerfile> as a base) . That image starts ABCL by itself, so you don't need to do it on the docker run command line as I do above. The -i switch hooks up stdin and the -d switch lets the container sit running in the background. Once ABCL is finished starting, the process in the container is effectively sitting at the repl prompt, waiting for input, but its stdin isn't connected to anything at the moment. Note that if you use the -t switch, as one commonly sees in docker examples, the checkpoint stage below will fail. 3. run: *docker ps* to get the Container ID for the container just created. 4. run: *docker checkpoint create <container-id> <checkpoint-name>* <container-id> is the id you just got from docker ps. <checkpoint-name> is a label you choose for the saved-state. On completion of the command the container stops running. 5. run: *docker start --checkpoint <checkpoint-name> <container-id>* After a much quicker startup(fraction of a second), the container is running again. You can interact with it by 6. run: *docker attach <container-id>* Hit return and you'll get the REPL prompt and can type something in to eval. Use control-d (EOF) to detach. You can reattach the same way again. Type (quit) to the repl, or run *docker kill <container-id>* to stop the container for good and exit. -- Obviously there is MUCH more that needs to be done to make this easy and practical, e.g. - packaging: While one can package up an image that a container can start from and easily serve it, the checkpoints are not easily attachable to images. Rather, they are specific to containers, and saving process state isn't couple with saving file-system state. That could be managed with some wrapper scripts that checkpoints on first run, etc. I'm also not sure of the mechanics of running several containers from the same checkpoint, at the same time. I'm guessing that sort of thing will be more directly supported in docker within a year or 2, if not sooner. - Doing this without docker: While using docker means that you can create an artifact that runs in all platforms, it may be easier to package up an application that will certainly run under linux to use CRIU directly. It may even be more practical to use CRIU inside the container instead of docker checkpoint. dunno. - reliability: I haven't run many tests yet to try to ensure that the checkpointed process doesn't have any problems - I've just tried simple things at the prompt. I haven't experimented with, e.g. running a web server inside ABCL and seeing if there are any issues with ports or network processes on restart. - restart hooks: some things may not be able to be saved. We'll need a provision for hooks that run when restarting and documentation about when they have to be used. Alan Ruttenberg

1 0

BUG: clhs limits adherence
by Peter Keller 10 Sep '17

10 Sep '17

Hello, I would like to report, well, a bug of sorts. Suppose we look at this in ABCL 1.5.0: CL-USER(1): (values call-arguments-limit lambda-parameters-limit multiple-values-limit (lisp-implementation-type)) 50 50 32 "Armed Bear Common Lisp" I claim that those limits are valid from the CLHS, but are not enforced, and hence not correct, in version 1.5.0 of ABCL. I did a cursory look through the ABCL sources and found that really only FORMAT actually checks (well, the appropriate ones anyway) these limits when processing the format string (IIUC). Here is a place where the limits should have been enforced: I tried these with (declaim (optimize (safety 3))) set. CL-USER(2): (list 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10) (1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10) CL-USER(3): Another example: CL-USER(3): (setf *foo* (loop for i below 1024 collect i)) <big correct list as output> CL-USER(4): (apply #'max *foo*) 1023 Another example: CL-USER(1): (defmacro defit (name size) (let ((ll (loop for i below size collect (make-symbol (format nil "V~A" i))))) `(defun ,name ,ll (list ,@ll)))) DEFIT CL-USER(2): (defit foo 1024) FOO CL-USER(3): (apply #'foo (loop for i below 1024 collect i)) <big correct list as output> Another example: (funcall #'values 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 ) <correct returned values> I believe that these worked when they should have failed. That is the, uh, bug, that I'm reporting. :) The only other legitimate option to believe is that I'm silently corrupting memory somewhere because I'm blowing unchecked limits... In looking at the code, all of the Primitives.java functions I sampled seemed to accept arbitrarily large numbers of arguments and handled this by allocating memory (as it should be). So, instead of fixing ABCL to actually honor those limits, which is a step backwards IMHO, I propose raising them to much larger values, like 2^32 or whatever true and real value they should have. Is there any reason why this can't be done? Like large allocated tables that I missed in the code, etc, etc, etc? Thank you! -pete

1 0

Hi, problem with building ABCL extension for MIT App Inventor
by Tomislav Tomšić 26 Aug '17

26 Aug '17

Greetings, currently I am building extension for AI, as indicated in title. It works for Scheme (JScheme and Kawa). It is quite a simply one, for now, I am only interested in evaluating simple symbolic expression, and then build on that, adding other features etc. However, I would also like to have access to Common Lisp, ergo ABCL. Here is a code for its respective method: @SimpleFunction(description = "ABCL evaluation") public String ABCLEvaluation(String expression) { // Environment.getInstance(true); // Interpreter abclInterpreter = Interpreter.createInstance(); // Interpreter.createInstance(); // LispObject evalResult = Interpreter.evaluate(expression); Interpreter interpreter = Interpreter.createInstance(); LispObject lo= interpreter.eval(expression); return lo.getStringValue(); } Commented code is there for completion sake, just as an indication that I tried everything I could find in documentation and examples. Nothing works. As you see, idea is a simple one, String is received, and then evaluated, except that in the case of ABCL it isn't. For JScheme and Kawa logic is precisely the same, environment/interpreter is initialized, expression is evaluated and then it returns the correct result. After playing with the various code combinations, there are always just two errors present in logs, so here they are: First one: W/System.err(20761): java.lang.NullPointerException: Attempt to invoke virtual method 'org.armedbear.lisp.LispObject org.armedbear.lisp.Interpreter.eval(java.lang.String)' on a null object reference W/System.err(20761): at lisp.tomislavt.ext.LispEvaluation.ABCLEvaluation(LispEvaluation.java:46) W/System.err(20761): at java.lang.reflect.Method.invoke(Native Method) W/System.err(20761): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(20761): at gnu.expr.PrimProcedure.apply(PrimProcedure.java:285) W/System.err(20761): at gnu.mapping.CallContext.runUntilDone(CallContext.java:234) W/System.err(20761): at gnu.mapping.CallContext.runUntilValue(CallContext.java:298) W/System.err(20761): at gnu.mapping.MethodProc.applyN(MethodProc.java:113) W/System.err(20761): at gnu.kawa.reflect.Invoke.applyN(Invoke.java:193) W/System.err(20761): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(20761): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(20761): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(20761): at com.google.youngandroid.runtime.callComponentMethod(runtime1661793284635134238.scm:879) W/System.err(20761): at appinventor.ai_test.AbclKawaTest.Screen1.Abcl$Click(Screen1.yail:68) W/System.err(20761): at appinventor.ai_test.AbclKawaTest.Screen1$frame.apply0(Screen1.yail:456) W/System.err(20761): at gnu.expr.ModuleBody.applyN(ModuleBody.java:226) W/System.err(20761): at gnu.expr.ModuleMethod.applyN(ModuleMethod.java:216) W/System.err(20761): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(20761): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(20761): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(20761): at appinventor.ai_test.AbclKawaTest.Screen1.dispatchEvent(Screen1.yail:10121) W/System.err(20761): at com.google.appinventor.components.runtime.EventDispatcher.delegateDispatchEvent(EventDispatcher.java:220) W/System.err(20761): at com.google.appinventor.components.runtime.EventDispatcher.dispatchEvent(EventDispatcher.java:198) W/System.err(20761): at com.google.appinventor.components.runtime.Button.Click(Button.java:51) W/System.err(20761): at com.google.appinventor.components.runtime.Button.click(Button.java:43) W/System.err(20761): at com.google.appinventor.components.runtime.ButtonBase.onClick(ButtonBase.java:656) W/System.err(20761): at android.view.View.performClick(View.java:4848) W/System.err(20761): at android.view.View$PerformClick.run(View.java:20262) W/System.err(20761): at android.os.Handler.handleCallback(Handler.java:815) W/System.err(20761): at android.os.Handler.dispatchMessage(Handler.java:104) W/System.err(20761): at android.os.Looper.loop(Looper.java:194) W/System.err(20761): at android.app.ActivityThread.main(ActivityThread.java:5631) W/System.err(20761): at java.lang.reflect.Method.invoke(Native Method) W/System.err(20761): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(20761): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959) W/System.err(20761): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754) I/RuntimeErrorAlert(20761): in alert Second one: W/System.err(26401): Unable to determine LISP_HOME. W/System.err(26401): Unable to determine LISP_HOME. W/System.err(26401): org.armedbear.lisp.IntegrityError W/System.err(26401): at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) W/System.err(26401): at org.armedbear.lisp.Primitive.execute(Primitive.java:113) W/System.err(26401): at org.armedbear.lisp.Symbol.execute(Symbol.java:803) W/System.err(26401): at org.armedbear.lisp.Lisp.error(Lisp.java:383) W/System.err(26401): at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) W/System.err(26401): at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) W/System.err(26401): at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) W/System.err(26401): at lisp.tomislavt.ext.LispEvaluation.ABCLEvaluation(LispEvaluation.java:48) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at gnu.expr.PrimProcedure.apply(PrimProcedure.java:285) W/System.err(26401): at gnu.mapping.CallContext.runUntilDone(CallContext.java:234) W/System.err(26401): at gnu.mapping.CallContext.runUntilValue(CallContext.java:298) W/System.err(26401): at gnu.mapping.MethodProc.applyN(MethodProc.java:113) W/System.err(26401): at gnu.kawa.reflect.Invoke.applyN(Invoke.java:193) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at com.google.youngandroid.runtime.callComponentMethod(runtime284371300273757224.scm:879) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.Abcl$Click(Screen1.yail:68) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1$frame.apply0(Screen1.yail:456) W/System.err(26401): at gnu.expr.ModuleBody.applyN(ModuleBody.java:226) W/System.err(26401): at gnu.expr.ModuleMethod.applyN(ModuleMethod.java:216) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.dispatchEvent(Screen1.yail:10121) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.delegateDispatchEvent(EventDispatcher.java:220) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.dispatchEvent(EventDispatcher.java:198) W/System.err(26401): at com.google.appinventor.components.runtime.Button.Click(Button.java:51) W/System.err(26401): at com.google.appinventor.components.runtime.Button.click(Button.java:43) W/System.err(26401): at com.google.appinventor.components.runtime.ButtonBase.onClick(ButtonBase.java:656) W/System.err(26401): at android.view.View.performClick(View.java:4848) W/System.err(26401): at android.view.View$PerformClick.run(View.java:20262) W/System.err(26401): at android.os.Handler.handleCallback(Handler.java:815) W/System.err(26401): at android.os.Handler.dispatchMessage(Handler.java:104) W/System.err(26401): at android.os.Looper.loop(Looper.java:194) W/System.err(26401): at android.app.ActivityThread.main(ActivityThread.java:5631) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959) W/System.err(26401): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754) I/System.out(26401): ERROR placeholder called with arguments: I/System.out(26401): Failed to find loadable system file 'boot.lisp' in boot classpath. I/System.out(26401): Failed to find loadable system file 'boot.lisp' in boot classpath. W/System.err(26401): org.armedbear.lisp.IntegrityError W/System.err(26401): at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) W/System.err(26401): at org.armedbear.lisp.Primitive.execute(Primitive.java:113) W/System.err(26401): at org.armedbear.lisp.Symbol.execute(Symbol.java:803) W/System.err(26401): at org.armedbear.lisp.Lisp.error(Lisp.java:383) W/System.err(26401): at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) W/System.err(26401): at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) W/System.err(26401): at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) W/System.err(26401): at lisp.tomislavt.ext.LispEvaluation.ABCLEvaluation(LispEvaluation.java:48) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at gnu.expr.PrimProcedure.apply(PrimProcedure.java:285) W/System.err(26401): at gnu.mapping.CallContext.runUntilDone(CallContext.java:234) W/System.err(26401): at gnu.mapping.CallContext.runUntilValue(CallContext.java:298) W/System.err(26401): at gnu.mapping.MethodProc.applyN(MethodProc.java:113) W/System.err(26401): at gnu.kawa.reflect.Invoke.applyN(Invoke.java:193) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at com.google.youngandroid.runtime.callComponentMethod(runtime284371300273757224.scm:879) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.Abcl$Click(Screen1.yail:68) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1$frame.apply0(Screen1.yail:456) W/System.err(26401): at gnu.expr.ModuleBody.applyN(ModuleBody.java:226) W/System.err(26401): at gnu.expr.ModuleMethod.applyN(ModuleMethod.java:216) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.dispatchEvent(Screen1.yail:10121) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.delegateDispatchEvent(EventDispatcher.java:220) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.dispatchEvent(EventDispatcher.java:198) W/System.err(26401): at com.google.appinventor.components.runtime.Button.Click(Button.java:51) W/System.err(26401): at com.google.appinventor.components.runtime.Button.click(Button.java:43) W/System.err(26401): at com.google.appinventor.components.runtime.ButtonBase.onClick(ButtonBase.java:656) W/System.err(26401): at android.view.View.performClick(View.java:4848) W/System.err(26401): at android.view.View$PerformClick.run(View.java:20262) W/System.err(26401): at android.os.Handler.handleCallback(Handler.java:815) W/System.err(26401): at android.os.Handler.dispatchMessage(Handler.java:104) W/System.err(26401): at android.os.Looper.loop(Looper.java:194) W/System.err(26401): at android.app.ActivityThread.main(ActivityThread.java:5631) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959) W/System.err(26401): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754) I hope that I am missing something obvious :), and I am thankful in advance for any input, advice or idea. Some additional clarification may be in order, MIT App Inventor is environment for rapid development of applications for Android (Arduino, Lego mindstorm etc.), hence it doesn't follow usual Android work-flow. Backbone of it is Kawa, components, extensions are written in Java, but more about it can be easily find on its webpage. First log example is fairly useless one imo, when i tested my extension with simple App, same expression was evaluated correctly in both Kawa and JScheme, so that String was not a null one, but I've put it here for completion sake. For the second one I've find something similar for version a.1 or 1.2, back in 2012, I believe, and it was something about dynamic linking during the build process. I am using ABCL 1.5 jar that I downloaded from the ABCL project page. In any case, I am bit at loss, and thus, I would appreciate any advice what should I try next. Thank you for your time. Respectfully, Tomislav Tomsic

2 1

ASDF Issue with compiler warnings on ABCL
by Robert Goldman 19 Aug '17

19 Aug '17

ASDF wraps its compilation process with WITH-COMPILATION-UNIT. On at least some implementations, this is necessary so that building doesn't emit spurious undefined function (variable, etc.) warnings. However, on ABCL, using WITH-COMPILATION-UNIT has the side effect of causing warnings to be intercepted and handled by HANDLE-WARNING. Then it seems that *resignal-compiler-warnings* is bound to NIL, and the compiler swallows them, instead of allowing them to flow down the stack to ASDF's handlers. In turn, this causes at least some of our regression tests to fail, because they check for expected warnings. This looks to me like a bug, but perhaps it's a feature ;-) Would you please explain and let us know how to handle this? thanks, r

2 2

Directory and wild pathnames.
by Mark Cox 24 Jul '17

24 Jul '17

G'day all, The following code signals an error in ABCL 1.5.0 on OS X 10.10.5. [1] CL-USER(1): (directory (merge-pathnames (make-pathname :directory '(:relative :wild)) (user-homedir-pathname))) #<THREAD "interpreter" {590C3415}>: 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). Any help would be appreciated. Thanks Mark Cox

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel