Home / Browse / ArmedBear / J / Mail / Archive

ArmedBear / J

Email Archive: armedbear-j-devel (read-only)

2002:	_Jan	_Feb	_Mar	_Apr	_May	_Jun (14)	_Jul (21)	_Aug (27)	_Sep (35)	_Oct (10)	_Nov (26)	_Dec (18)
2003:	_Jan (23)	_Feb (4)	_Mar (9)	_Apr (9)	_May (61)	_Jun (51)	_Jul (35)	_Aug (33)	_Sep (11)	_Oct (70)	_Nov (66)	_Dec (109)
2004:	_Jan (21)	_Feb (1)	_Mar (10)	_Apr (12)	_May (14)	_Jun (46)	_Jul (31)	_Aug (164)	_Sep (51)	_Oct (36)	_Nov (36)	_Dec (16)
2005:	_Jan (41)	_Feb (31)	_Mar (11)	_Apr (15)	_May (24)	_Jun (42)	_Jul (16)	_Aug (13)	_Sep (24)	_Oct (64)	_Nov (20)	_Dec (6)
2006:	_Jan (39)	_Feb (13)	_Mar (19)	_Apr (10)	_May (12)	_Jun (16)	_Jul (2)	_Aug (13)	_Sep (13)	_Oct (18)	_Nov (6)	_Dec (6)
2007:	_Jan (8)	_Feb (51)	_Mar (28)	_Apr (5)	_May (37)	_Jun (20)	_Jul (12)	_Aug (22)	_Sep (8)	_Oct (24)	_Nov (11)	_Dec (7)
2008:	_Jan (33)	_Feb (16)	_Mar	_Apr	_May (2)	_Jun (7)	_Jul (4)	_Aug (89)	_Sep (141)	_Oct (136)	_Nov (81)	_Dec (143)
2009:	_Jan (182)	_Feb (100)	_Mar (119)	_Apr (91)	_May (112)	_Jun (32)	_Jul (7)	_Aug	_Sep (4)	_Oct (11)	_Nov (5)	_Dec (3)
2010:	_Jan (25)	_Feb	_Mar	_Apr	_May (2)	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec
2011:	_Jan	_Feb	_Mar	_Apr	_May	_Jun (2)	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec
2012:	_Jan	_Feb (1)	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec (1)
2013:	_Jan	_Feb	_Mar (1)	_Apr (1)	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec

[j-devel] recompiling anonymous functions

From: Andras Simon <asimon@ma...> - 2004-08-26 10:06

I think this is a bug:

CL-USER> (compile nil (compile nil (lambda ())))
; Compiling top-level form ...
; Compiled top-level form
; Compiling top-level form ...
; Note: #<SIMPLE-ERROR @ #x1ebf5c>
; Unable to compile top-level form.
NIL
T
T
CL-USER>

From the CLHS chapter on COMPILE:

   If the definition is already a compiled function, compile either
   produces that function itself (i.e., is an identity operation) or an
   equivalent function.

Andras

Re: [j-devel] recompiling anonymous functions

From: Peter Graves <peter@ar...> - 2004-08-26 14:28

On Thu, 26 Aug 2004 at 12:06:00 +0200, Andras Simon wrote:
> I think this is a bug:
>
> CL-USER> (compile nil (compile nil (lambda ())))
> ; Compiling top-level form ...
> ; Compiled top-level form
> ; Compiling top-level form ...
> ; Note: #<SIMPLE-ERROR @ #x1ebf5c>
> ; Unable to compile top-level form.
> NIL
> T
> T

Not one bug but two (the error message was broken as well).

Both of them are now fixed in CVS.

Thanks!

-Peter

Re: [j-devel] recompiling anonymous functions

From: Andras Simon <asimon@ma...> - 2004-08-27 08:22

On Thu, 26 Aug 2004, Peter Graves wrote:

> Not one bug but two (the error message was broken as well).
>
> Both of them are now fixed in CVS.

Thanks!

There is, however a new compiler bug, introduced in jvm.lisp 1.289:
compiling a file with

