I'm trying to set up lep/eli with sbcl, but with very limited
success. (If you are an eli addict like me, and don't know about it,
the link for lep is at http://www.cliki.net/ELI.) After starting up it
says
debugger invoked on condition of type TYPE-ERROR:
The value T is not of type (OR (VECTOR NIL) BASE-STRING PATHNAME
FILE-STREAM).
I can hack my way through this by
(lep::start-emacs-lisp-interface
:announce-to-stream *standard-output*)
and then there is a connection to lisp, and fi:lisp-arglist,
fi:lisp-macroexpand works (although the *background-interaction*
buffer pops up and it shouldn't). Even opening a new listener in a new
frame works, and symbol completion behaves somewhat better in the new
listener (in the old one it gives "Args out of range: 3813, 3816" kind
of errors, in the new one it prints the completion in the
*background-interaction* buffer).
Does anyone use lep with sbcl? Is there something I'm missing? Or is
it just the alphaness of this lep implementation?
Andras
······@math.bme.hu (Simon Andr�s) writes:
> debugger invoked on condition of type TYPE-ERROR:
> The value T is not of type (OR (VECTOR NIL) BASE-STRING PATHNAME
> FILE-STREAM).
That should not happen. Can you send me a stacktrace?
(Though it may well be that I broke something for the `normal' startup
procedure, since I do not start the Lisp from Emacs anymore. Instead, I
run Lisp and LEP in a separate terminal, and use the listener binary to
connect later. That way Lisp and Emacs can be restarted independently,
and LEP communication hickups can be solved by reconnecting.)
> Does anyone use lep with sbcl? Is there something I'm missing? Or is
> it just the alphaness of this lep implementation?
That is mostly the alphaness. It is also depending on the quickly
changing sb-simple-streams and sb-thread implementations.
But those extensions are getting better and better, and Luke Gorrie's
SLIME is receiving a lot of attention, too. Everyone seems to be
looking for a stable and free Lisp development environment these days.
David
David Lichteblau <············@lichteblau.com> writes:
> ······@math.bme.hu (Simon Andr�s) writes:
>> debugger invoked on condition of type TYPE-ERROR:
>> The value T is not of type (OR (VECTOR NIL) BASE-STRING PATHNAME
>> FILE-STREAM).
>
> That should not happen. Can you send me a stacktrace?
Actually, I can guess what this one is about, because I think it
happened to me as well.
(defun invoke-with-stream (fn stream-or-pathname open-args)
(if (or (streamp stream-or-pathname) (eql stream-or-pathname t))
(funcall fn stream-or-pathname)
(with-open-stream (s (apply #'open stream-or-pathname open-args))
(funcall fn s))))
... something calls invoke-with-stream expecting that T will work as a
stream designator.
> That is mostly the alphaness. It is also depending on the quickly
> changing sb-simple-streams and sb-thread implementations.
>
> But those extensions are getting better and better, and Luke Gorrie's
> SLIME is receiving a lot of attention, too. Everyone seems to be
> looking for a stable and free Lisp development environment these days.
Indeed. We're also in the process of developing a supported(sic)
interface to the necessary internals, so that all these IDE authors
don't have to keep dipping into SBCL internals.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
David Lichteblau <············@lichteblau.com> writes:
> ······@math.bme.hu (Simon Andr�s) writes:
> > debugger invoked on condition of type TYPE-ERROR:
> > The value T is not of type (OR (VECTOR NIL) BASE-STRING PATHNAME
> > FILE-STREAM).
>
> That should not happen. Can you send me a stacktrace?
Not easily :-( I don't know how to get the backtrace of a background
process in sbcl. But I think I know what happens:
The :announce-to-stream argument to start-emacs-lisp-interface
defaults to t, so the expansion of the with-stream macro calls
invoke-with-stream with t as its second argument, and so
invoke-with-stream tries to open t.
> (Though it may well be that I broke something for the `normal' startup
> procedure, since I do not start the Lisp from Emacs anymore. Instead, I
> run Lisp and LEP in a separate terminal, and use the listener binary to
> connect later. That way Lisp and Emacs can be restarted independently,
> and LEP communication hickups can be solved by reconnecting.)
Nice! And I didn't have any trouble starting lep this way. But the
other problems (with symbol completion, arglist, etc.) I mentioned in
my previous post are still there. Any ideas on what/how I should
investigate?
BTW I could only compile listener.c and eval.c by moving declarations
around a bit.
> That is mostly the alphaness. It is also depending on the quickly
> changing sb-simple-streams and sb-thread implementations.
OK, so I should've mentioned that I was using sbcl 0.8.4. Couldn't
some kind of compatibility layer (perhaps acl-compat from portable
aserve) be used to hide those changes? That would have the additional
benefit that lep wouldn't be tied so much to sbcl. I can imagine that
even Lispworks users would be interested in replacing ilisp with
eli. Though I don't know if simple-streams is implemented for LW.
> But those extensions are getting better and better, and Luke Gorrie's
> SLIME is receiving a lot of attention, too. Everyone seems to be
> looking for a stable and free Lisp development environment these
> days.
Out of sheer curiosity, I'll look at SLIME once its sf page is back in
order. But since I'm also using acl, it'd be great if eli worked with
one of the high quality aserve capable free cl's.
Thanks for your reply (and for lep!),
Andras
--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
······@math.bme.hu (Simon Andr=E1s) writes:
> Not easily :-( I don't know how to get the backtrace of a background
> process in sbcl. But I think I know what happens:=20
The UI is kind of primitive (read: non-existent) as yet. If you get a
"debugger invoked ..." report, it means that the thread in question is
now stopped on the terminal io queue. You can stop the current thread
and resume something on the queue with
* (sb-thread:release-foreground)
;; or, perhaps more dependable
* (progn (sb-thread:release-foreground) (sleep 1))
=2D this should then let the debugger start running, and you can use
debugger commands as normal. When you select a restart, the thread
will background itself again before carrying on, so you should get
your original repl back.
>> That is mostly the alphaness. It is also depending on the quickly
>> changing sb-simple-streams and sb-thread implementations.
>
> OK, so I should've mentioned that I was using sbcl 0.8.4. Couldn't
> some kind of compatibility layer (perhaps acl-compat from portable
> aserve) be used to hide those changes? That would have the additional
Realistically, no. These are mostly not interface changes (though
it's clear we need such for the debugger UI ;-) , they're
implementation bug fixes.
> benefit that lep wouldn't be tied so much to sbcl. I can imagine that
> even Lispworks users would be interested in replacing ilisp with
> eli. Though I don't know if simple-streams is implemented for LW.
Possibly in acl-compat, I don't know. That might not be a bad idea
anyway, but unfortunately won't help with the immediate problem.
=2Ddan
=2D-=20
http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQA/hc3LHDK5ZnWQiRMRAgMUAJ9i3Yq1kAZxUT/w7RN/h38y8sTE5wCeMeSq
tUJVlhKn4w850Fb9uqQQ8Zw=
=4yF/
-----END PGP SIGNATURE-----
--=-=-=--
······@math.bme.hu (Simon Andr�s) writes:
> Not easily :-( I don't know how to get the backtrace of a background
> process in sbcl. But I think I know what happens:
The UI is kind of primitive (read: non-existent) as yet. If you get a
"debugger invoked ..." report, it means that the thread in question is
now stopped on the terminal io queue. You can stop the current thread
and resume something on the queue with
* (sb-thread:release-foreground)
;; or, perhaps more dependable
* (progn (sb-thread:release-foreground) (sleep 1))
- this should then let the debugger start running, and you can use
debugger commands as normal. When you select a restart, the thread
will background itself again before carrying on, so you should get
your original repl back.
>> That is mostly the alphaness. It is also depending on the quickly
>> changing sb-simple-streams and sb-thread implementations.
>
> OK, so I should've mentioned that I was using sbcl 0.8.4. Couldn't
> some kind of compatibility layer (perhaps acl-compat from portable
> aserve) be used to hide those changes? That would have the additional
Realistically, no. These are mostly not interface changes (though
it's clear we need such for the debugger UI ;-) , they're
implementation bug fixes.
> benefit that lep wouldn't be tied so much to sbcl. I can imagine that
> even Lispworks users would be interested in replacing ilisp with
> eli. Though I don't know if simple-streams is implemented for LW.
Possibly in acl-compat, I don't know. That might not be a bad idea
anyway, but unfortunately won't help with the immediate problem.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> ······@math.bme.hu (Simon Andr�s) writes:
>
> > Not easily :-( I don't know how to get the backtrace of a background
> > process in sbcl. But I think I know what happens:
>
> The UI is kind of primitive (read: non-existent) as yet. If you get a
> "debugger invoked ..." report, it means that the thread in question is
> now stopped on the terminal io queue. You can stop the current thread
> and resume something on the queue with
>
> * (sb-thread:release-foreground)
>
> ;; or, perhaps more dependable
>
> * (progn (sb-thread:release-foreground) (sleep 1))
>
> - this should then let the debugger start running, and you can use
> debugger commands as normal. When you select a restart, the thread
> will background itself again before carrying on, so you should get
> your original repl back.
Thanks. Here's the backtrace then.
0: (MERGE-PATHNAMES 1 T (:DIRECTION :OUTPUT :IF-EXISTS :SUPERSEDE)
1)[:EXTERNAL]
1: ("varargs entry for OPEN" T :DIRECTION :OUTPUT :IF-EXISTS
:SUPERSEDE)
2: (LEP::INVOKE-WITH-STREAM
#<FUNCTION "CLOSURE" {94A8CCD}>
T
(:DIRECTION :OUTPUT :IF-EXISTS :SUPERSEDE))
3: ("FLET LEP::DOIT")
4: ("FLET LEP::DOIT")
5: ("#'(LAMBDA NIL (LET # # ...))")
6: ("foreign function call land: ra=#x8055071")
7: ("foreign function call land: ra=#x8054ECE")
>
> >> That is mostly the alphaness. It is also depending on the quickly
> >> changing sb-simple-streams and sb-thread implementations.
> >
> > OK, so I should've mentioned that I was using sbcl 0.8.4. Couldn't
> > some kind of compatibility layer (perhaps acl-compat from portable
> > aserve) be used to hide those changes? That would have the additional
>
> Realistically, no. These are mostly not interface changes (though
> it's clear we need such for the debugger UI ;-) , they're
> implementation bug fixes.
Then perhaps the version of sbcl I'm using just doesn't have the right
amount of bugs to satisfy lep.
>
> > benefit that lep wouldn't be tied so much to sbcl. I can imagine that
> > even Lispworks users would be interested in replacing ilisp with
> > eli. Though I don't know if simple-streams is implemented for LW.
>
> Possibly in acl-compat, I don't know. That might not be a bad idea
> anyway, but unfortunately won't help with the immediate problem.
No, not in acl-compat. Portable aserve is a Gray area, I think.
Andras
>
>
> -dan
>
> --
>
> http://www.cliki.net/ - Link farm for free CL-on-Unix resources
David Lichteblau <············@lichteblau.com> writes:
> Daniel Barlow <···@telent.net> writes:
> > * (sb-thread:release-foreground)
>
> Or use :focus in sb-aclrepl. ACL's :focus and :unarrest are pretty nice.
Right, thanks, that works, too!
Some other things.
1. The reason for the "Args out of range" error with symbol completion
is that emacs does delete-region in the *background-interaction*
buffer (because that becomes the current buffer somewhere in the
completion process) instead of the lisp listener buffer.
2. Completion sometimes fails already on the lisp side:
CL-USER(10): (lep::list-all-completions-session :pattern "dol" :functions-only-p t)
(SB-PCL::DOLIST-CAREFULLY DOLIST)
;; Good.
CL-USER(11): (lep::list-all-completions-session :pattern "do" :functions-only-p t)
debugger invoked on condition of type TYPE-ERROR:
The value NIL is not of type NUMBER.
;;Not so good.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT ] Reduce debugger level (leaving debugger, returning to
toplevel).
1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
("varargs entry for LEP::LIST-ALL-COMPLETIONS-SESSION"
:PATTERN
"do"
:FUNCTIONS-ONLY-P
T)
source: (= (MISMATCH (STRING-UPCASE (SYMBOL-NAME SYMBOL)) PATTERN)
(LENGTH PATTERN))
0] back
0: ("varargs entry for LEP::LIST-ALL-COMPLETIONS-SESSION"
:PATTERN
"do"
:FUNCTIONS-ONLY-P
T)
1: (SB-INT:EVAL-IN-LEXENV
2
(LEP::LIST-ALL-COMPLETIONS-SESSION :PATTERN "do" :FUNCTIONS-ONLY-P
T)
#S(SB-KERNEL:LEXENV
:FUNS NIL
:VARS NIL
:BLOCKS NIL
:TAGS NIL
:TYPE-RESTRICTIONS NIL
:LAMBDA NIL
:CLEANUP NIL
...))[:EXTERNAL]
etc.
I haven't looked at lep::list-all-completions-session yet, because I'd
like to know first whether this only affects me (i.e. if something's
fundamentally wrong with my setup). The same for problem no 1 above.
Andras
Simon Andr�s wrote:
> I'm trying to set up lep/eli with sbcl, but with very limited
> success. (If you are an eli addict like me, and don't know about it,
> the link for lep is at http://www.cliki.net/ELI.) After starting up it
> says
>
> debugger invoked on condition of type TYPE-ERROR:
> The value T is not of type (OR (VECTOR NIL) BASE-STRING PATHNAME
> FILE-STREAM).
>
> I can hack my way through this by
>
> (lep::start-emacs-lisp-interface
> :announce-to-stream *standard-output*)
>
> and then there is a connection to lisp, and fi:lisp-arglist,
> fi:lisp-macroexpand works (although the *background-interaction*
> buffer pops up and it shouldn't). Even opening a new listener in a new
> frame works, and symbol completion behaves somewhat better in the new
> listener (in the old one it gives "Args out of range: 3813, 3816" kind
> of errors, in the new one it prints the completion in the
> *background-interaction* buffer).
>
> Does anyone use lep with sbcl? Is there something I'm missing? Or is
> it just the alphaness of this lep implementation?
>
> Andras
>
Hmm, I'm having a similar problem with lep/eli/sbcl under os x. I have
hacked around with it a bit, but I haven't been able to get it resolved.
I've just been exiting the break loop to the top level and continuing
from there. I'm not sure what I'm missing when I do taht though.
The exact error I'm getting is: SB-INT:SIMPLE-FILEERROR:
"/usr/local/lib/sbcl/lep/lep.lisp" does not exist
I followed the instructions, but maybe I missed something. I've tried
setting this file up, and a few other things that I don't recall at the
moment, but it doesn't seem to be working. Any ideas?
--
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton <····@nospam.com> writes:
> Hmm, I'm having a similar problem with lep/eli/sbcl under os x. I have
Sorry, SBCL has threads only on Linux/x86, so you are out of luck
anyway. Try SLIME -- AFAIK it neither needs nor supports threads.
> The exact error I'm getting is: SB-INT:SIMPLE-FILEERROR:
> "/usr/local/lib/sbcl/lep/lep.lisp" does not exist
Looks like a (REQUIRE 'ASDF) is missing. Also make sure to configure
ASDF:*CENTRAL-REGISTRY* appropriately. Both should go into your .sbclrc