headers
Bob Rogers | 18 Dec 2003 03:58
Picon

Re: [Ilisp-help] edit-definitions-lisp problems

   From: Lynn Quam <quam <at> AI.SRI.COM>
   Date: Tue, 16 Dec 2003 21:18:55 -0800

   . . .

   Here is a trivial test file that appears to cause this problem in 
   both Allegro 6.0 and CMU Common Lisp CVS snapshot 2003-12.

   In both cases I started Emacs 21.1.95.1 with -q so that my emacs init
   file was ignored, just in case something it loads might be causing
   then problems.

Thank you for isolating a test case; I was able to reproduce the problem
using "emacs -q" with ACL 6.1 (though, as it turns out, I expect any
Lisp would have done as well).

   Then in emacs I did:

   (progn 
     (push "/opt/share/emacs/site-lisp/packages/ilisp" load-path)
     (require 'ilisp)
     (setq lisp-edit-file nil)
     (setq lisp-find-definition-verbose-p  t)
     (setq allegro-program "allegro")
   )

You needed to do "(setq lisp-edit-files nil)" [note plural] instead.
But no matter; I have committed the obvious (and overdue) fix, so this
setting should cause problems for M-. users no longer.
(Continue reading)

Permalink | Reply |
headers
Lynn Quam | 18 Dec 2003 18:39

Re: [Ilisp-help] edit-definitions-lisp problems

Changing (setq lisp-edit-file nil) to (setq lisp-edit-files nil)
fixed some problems, but I have isolated another problem related
to setf methods.  Here is a test file:

File: /tmp/ilisp-test.lisp
#########################################

(in-package :cl-user)

(defclass foo ()
    ((x :initform 'x)))

(defmethod bar ((obj foo))
  nil)

(defmethod (setf bar) (value (obj foo))
  nil)

(defun foo (x)
  nil)

(defun (setf foo) (value x)
  nil)

#|
(load (compile-file "/tmp/ilisp-test.lisp"))

(bar x)

(foo x)
(Continue reading)

Permalink | Reply |
headers
Bob Rogers | 20 Dec 2003 04:34
Picon

Re: [Ilisp-help] edit-definitions-lisp problems

   From: Lynn Quam <quam <at> AI.SRI.COM>
   Date: Thu, 18 Dec 2003 09:39:19 -0800

   Changing (setq lisp-edit-file nil) to (setq lisp-edit-files nil)
   fixed some problems, but I have isolated another problem related
   to setf methods.  Here is a test file . . .

   So, ILISP::SOURCE-FILE is doing the right thing, but
   LISP-FIND-NEXT-POSSIBILITY is losing.

I think I can reproduce this more-or-less reliably, by doing all of the
following:

   1.  Start a lisp (I tried both CMUCL and ACL, with similar results).

   2.  Load ilisp and your test case, in the manner prescribed.

   3.  In the Lisp buffer, do M-. on a nonexistent definition.  This has
the effect of flushing the cache, and forcing further communication with
the Lisp.

   4.  Still in the Lisp buffer, do M-. on "baz".  The exact means by
which M-. is invoked (keyboard, mouse, C-x ESC ESC) doesn't seem to
matter.

   5.  Repeat at step 3.

But I had such trouble that I'm not confident I found the same problem.
In any case, this allowed me to find a problem with the sit-for around
line 700 of the CVS version of ilisp-src.el.  The code looks like this:
(Continue reading)

Permalink | Reply |
headers
Lynn Quam | 20 Dec 2003 14:31

Re: [Ilisp-help] edit-definitions-lisp problems

Bob Rogers wrote:
>  I can only imagine that
>  the ilisp process filter is running during the sit-for interval, and it
>  somehow fails to preserve the current buffer. 

Are native threads somehow being used here?  I am running on a dual processor
AMD Athlon machine.  That might help to explain the problem.

Wrapping save-excursion around (sit-for 1) fixes some of the problems,
but I encountered another problem:

When I did a M-. in a real application I got an error in
lisp-make-cl-method-definition-regexp.  It appears to be a 
bug related to case-sensitivity in read-from-string.  See below.

I did M-. on a method call (selected-object interactor) and got an
error:

Here is the *Messages* buffer
and backtrace:

*Messages*
Finding any selected-object definitions
GUI::SELECTED-OBJECT is a generic function with 1 method.
lisp-find-next-possibility returned [cl-struct-ilisp-defn-spec (nil nil "(METHOD
GUI::SELECTED-OBJECT NIL)") "(METHOD GUI::SELECTED-OBJECT NIL)" "function"
"/m/opt/IU/FREEDIUS/lisp/basic-gui/interactor.lisp" nil nil].
[doing (lisp-locate-definition-in-file lisp-locate-clisp [cl-struct-ilisp-defn-spec (nil nil
"(METHOD GUI::SELECTED-OBJECT NIL)") "(METHOD GUI::SELECTED-OBJECT NIL)" "function"
"/m/opt/IU/FREEDIUS/lisp/basic-gui/interactor.lisp" nil nil] t).]
(Continue reading)

Permalink | Reply |
headers
Bob Rogers | 21 Dec 2003 04:38
Picon

Re: [Ilisp-help] edit-definitions-lisp problems

   This syndrome turns out to be due to a particular series of events
that exposes a comint-process-filter flaw.  The key requirement is that
the response be broken into at least two chunks, resulting in two calls
to comint-process-filter.  Here's what's happening in detail:

   1.  emacs queries the lisp for definitions.  This amounts to sending
the query string, and doing accept-process-output until a reponse comes
back.

   2.  The lisp responds, but not fully, due to buffering.  The partial
response must contain the complete Lisp response sexp, but must not
include the prompt.  This allows M-. to continue while the Lisp is still
sending output.

   3.  Back in emacs, the process filter changes from the current buffer
(where you typed M-.), updates data structures to pass the result back
to M-., and restores the current buffer.

   4.  The query returns, and the caller takes the response, builds the
*Edit-Definitions* buffer, and goes to work on it.  When it gets to a
comment in *Edit-Definitions*, it does sit-for, which allows process
filters to run.

   5.  When the process filter is called the second time, the current
buffer is initially *Edit-Definitions*, which was installed temporarily
via set-buffer (rather than switch-to-buffer), so it isn't visible in
any window.  For that dubious reason, the following fragment at the end
of comint-process-filter decides not to restore the current buffer:

    (if (or (get-buffer-window comint-original-buffer)
(Continue reading)

Permalink | Reply |
headers
Bob Rogers | 20 Dec 2003 16:57
Picon

Re: [Ilisp-help] edit-definitions-lisp problems

   From: Lynn Quam <quam <at> AI.SRI.COM>
   Date: Sat, 20 Dec 2003 05:31:22 -0800

   Bob Rogers wrote:
   >  I can only imagine that
   >  the ilisp process filter is running during the sit-for interval, and it
   >  somehow fails to preserve the current buffer. 

   Are native threads somehow being used here?  I am running on a dual processor
   AMD Athlon machine.  That might help to explain the problem.

I am not aware of any threaded emacs implementations.  sit-for runs the
normal low-level emacs input/event loop, which in turn runs the process
filters for any processes that generate output during the interval.
This gives the appearance of threading, but the process filters have to
be well-behaved.

   Wrapping save-excursion around (sit-for 1) fixes some of the problems,
   but I encountered another problem:

   When I did a M-. in a real application I got an error in
   lisp-make-cl-method-definition-regexp.  It appears to be a 
   bug related to case-sensitivity in read-from-string.  See below.

   I did M-. on a method call (selected-object interactor) and got an
   error . . .

   I tracked to problem down to the NIL being passed to reverse is not eq
   to nil.  (I didn't realize Elisp read-from-string was case sensitive.)
(Continue reading)

Permalink | Reply |
headers
Lynn Quam | 21 Dec 2003 00:49

Re: Re: [Ilisp-help] edit-definitions-lisp problems

Bob Rogers <rogers-ilisp <at> rgrjr.dyndns.org> supplied a patch
for some M-. related problems.

I am confirming that the patch fixes the problems I reported.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply |
headers
Lynn Quam | 20 Dec 2003 17:34

Re: Re: [Ilisp-help] edit-definitions-lisp problems

>  
>     BTW: I appreciate your suggestion to consider using SLIME . . .
>  
>  My suggestion?

Sorry, I got confused by another response from "Robert P. Goldman"
<rpgoldman <at> sift.info> who said:

>  
>  >>>>> "Lynn" == Lynn Quam <quam <at> AI.SRI.COM> writes:
>  
>      >> With all due respect, is there some reason you are using ILISP instead
>      >> of Allegro's ELI?  
>  
>      Lynn> I almost exclusively use CMUCL since I am developing a
>      Lynn> system for open source distribution and assume than many or
>      Lynn> most users will not want to purchase Allegro.
>  
>  For license reasons, I like to have CMUCL ports of my software.  But
>  since my employers are willing to buy Allegro, I develop under
>  Allegro, with the superior Emacs interface and the better debugger,
>  and then try to port....
>  
>      >> When you are running Allegro, Ilisp is far less
>      >> capable than ELI, which can, e.g., ask the running lisp process to
>      >> find definitions for it.
>  
>      Lynn> Yes, I agree that ILISP has many deficiencies, primarily due to its
>      Lynn> communication with the Lisp subprocess.
>
(Continue reading)

Permalink | Reply |

Gmane