From: Andras S. <as...@ma...> - 2004-09-24 14:15:30
|
(defun listener-eval (&rest x)) (let ((*print-circle* t)) (pprint (list 'apply '((listener-eval "(setq a (backtrace-as-list)) ") "COMMON-LISP-USER" 123)))) Debugger invoked on condition of type TYPE-ERROR: The value #S(XP::XP-STRUCTURE :BASE-STREAM #<STREAM @ #x17cd15d> :LINEL 70 .....) is not of type character output stream. I would've liked to trigger the bug with a simpler case but this is how far I could get. Andras |
From: Peter G. <pe...@ar...> - 2004-09-24 18:40:11
|
On Fri, 24 Sep 2004 at 16:15:26 +0200, Andras Simon wrote: > (defun listener-eval (&rest x)) > > (let ((*print-circle* t)) > (pprint (list 'apply > '((listener-eval "(setq a (backtrace-as-list)) ") > "COMMON-LISP-USER" > 123)))) > > Debugger invoked on condition of type TYPE-ERROR: > The value #S(XP::XP-STRUCTURE :BASE-STREAM #<STREAM @ #x17cd15d> :LINEL 70 .....) is not of type character output stream. > > I would've liked to trigger the bug with a simpler case but this is > how far I could get. This is more or less a known problem; printing is a bit sketchy when *PRINT-CIRCLE* is T. There are a number of ANSI test failures related to this. I'll take a look at this particular example as soon as I finish with the 0.21.0 release, which is taking a little longer (well, really a lot longer) than I expected. It turns out that when you don't do a full release for nearly a year, bit rot takes over in unexpected places. And at the last minute I decided to integrate COMPILE-SYSTEM into the build process... If all goes well, 0.21.0 will be released tomorrow morning, and then I can get back to work fixing bugs. Thanks for your support. -Peter |
From: Andras S. <as...@ma...> - 2004-09-25 11:44:59
|
On Fri, 24 Sep 2004, Peter Graves wrote: > This is more or less a known problem; printing is a bit sketchy when > *PRINT-CIRCLE* is T. There are a number of ANSI test failures related > to this. Then you needn't bother with this particular example (of course unless it helps tracking down major bugs). Its only visible effect is that slime cannot pprint frames - not a big deal. Andras |
From: Peter G. <pe...@ar...> - 2004-10-08 14:46:40
|
On Fri, 24 Sep 2004 at 16:15:26 +0200, Andras Simon wrote: > (defun listener-eval (&rest x)) > > (let ((*print-circle* t)) > (pprint (list 'apply > '((listener-eval "(setq a (backtrace-as-list)) ") > "COMMON-LISP-USER" > 123)))) > > Debugger invoked on condition of type TYPE-ERROR: > The value #S(XP::XP-STRUCTURE :BASE-STREAM #<STREAM @ #x17cd15d> :LINEL 70 .....) is not of type character output stream. > > I would've liked to trigger the bug with a simpler case but this is > how far I could get. This morning I checked in new versions of print.lisp and pprint.lisp that fix this bug. I've spent the last two weeks working on ABCL's printer (and pretty printer). One big change is that pprint.lisp is now loaded directly in boot.lisp. In previous versions, the pretty printer was autoloaded, in the hope of making startup faster, but that led to a number of other problems (including this particular bug), and it turned out that the startup cost is not very high after all. With these changes, ABCL in current CVS fails 114 out of 18159 tests in the ANSI test suite, down from 164 failures out of 17942 tests two weeks ago. The apparent hang in PRINT.CONS.RANDOM.2 (which I've commented out for now) is really due to ABCL's awful CLOS slowness and not to any issue with the test or what it's primarily testing; reducing N from 50 to 10 allows the test to finish without error on the same day it starts. There are still some printer-related test failures, mostly having to do with the pretty-printing of circular lists. Barring interrupts, my next project (starting today) will be to fix the aforementioned awful CLOS slowness. Thanks for your support. -Peter |
From: Andras S. <as...@ma...> - 2004-10-08 18:38:21
|
On Fri, 8 Oct 2004, Peter Graves wrote: > On Fri, 24 Sep 2004 at 16:15:26 +0200, Andras Simon wrote: >> (defun listener-eval (&rest x)) >> >> (let ((*print-circle* t)) >> (pprint (list 'apply >> '((listener-eval "(setq a (backtrace-as-list)) ") >> "COMMON-LISP-USER" >> 123)))) >> >> Debugger invoked on condition of type TYPE-ERROR: >> The value #S(XP::XP-STRUCTURE :BASE-STREAM #<STREAM @ #x17cd15d> :LINEL 70 .....) is not of type character output stream. >> >> I would've liked to trigger the bug with a simpler case but this is >> how far I could get. > > This morning I checked in new versions of print.lisp and pprint.lisp > that fix this bug. Thanks Peter, this fix lets me pretty print frames in backtraces in slime, which makes them much more readable. > With these changes, ABCL in current CVS fails 114 out of 18159 tests in > the ANSI test suite, down from 164 failures out of 17942 tests two > weeks ago. Impressive figures! > Barring interrupts, my next project (starting today) will be to fix the > aforementioned awful CLOS slowness. Perhaps this is a good time to ask why you decided to adapt closette, and not pcl (or its CMUCL/SBCL version). Just curious. Andras |
From: Peter G. <pe...@ar...> - 2004-10-08 20:00:59
|
On Fri, 8 Oct 2004 at 20:38:11 +0200, Andras Simon wrote: > Perhaps this is a good time to ask why you decided to adapt closette, > and not pcl (or its CMUCL/SBCL version). Just curious. Well, it was a long time ago, and there was really no hope of getting ABCL to run PCL at that time. I don't think the CMUCL and SBCL versions of PCL are really very portable, despite the name. Closette had the advantage of being much smaller and more approachable (less than 2000 lines vs. around 20,000 lines for PCL). And at the time I started working with Closette I hadn't really decided to do a full ANSI CL, so I was even entertaining the crazy idea that Closette might end up being enough of a CLOS by itself. In the long term I think most of the Closette code will go away and ABCL will end up with a more-or-less home-grown CLOS implementation, but in the early days Closette provided a useful outline for the code and a rough framework to build on. Performance is terrible, but that's mostly my fault. -Peter |
From: Andras S. <as...@ma...> - 2004-10-09 14:15:01
|
On Fri, 8 Oct 2004, Peter Graves wrote: > On Fri, 8 Oct 2004 at 20:38:11 +0200, Andras Simon wrote: >> Perhaps this is a good time to ask why you decided to adapt closette, >> and not pcl (or its CMUCL/SBCL version). Just curious. > > Well, it was a long time ago, and there was really no hope of getting > ABCL to run PCL at that time. I don't think the CMUCL and SBCL versions > of PCL are really very portable, despite the name. Yes, I suppose portability was lost when it got ported (to CMUCL). > Closette had the advantage of being much smaller and more approachable > (less than 2000 lines vs. around 20,000 lines for PCL). And at the time > I started working with Closette I hadn't really decided to do a full > ANSI CL, so I was even entertaining the crazy idea that Closette might > end up being enough of a CLOS by itself. > > In the long term I think most of the Closette code will go away and > ABCL will end up with a more-or-less home-grown CLOS implementation, I know that ANSI compliance is your no. 1 target, but I hope the home-grown CLOS will have at least as much of the MOP as closette does. > but in the early days Closette provided a useful outline for the code > and a rough framework to build on. Performance is terrible, but that's > mostly my fault. Is it that bad? The only issue I've had with clos (as it is) is not performance, but that it requires BAR to be defined before (defclass foo (bar)()) can be evaluated. But I guess this is one of the known ANSI test failures. Andras |
From: Peter G. <pe...@ar...> - 2004-10-09 15:36:06
|
On Sat, 9 Oct 2004 at 16:14:45 +0200, Andras Simon wrote: > I know that ANSI compliance is your no. 1 target, but I hope the > home-grown CLOS will have at least as much of the MOP as closette > does. The long-term goal is to have a full MOP implementation (for some value of "full"). > > but in the early days Closette provided a useful outline for the code > > and a rough framework to build on. Performance is terrible, but that's > > mostly my fault. > > Is it that bad? It's pretty bad, but it should be easy to improve. Teaching the compiler about generic functions should make a big difference! > The only issue I've had with clos (as it is) is not performance, but > that it requires BAR to be defined before (defclass foo (bar)()) can > be evaluated. But I guess this is one of the known ANSI test failures. Right. I hope to clean up all the CLOS-related ANSI test failures as part of the current effort. -Peter |