From: Dr. T. S. <st...@re...> - 2009-11-15 17:45:47
Attachments:
smime.p7s
|
Hi, I am experimenting with bootstrapping the computer algebra system Reduce on ABCL. I now have encountered a problem, which might be a bug in the ABCL compiler. I give a simplified version of my situation. (compile-file "test") where test.lisp has the following content does not terminate: (defparameter single-character-symbols '#.(let ((a (make-array 129))) (dotimes (i 129) (setf (svref a i) (make-string 1 :initial-element (code-char i)))) a)) When replacing 129 by 128 everything is fine. The size that I actually would like to have there is 256. If this is really a bug, I would be grateful for any hint on a possible workaround. Thanks, Thomas -- Thomas Sturm Departamento de Matematicas, Estadistica y Computacion Universidad de Cantabria, Santander, Spain Avda. Los Castros s/n, Room 1072, +34 693 251058 http://personales.unican.es/sturmt/ |
From: Alessio S. <ale...@gm...> - 2009-11-15 20:37:10
|
On Sun, Nov 15, 2009 at 6:26 PM, Dr. Thomas Sturm <st...@re...> wrote: > Hi, > > I am experimenting with bootstrapping the computer algebra system Reduce on ABCL. I now have encountered a problem, which might be a bug in the ABCL compiler. I give a simplified version of my situation. > > (compile-file "test") where test.lisp has the following content does not terminate: > > (defparameter single-character-symbols > '#.(let ((a (make-array 129))) > (dotimes (i 129) > (setf (svref a i) (make-string 1 :initial-element (code-char i)))) > a)) > > When replacing 129 by 128 everything is fine. The size that I actually would like to have there is 256. > > If this is really a bug, I would be grateful for any hint on a possible workaround. Hello, I couldn't reproduce the bug on my copy of abcl, which is the latest revision from svn. So either it has been fixed after 0.17, or it depends on certain circumstances which are not apparent from your mail (e.g. a specific platform, JVM version, something you did before compiling the file, ...). Can you provide us with more information? Thanks, Alessio |
From: Dr. T. S. <st...@re...> - 2009-11-15 21:04:09
Attachments:
smime.p7s
|
I am using a 64-bit Mac with Snow Leopard (Mac OSX 10.6.2). I didi not do anything special but simply went (compile-file "test") in a fresh session. Here is my banner of ABCL: sturm@lennier[~] abcl Armed Bear Common Lisp 0.17.0 Java 1.6.0_15 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.348 seconds. Startup completed in 0.936 seconds. Type ":help" for a list of available commands. CL-USER(1): The ABCL is not from the svn but the 0.17.0 distribution as of last Saturday. Do you also succeed when increasing the 129 to 256? I am going to try the ABCL on a (virtual) 64 bit Ubuntu and I will also check out the svn version. Thanks for your quick reply! Thomas Am 15.11.2009 um 21:30 schrieb Alessio Stalla: > On Sun, Nov 15, 2009 at 6:26 PM, Dr. Thomas Sturm <st...@re...> wrote: >> Hi, >> >> I am experimenting with bootstrapping the computer algebra system Reduce on ABCL. I now have encountered a problem, which might be a bug in the ABCL compiler. I give a simplified version of my situation. >> >> (compile-file "test") where test.lisp has the following content does not terminate: >> >> (defparameter single-character-symbols >> '#.(let ((a (make-array 129))) >> (dotimes (i 129) >> (setf (svref a i) (make-string 1 :initial-element (code-char i)))) >> a)) >> >> When replacing 129 by 128 everything is fine. The size that I actually would like to have there is 256. >> >> If this is really a bug, I would be grateful for any hint on a possible workaround. > > Hello, > I couldn't reproduce the bug on my copy of abcl, which is the latest > revision from svn. So either it has been fixed after 0.17, or it > depends on certain circumstances which are not apparent from your mail > (e.g. a specific platform, JVM version, something you did before > compiling the file, ...). Can you provide us with more information? > > Thanks, > Alessio -- Thomas Sturm Departamento de Matematicas, Estadistica y Computacion Universidad de Cantabria, Santander, Spain Avda. Los Castros s/n, Room 1072, +34 693 251058 http://personales.unican.es/sturmt/ |
From: Mark E. <ev...@pa...> - 2009-11-15 21:08:58
|
On 11/15/09 10:03 PM, Dr. Thomas Sturm wrote: > I am using a 64-bit Mac with Snow Leopard (Mac OSX 10.6.2). I didi not do anything special but simply went (compile-file "test") in a fresh session. > > Here is my banner of ABCL: > > sturm@lennier[~] abcl > Armed Bear Common Lisp 0.17.0 > Java 1.6.0_15 Apple Inc. > Java HotSpot(TM) 64-Bit Server VM > Low-level initialization completed in 0.348 seconds. > Startup completed in 0.936 seconds. > Type ":help" for a list of available commands. > CL-USER(1): > > The ABCL is not from the svn but the 0.17.0 distribution as of last Saturday. […] I can reproduce your problem as well with ABCL trunk under the same OS/JVM. No idea yet on fixing it, but I will file a bug report for you. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Erik H. <eh...@gm...> - 2009-12-30 23:30:14
|
On Sun, Nov 15, 2009 at 6:26 PM, Dr. Thomas Sturm <st...@re...> wrote: > Hi, > > I am experimenting with bootstrapping the computer algebra system Reduce on ABCL. I now have encountered a problem, which might be a bug in the ABCL compiler. I give a simplified version of my situation. > > (compile-file "test") where test.lisp has the following content does not terminate: > > (defparameter single-character-symbols > '#.(let ((a (make-array 129))) > (dotimes (i 129) > (setf (svref a i) (make-string 1 :initial-element (code-char i)))) > a)) > > When replacing 129 by 128 everything is fine. The size that I actually would like to have there is 256. > > If this is really a bug, I would be grateful for any hint on a possible workaround. Well, I finally got around to checking this issue: you indeed identified a bug. Unfortunately it's not easy to work around, because it has to do with the fact that your output encoding doesn't seem to support the specific character (character 0x80, that is). The weird thing is that the strategy is to replace characters that can't be encoded, so there's a big question mark here as to why this error occurs. Anyway, we have a new interesting test case to add to the tests for our RandomAccessCharacterFile class. Locally, I patched ABCL to create UTF-8 output files, but that would require you to patch the Load part of ABCL to read UTF-8 input as well. Since I can't really do that as simple as that, I can't fix it right now. However, if you're fine using UTF-8 for input for LOAD, I could provide you with a patch. Bye, Erik. |
From: Erik H. <eh...@gm...> - 2010-01-04 10:36:28
|
Hi Thomas, >> (compile-file "test") where test.lisp has the following content does not terminate: >> >> (defparameter single-character-symbols >> '#.(let ((a (make-array 129))) >> (dotimes (i 129) >> (setf (svref a i) (make-string 1 :initial-element (code-char i)))) >> a)) >> >> When replacing 129 by 128 everything is fine. The size that I actually would like to have there is 256. >> >> If this is really a bug, I would be grateful for any hint on a possible workaround. As stated before, there's no workaround; however, I have a local patch which will be included in 0.18 (scheduled to be released this month) which completely cures the problem: FASLs should support all characters that can be constructed in-memory, meaning they should be any kind of encoded unicode. I chose UTF-8, because I expect our FASLs to be mostly ASCII, in which case UTF-8 is an efficient encoding. > Well, I finally got around to checking this issue: you indeed > identified a bug. Unfortunately it's not easy to work around, because > it has to do with the fact that your output encoding doesn't seem to > support the specific character (character 0x80, that is). > > The weird thing is that the strategy is to replace characters that > can't be encoded, so there's a big question mark here as to why this > error occurs. Anyway, we have a new interesting test case to add to > the tests for our RandomAccessCharacterFile class. I found the issue: when *en*coding, we don't replace. When decoding (ie. reading existing data) we *do* replace. Replacing on encoding would destroy data integrity. That's why we chose not to do it. However, it generates errors now in case a character can't be encoded. > Locally, I patched ABCL to create UTF-8 output files, but that would > require you to patch the Load part of ABCL to read UTF-8 input as > well. Since I can't really do that as simple as that, I can't fix it > right now. However, if you're fine using UTF-8 for input for LOAD, I > could provide you with a patch. Above mentioned patch does exactly this: set the encoding on the stream loaded from to UTF-8. I expect this patch to be committed this week. I hope that addresses your problem. With kind regards, Erik. |
From: Erik H. <eh...@gm...> - 2010-01-04 22:17:14
|
Just to keep you up to date: > Above mentioned patch does exactly this: set the encoding on the > stream loaded from to UTF-8. I expect this patch to be committed this > week. I hope that addresses your problem. I had some time to add the required code comments and optimizations today. I tested it the way I usually do. The fix is now in the development version of ABCL; if you want to test it, please check out the latest version of trunk/ Bye, Erik. |