Re: [slime-cvs] CVS update: slime/swank-cmucl.lisp

Helmut Eller <heller <at> common-lisp.net> writes:

> +(defun read-next-form ()
> +  (handler-case 
> +      (let* ((length (logior (ash (read-byte *emacs-io*) 16)
> +			     (ash (read-byte *emacs-io*) 8)
> +			     (read-byte *emacs-io*)))
> +	     (string (make-string length)))
> +	(sys:read-n-bytes *emacs-io* string 0 length)
> +	(read-form string))
> +    (condition (c)
> +      (throw 'serve-request-catcher c))))

OK, so what is the problem with CMUCL that means it can't use
read-sequence here?  I know it used to be broken (did partial reads)
but I thought that was fixed ages ago.  Can we not report this as a
bug to the cmucl developers?

Thanks for cleaning up my other mess.  Now I have to look through your
structure stuff and who-calls, see what I can steal for sbcl 

-dan

--

-- 

   http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro

_______________________________________________
slime-devel site list

Re: [slime-cvs] CVS update: slime/swank-cmucl.lisp

Daniel Barlow <dan <at> telent.net> writes:

> Helmut Eller <heller <at> common-lisp.net> writes:
> 
> > +(defun read-next-form ()
> > +  (handler-case 
> > +      (let* ((length (logior (ash (read-byte *emacs-io*) 16)
> > +			     (ash (read-byte *emacs-io*) 8)
> > +			     (read-byte *emacs-io*)))
> > +	     (string (make-string length)))
> > +	(sys:read-n-bytes *emacs-io* string 0 length)
> > +	(read-form string))
> > +    (condition (c)
> > +      (throw 'serve-request-catcher c))))
> 
> OK, so what is the problem with CMUCL that means it can't use
> read-sequence here?  I know it used to be broken (did partial reads)
> but I thought that was fixed ages ago.  Can we not report this as a
> bug to the cmucl developers?

I think you can't read bytes and characters from the same stream.  If
that's a bug, then a proper fix is of course preferable.

--helmut.

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

Re: [slime-cvs] CVS update: slime/swank-cmucl.lisp

Helmut Eller <e9626484 <at> stud3.tuwien.ac.at> writes:

> I think you can't read bytes and characters from the same stream.  If
> that's a bug, then a proper fix is of course preferable.

You're right, I'm dumb.  Sigh.

-dan

--

-- 

   http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

stuff

Howdyo,

Feels good to be hacking again 

Helmut, list-callers is great! The inspector too!

This backend integration is groovy too.

I've been hacking on the Elisp source-path support a bit more just
now. It turns out backquote is really hard (see ChangeLog for
details). We probably should push resolving source-paths into Lisp to
use their reader for compiler notes too. Maybe `forward-source-path's
days are numbered?

Also hacked the batch-mode test suite a bit. There's a little
'test.sh' in CVS for running it. I drive it with different lisp/emacs
versions with this script:

  #!/bin/bash

  tester="/home/luke/hacking/slime/test.sh"
  emacsen="emacs21 emacs20"
  lispen="sbcl-cvs cmucl-snapshot cmucl-cvs"

  echo "(Removing old output.)"
  rm *.dribble* *.results* &>/dev/null

  for emacs in $emacsen; do
      for lisp in $lispen; do
          tag=${emacs}_${lisp}

OpenMCL Stuff and Swank Compilation

Greetings,

I've about finished merging my latest OpenMCL code with Slime CVS.
However, the code that compiles the sys-dependent backend in an
EVAL-WHEN in swank.lisp does not work in OpenMCL.  (As I understand
the problem, all the DEFMACROs and DEFVARs would need to have
EVAL-WHENs around them as well...)

Following Dan's suggestion in IRC I started on a loader that the Emacs
Lisp calls to compile and load the backend---I've put it up at
http://jamesjb.com/slime/swank-loader.lisp for comments.

One thing we lose if we do it this way is the ability to give the user
the nice "recompile swank?" prompt---we could instead have the elisp
compile each of the backend files but then we cannot automagically
figure the right backend based on *FEATURES*.

(I tried to test the loader under MacOS X SBCL but Swank doesn't seem
to run in my build of 0.8.4., thus only tested in OpenMCL).

Speaking of testing, a few trivial runs of the unit tests with the
OpenMCL backend resulted in 255 failures---after glancing at the code
it looks like it would need a fair bit of work to port.  

In particular it doesn't seem to deal very well with unimplemented
slimefuns---perhaps we need a better way to say 'this function is
unimplemented' besides dumping the user into the debugger?

James

STYLE-WARNING/NOTE distinction

Hi,

SBCL pays careful attention to the distinction between a STYLE-WARNING
(a condition strong enough to warrant returning from COMPILE-FILE with
WARNINGSP set) and a compiler note (generally an optimization note,
but sometimes a code deletion note or something similar), which aren't
counted as warnings.

Attached is a patch to implement this.  I know cmucl doesn't have this
distinction; I'm unsure as to whether OpenMCL does, so I've just
implemented it for SBCL; the behaviour of other lisps should be
unchanged.

Index: slime.el
===================================================================
RCS file: /project/slime/cvsroot/slime/slime.el,v
retrieving revision 1.37
diff -u -r1.37 slime.el
--- slime.el	17 Oct 2003 01:38:01 -0000	1.37
+++ slime.el	17 Oct 2003 17:28:38 -0000
 <at>  <at>  -76,7 +76,7  <at>  <at> 
   "Number of times to try connecting to the Swank server before aborting.
 Nil means never give up.")

-(defvar slime-lisp-binary-extension ".x86f"
+(defvar slime-lisp-binary-extension ".fasl"
   "Filename extension for Lisp object files.")

Re: stuff

Luke Gorrie <luke <at> bluetail.com> writes:

> Howdyo,
> 
> Feels good to be hacking again 
> 
> Helmut, list-callers is great! The inspector too!

What do you think about the window for selecting a caller?  I had some
trouble to figure out how to reuse the xref window, so I came up with
my own, and tried to imitate the w3m-select-buffer window.  Should I
switch to the xref window?

> This backend integration is groovy too.
> 
> I've been hacking on the Elisp source-path support a bit more just
> now. It turns out backquote is really hard (see ChangeLog for
> details). We probably should push resolving source-paths into Lisp to
> use their reader for compiler notes too. Maybe `forward-source-path's
> days are numbered?

Yes, I think that would be good.  At least worth at try.  Would it be
efficient enough to send the entire buffer as a string to Lisp and
resolve the source path there?  Or should we drop source paths
entirely and only send buffer offsets across the wire?  It's a bit
difficult for compiler notes, because we don't want to slow down
compilation, but we need the buffer offsets for the annotations
immediately after the compilation.  Perhaps we could do the annotation
and source path resolution lazily, only when M-n or M-p are pressed.

Re: OpenMCL Stuff and Swank Compilation

James Bielman <jamesjb <at> jamesjb.com> writes:

> Following Dan's suggestion in IRC I started on a loader that the Emacs
> Lisp calls to compile and load the backend---I've put it up at
> http://jamesjb.com/slime/swank-loader.lisp for comments.

Let's do it.

> Speaking of testing, a few trivial runs of the unit tests with the
> OpenMCL backend resulted in 255 failures---after glancing at the code
> it looks like it would need a fair bit of work to port.  

Ahem, that's probably just my crappy scripts. I used unix exit code to
report the number of failed cases, but of course other sorts of errors
can override my number. When in doubt, run M-x slime-run-tests
interactively.

There's a bug in the interactive testing too though -- it reports the
number of successful tests with the number of failed _cases_, so it
might say "Failed 100/10 tests". Will fix 

-Luke

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

Re: stuff

Helmut Eller <e9626484 <at> stud3.tuwien.ac.at> writes:

> What do you think about the window for selecting a caller?  I had some
> trouble to figure out how to reuse the xref window,

My data structure is a bit funky. I'll change it to use a property
list and make the filename optional.

> so I came up with my own, and tried to imitate the w3m-select-buffer
> window.  Should I switch to the xref window?

Dunno - I think your window looks cool, but it doesn't fit my personal
window-management scheme (not enough frame width). For people who use
wider windows it might be ideal, so perhaps we could have a
configurable to use either scheme for both xref and list-callers.

> Would it be efficient enough to send the entire buffer as a string
> to Lisp and resolve the source path there?  Or should we drop source
> paths entirely and only send buffer offsets across the wire?  It's a
> bit difficult for compiler notes, because we don't want to slow down
> compilation, but we need the buffer offsets for the annotations
> immediately after the compilation.  Perhaps we could do the
> annotation and source path resolution lazily, only when M-n or M-p
> are pressed.

I have no real answers . It might even be hard to handle
source-paths correctly in Lisp code. We're using "(read-delimited-list
#\( ...)" currently and I don't think it will handle this awkwardness
with , <at>  in backquotes. Really it seems you need to use a full READ and
then break out at a certain point in the call graph -- at least, I

strange failure with the sbcl backend

Hi,

I was wondering lately why slime/sbcl did not want to compile
swank-sbcl.lisp. When I tried it, I got the backtrace available at
<URL:http://shell.iddqd.org:8081/paste/display/103>. 

As you can see, somehow sbcl fails to find the appropriate method for
slime-output-stream-buffer. I can trigger this by executing

C-c : (defclass slime-output-stream (sb-gray:fundamental-character-output-stream)
  ((buffer :initform (make-string-output-stream :element-type 'character)
           :accessor slime-output-stream-buffer))) RET

(i.e. a complete 1:1 redefinition of the slime-output-stream class and
the slime-output-stream-buffer GF)

I'm not sure which is to blame: me, sbcl or swank. It also seems like
I'm the only person for whom this is failing. On my machine, I can
reproduce this with a clean slime, fresh sbcl (no .sbclrc), while
running emacs -q; so it must be my karma or something 

Thanks,
--

-- 
Andreas Fuchs, <asf <at> acm.org>, asf <at> jabber.at, antifuchs

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel