armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] Package-local nicknames landed
by Rudolf Schlatte 01 Mar '13

01 Mar '13

Hi, I just committed support for package-local nicknames in abcl. This follows the lead of sbcl and lets you introduce short, meaningful nicknames ("XML" for "COM.WHATEVER.FOO.XML-PARSER") in your own packages without fear of package (nick)name collisions. Here's the example from Nikodemus' documentation: (defpackage :bar (:intern "X")) (defpackage :foo (:intern "X")) (defpackage :quux (:use :cl) (:local-nicknames (:bar :foo) (:foo :bar))) (find-symbol "X" :foo) ; => FOO::X (find-symbol "X" :bar) ; => BAR::X (let ((*package* (find-package :quux))) (find-symbol "X" :foo)) ; => BAR::X (let ((*package* (find-package :quux))) (find-symbol "X" :bar)) ; => FOO::X This puts :package-local-nicknames on *features*; I had to increase the fasl version since %defpackage got a new parameter. Cheers, Rudi

2 1

[armedbear-devel] strange interaction between ql:quickload and ABCL
by Anton Vodonosov 28 Feb '13

28 Feb '13

Hello. I have very strange behaviour of ql:quickload that I observer only on ABCL. It happens when I run (ql:quickload :modf). Precondition: the system :modf is NOT installed into quicklisp. > java -jar abcl.jar --noinit --nosystem Armed Bear Common Lisp 1.1.0 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.945 seconds. Startup completed in 4.8 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "C:\\Users\\anton\\quicklisp\\setup.lisp") T CL-USER(2): (ql:quickload :modf) Error loading C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128-darcs/closer-mop.asd at line 43 (offset 1649) #<THREAD "interpreter" {40773F4B}>: Debugger invoked on condition of type LOAD-SYSTEM-DEFINITION-ERROR Error while trying to load definition for system closer-mop from pathname C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128 -darcs/closer-mop.asd: Unrecognized keyword argument ("closer-mop-packages" "closer-mop-shared") Restarts: 0: REINITIALIZE-SOURCE-REGISTRY-AND-RETRY Retry finding system closer-mop after reinitializing the source-registry. 1: ABORT Give up on "modf" 2: TOP-LEVEL Return to top level. [1] ASDF0(3): As you see it is trying to load closer-mop. Why? If :modf ASDF is not available, quicklisp should not load anything other systems yet. Moreover, modf.asd has :depends-on (:alexandria #-abcl :closer-mop :iterate) So on ABCL it does not depend on closer-mop. I got backtrace using this command: [1] ASDF0(3): (with-open-file (stream "C:\\Users\\anton\\unpacked\\abcl\\abcl-bin-1.1.0\\backtrace.txt" :direction :output :if-exists :supersede :if-does-not-exist :create) (let ((*debug-io* stream)) (top-level::backtrace-command "10000"))) The resulting file is here: https://dl.dropbox.com/u/5708042/backtrace.txt. @abcl dvelopers: this backtrace seem to contain not only the current invocation stack, but also previous calls, already finished. For example the (LOAD "C:\\Users\\anton\\quicklisp\\setup.lisp") at the very bottom of the file. Do I retrieve backtrace incorrectly? Back to the ql:quickload problem. I know that if I install :modf with CCL, this problem doesn't happen anymore, and ABCL can load it. Zach, how it works? Best regards, - Anton

3 5

[armedbear-devel] encoding issues with ABCL
by Faré 26 Feb '13

26 Feb '13

