Re: [armedbear-devel] How can I build ABCL 1.1.1 without recording the absolute path of the source ?
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@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@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@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@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."
Hi, Mark. I had updated my JDK to 1.7.0_15, then recompiled ABCL 1.1.1 using JDK 1.7.0_15 and ran it using JDK 1.7.0_15. But, there are the same problems. Even the symbols are the same as what I mentioned before. I collected the symbols that cannot be resolved. I hope it useful. (defparameter *cannot-resolve* '("CLASS-DIRECT-SLOTS" "COMPUTE-CLASS-DIRECT-SLOTS" "MAKE-FORWARD-REFERENCED-CLASS" "%SET-STREAM-EXTERNAL-FORMAT" "%IMPORT" "%DELETE-PACKAGE")) Best regards, Xiaofeng Yang 2013/2/23 Mark Evenson <evenson@panix.com>
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@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@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@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@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."
On 2/24/13 0421 , Xiaofeng Yang wrote:
Hi, Mark. I had updated my JDK to 1.7.0_15, then recompiled ABCL 1.1.1 using JDK 1.7.0_15 and ran it using JDK 1.7.0_15. But, there are the same problems. Even the symbols are the same as what I mentioned before. I collected the symbols that cannot be resolved. I hope it useful. (defparameter *cannot-resolve* '("CLASS-DIRECT-SLOTS" "COMPUTE-CLASS-DIRECT-SLOTS" "MAKE-FORWARD-REFERENCED-CLASS" "%SET-STREAM-EXTERNAL-FORMAT" "%IMPORT" "%DELETE-PACKAGE"))
Thanks for the report: you exposed some problems with how we were setting up autoload for symbols, as well as with the EXT:RESOLVE function failing on a non-existent symbol. Everything should be fixed with [r14400][]. [r14400]: http://trac.common-lisp.net/armedbear/changeset/14400 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (2)
-
Mark Evenson -
Xiaofeng Yang