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

[armedbear-devel] ASDF 2.32 released
by Faré 06 Mar '13

06 Mar '13

Dear ABCL hackers, ASDF 2.32 was released in time for inclusion in the upcoming CCL 1.9. Once again, we invite all implementation vendors and distributors to upgrade the version of ASDF included in their releases. Yes, I know, that's a lot of releases in a bit more than a month. But it was also a lot of development, and a lot of adjustment to reality after that development was first released. We will keep fixing bugs and improve ASDF based on our growing internal test suite and results from Anton Vodonosov's cl-test-grid. This is still a pre-release for ASDF3. Here are the changes, since previous release 2.31, and since previous public announcement for 2.30. >From 2.31 to 2.32: * deferred-warning checks are now disabled by default, to enhance backward compatibility with ASDF 2.26 and earlier. In the future, we will enable them by default, but not until we implement a smoother transition plan. Also, CCL-specific fixes to deferred-warning support. * UIOP is the new official name for ASDF-DRIVER. "Utilities for Implementation- and OS- Portability". Old names remain as package and system nicknames: ASDF/DRIVER ASDF-DRIVER ASDF-UTILS * require-system so systems may depend on implementation-provided modules. * auto-upgrade attempt in operate *before* the implicit find-system. * class specification for components can now be a string to be read as a symbol. * feature conditional dependencies are now debugged and tested: :depends-on ("some-system" (:feature :foo "other-system)) we only recommend them for dependencies between systems; within systems, we recommend you use feature-conditional components with :if-feature :foo and we only provide limited support for the deprecated legacy way of using feature-conditionals with a module having :if-component-dep-fails :ignore while its components specify things like: :in-order-to ((compile-op (feature :foo))) * read-from-file for :version specification is made more useful by using the ASDF-USER package rather than CL (into which interning is forbidden) to read the files. Changes from 2.30 to 2.31: * *default-encoding* is now UTF-8. As tested with cl-test-grid, This is a boon for most programs, that will compile in a more predictable way in a wider range of settings. A handful of unmaintained outliers still need to be fixed. * Downgrade is now explicitly avoided. ASDF will issue a warning if your system is misconfigured in a way that specifies downgrade, but will then ignore the specified ASDF downgrade. * version specifications, when invalid, will lead only to a warning for now; a future ASDF3 may restore the behavior of ASDF 2.27, that raises an errors when there is a bad :version specification, but for now, backward compatibility prevails. * ECL support received several bug fixes. * precompiled-system support was notably fixed, enabling single-fasl deployment of SBCL contribs. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is, jam to-morrow and jam yesterday, but never jam today. — Lewis Carroll

2 1

[armedbear-devel] [Extended Deadline] European Lisp Symposium 2013 - Madrid - June 1-4
by Didier Verna 05 Mar '13

05 Mar '13

;; ______ _ _____ _ __ ____ ;; | ____| | | / ____| ( ) /_ | |___ \ ;; | |__ | | | (___ |/ | | __) | ;; | __| | | \___ \ | | |__ < ;; | |____ | |____ ____) | | | ___) | ;; |______| |______| |_____/ |_| |____/ ;; ;; European Lisp Symposium 2013 - ELS'13 ;; Madrid, Spain ;; ;; June 1-4, 2013 ;; ;; http://els2013.european-lisp-symposium.org/ ** DEADLINE EXTENSION: March 17th ** The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The main theme of the 2013 European Lisp Symposium is on the use of these languages with respect to the current grand challenges: big tables, open data, semantic web, network programming, discovery, robustness, runtime failures, etc. The European Lisp Symposium 2013 solicits the submission of papers with these specific themes in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Invited speakers: Florian Loitsch, Google: Dart, why you should care. Gérard Assayag, Ircam: Lisp and Music Research. Important dates: March, 17th 2013: submission deadline ** EXTENDED ** April, 5th 2013: acceptance results June, 1-4 2013: symposium Program Commitee: Pascal Costanza, Intel, Belgium Ludovic Courtes, INRIA, France Theo D'Hondt, Vrije Universiteit Brussel, Belgium Florian Loitsch, Google, Denmark Christian Queinnec, UPMC, France Kurt Noermark, Aalborg University, Denmark Olin Shivers, Northeastern University, USA Manuel Serrano, INRIA, France Didier Verna, EPITA, France Chair: Juan Jose Garcia-Ripoll, local organizer Christian Queinnec, PC co-chair Manuel Serrano, PC co-chair -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Fwd: variable-information?
by Erik Huelsmann 03 Mar '13

03 Mar '13

---------- Forwarded message ---------- From: James M. Lawrence <llmjjmll(a)gmail.com> Date: Sat, Mar 2, 2013 at 5:21 PM Subject: Re: [armedbear-devel] variable-information? To: Erik Huelsmann <ehuels(a)gmail.com> On Sat, Mar 2, 2013 at 10:38 AM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi James, > > Are you in a macro expansion environment? If that's the case, then we could > quite easily make that available, I'm sure. > > Could you provide a bit more detail on what your usecase is? (I'm not > familiar with cltl2, I'm affraid) Hi, Yes by environment I mean the &environment parameter to defmacro. The distributed version of lparallel uses variable-information to create closures which are executed on remote machines. Since at least four implementations offer variable-information (SBCL, CCL, LispWorks, Allegro), this technique amounts to a somewhat portable way to serialize closures. [Did you mean to respond to the list?] Regards, lmj

1 0

[armedbear-devel] variable-information?
by James M. Lawrence 02 Mar '13

02 Mar '13

Is there something akin to variable-information in CLTL2? For a given environment I would like to know if a symbol is a lexical variable or a symbol macrolet.

2 1

[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