Dear ABCL developers, it looks like ABCL is not doing the Right Thing with respect to LOAD's :EXTERNAL-FORMAT argument, instead reading everything with some dubious default from the environment. Can you fix it? For instance, in Robert Golman's test below, the file is read as MacRoman. Please check COMPILE-FILE too in case it has the same bug. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Men have a much better time of it than women; for one thing they marry later; for another thing they die earlier. — H.L. Mencken ---------- Forwarded message ---------- From: Robert Goldman <rpgoldman(a)sift.info> Date: Mon, Feb 25, 2013 at 4:15 PM Subject: Re: [asdf-devel] Test results on Mac OSX To: Faré <fahree(a)gmail.com> Cc: ASDF-devel <asdf-devel(a)common-lisp.net> On 2/25/13 Feb 25 -10:34 AM, Faré wrote: >> But when I look for "should be" in my test output file, it is many lines >> away from the failure message. >> > That's autoloading for you. > > Can you trace LOAD* COMPILE-FILE* and/or COMPILE-FILE LOAD > and check that indeed :EXTERNAL-FORMAT :UTF-8 is used? > > If it isn't, then it's a bug in our code or test > (Note: considering the portable nature of the code, > and the fact that it works for me, that is unlikely.) > > If it is, then it's time to file a bug against ABCL. > (Note: considering that I already had to disable most of the test > for ABCL, that is very likely.) > > rlwrap abcl > (load "test/script-support.lisp") (da) (la) (trace load compile-file > load* compile-file*) (load "test/test-encodings.script") Done. I'm afraid the results are Greek to me. Or would be if I could get ABCL to print non-ASCII! ;-) ASDF-TEST(7): (load "test-encodings.script") 0: (LOAD "test-encodings.script") ; Loading /Users/rpg/lisp/asdf/test/test-encodings.script ... Test TEST-ENCODING-EXPLICIT-U8: should be UTF-8 ; Registering #<ASDF/SYSTEM:SYSTEM "test-encoding-explicit-u8"> 1: (ASDF/LISP-BUILD:LOAD* #P"/Users/rpg/lisp/asdf/test/lambda.lisp" :EXTERNAL-FORMAT :UTF-8) 2: (LOAD #P"/Users/rpg/lisp/asdf/test/lambda.lisp" :EXTERNAL-FORMAT :UTF-8) ; Loading /Users/rpg/lisp/asdf/test/lambda.lisp ... ; Loaded /Users/rpg/lisp/asdf/test/lambda.lisp (0.0020 seconds) 2: LOAD returned T 1: LOAD* returned T Error loading /Users/rpg/lisp/asdf/test/test-encodings.script at line 43 (offset 1675) #<THREAD "interpreter" {9C2DF08}>: Debugger invoked on condition of type SIMPLE-ERROR On sub-test Encoding test EXPLICIT-U8. These two expressions fail comparison with EQUAL: (ASDF-TEST::STRING-CHAR-CODES "λ") evaluates to (338 170) (ASDF-TEST::EXPECTED-CHAR-CODES (QUOTE :UTF-8)) evaluates to (955) Best, r

2 5

Re: [armedbear-devel] How can I build ABCL 1.1.1 without recording the absolute path of the source ?
by Mark Evenson 25 Feb '13

25 Feb '13

