From: Vladimir K. <vko...@gm...> - 2009-04-26 13:55:21
|
Test case: (defpackage "TEST") (eval-when (:compile-toplevel :load-toplevel) (intern "TEST" "TEST") (export 'test::test "TEST")) (format t "Everything's fine.~%") (quit) Simply loading this file works: E:\Users\Vladimir>abcl --noinform --noinit --load export.lisp Everything's fine. ... but if we compile it and try to load the resulting fasl, this happens: E:\Users\Vladimir>abcl --noinform --noinit CL-USER(1): (load "export.abcl") Error loading E:\Users\Vladimir\export.abcl at line 8 (offset 448) Debugger invoked on condition of type READER-ERROR: The symbol "TEST" is not external in package TEST. Restarts: 0: TOP-LEVEL Return to top level. The problem lies in export.abcl/export._: ; -*- Mode: Lisp -*- (SYSTEM:INIT-FASL :VERSION 29) (SETQ SYSTEM:*SOURCE* #P"E:\\Users\\Vladimir\\export.lisp") (SYSTEM::%DEFPACKAGE "TEST" 'COMMON-LISP:NIL 'COMMON-LISP:NIL 'COMMON-LISP:NIL (SYSTEM::ENSURE-AVAILABLE-SYMBOLS 'COMMON-LISP:NIL) 'COMMON-LISP:NIL (SYSTEM::ENSURE-AVAILABLE-SYMBOLS 'COMMON-LISP:NIL) 'COMMON-LISP:NIL 'COMMON-LISP:NIL 'COMMON-LISP:NIL) (FUNCALL (SYSTEM:LOAD-COMPILED-FUNCTION "export-1.cls")) (EXPORT 'TEST:TEST "TEST") ;; <-- note the single colon (FUNCALL (SYSTEM:LOAD-COMPILED-FUNCTION "export-2.cls")) (QUIT) It seems that ABCL writes the "_" file after the entirety of the source file has been processed, including evaluating the 'export' form. And since the TEST::TEST symbol is exported at that time, the printer uses a single colon. |
From: Erik H. <eh...@gm...> - 2009-04-27 07:40:40
|
Hi Vladimir On Sun, Apr 26, 2009 at 3:49 PM, Vladimir Korablin <vko...@gm...> wrote: > Test case: > > (defpackage "TEST") > > (eval-when (:compile-toplevel :load-toplevel) > (intern "TEST" "TEST") > (export 'test::test "TEST")) > > (format t "Everything's fine.~%") > (quit) > > Simply loading this file works: > > E:\Users\Vladimir>abcl --noinform --noinit --load export.lisp > Everything's fine. > > ... but if we compile it and try to load the resulting fasl, this happens: > > E:\Users\Vladimir>abcl --noinform --noinit > CL-USER(1): (load "export.abcl") > Error loading E:\Users\Vladimir\export.abcl at line 8 (offset 448) > Debugger invoked on condition of type READER-ERROR: > The symbol "TEST" is not external in package TEST. > Restarts: > 0: TOP-LEVEL Return to top level. > > The problem lies in export.abcl/export._: Thanks for the test case and analysis! I was busy fixing some other part of our code this weekend, so I was looking at it just now - although fixing it will have to wait until one of the evenings this week. [ snip .. ] > It seems that ABCL writes the "_" file after the entirety of the > source file has been processed, including evaluating the 'export' > form. And since the TEST::TEST symbol is exported at that time, the > printer uses a single colon. This is exactly what's happening. If you're interested in submitting a patch, have a look at src/org/armedbear/lisp/compile-file.lisp. There - in PROCESS-TOPLEVEL-FORM - you'll find a long case statement with operators which need special-handling with file-compilation. in the T clause, EXPORT is being handled (before the IMPORT clause) in a nested case. If you look at the start of the nested case, there's a "(when compile-time-too (eval form))". That form is our issue, because it's being evaluated too early; just as you expected. Care to (discuss and) prepare a patch? It would really help if you did that, because I would be able to sort out the stuff in my working copy. Thanks in advance! Bye, Erik. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2009-04-27 08:09:36
|
> If you look at the start of the nested case, there's a "(when > compile-time-too (eval form))". That form is our issue, because it's > being evaluated too early; just as you expected. See http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/compile-file.lisp#L261 Bye, Erik. |
From: Vladimir K. <vko...@gm...> - 2009-04-29 06:15:36
Attachments:
export.diff
|
On Mon, Apr 27, 2009 at 11:40 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > If you look at the start of the nested case, there's a "(when > compile-time-too (eval form))". That form is our issue, because it's > being evaluated too early; just as you expected. > > Care to (discuss and) prepare a patch? It would really help if you did > that, because I would be able to sort out the stuff in my working > copy. > Here's a stab at fixing it. This patch simply checks if the form we're processing is an EXPORT form and if so, postpones evaluating it until after it's been dumped. Can ABCL's printer be told to just print double colons and package prefixes for all symbols? (Via a control variable, for example.) That could be a cleaner way, with less special-casing... |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2009-04-30 06:52:34
|
On Wed, Apr 29, 2009 at 8:15 AM, Vladimir Korablin <vko...@gm...> wrote: > On Mon, Apr 27, 2009 at 11:40 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > >> If you look at the start of the nested case, there's a "(when >> compile-time-too (eval form))". That form is our issue, because it's >> being evaluated too early; just as you expected. >> >> Care to (discuss and) prepare a patch? It would really help if you did >> that, because I would be able to sort out the stuff in my working >> copy. >> > Here's a stab at fixing it. This patch simply checks if the form we're > processing is an EXPORT form and if so, postpones evaluating it until > after it's been dumped. Thanks for your proposal. I've looked at the surrounding code and I think that it may have similar side effects, so I decided to postpone evaluation in all cases. > Can ABCL's printer be told to just print double colons and package > prefixes for all symbols? (Via a control variable, for example.) That > could be a cleaner way, with less special-casing... No, the printer prints symbols as it finds them in the environment... I hope I solved it with more logical special casing. Anyway, your example now runs successfully to completion. Could you verify your application works (better) now? Thanks for the report and the attempt at fixing! Bye, Erik. |
From: Vladimir K. <vko...@gm...> - 2009-04-30 10:37:00
|
On Thu, Apr 30, 2009 at 10:52 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > I hope I solved it with more logical special casing. Anyway, your > example now runs successfully to completion. > > Could you verify your application works (better) now? > Everything seems to work. Thanks! |