(defmacro foo ()
   (flet ((bar (x) x))
     (bar '(progn))))

in it gives

; Processing macro FOO
java.lang.reflect.InvocationTargetException
 	at
 	sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 	Method)
 	at
 	sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 	at
 	sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 	at
 	java.lang.reflect.Constructor.newInstance(Constructor.java:274)
 	at org.armedbear.lisp.CompiledFunction$2.execute(Unknown
 	Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.compile_file_4.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.compile_file_13.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Primitives$18.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.precompiler_63.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall1(Unknown Source)
 	at org.armedbear.lisp.Lisp$1.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.top_level_37.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.top_level_38.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall0(Unknown Source)
 	at org.armedbear.lisp.Interpreter.run(Unknown Source)
 	at org.armedbear.lisp.Main.main(Unknown Source)
Caused by: org.armedbear.lisp.Go
        at org.armedbear.lisp.compile_file_8.execute(Unknown Source)
        at org.armedbear.lisp.CompiledClosure.execute(Unknown Source)
        at org.armedbear.lisp.LispThread.execute(Unknown Source)
        at org.armedbear.lisp.signal_1.execute(Unknown Source)
        at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
        at org.armedbear.lisp.Lisp.signal(Unknown Source)
        at org.armedbear.lisp.Lisp.loadCompiledFunction(Unknown Source)
        at org.armedbear.lisp.sw_1.<init>(Unknown Source)
        ... 27 more

[1] CL-USER(17): :bt
   0: (BACKTRACE-AS-LIST)
   1: (SYSTEM::LOAD-COMPILED-FUNCTION "/tmp/sw-1.cls")
   2: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFMACRO FOO NIL (FLET ((BAR (X)
   X)) (BAR '(PROGN)))) #<FILE-STREAM @ #x7aa187> NIL)
   3: (COMPILE-FILE "/tmp/sw.cl")
   4: (SYSTEM::%EVAL (COMPILE-FILE "/tmp/sw.cl"))
   5: (EVAL (COMPILE-FILE "/tmp/sw.cl"))
   6: (SYSTEM::INTERACTIVE-EVAL (COMPILE-FILE "/tmp/sw.cl"))
   7: (TOP-LEVEL::REPL)
   8: (TOP-LEVEL::TOP-LEVEL-LOOP)


Reverting to 1.288 is a good temporary fix.

Andras

Re: [j-devel] recompiling anonymous functions

From: Andras Simon <asimon@ma...> - 2004-08-27 12:14

On Fri, 27 Aug 2004, Andras Simon wrote:

>
> Reverting to 1.288 is a good temporary fix.
>

Well, not completely, because of the relative pathnames.

Andras

Re: [j-devel] recompiling anonymous functions

From: Peter Graves <peter@ar...> - 2004-08-27 15:02

On Fri, 27 Aug 2004 at 14:14:14 +0200, Andras Simon wrote:
> > Reverting to 1.288 is a good temporary fix.
> >
>
> Well, not completely, because of the relative pathnames.

I'm working on a proper fix.

In the meantime, I think the problem only occurs if you're doing
COMPILE-FILE on a file that's not in the current directory (i.e. not in
the directory pointed to by *DEFAULT-PATHNAME-DEFAULTS*), so a
workaround is not to do that... ;)

-Peter

Re: [j-devel] recompiling anonymous functions

From: Peter Graves <peter@ar...> - 2004-08-27 16:27

On Fri, 27 Aug 2004 at 08:02:03 -0700, Peter Graves wrote:
> In the meantime, I think the problem only occurs if you're doing
> COMPILE-FILE on a file that's not in the current directory (i.e. not
> in the directory pointed to by *DEFAULT-PATHNAME-DEFAULTS*), so a
> workaround is not to do that... ;)

I've just checked in a new version of compile-file.lisp that seems to
work correctly in this situation with version 1.289 of jvm.lisp.

Please let me know if there's a scenario that's still broken.

-Peter

Re: [j-devel] recompiling anonymous functions

From: Andras Simon <asimon@ma...> - 2004-08-27 18:00

On Fri, 27 Aug 2004, Peter Graves wrote:

> I've just checked in a new version of compile-file.lisp that seems to
> work correctly in this situation with version 1.289 of jvm.lisp.
>
> Please let me know if there's a scenario that's still broken.

There is... but now I can't reproduce it with a small example. 
What happens is that when compiling slime, I get

; Processing macro DESTRUCTURE-CASE
java.lang.reflect.InvocationTargetException
 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 	at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
 	at org.armedbear.lisp.CompiledFunction$2.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.compile_file_4.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.compile_file_6.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.compile_file_13.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Primitives$48.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators$8.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Primitives$137.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators._let(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators.access$000(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators$3.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Primitives$134.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators._let(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators.access$000(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators$3.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Primitives$136.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators._let(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators.access$000(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators$3.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.dolist.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators._let(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators.access$000(Unknown Source)
 	at org.armedbear.lisp.SpecialOperators$3.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Primitives$136.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Closure.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Load.loadStream(Unknown Source)
 	at org.armedbear.lisp.Load.loadFileFromStream(Unknown Source)
 	at org.armedbear.lisp.Load.load(Unknown Source)
 	at org.armedbear.lisp.Load$3.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.load_1.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Lisp.eval(Unknown Source)
 	at org.armedbear.lisp.Primitives$18.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.precompiler_63.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall1(Unknown Source)
 	at org.armedbear.lisp.Lisp$1.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.top_level_37.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.top_level_38.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.funcall0(Unknown Source)
 	at org.armedbear.lisp.Interpreter.run(Unknown Source)
 	at org.armedbear.lisp.Main.main(Unknown Source)
Caused by: org.armedbear.lisp.Go
 	at org.armedbear.lisp.compile_file_5.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledClosure.execute(Unknown Source)
 	at org.armedbear.lisp.LispThread.execute(Unknown Source)
 	at org.armedbear.lisp.signal_1.execute(Unknown Source)
 	at org.armedbear.lisp.CompiledFunction.execute(Unknown Source)
 	at org.armedbear.lisp.Lisp.signal(Unknown Source)
 	at org.armedbear.lisp.Lisp.loadCompiledFunction(Unknown Source)
 	at org.armedbear.lisp.swank_41.<init>(Unknown Source)
 	... 73 more
Error loading #P"/home/simon/lisp_packages/slime-cvs/slime/swank-loader.lisp" at line 104 (offset 4124).
Debugger invoked on condition of type ERROR:
   Unable to load #P"/home/simon/.slime/fasl/abcl/swank-41.cls"
Restarts:
   0: TOP-LEVEL Return to top level.
[1] SWANK(2): :bt
   0: (EXTENSIONS:BACKTRACE-AS-LIST)
   1: (SYSTEM::LOAD-COMPILED-FUNCTION "/home/simon/.slime/fasl/abcl/swank-41.cls")
   2: (SYSTEM::VERIFY-LOAD "/home/simon/.slime/fasl/abcl/swank-41.cls")
   3: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFMACRO DESTRUCTURE-CASE (VALUE &REST PATTERNS) "Dispatch VALUE to one of PATTERNS.
A cross between `case' and `destructuring-bind'.
The pattern syntax is:
   ((HEAD . ARGS) . BODY)
The list of patterns is searched for a HEAD `eq' to the car of
VALUE. If one is found, the BODY is executed with ARGS bound to the
corresponding values in the CDR of VALUE." (LET ((OPERATOR (GENSYM "op-")) (OPERANDS (GENSYM "rand-")) (TMP (GENSYM "tmp-"))) (COMMON-LISP::BACKQUOTE (LET* (((COMMON-LISP::COMMA TMP) (COMMON-LISP::COMMA VALUE)) ((COMMON-LISP::COMMA OPERATOR) (CAR (COMMON-LISP::COMMA TMP))) ((COMMON-LISP::COMMA OPERANDS) (CDR (COMMON-LISP::COMMA TMP)))) (CASE (COMMON-LISP::COMMA OPERATOR) (COMMON-LISP::COMMA-ATSIGN (MAPCAR (LAMBDA (CLAUSE) (IF (EQ (CAR CLAUSE) T) (COMMON-LISP::BACKQUOTE (T (COMMON-LISP::COMMA-ATSIGN (CDR CLAUSE)))) (DESTRUCTURING-BIND ((OP &REST RANDS) &REST BODY) CLAUSE (COMMON-LISP::BACKQUOTE ((COMMON-LISP::COMMA OP) (DESTRUCTURING-BIND (COMMON-LISP::COMMA RANDS) (COMMON-LISP::COMMA OPERANDS) COMMON-LISP::COMMA BODY)))))) PATTERNS)) (COMMON-LISP::COMMA-ATSIGN (IF (EQ (CAAR (LAST PATTERNS)) T) 'NIL (COMMON-LISP::BACKQUOTE ((T (ERROR "destructure-case failed: ~S" (COMMON-LISP::COMMA TMP)))))))))))) #<FILE-STREAM @ #x1c1eceb> NIL)
   4: (COMPILE-FILE #P"/home/simon/lisp_packages/slime-cvs/slime/swank.lisp" :OUTPUT-FILE #P"/home/simon/.slime/fasl/abcl/swank.abcl")
   5: (SWANK-LOADER::COMPILE-FILES-IF-NEEDED-SERIALLY (#P"/home/simon/lisp_packages/slime-cvs/slime/swank-backend.lisp" #P"/home/simon/lisp_packages/slime-cvs/slime/nregex.lisp" #P"/home/simon/lisp_packages/slime-cvs/slime/swank-abcl.lisp" #P"/home/simon/lisp_packages/slime-cvs/slime/swank-gray.lisp" #P"/home/simon/lisp_packages/slime-cvs/slime/swank.lisp"))
   6: (SYSTEM::%LOAD "/home/simon/lisp_packages/slime-cvs/slime/swank-loader.lisp" T NIL T)
   7: (LOAD "/home/simon/lisp_packages/slime-cvs/slime/swank-loader.lisp")
   8: (SYSTEM::%EVAL (LOAD "/home/simon/lisp_packages/slime-cvs/slime/swank-loader.lisp"))
   9: (EVAL (LOAD "/home/simon/lisp_packages/slime-cvs/slime/swank-loader.lisp"))
   10: (SYSTEM::INTERACTIVE-EVAL (LOAD "/home/simon/lisp_packages/slime-cvs/slime/swank-loader.lisp"))
   11: (TOP-LEVEL::REPL)
   12: (TOP-LEVEL::TOP-LEVEL-LOOP)
[1] SWANK(3):

But if I put the offending form in a separate file and compile that, it's fine.

Andras

Re: [j-devel] recompiling anonymous functions

From: Andras Simon <asimon@ma...> - 2004-08-27 18:12

On Fri, 27 Aug 2004, Andras Simon wrote:

>
> But if I put the offending form in a separate file and compile that, it's 
> fine.

It's worse than that: the process is undeterministic. After two
unsuccesful attempts, now I got it compiled without a hitch. (And I
removed the abcl and the cls files in between the attempts.) Scary.

Andras

Re: [j-devel] recompiling anonymous functions

From: Peter Graves <peter@ar...> - 2004-08-27 18:18

On Fri, 27 Aug 2004 at 19:59:56 +0200, Andras Simon wrote:
> > Please let me know if there's a scenario that's still broken.
>
> There is... but now I can't reproduce it with a small example. 
> What happens is that when compiling slime, I get

[...]

>    4: (COMPILE-FILE #P"/home/simon/lisp_packages/slime-cvs/slime/swank.lisp" :OUTPUT-FILE #P"/home/simon/.slime/fasl/abcl/swank.abcl")

I suspect the problem is :OUTPUT-FILE in a different directory. I'll
look into it.

-Peter

Re: [j-devel] recompiling anonymous functions

From: Andras Simon <asimon@ma...> - 2004-08-27 18:30

On Fri, 27 Aug 2004, Peter Graves wrote:

> I suspect the problem is :OUTPUT-FILE in a different directory. I'll
> look into it.

I tried to compile a file with the offending DEFMACRO form with
:OUTPUT-FILE in a different directory, but it doesn't seem to make
difference (ie., it compiles just fine). Also, this wouldn't explain
the nondeterminism.

Andras

Re: [j-devel] recompiling anonymous functions

From: Peter Graves <peter@ar...> - 2004-08-27 19:39

On Fri, 27 Aug 2004 at 20:30:01 +0200, Andras Simon wrote:
> I tried to compile a file with the offending DEFMACRO form with
> :OUTPUT-FILE in a different directory, but it doesn't seem to make
> difference (ie., it compiles just fine). Also, this wouldn't explain
> the nondeterminism.

I just checked in a fix for an obvious error in compile-file.lisp.

Doing (load "swank-loader") in the slime directory seems to work
correctly now.

I'm not too worried about the nondeterminism. I think it probably had
to do with what directory you were in when you started abcl and what
the value of *DEFAULT-PATHNAME-DEFAULTS* was when you did (load "swank-
loader"). Running under emacs might have muddied the waters a bit too.

I'll take another look at all of this next week.

On the subject of slime, it looks like there might be some weird
interactions between Gray streams and pretty-printing streams that will
need to be ironed out as part of the ongoing pretty printer cleanup
work.

-Peter

Re: [j-devel] recompiling anonymous functions

From: Andras Simon <asimon@ma...> - 2004-08-27 20:17

On Fri, 27 Aug 2004, Peter Graves wrote:

> On Fri, 27 Aug 2004 at 20:30:01 +0200, Andras Simon wrote:
>> I tried to compile a file with the offending DEFMACRO form with
>> :OUTPUT-FILE in a different directory, but it doesn't seem to make
>> difference (ie., it compiles just fine). Also, this wouldn't explain
>> the nondeterminism.
>
> I just checked in a fix for an obvious error in compile-file.lisp.

I'll try it.

>
> Doing (load "swank-loader") in the slime directory seems to work
> correctly now.
>
> I'm not too worried about the nondeterminism. I think it probably had
> to do with what directory you were in when you started abcl and what
> the value of *DEFAULT-PATHNAME-DEFAULTS* was when you did (load "swank-
> loader"). Running under emacs might have muddied the waters a bit too.

In all cases, I started emacs (and then slime) from the same directory.

>
> I'll take another look at all of this next week.

Thanks!

>
> On the subject of slime, it looks like there might be some weird
> interactions between Gray streams and pretty-printing streams that will
> need to be ironed out as part of the ongoing pretty printer cleanup
> work.

That'd be great!

I've noticed one (new) problem: when there is an error in the
listener, instead of the *sldb* buffer popping up, abcl gets into an
infinite recursion. Replacing PPRINT with PRINT in PRINT-FRAME (in
swank-abcl.lisp) is a workaround for now.

Andras

3 messages have been excluded from this view by a project administrator.