JDK 7 before 1.7.0_04 had some funkiness with loading things, which I never fully investigated. Please try to update to 1.7.0_15 to see if you have the same problems. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad idea? A: Top-posting. Q: What is the most annoying thing in email? On Feb 23, 2013, at 8:39 AM, Xiaofeng Yang <n.akr.akiiya(a)gmail.com> wrote: > Thanks in advanced, Mark. Now it works for some symbols (e.g. DISASSEMBLE). > > But, every time I performed this on all symbols, it threw exceptions and crashed. > > D:\mefcl-0.2\abcl>java -jar dist\abcl.jar org.armedbear.lisp.Main --load "mefcl-init.lisp" > Armed Bear Common Lisp 1.1.1 > Java 1.7.0_02 Oracle Corporation > Java HotSpot(TM) Client VM > Low-level initialization completed in 0.305 seconds. > Startup completed in 4.078 seconds. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/quicklisp/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/mvn/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jss/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jfli/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-install/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. > Unable to autoload CLASS-DIRECT-SLOTS > Exception in thread "interpreter" org.armedbear.lisp.IntegrityError > at org.armedbear.lisp.Autoload.load(Autoload.java:156) > at org.armedbear.lisp.Autoload$pf_resolve.execute(Autoload.java:339) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:553) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_when.execute(Primitives.java:844) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:154) > at org.armedbear.lisp.LispThread.execute(LispThread.java:653) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:560) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:824) > at org.armedbear.lisp.Primitives$sf_tagbody.execute(Primitives.java:3684) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:148) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Primitives$pf_mapc.execute(Primitives.java:2961) > at org.armedbear.lisp.LispThread.execute(LispThread.java:653) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:560) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:148) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:553) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.SpecialOperators._flet(SpecialOperators.java:362) > at org.armedbear.lisp.SpecialOperators$sf_flet.execute(SpecialOperators.java:290) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Closure.execute(Closure.java:220) > at org.armedbear.lisp.Closure.execute(Closure.java:148) > at org.armedbear.lisp.LispThread.execute(LispThread.java:640) > at org.armedbear.lisp.Primitives$pf_mapc.execute(Primitives.java:2961) > at org.armedbear.lisp.LispThread.execute(LispThread.java:653) > at org.armedbear.lisp.Lisp.evalCall(Lisp.java:560) > at org.armedbear.lisp.Lisp.eval(Lisp.java:518) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.SpecialOperators._flet(SpecialOperators.java:362) > at org.armedbear.lisp.SpecialOperators$sf_flet.execute(SpecialOperators.java:290) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3737) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Lisp.eval(Lisp.java:511) > at org.armedbear.lisp.Lisp.eval(Lisp.java:516) > at org.armedbear.lisp.Lisp.progn(Lisp.java:687) > at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169) > at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101) > at org.armedbear.lisp.Lisp.eval(Lisp.java:508) > at org.armedbear.lisp.Load.loadStream(Load.java:606) > at org.armedbear.lisp.Load.loadFileFromStream(Load.java:574) > at org.armedbear.lisp.Load.load(Load.java:206) > at org.armedbear.lisp.Load.load(Load.java:128) > at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:333) > at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:110) > at org.armedbear.lisp.Main$1.run(Main.java:46) > at java.lang.Thread.run(Thread.java:722) > > When I loaded `mefcl-init.lisp'(just the code I wrote before to change the source location) after the REPL started, it crashed without stack trace printed. > > D:\mefcl-0.2\abcl>java -jar dist\abcl.jar org.armedbear.lisp.Main > Armed Bear Common Lisp 1.1.1 > Java 1.7.0_02 Oracle Corporation > Java HotSpot(TM) Client VM > Low-level initialization completed in 0.309 seconds. > Startup completed in 4.086 seconds. > Type ":help" for a list of available commands. > CL-USER(1): (load "mefcl-init.lisp") > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/quicklisp/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/mvn/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jss/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/jfli/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-jar/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/asdf-install/ to ASDF. > Added jar:file:D:/mefcl-0.2/abcl/dist/abcl-contrib.jar!/abcl-asdf/ to ASDF. > Unable to autoload CLASS-DIRECT-SLOTS > > So I tried to restart ABCL and resolve CLASS-DIRECT-SLOTS manually. > CL-USER(1): (autoload 'class-direct-slots) > T > CL-USER(2): (resolve 'class-direct-slots) > #<THREAD "interpreter" {EF89C6}>: Debugger invoked on condition of type ERROR > Failed to find loadable system file 'class-direct-slots' in boot classpath. > Restarts: > 0: TOP-LEVEL Return to top level. > > Did I miss something ? Or say, how to solve this problem ? > > > Best regards, > Xiaofeng Yang > > > 2013/2/23 Mark Evenson <evenson(a)panix.com> >> Congratulations! You've met the autoloader, now level up... >> >> In order to reduce initial system boot times (and also to partially optimize for booting over the network), not all functions corresponding to symbols in the base ABCL system are loaded initially. Instead, the symbol function slot contains a stub which when first executed as a function loads the necessary code, which as a side effect also populates the symbol plist. >> >> Users of the implementation may currently interact with this mechanism meaningfullly through the EXT:AUTOLOADP and EXT:RESOLVE functions, which tell you if a symbol needs to be autoloaded and to resolve it, respectively. >> >> Using these functions we may define >> >> (defun maybe-resolve-symbol-plist (symbol) >> (when (autoloadp symbol) >> (resolve symbol)) >> (symbol-plist symbol)) >> >> which you can then use in your code to change the source locations. >> >> yers, >> Mark >> >> -- >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad idea? >> A: Top-posting. >> Q: What is the most annoying thing in email? >> >> On Feb 23, 2013, at 7:25 AM, Xiaofeng Yang <n.akr.akiiya(a)gmail.com> wrote: >> >>> Thanks. >>> >>> More details, I found that after the REPL started: >>> ; SLIME 2011-10-19 >>> CL-USER> (symbol-plist 'disassemble) >>> NIL >>> CL-USER> (disassemble 'disassemble) >>> ; Compiled from "disassemble.lisp" >>> ... very long output >>> NIL >>> CL-USER> (symbol-plist 'disassemble) >>> (SYSTEM::%SOURCE (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/disassemble.lisp" . 1693)) >>> >>> After I called DISASSEMBLE, the result of (symbol-plist 'disassemble) was not NIL. How can I make the result of the first (symbol-plist 'disassemble) no NIL? >>> >>> >>> >>> Best regards, >>> Xiaofeng Yang >>> >>> >>> 2013/2/23 Mark Evenson <evenson(a)panix.com> >>>> On 2/22/13 4:01 PM, Xiaofeng Yang wrote: >>>> > Hi, all >>>> > >>>> > I built ABCL 1.1.1 using Ant. After I built it, I found that the source >>>> > locations of all the symbols are absolute path. For exmaple: >>>> > [1] CL-USER(1): (symbol-plist 'defun) >>>> > (SYSTEM::%SOURCE >>>> > (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/precompiler.lisp" . 44441) >>>> > PRECOMPILER::PRECOMPILE-HANDLER PRECOMPILER::PRECOMPILE-DEFUN) >>>> > >>>> > I tried using '--nosystem', setting (LOGICAL-PATHNAME-TRANSLATIONS >>>> > "sys") by myself, and even deleting system.lisp from the jar. But the >>>> > source location didn't change. >>>> > >>>> > How can I build ABCL 1.1.1 without recording the absolute path of the >>>> > source ? Or, making the source location changable so that I can locate >>>> > it even if I change the path of the source code ? I think I can do it >>>> > manually by i.g. >>>> > (dolist (pkg (list-all-packages)) >>>> > (do-symbols (sym pkg) >>>> > if there exists system::%source in symbol-plist, replace it)). >>>> > Is there any other way to do this ? >>>> >>>> Currently, there is no way of building to not recording the physical >>>> pathname, but there should be. The values stored in the symbol plists >>>> should use the SYS:SRC logical pathname. I've recorded this as ticket >>>> [#301][]. >>>> >>>> >>>> [#301]: http://trac.common-lisp.net/armedbear/ticket/301 >>>> >>>> -- >>>> >>>> "A screaming comes across the sky. It has happened before, but there is >>>> nothing to compare it to now." >

2 2

[armedbear-devel] How can I build ABCL 1.1.1 without recording the absolute path of the source ?
by Xiaofeng Yang 23 Feb '13

23 Feb '13

Hi, all I built ABCL 1.1.1 using Ant. After I built it, I found that the source locations of all the symbols are absolute path. For exmaple: [1] CL-USER(1): (symbol-plist 'defun) (SYSTEM::%SOURCE (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/precompiler.lisp" . 44441) PRECOMPILER::PRECOMPILE-HANDLER PRECOMPILER::PRECOMPILE-DEFUN) I tried using '--nosystem', setting (LOGICAL-PATHNAME-TRANSLATIONS "sys") by myself, and even deleting system.lisp from the jar. But the source location didn't change. How can I build ABCL 1.1.1 without recording the absolute path of the source ? Or, making the source location changable so that I can locate it even if I change the path of the source code ? I think I can do it manually by i.g. (dolist (pkg (list-all-packages)) (do-symbols (sym pkg) if there exists system::%source in symbol-plist, replace it)). Is there any other way to do this ? Thanks Best regards, Xiaofeng Yang

3 3

Re: [armedbear-devel] How can I build ABCL 1.1.1 without recording the absolute path of the source ?
by Mark Evenson 23 Feb '13

23 Feb '13

Congratulations! You've met the autoloader, now level up... In order to reduce initial system boot times (and also to partially optimize for booting over the network), not all functions corresponding to symbols in the base ABCL system are loaded initially. Instead, the symbol function slot contains a stub which when first executed as a function loads the necessary code, which as a side effect also populates the symbol plist. Users of the implementation may currently interact with this mechanism meaningfullly through the EXT:AUTOLOADP and EXT:RESOLVE functions, which tell you if a symbol needs to be autoloaded and to resolve it, respectively. Using these functions we may define (defun maybe-resolve-symbol-plist (symbol) (when (autoloadp symbol) (resolve symbol)) (symbol-plist symbol)) which you can then use in your code to change the source locations. yers, Mark -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad idea? A: Top-posting. Q: What is the most annoying thing in email? On Feb 23, 2013, at 7:25 AM, Xiaofeng Yang <n.akr.akiiya(a)gmail.com> wrote: > Thanks. > > More details, I found that after the REPL started: > ; SLIME 2011-10-19 > CL-USER> (symbol-plist 'disassemble) > NIL > CL-USER> (disassemble 'disassemble) > ; Compiled from "disassemble.lisp" > ... very long output > NIL > CL-USER> (symbol-plist 'disassemble) > (SYSTEM::%SOURCE (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/disassemble.lisp" . 1693)) > > After I called DISASSEMBLE, the result of (symbol-plist 'disassemble) was not NIL. How can I make the result of the first (symbol-plist 'disassemble) no NIL? > > > > Best regards, > Xiaofeng Yang > > > 2013/2/23 Mark Evenson <evenson(a)panix.com> >> On 2/22/13 4:01 PM, Xiaofeng Yang wrote: >> > Hi, all >> > >> > I built ABCL 1.1.1 using Ant. After I built it, I found that the source >> > locations of all the symbols are absolute path. For exmaple: >> > [1] CL-USER(1): (symbol-plist 'defun) >> > (SYSTEM::%SOURCE >> > (#P"L:/abcl-src-1.1.1/src/org/armedbear/lisp/precompiler.lisp" . 44441) >> > PRECOMPILER::PRECOMPILE-HANDLER PRECOMPILER::PRECOMPILE-DEFUN) >> > >> > I tried using '--nosystem', setting (LOGICAL-PATHNAME-TRANSLATIONS >> > "sys") by myself, and even deleting system.lisp from the jar. But the >> > source location didn't change. >> > >> > How can I build ABCL 1.1.1 without recording the absolute path of the >> > source ? Or, making the source location changable so that I can locate >> > it even if I change the path of the source code ? I think I can do it >> > manually by i.g. >> > (dolist (pkg (list-all-packages)) >> > (do-symbols (sym pkg) >> > if there exists system::%source in symbol-plist, replace it)). >> > Is there any other way to do this ? >> >> Currently, there is no way of building to not recording the physical >> pathname, but there should be. The values stored in the symbol plists >> should use the SYS:SRC logical pathname. I've recorded this as ticket >> [#301][]. >> >> >> [#301]: http://trac.common-lisp.net/armedbear/ticket/301 >> >> -- >> >> "A screaming comes across the sky. It has happened before, but there is >> nothing to compare it to now." >

2 2

[armedbear-devel] ASDF 2.30 released
by Faré 21 Feb '13

21 Feb '13

Dear Lisp hackers, ASDF 2.30 is another stability release in preparation for ASDF 3. Since 2.29, in addition to specific portability fixes for CCL and CMUCL, it notably restores some backward compatible behavior for syntax tables around loading .asd files, using mutable global tables, instead of standard syntax tables. Just like 2.29, 2.28 and 2.27 before it, ASDF 2.30 is a pre-release of ASDF 3, an almost complete rewrite of ASDF, and includes a vast number of improvements since ASDF 2.26. http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… We invite all implementation vendors to update to ASDF 2.30. We also invite all implementations to make the standard *readtable* and *print-pprint-dispatch* tables immutable, with useful error messages when a modification is attempted. See how the CLHS forbids conformant programs from modifying them: http://clhs.lisp.se/Body/26_glo_s.htm#standard_readtable http://clhs.lisp.se/Body/26_glo_s.htm#standard_pprint_dispatch_table Such modification can only result in problems down the line for users, and it would be nice if at least when SAFETY isn't 0, that were checked. In some unspecified future, we'd like to revert to ASDF 2.29's behavior of binding the syntax tables to their standard values, and then we hope that most implementations will immediately catch misguided attempts by users to modify them (SBCL is the only implementation enforced immutability on both tables). Many thanks to stassats and avodonosov for their help in testing ASDF and helping make it more robust, more portable and more backward compatible. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a free market there are no market failures, only market opportunities. In a bureaucracy there is no possible success, only a perpetual ever-worsening crisis.

2 1

[armedbear-devel] Seamless ABCL / Java integration proposal
by Blake McBride 20 Feb '13

20 Feb '13

I have an idea for a largely seamless integration method for ABCL with Java that involves changing the ABCL REPL. It would work as follows. 1. From within Java or lisp, have the ability to register any number of Java classes with ABCL. 2. When executing lisp code of the form (fun args ...), try running the code as regular lisp code as it does now, but if it fails to find the lisp function and has at least one argument then: 3. Examine the arguments and, through reflection, try to find a Java method (with the same name as the lisp function) in one of the registered Java classes that matches the number and types of arguments and execute that. So, it would auto translate (in effect): (fun arg1 arg2 arg3 ...) into Java arg1.fun(arg2, arg3, ...); 4. There must be better auto-translation of lisp <-> java data types to include arrays and lists in order for this to work. So, in other words, when executing a lisp function passing a lisp array as one of the arguments, the Java reflection query will see a Java array argument type. It will also be auto-converted when making the call. 5. There must be some sort of cacheing mechanism to avoid redundant Java reflection calls. 6. This mechanism must take into account and correctly handle similar Java method names with different number and types of arguments both within and across different classes. It must also handle the fact that methods may be declared in Java superclasses. 7. This functionality can be enabled or disabled through some (Java and/or lisp function). Off by default to avoid troubles. Adding this functionality would make ABCL a plugin-and-go extension to Java. Any code could be written in Java or lisp immediately without complicated and cumbersome interface/translation code in most cases. There would be no huge initial hill to climb (to create all the interface code), and the usage would be natural and uncomplicated. Thanks. Blake McBride

5 14

Re: [armedbear-devel] Catching CL errors in java
by Alessio Stalla 20 Feb '13

20 Feb '13

I don't think the package is the culprit. Your package most probably USEs the CL package, or many other things would not work as you'd expect. Answering your earlier question, the correct way would be (setf *debugger-hook* ...) rather than defparameter, or even better binding instead of assigning - (let ((*debugger-hook* ...)) (do-your-stuff)). But I don't think that can make a difference between working and not working at all. It is more of a question of good style. Perhaps you're not considering thread-local bindings? If you run your defparameter/setf form on one thread, but .eval is called on another thread (and with a GUI involved, that is very probable), then chances are that the code in your .eval call is running in a dynamic environment where *debugger-hook* is locally rebound, and thus the global binding that you modify with defparameter/setf is shadowed. You can detect it by printing the value of *debugger-hook* in an .eval call triggered by the GUI. If that is the case, you should make sure to assign a new value to *debugger-hook* on the right thread, or, better, to use (let ...) as shown above. Let me stress that using LET is usually what you want in Lisp, especially when dealing with dynamic variables; a good rule of thumb is: avoid SETF and friends (defparameter is a friend) unless you're working on local variables. Of course, experts know when and how to break the rules :D but if you're a beginner, sticking to that style will make things easier to understand and debug, once you enter the right mindset. hth, Alessio On Tue, Feb 19, 2013 at 5:50 PM, Jonathan Fischer Friberg <odyssomay(a)gmail.com> wrote: > It might be that I'm in the wrong package. Although the repl is in cl-user, > and even if I change to that package the code in the previous mail has no > effect. > > Jonathan > > > On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg > <odyssomay(a)gmail.com> wrote: >> >> I don't know if this is the correct way to do it, but I did: >> >> (defparameter *debugger-hook* #'sys::%debugger-hook-function) >> >> In the repl (from running java -jar abcl.jar), this worked as expected. >> However, I can't seem to get it working with the .eval function of my >> interpreter instance. >> >> Jonathan >> >> >> On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <alessiostalla(a)gmail.com> >> wrote: >>> >>> Short story: if you call into Lisp using the JSR-223 API, conditions >>> are automatically rethrown as Java exceptions. >>> >>> Long story: the way this is implemented is by binding *debugger-hook* >>> to an internal, probably undocumented function, that already does what >>> you want. It is called sys::%debugger-hook-function. >>> >>> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg >>> <odyssomay(a)gmail.com> wrote: >>> > I should add that a solution from inside CL would also work. I'm using >>> > the >>> > ABCL eval to execute all code, so maybe I could wrap the call with >>> > something >>> > like this: >>> > >>> > (handler-case >>> > (... do-stuff ...) >>> > (... catch CL-condition + throw java exception ...)) >>> > >>> > I don't know if that would work. Also, my CL skills are not good enough >>> > to >>> > finish the code above (how do I capture all conditions?), so help would >>> > be >>> > appreciated. >>> > >>> > Jonathan >>> > >>> > >>> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg >>> > <odyssomay(a)gmail.com> wrote: >>> >> >>> >> Hi again, :) >>> >> >>> >> I'm currently running CL-code from java. The gui is completely >>> >> implemented >>> >> on the java side. It would be nice if all errors occuring inside abcl >>> >> could >>> >> be captured from the java side (to be displayed in the gui as an >>> >> error). Is >>> >> that possible? >>> >> >>> >> Jonathan >>> > >>> > >>> > >>> > _______________________________________________ >>> > armedbear-devel mailing list >>> > armedbear-devel(a)common-lisp.net >>> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >>> > >>> >>> >>> >>> -- >>> Some gratuitous spam: >>> >>> http://ripple-project.org Ripple, social credit system >>> http://villages.cc Villages.cc, Ripple-powered community economy >>> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM >>> http://code.google.com/p/tapulli my current open source projects >>> http://www.manydesigns.com/ ManyDesigns Portofino, open source >>> model-driven Java web application framework >> >> > -- Some gratuitous spam: http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework

2 6

[armedbear-devel] Fwd: Catching CL errors in java
by Jonathan Fischer Friberg 19 Feb '13

19 Feb '13

Sorry! Accidentally sent mail only to Alessio. If anyone else would like to help, the info/questions are below. Jonathan ---------- Forwarded message ---------- From: Jonathan Fischer Friberg <odyssomay(a)gmail.com> Date: Tue, Feb 19, 2013 at 5:50 PM Subject: Re: [armedbear-devel] Catching CL errors in java To: Alessio Stalla <alessiostalla(a)gmail.com> It might be that I'm in the wrong package. Although the repl is in cl-user, and even if I change to that package the code in the previous mail has no effect. Jonathan On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg < odyssomay(a)gmail.com> wrote: > I don't know if this is the correct way to do it, but I did: > > (defparameter *debugger-hook* #'sys::%debugger-hook-function) > > In the repl (from running java -jar abcl.jar), this worked as expected. > However, I can't seem to get it working with the .eval function of my > interpreter instance. > > Jonathan > > > On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <alessiostalla(a)gmail.com>wrote: > >> Short story: if you call into Lisp using the JSR-223 API, conditions >> are automatically rethrown as Java exceptions. >> >> Long story: the way this is implemented is by binding *debugger-hook* >> to an internal, probably undocumented function, that already does what >> you want. It is called sys::%debugger-hook-function. >> >> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg >> <odyssomay(a)gmail.com> wrote: >> > I should add that a solution from inside CL would also work. I'm using >> the >> > ABCL eval to execute all code, so maybe I could wrap the call with >> something >> > like this: >> > >> > (handler-case >> > (... do-stuff ...) >> > (... catch CL-condition + throw java exception ...)) >> > >> > I don't know if that would work. Also, my CL skills are not good enough >> to >> > finish the code above (how do I capture all conditions?), so help would >> be >> > appreciated. >> > >> > Jonathan >> > >> > >> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg >> > <odyssomay(a)gmail.com> wrote: >> >> >> >> Hi again, :) >> >> >> >> I'm currently running CL-code from java. The gui is completely >> implemented >> >> on the java side. It would be nice if all errors occuring inside abcl >> could >> >> be captured from the java side (to be displayed in the gui as an >> error). Is >> >> that possible? >> >> >> >> Jonathan >> > >> > >> > >> > _______________________________________________ >> > armedbear-devel mailing list >> > armedbear-devel(a)common-lisp.net >> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >> > >> >> >> >> -- >> Some gratuitous spam: >> >> http://ripple-project.org Ripple, social credit system >> http://villages.cc Villages.cc, Ripple-powered community economy >> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM >> http://code.google.com/p/tapulli my current open source projects >> http://www.manydesigns.com/ ManyDesigns Portofino, open source >> model-driven Java web application framework >> > >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel