From: Gabor M. <me...@ho...> - 2004-08-05 21:22:16
|
ABCL starts very slowly (6s on a P2.8, is that normal?). I'm trying to speed things up by compiling it as suggested, but (compile-system) fails: ... ; Compiling /home/mega/j/src/org/armedbear/lisp/macros.lisp ... ; Processing macro PROG1 ; Macro PROG1 => macros-1.cls ; Processing macro PROG2 ; Macro PROG2 => macros-2.cls ; Processing macro PUSH ; Macro PUSH => macros-3.cls ; Processing macro PUSHNEW ; Macro PUSHNEW => macros-4.cls ; Processing macro POP ; Macro POP => macros-5.cls ; Processing macro PSETQ Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type HASH-TABLE. [1] CL-USER(3): It's on Debian/Sarge with Blackdown 1.4.1_99 sdk with the current J CVS. Thanks, Gabor Melis |
From: Peter G. <pe...@ar...> - 2004-08-06 04:27:35
|
On Thu, 5 Aug 2004 at 23:27:17 +0200, Gabor Melis wrote: > ABCL starts very slowly (6s on a P2.8, is that normal?). Fairly normal. > I'm trying to speed things up by compiling it as suggested, but > (compile-system) fails: > > ... > ; Compiling /home/mega/j/src/org/armedbear/lisp/macros.lisp ... > ; Processing macro PROG1 > ; Macro PROG1 => macros-1.cls > ; Processing macro PROG2 > ; Macro PROG2 => macros-2.cls > ; Processing macro PUSH > ; Macro PUSH => macros-3.cls > ; Processing macro PUSHNEW > ; Macro PUSHNEW => macros-4.cls > ; Processing macro POP > ; Macro POP => macros-5.cls > ; Processing macro PSETQ > Debugger invoked on condition of type TYPE-ERROR: > The value NIL is not of type HASH-TABLE. > [1] CL-USER(3): > > > It's on Debian/Sarge with Blackdown 1.4.1_99 sdk with the current J > CVS. I don't know what's causing that problem. Similar things have been reported on this list before, but they haven't happened to me, and I haven't been able to pin down anything specific from the information that's been provided. Some suggestions: 1. Make sure to rm *.abcl *.cls in the lisp directory before starting up abcl to do COMPILE-SYSTEM. 2. If you're running abcl inside j, make sure you're running "Lisp as Separate Process" rather than "Embedded Lisp". If in doubt, run abcl in a normal shell. 3. If you're having a problem with a particular file in COMPILE-SYSTEM, you might try commenting out that file in compile-system.lisp to see if you can get any further. 4. It's possible (but not very likely) that the files you pulled from anonymous CVS were somehow out of sync or buggy. As the saying goes, if at first you don't suck seed, try and suck another seed... ;) -Peter |
From: Gabor M. <me...@ho...> - 2004-08-06 06:45:57
|
On Friday 06 August 2004 06:27, Peter Graves wrote: > On Thu, 5 Aug 2004 at 23:27:17 +0200, Gabor Melis wrote: > > ABCL starts very slowly (6s on a P2.8, is that normal?). > > Fairly normal. What makes it so much slower than 0.20.2 which starts within 2s? If I could get it compile how much faster would it be to start? > 3. If you're having a problem with a particular file in COMPILE-SYSTEM, > you might try commenting out that file in compile-system.lisp to see if > you can get any further. It's precompiler.lisp and this is the backtrace: 1] CL-USER(4): :bt 0: (BACKTRACE-AS-LIST) 1: (#:G9500 #S(JVM::INSTRUCTION :OPCODE 178 :ARGS ("org/armedbear/lisp/precompiler_22" "G4174_APPEND" "Lorg/armedbear/lisp/LispObject;") :STACK NIL :DEPTH NIL)) 2: (JVM:COMPILE-DEFUN PRECOMPILER::MAYBE-REWRITE-LAMBDA (LAMBDA (PRECOMPILER::FORM) (BLOCK PRECOMPILER::MAYBE-REWRITE-LAMBDA (LET* ((PRECOMPILER::ARGS (CDR PRECOMPILER::FORM)) (PRECOMPILER::LAMBDA-LIST (CAR PRECOMPILER::ARGS)) (PRECOMPILER::BODY (CDR PRECOMPILER::ARGS)) (PRECOMPILER::AUXVARS (MEMQ '&AUX PRECOMPILER::LAMBDA-LIST))) (WHEN PRECOMPILER::AUXVARS (SETF PRECOMPILER::LAMBDA-LIST (SUBSEQ PRECOMPILER::LAMBDA-LIST 0 (POSITION '&AUX PRECOMPILER::LAMBDA-LIST))) (SETF PRECOMPILER::BODY (LIST (APPEND (LIST 'LET* (CDR PRECOMPILER::AUXVARS)) PRECOMPILER::BODY)))) (LET ((PRECOMPILER::SPECIALS NIL)) (DOLIST (PRECOMPILER::VAR PRECOMPILER::LAMBDA-LIST) (WHEN (CONSP PRECOMPILER::VAR) (IF (CONSP (FIRST PRECOMPILER::VAR)) (SETF PRECOMPILER::VAR (SECOND (FIRST PRECOMPILER::VAR))) (SETF PRECOMPILER::VAR (FIRST PRECOMPILER::VAR)))) (WHEN (SPECIAL-VARIABLE-P PRECOMPILER::VAR) (PUSH PRECOMPILER::VAR PRECOMPILER::SPECIALS))) (WHEN PRECOMPILER::SPECIALS (DOLIST (SPECIAL PRECOMPILER::SPECIALS) (LET ((PRECOMPILER::SYM (GENSYM))) (LET ((PRECOMPILER::RES NIL)) (DOLIST (PRECOMPILER::VAR PRECOMPILER::LAMBDA-LIST) (COND ((AND (CONSP PRECOMPILER::VAR) (CONSP (FIRST PRECOMPILER::VAR)) (EQ SPECIAL (SECOND (FIRST PRECOMPILER::VAR)))) (PUSH (LIST (LIST (FIRST (FIRST PRECOMPILER::VAR)) PRECOMPILER::SYM) (SECOND PRECOMPILER::VAR)) PRECOMPILER::RES)) ((AND (CONSP PRECOMPILER::VAR) (EQ SPECIAL (FIRST PRECOMPILER::VAR))) (PUSH (CONS PRECOMPILER::SYM (CDR PRECOMPILER::VAR)) PRECOMPILER::RES)) ((EQ PRECOMPILER::VAR SPECIAL) (PUSH PRECOMPILER::SYM PRECOMPILER::RES)) (T (PUSH PRECOMPILER::VAR PRECOMPILER::RES)))) (SETF PRECOMPILER::LAMBDA-LIST (NREVERSE PRECOMPILER::RES))) (SETF PRECOMPILER::BODY (LIST (APPEND (LIST 'LET* (LIST (LIST SPECIAL PRECOMPILER::SYM))) PRECOMPILER::BODY))))))) (LIST* 'LAMBDA PRECOMPILER::LAMBDA-LIST (MAPCAR #'PRECOMPILER::PRECOMPILE1 PRECOMPILER::BODY))))) NIL "/home/mega/j/src/org/armedbear/lisp/precompiler-22.cls") 3: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFUN PRECOMPILER::MAYBE-REWRITE-LAMBDA (PRECOMPILER::FORM) (LET* ((PRECOMPILER::ARGS (CDR PRECOMPILER::FORM)) (PRECOMPILER::LAMBDA-LIST (CAR PRECOMPILER::ARGS)) (PRECOMPILER::BODY (CDR PRECOMPILER::ARGS)) (PRECOMPILER::AUXVARS (MEMQ '&AUX PRECOMPILER::LAMBDA-LIST))) (WHEN PRECOMPILER::AUXVARS (SETF PRECOMPILER::LAMBDA-LIST (SUBSEQ PRECOMPILER::LAMBDA-LIST 0 (POSITION '&AUX PRECOMPILER::LAMBDA-LIST))) (SETF PRECOMPILER::BODY (LIST (APPEND (LIST 'LET* (CDR PRECOMPILER::AUXVARS)) PRECOMPILER::BODY)))) (LET ((PRECOMPILER::SPECIALS NIL)) (DOLIST (PRECOMPILER::VAR PRECOMPILER::LAMBDA-LIST) (WHEN (CONSP PRECOMPILER::VAR) (IF (CONSP (FIRST PRECOMPILER::VAR)) (SETF PRECOMPILER::VAR (SECOND (FIRST PRECOMPILER::VAR))) (SETF PRECOMPILER::VAR (FIRST PRECOMPILER::VAR)))) (WHEN (SPECIAL-VARIABLE-P PRECOMPILER::VAR) (PUSH PRECOMPILER::VAR PRECOMPILER::SPECIALS))) (WHEN PRECOMPILER::SPECIALS (DOLIST (SPECIAL PRECOMPILER::SPECIALS) (LET ((PRECOMPILER::SYM (GENSYM))) (LET ((PRECOMPILER::RES NIL)) (DOLIST (PRECOMPILER::VAR PRECOMPILER::LAMBDA-LIST) (COND ((AND (CONSP PRECOMPILER::VAR) (CONSP (FIRST PRECOMPILER::VAR)) (EQ SPECIAL (SECOND (FIRST PRECOMPILER::VAR)))) (PUSH (LIST (LIST (FIRST (FIRST PRECOMPILER::VAR)) PRECOMPILER::SYM) (SECOND PRECOMPILER::VAR)) PRECOMPILER::RES)) ((AND (CONSP PRECOMPILER::VAR) (EQ SPECIAL (FIRST PRECOMPILER::VAR))) (PUSH (CONS PRECOMPILER::SYM (CDR PRECOMPILER::VAR)) PRECOMPILER::RES)) ((EQ PRECOMPILER::VAR SPECIAL) (PUSH PRECOMPILER::SYM PRECOMPILER::RES)) (T (PUSH PRECOMPILER::VAR PRECOMPILER::RES)))) (SETF PRECOMPILER::LAMBDA-LIST (NREVERSE PRECOMPILER::RES))) (SETF PRECOMPILER::BODY (LIST (APPEND (LIST 'LET* (LIST (LIST SPECIAL PRECOMPILER::SYM))) PRECOMPILER::BODY))))))) (LIST* 'LAMBDA PRECOMPILER::LAMBDA-LIST (MAPCAR #'PRECOMPILER::PRECOMPILE1 PRECOMPILER::BODY)))) #<FILE-STREAM @ #x23f1bb> NIL) 4: (COMPILE-FILE "precompiler.lisp") 5: (SYSTEM::%TIME #<FUNCTION @ #x1d33a6b>) 6: (COMPILE-SYSTEM) 7: (EVAL (COMPILE-SYSTEM)) 8: (SYSTEM::INTERACTIVE-EVAL (COMPILE-SYSTEM)) 9: (TOP-LEVEL::REPL) 10: (TOP-LEVEL::TOP-LEVEL-LOOP) [1] CL-USER(5): If I just load the lisp file without compiling then the same thing happens in jvm.lisp: ; Processing function ADD-VARIABLE-TO-CONTEXT ; ADD-VARIABLE-TO-CONTEXT => jvm-37.cls ; Processing function PUSH-VARIABLE Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type HASH-TABLE. 1] CL-USER(2): :bt 0: (BACKTRACE-AS-LIST) 1: (#:G7917 #S(JVM::INSTRUCTION :OPCODE 181 :ARGS ("org/armedbear/lisp/LispThread" "_values" "[Lorg/armedbear/lisp/LispObject;") :STACK NIL :DEPTH NIL)) 2: (JVM:COMPILE-DEFUN JVM::PUSH-VARIABLE (LAMBDA (JVM::NAME JVM::SPECIAL-P) (BLOCK JVM::PUSH-VARIABLE (LET* ((JVM::INDEX (IF JVM::SPECIAL-P NIL (LENGTH (JVM::CONTEXT-VARS JVM::*CONTEXT*)))) (JVM::VARIABLE (JVM::MAKE-VARIABLE :NAME JVM::NAME :SPECIAL-P JVM::SPECIAL-P :INDEX JVM::INDEX))) (PUSH JVM::VARIABLE JVM::*VISIBLE-VARIABLES*) (PUSH JVM::VARIABLE JVM::*ALL-VARIABLES*) (UNLESS JVM::SPECIAL-P (JVM::ADD-VARIABLE-TO-CONTEXT JVM::VARIABLE)) JVM::VARIABLE))) NIL "/home/mega/j/src/org/armedbear/lisp/jvm-38.cls") 3: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFUN JVM::PUSH-VARIABLE (JVM::NAME JVM::SPECIAL-P) (LET* ((JVM::INDEX (IF JVM::SPECIAL-P NIL (LENGTH (JVM::CONTEXT-VARS JVM::*CONTEXT*)))) (JVM::VARIABLE (JVM::MAKE-VARIABLE :NAME JVM::NAME :SPECIAL-P JVM::SPECIAL-P :INDEX JVM::INDEX))) (PUSH JVM::VARIABLE JVM::*VISIBLE-VARIABLES*) (PUSH JVM::VARIABLE JVM::*ALL-VARIABLES*) (UNLESS JVM::SPECIAL-P (JVM::ADD-VARIABLE-TO-CONTEXT JVM::VARIABLE)) JVM::VARIABLE)) #<FILE-STREAM @ #x82751> NIL) 4: (COMPILE-FILE "jvm.lisp") 5: (SYSTEM::%TIME #<FUNCTION @ #x14d5bc9>) 6: (COMPILE-SYSTEM) 7: (SYSTEM::%EVAL (COMPILE-SYSTEM)) 8: (EVAL (COMPILE-SYSTEM)) 9: (SYSTEM::INTERACTIVE-EVAL (COMPILE-SYSTEM)) 10: (TOP-LEVEL::REPL) 11: (TOP-LEVEL::TOP-LEVEL-LOOP) Gabor |
From: Peter G. <pe...@ar...> - 2004-08-06 10:59:22
|
On Fri, 6 Aug 2004 at 08:50:54 +0200, Gabor Melis wrote: > On Friday 06 August 2004 06:27, Peter Graves wrote: > > On Thu, 5 Aug 2004 at 23:27:17 +0200, Gabor Melis wrote: > > > ABCL starts very slowly (6s on a P2.8, is that normal?). > > > > Fairly normal. > > What makes it so much slower than 0.20.2 which starts within 2s? I don't know offhand. Even though 0.20.2 was the last official release, that was a long time ago. There's more functionality now, so that might be part of the problem. The code, in general, should be faster now, but it's possible that 0.20.2 was taking some shortcuts which didn't survive the test of time. Sometimes correctness makes things slower (or, to put it the other way around, you can be really fast if you don't care about getting the right answer). > If I could get it compile how much faster would it be to start? Startup would be about twice as fast as it is with uncompiled .lisp files. > > 3. If you're having a problem with a particular file in COMPILE-SYSTEM, > > you might try commenting out that file in compile-system.lisp to see if > > you can get any further. > > It's precompiler.lisp and this is the backtrace: Yeah. After successfully compiling 21 functions, the compiler is somehow overwriting JVM::*RESOLVERS* (which has happly been a hash-table all that time) with NIL. There's no place in the code that intentionally does this, so I don't know why it's happening. As mentioned, I'm not seeing the same problem here. It's probably a bug. ABCL isn't really ready for use by anyone but its developers. Work is continuing, so you might want to try again in a week or two and see if the problem has magically disappeared. -Peter |
From: Larry C. <la...@th...> - 2004-08-06 11:07:00
|
Peter Graves said: > On Thu, 5 Aug 2004 at 23:27:17 +0200, Gabor Melis wrote: >> I'm trying to speed things up by compiling it as suggested, but >> (compile-system) fails: >> >> ... >> ; Compiling /home/mega/j/src/org/armedbear/lisp/macros.lisp ... >> ; Processing macro PROG1 >> ; Macro PROG1 => macros-1.cls >> ; Processing macro PROG2 >> ; Macro PROG2 => macros-2.cls >> ; Processing macro PUSH >> ; Macro PUSH => macros-3.cls >> ; Processing macro PUSHNEW >> ; Macro PUSHNEW => macros-4.cls >> ; Processing macro POP >> ; Macro POP => macros-5.cls >> ; Processing macro PSETQ >> Debugger invoked on condition of type TYPE-ERROR: >> The value NIL is not of type HASH-TABLE. >> [1] CL-USER(3): >> >> >> It's on Debian/Sarge with Blackdown 1.4.1_99 sdk with the current J >> CVS. > > I don't know what's causing that problem. > > Similar things have been reported on this list before, but they haven't > happened to me, and I haven't been able to pin down anything specific > from the information that's been provided. I've gotten the same error. I got a clean compile after commenting out '(load (compile-file "jvm.lisp"))'. CVS from 8/6, ~6:50am EST. % java -version -server java version "1.4.1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01) Java HotSpot(TM) Server VM (build Blackdown-1.4.1-01, mixed mode) Same error at work with CVS from 8/2, same fix: comment (load (compile-file "jvm.lisp")). % java -version: java version "1.4.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1) Classic VM (build 1.4.1, J2RE 1.4.1 IBM build cxia321411-20030930 (JIT enabled: jitc)) Debian GNU/Linux, kernel 2.6.6. One obvious difference is that you use jikes and we don't. -- Larry |
From: Peter G. <pe...@ar...> - 2004-08-06 11:49:01
|
On Fri, 6 Aug 2004 at 07:06:49 -0400, Larry Clapp wrote: > I've gotten the same error. I got a clean compile after commenting out > '(load (compile-file "jvm.lisp"))'. CVS from 8/6, ~6:50am EST. > > % java -version -server > java version "1.4.1" > Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01) > Java HotSpot(TM) Server VM (build Blackdown-1.4.1-01, mixed mode) > > Same error at work with CVS from 8/2, same fix: comment (load > (compile-file "jvm.lisp")). > > % java -version: > java version "1.4.1" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1) > Classic VM (build 1.4.1, J2RE 1.4.1 IBM build cxia321411-20030930 (JIT > enabled: jitc)) OK, that's an interesting data point. If you load the compiled version of the compiler, you've got trouble. If you don't, meaning you're sticking with the interpreted version of the compiler, things work correctly. > Debian GNU/Linux, kernel 2.6.6. > > One obvious difference is that you use jikes and we don't. True enough, but the compiler doesn't use jikes; it generates the bytecode by itself. Another obvious difference is that I normally use Java 1.5. So, I've just rebuilt the .java files with Javac (from Sun 1.4.2_03, as it happens), fired up abcl with Blackdown 1.4.2-rc1, and run COMPILE- SYSTEM with nary a hiccup. Of course, the version of jvm.lisp that I'm using is different from what's in CVS, and I have no idea what version you guys are using. BTW, there's a line near the top of the file that tells you: $Id: jvm.lisp,v 1.267 2004/08/05 02:35:34 piso Exp $ And indeed, it might be useful to mention the version of jvm.lisp you're using when you report a compiler problem. But in any case, I still can't reproduce the problem you guys are seeing, and I know at least some other people have gotten things to work (I'm assuming Andras has or he would have said something, and Cristian Pietsch was able to get abcl to run cl-bench). I do seem to recall that for a little while (maybe sometime last weekend), the compiler worked OK for me if I loaded jvm.lisp, but was broken if I compiled jvm.lisp and loaded jvm.abcl. I can't remember what the problem was, or what I did to fix it, or whether I ever checked it in in that broken state. (On a good day, I might fix a dozen compiler bugs and introduce a dozen new ones, so it's hard for me to keep all the details in mind.) My best suggestion is to check back later, and in the meantime, Larry's trick of commenting out (load (compile-file "jvm.lisp")) sounds like a reasonable workaround. -Peter |
From: Larry C. <la...@th...> - 2004-08-06 12:03:37
|
Peter Graves said: > Of course, the version of jvm.lisp that I'm using is different from > what's in CVS, and I have no idea what version you guys are using. > > BTW, there's a line near the top of the file that tells you: > > $Id: jvm.lisp,v 1.267 2004/08/05 02:35:34 piso Exp $ I have my problems with ;;; $Id: jvm.lisp,v 1.267 2004/08/05 02:35:34 piso Exp $ and ;;; $Id: jvm.lisp,v 1.263 2004/08/02 02:07:10 piso Exp $ > My best suggestion is to check back later Ok. No sweat. I understand version 0.0.xxx, etc. :) > and in the meantime, Larry's > trick of commenting out (load (compile-file "jvm.lisp")) sounds like a > reasonable workaround. And makes abcl load several seconds faster, too (about 6, I think). Someone had wondered. -- Larry |
From: Andras S. <as...@ma...> - 2004-08-06 13:28:14
|
On Fri, 6 Aug 2004, Peter Graves wrote: > But in any case, I still can't reproduce the problem you guys are > seeing, and I know at least some other people have gotten things to > work (I'm assuming Andras has or he would have said something, and > Cristian Pietsch was able to get abcl to run cl-bench). Indeed, I haven't experienced any build problems. I'm using javac and 1.4.2 JDK. Andras |
From: Gabor M. <me...@ho...> - 2004-08-06 13:32:32
|
On Friday 06 August 2004 13:48, Peter Graves wrote: > So, I've just rebuilt the .java files with Javac (from Sun 1.4.2_03, as > it happens), fired up abcl with Blackdown 1.4.2-rc1, and run COMPILE- > SYSTEM with nary a hiccup. > > Of course, the version of jvm.lisp that I'm using is different from > what's in CVS, and I have no idea what version you guys are using. > > BTW, there's a line near the top of the file that tells you: > > $Id: jvm.lisp,v 1.267 2004/08/05 02:35:34 piso Exp $ > > And indeed, it might be useful to mention the version of jvm.lisp > you're using when you report a compiler problem. It's 1.267 here too. Meanwhile, I switched to Sun's 1.4.2_03 and the problem disappeared. |
From: Peter G. <pe...@ar...> - 2004-08-06 18:36:41
|
On Fri, 06 Aug 2004 at 08:42:11 -0700, glr wrote: > I've attach a zip that fails on my build. The zip contains two > versions of asdf.lisp. The good version was obtained from Peter's > zipped source, the bad version from cvs. The only difference between > them are in the line end conventions (hex 0d0a vs 0a). The good > version (0a) loads and compile like a champ. The bad version blows up. > > I had this problem with both asdf and bit-array-ops. I'm running on > Win2K with Sun's jdk 1.4.2. Aha! Bottom line, abcl (as things stand) isn't going to work reliably with Lisp source files that use Windows line endings (#\return + #\linefeed, as opposed to #\linefeed only). One place there's trouble is with FORMAT strings that use the "ignored newline" feature (Section 22.3.9.3). The #\~ ends up being followed by a #\return, rather than a #\linefeed as expected, and things go south from there. This feature is used in asdf.lisp and bit-array-ops.lisp, which explains the behavior you're seeing. This is clearly a bug in abcl's FORMAT implementation on Windows, which in any case should recognize #\~ followed by the Windows #\newline (which is #\return + #\linefeed) as being an ignored newline. In other words, Windows line endings should work on Windows! BUt I'm going to resist the urge to fix this right away, for a couple of reasons: 1. A purist might argue that on Windows, #\~ followed by #\linefeed should signal an error, just like #\~ followed by #\return on Unix. Doing things that way would mean that you couldn't transparently use the same source files on both platforms. The current situation, albeit buggy, is, I think, slightly better in practice: Unix line endings work on Windows, but not vice versa. 2. The ANSI test suite should include FORMAT tests within the next couple of weeks, at which point it will become much easier to work in that area without inflicting unnoticed collateral damage. So, for the moment, folks who want to run abcl on Windows will have to find some way to work around this problem. A little bit of googling suggests that this may not be easy if you want to follow CVS, since CVS seems to insist on converting the line endings for you when you do a checkout on Windows. The development snapshots do not have this problem: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) But they're not updated on anything close to a daily basis. -Peter |
From: glr <gl...@rc...> - 2004-08-06 18:50:41
|
Not a problem. I'm just curious as to whether or not this was causing others problems. On Fri, 6 Aug 2004 11:36:34 -0700, Peter Graves <pe...@ar...> wrote: > On Fri, 06 Aug 2004 at 08:42:11 -0700, glr wrote: >> I've attach a zip that fails on my build. The zip contains two >> versions of asdf.lisp. The good version was obtained from Peter's >> zipped source, the bad version from cvs. The only difference between >> them are in the line end conventions (hex 0d0a vs 0a). The good >> version (0a) loads and compile like a champ. The bad version blows up. >> >> I had this problem with both asdf and bit-array-ops. I'm running on >> Win2K with Sun's jdk 1.4.2. > > Aha! > > Bottom line, abcl (as things stand) isn't going to work reliably with > Lisp source files that use Windows line endings (#\return + #\linefeed, > as opposed to #\linefeed only). > > One place there's trouble is with FORMAT strings that use the "ignored > newline" feature (Section 22.3.9.3). The #\~ ends up being followed by > a #\return, rather than a #\linefeed as expected, and things go south > from there. This feature is used in asdf.lisp and bit-array-ops.lisp, > which explains the behavior you're seeing. > > This is clearly a bug in abcl's FORMAT implementation on Windows, which > in any case should recognize #\~ followed by the Windows #\newline > (which is #\return + #\linefeed) as being an ignored newline. In other > words, Windows line endings should work on Windows! > > BUt I'm going to resist the urge to fix this right away, for a couple > of reasons: > > 1. A purist might argue that on Windows, #\~ followed by #\linefeed > should signal an error, just like #\~ followed by #\return on Unix. > Doing things that way would mean that you couldn't transparently > use the same source files on both platforms. The current situation, > albeit buggy, is, I think, slightly better in practice: Unix line > endings work on Windows, but not vice versa. > > 2. The ANSI test suite should include FORMAT tests within the next > couple of weeks, at which point it will become much easier to work > in that area without inflicting unnoticed collateral damage. > > So, for the moment, folks who want to run abcl on Windows will have to > find some way to work around this problem. A little bit of googling > suggests that this may not be easy if you want to follow CVS, since CVS > seems to insist on converting the line endings for you when you do a > checkout on Windows. > > The development snapshots do not have this problem: > > http://armedbear.org/j.zip (source) > http://armedbear.org/j-jar.zip (just j.jar) > > But they're not updated on anything close to a daily basis. > > -Peter > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |