Menu
▾
▴
ilisp-devel — This is the list for discussion on the developement of ILISP.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(25) |
Feb
(13) |
Mar
(8) |
Apr
(20) |
May
(24) |
Jun
(12) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(20) |
Nov
(35) |
Dec
(27) |
| 2002 |
Jan
(17) |
Feb
(25) |
Mar
(16) |
Apr
(3) |
May
(35) |
Jun
(35) |
Jul
(10) |
Aug
(23) |
Sep
(23) |
Oct
(16) |
Nov
(31) |
Dec
(7) |
| 2003 |
Jan
(8) |
Feb
(12) |
Mar
(6) |
Apr
(28) |
May
(52) |
Jun
(12) |
Jul
(18) |
Aug
(3) |
Sep
(3) |
Oct
(11) |
Nov
(31) |
Dec
(31) |
| 2004 |
Jan
(4) |
Feb
(2) |
Mar
(5) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Marco A. <ma...@cs...> - 2008-12-16 16:50:07
|
Wow, this is quite some time since an ILISP message got through.
I am afraid ILISP is quite smelly at this point to say the least. At
a certain point I passed the torch (let it drop more like it) and more
recently I even decided to use SLIME on Emacs.
I am afraid there are not many people here who could help. Sorry.
Cheers
--
Marco
On Dec 16, 2008, at 17:31 , Martin Cracauer wrote:
> Ilisp folks,
>
> Appended is a first diff that make SBCL in Ilisp snapshot work, after
> a fashion. It starts and evaluates fine, but the debugger is broken.
> The debugger displays it's prompt twice, the cursor is left after the
> first prompt. Any attempt to enter things with the keyboard ends up
> with a hung Lisp and the infamous
> "Abort commands before interrupting top level? (y or n)" when hitting
> Control-C. The session seems nonrecoverable.
>
> The below is an example session, the last line is being displayed
> after hitting Control-C (not shown):
>
>
> Starting ,sbcl ...
> :cl-user - Yes, Master? (+ 1 2)
>
> 3
> :cl-user - Yes, Master? (+ 1 'foo)
>
> debugger invoked on a SIMPLE-TYPE-ERROR in thread #<THREAD "initial
> thread" {10\
> 00018D21}>:
> Argument Y is not a NUMBER: FOO
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-KERNEL:TWO-ARG-+ 1 FOO)
> 0] a
> 0] a
> a
> 1
>
> ----:**-F1 *sbcl* All L20
> (ILISP :load)-----------------------------
> Abort commands before interrupting top level? (y or n)
>
> --
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/
> FreeBSD - where you want to go, today. http://www.freebsd.org/
> <ilisp-20021222-patch-for-
> emacs22_001
> .diff
> >
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> Nevada.
> The future of the web can't happen without you. Join us at MIX09 to
> help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/_______________________________________________
> Ilisp-devel mailing list
> Ili...@li...
> https://lists.sourceforge.net/lists/listinfo/ilisp-devel
--
Marco Antoniotti
|
|
From: Martin C. <cra...@co...> - 2008-12-16 16:31:57
|
Ilisp folks,
Appended is a first diff that make SBCL in Ilisp snapshot work, after
a fashion. It starts and evaluates fine, but the debugger is broken.
The debugger displays it's prompt twice, the cursor is left after the
first prompt. Any attempt to enter things with the keyboard ends up
with a hung Lisp and the infamous
"Abort commands before interrupting top level? (y or n)" when hitting
Control-C. The session seems nonrecoverable.
The below is an example session, the last line is being displayed
after hitting Control-C (not shown):
Starting ,sbcl ...
:cl-user - Yes, Master? (+ 1 2)
3
:cl-user - Yes, Master? (+ 1 'foo)
debugger invoked on a SIMPLE-TYPE-ERROR in thread #<THREAD "initial thread" {10\
00018D21}>:
Argument Y is not a NUMBER: FOO
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-KERNEL:TWO-ARG-+ 1 FOO)
0] a
0] a
a
1
----:**-F1 *sbcl* All L20 (ILISP :load)-----------------------------
Abort commands before interrupting top level? (y or n)
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/
|
|
From: YANG S. <yan...@fl...> - 2005-08-17 05:58:50
|
Package: ilisp Version: 5.12.0+cvs.2004.12.24 Tags: patch Since emacs-snapshot enters Debian sid, I decided to try it and found it failed to configure, though emacs-snapshot runs well. I dig the problem a bit and come to the conclusion that the problem is with ilisp, not emacs-snapshot. The real reason is that there is emacs-snapshot has emacs-version 22, which ilcompat.el will fall back to 'fsf-18. The following minimal patch reuses ilfsf21.el for emacs 22. Maybe it's more in line with ilisp's way to provide ilfsf22.el, which is almost identical to ilfsf21.el, but the simplest is the best. --- ilisp-5.12.0+cvs.2004.12.24.orig/ilcompat.el +++ ilisp-5.12.0+cvs.2004.12.24/ilcompat.el @@ -27,6 +27,8 @@ 'fsf-20) ((string-match "^21" emacs-version) 'fsf-21) + ((string-match "^22" emacs-version) + 'fsf-21) (t 'fsf-18)) "The major version of (X)Emacs ILISP is running in. Declared as '(member fsf-19 fsf-19 fsf-20 fsf-21 lucid-19 lucid-19-new xemacs). |
|
From: Kevin R. <ke...@ro...> - 2004-12-24 04:20:36
|
If there is any (left) using ILISP and CMUCL, perhaps you might have an idea what is causing the problem with this user's installation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284292 Thanks, -- Kevin Rosenberg ke...@ro... |
|
From: Autumn C. <ili...@li...> - 2004-09-01 00:35:20
|
You must enable HTML to view this message. 2630.COf |
|
From: Kevin R. <ke...@ro...> - 2004-08-11 19:13:38
|
Christophe Rhodes wrote: > I'm not sure that anyone still develops ilisp with a great amount of > seriousness. However, find attached a patch against ilisp CVS which > should make it load again (you may need to delete ilisp fasls). I > haven't tested whether this actually works, though it should work > about as well as ilisp did with sbcl 0.8.10. Thank you for the patch. I'll commit it. Kevin |
|
From: Kevin R. <ke...@ro...> - 2004-08-03 04:19:35
|
As noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260095 "... completer.el ... unconditionally alters minibuffer-local-completion-map and minibuffer-local-must-match-map. This behavior violates an Emacs Lisp Coding Convention: "Design the package so that simply loading it has no visible effect--that should not enable the feature." I wonder if anyone is interested in fixing this. -- Kevin Rosenberg ke...@ro... |
|
From: OEM on S. <by...@ho...> - 2004-05-23 23:43:21
|
Looking for not expensive high-quality software? We have All Softwares that you may need. Windows XP Professional ............. $50 Adobe Photoshop 7.0 ...................... $60 Microsoft Office XP Professional .... $60 Corel Draw Graphics Suite 11 ............. $60 and lots more... http://GIFHAA.info/OE017/?affiliate_id=233633&campaign_id=601 |
|
From: Kevin R. <ke...@ro...> - 2004-04-02 02:18:11
|
Daniel Skarda wrote:
> When I call run-ilisp with "gcl" argument, Emacs hangs, eats 100% of CPU and
> C-g does not work anymore.
I've confirm this with emacs as well as xemacs. Xemacs shows the first
function in the backtrace is sit-for being called by ilisp-init. From
ilisp-snd.el:
(when waitp
(while (ilisp-value 'ilisp-initializing t)
(accept-process-output)
(sit-for 0)))))
Apparently the ilisp-value for ilisp-initializing is not being set to
t. I'm forwarding this report to the ilisp mail list in case any
developers have some insight how to fix the problem with gcl.
--
Kevin Rosenberg
ke...@ro...
|
|
From: Bob R. <rog...@rg...> - 2004-03-01 02:49:48
|
It occurs to me that cmulisp-source-directory-regexp and cmulisp-local-source-directory only exist to convert "target:" in raw source file names into the actual source directory on the local filesystem. I can think of three reasons to flush this: 1. The new M-. implementation now tries to return truenames whenever possible, so emacs should only see "target:" if (search-list "target:") is wrong. 2. Since emacs doesn't know what the search list should be, the pathname rewriting might not produce the right result in any case. 3. This is actually just a gloss on the underlying ilisp-source-directory-fixup-alist, which can always be used directly for other rewriting needs. If the search list is set up correctly, then M-. should always return the right thing; if not, then other bad things ensue. As a result, I think we should flush these variable, and encourage users to correct the lisp's notion of where the sources are. If I don't hear otherwise, I will commit something along these lines in the next few days. -- Bob Rogers http://rgrjr.dyndns.org/ |
|
From: Michael S. <sp...@in...> - 2004-01-28 16:46:51
|
ilxemacs.el gets the various comint variables exactly the wrong way, getting a lot of Symbol's value as variable is void: input-ring-index on current XEmacs. This suggests testing on boundness rather than on the XEmacs version. Patch is attached. --=20 Cheers =3D8-} Mike Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla |
|
From: Matthias K. <mk...@ma...> - 2004-01-07 15:25:05
|
Michael Sperber <sp...@in...> writes: > I use ILISP for Common Lisp, but not for Scheme. I assumed, > > (setq lisp-source-modes '(lisp-mode)) > > would prevent ILISP from messing with scheme-mode. Unfortunately, it > doesn't prevent ILISP from changing the scheme-mode keymap. I submit > that's wrong. Here's a patch. [...] Thanks, I have checked it into CVS. -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe |
|
From: <Mic...@HV...> - 2004-01-05 15:38:53
|
Hi there,
I'm using ILISP with LispWorks 4.3, and I've run into a number of problems.
Please excuse my not sending proper patches---the tools necessary for this
are not available in my (very restricted) working environment. (Outlook
will likely also have mangled the source code---sorry about that.)
First of all, there's some magic specific to LW 4.1 and 4.2 in
lispworks.lisp
which I've rewritten ot not refer to the LispWorks version directly:
(defun ilisp-find-function (name package)
(multiple-value-bind (symbol status)
(intern name package)
(and (eq status :external)
symbol)))
(defun ilisp-callers (symbol package)
"Print a list of all of the functions that call FUNCTION.
Returns T if successful."
(ilisp-errors
(let ((function-name (ilisp-find-symbol symbol package))
(*print-level* nil)
(*print-length* nil)
(*package* (find-package 'lisp))
(callers ())
)
(when (and function-name (fboundp function-name))
(setf callers (munge-who-calls
(cond
((ilisp-find-function "WHO-CALLS" 'lw)
(funcall (ilisp-find-function "WHO-CALLS" 'lw)
function-name))
((ilisp-find-function "WHO-CALLS" 'hcl)
(funcall (ilisp-find-function "WHO-CALLS" 'hcl)
function-name)))))
(dolist (caller callers)
(print caller))
t))))
Next, the code for sys:get-top-loop-handler etc. doesn't work anymore in
4.3---
specifically, sys::line is no longer available. Accordingly, the settings
for `ilisp-save-command' and `ilisp-restore-command' in ilisp-hlw.el are
obsolete.
On Windows, ILISP also fails to quote filenames correctly. I've put the
following kludge
into ilisp-snd.el:
(defun ilisp-quote-filename (file)
"Quote backslashes in FILE."
(replace-in-string file "\\\\" "\\\\\\\\"))
(defun ilisp-load-or-send (file)
"Try to load FILE into the inferior LISP.
If the file is not accessible in the inferior LISP as determined by
ilisp-load-or-send-command, then visit the file and send the file over
the process interface."
(let* ((command
(format (ilisp-value 'ilisp-load-or-send-command)
(ilisp-quote-filename
(lisp-file-extension
file
(ilisp-value 'ilisp-init-binary-extension t)))
file)))
(insert-string (format ilisp-block-command string)
(process-buffer (ilisp-process)))
...
With this in place, I can at least eval stuff like (+ 1 2). I'll see if
more develops.
Please direct feedback to sp...@in...---I'm not on
ilisp-devel.
Cheers,
Mike
|
|
From: Bob R. <rog...@rg...> - 2003-12-28 22:58:42
|
I just committed the change noted below to sbcl.lisp. Someone with more SBCL experience than I have might want to check it over. (At one point while tracking this down, I got the following message GC invariant lost, file "gc-common.c", line 372 and lisp died on me, so I thought it was better to patch first & ask questions later. ;-) -- Bob Rogers http://rgrjr.dyndns.org/ ------------------------------------------------------------------------ revision 1.11 date: 2003/12/28 22:50:56; author: rgrjr; state: Exp; lines: +29 -23 * Change arglist to use %CLOSURE-FUN on closures. This fixes seeing the string "#<unknown immediate object, lowtag=#b10, widetag=#xC2 {DC2}>" as the arglist of (e.g.) structure accessors. * Remove some "eliminating dead code" warnings for massage-arglist. |
|
From: Marco A. <ma...@cs...> - 2003-12-21 16:45:12
|
Hi I did remove you as an "administrator". Which brings up another question. Another adnministrator or two are needed. Any takers? Cheers Marco Paolo Amoroso wrote: >Can Marco, or someone else with appropriate privileges, please remove >me from ILISP's list of developers at SourceForge? Thanks, > > >Paolo > > |
|
From: Paolo A. <am...@mc...> - 2003-12-21 10:22:18
|
Can Marco, or someone else with appropriate privileges, please remove me from ILISP's list of developers at SourceForge? Thanks, Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film |
|
From: Bob R. <rog...@rg...> - 2003-12-21 03:38:11
|
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)
(eq (window-buffer (minibuffer-window)) comint-original-buffer))
(set-buffer comint-original-buffer))))
6. The sit-for returns, and lisp-find-next-possibility comes up
empty-handed, because it's looking in the Lisp buffer instead of
*Edit-Definitions*.
7. On exit from lisp-find-next-possibility, the initial current
buffer (where M-. was typed) is restored, neatly hiding the problem.
I can't imagine what the point of the conditional buffer restore
could be. It's not doing "switch to buffer on output," because we may
not have actually generated any output -- and in the case of M-., we see
that it is doomed to fail anyway.
In addition to doing set-buffer unconditionally in the patch I just
committed, I also wrapped the whole thing in an unwind-protect, since
that's the only way to get emacs to clean up for us if the process
filter encounters an error. Figuring out the timing requirements made
this error symptom 100% repeatable (sometimes it helps to have a slow
machine), so I am pretty confident of this fix, despite lack of
comint-ipc experience. Let me know if you see any problems.
-- Bob Rogers
http://rgrjr.dyndns.org/
|
|
From: Lynn Q. <qu...@AI...> - 2003-12-20 23:54:34
|
Bob Rogers <rog...@rg...> supplied a patch for some M-. related problems. I am confirming that the patch fixes the problems I reported. |
|
From: Lynn Q. <qu...@AI...> - 2003-12-20 16:38:54
|
> > BTW: I appreciate your suggestion to consider using SLIME . . . > > My suggestion? Sorry, I got confused by another response from "Robert P. Goldman" <rpg...@si...> who said: > > >>>>> "Lynn" == Lynn Quam <qu...@AI...> 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. > > I think a lot of that has to do with the fact that ILISP cannot assume > that the subprocess can have multiple listeners, meaning that the > listener/repl state can (in my experience, often does) get gaffed. > > Have you looked into SLIME, the ILISP replacement? Seems like the > CMUCL and SBCL developers, at least, have abandoned ILISP for > SLIME.... > > Good luck! > R |
|
From: Bob R. <rog...@rg...> - 2003-12-20 15:57:56
|
From: Lynn Quam <qu...@AI...>
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.)
Yes, and M-. tries not to depend on the case of the symbols it gets back
from the Lisp. But NIL, as usual, is special, and I had never tried M-.
on a GF with an empty specializer list before. ;-/
In any case, the patch below (as committed) should take care of this,
plus adding some extra debugging output to deal with the process filter
issue.
BTW: I appreciate your suggestion to consider using SLIME . . .
My suggestion?
. SLIME is a serious project and is likely to produce a far
superior replacement for ILISP.
It does sound like SLIME is on a trajectory to surpass ILISP. But I
haven't had a chance to check it out yet.
-- Bob Rogers
http://rgrjr.dyndns.org/
------------------------------------------------------------------------
Index: ilisp-src.el
===================================================================
RCS file: /cvsroot/ilisp/ILISP/ilisp-src.el,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ilisp-src.el 18 Dec 2003 02:44:29 -0000 1.11
+++ ilisp-src.el 20 Dec 2003 15:32:20 -0000 1.12
@@ -8,7 +8,7 @@
;;; Please refer to the file ACKNOWLEGDEMENTS for an (incomplete) list
;;; of present and past contributors.
;;;
-;;; $Id: ilisp-src.el,v 1.11 2003/12/18 02:44:29 rgrjr Exp $
+;;; $Id: ilisp-src.el,v 1.12 2003/12/20 15:32:20 rgrjr Exp $
(require 'cl)
@@ -187,8 +187,11 @@
(condition-case error
(while t
(setq result (cons (read (current-buffer)) result)))
+ ;; EOF could also be incomplete syntax, or some CL syntax we can't read.
(end-of-file nil))
- (nreverse result))))
+ ;; Deal with NIL vs nil. Other symbol case issues need to be addressed by
+ ;; the caller, but the empty list has to be the empty list.
+ (nreverse (nsubst nil 'NIL result)))))
;;; Source code definition line matching hacks.
@@ -683,9 +686,13 @@
(original-buffer (current-buffer)))
;; [can't use save-excursion because we have to update point in the
;; definitions buffer. -- rgr, 6-Aug-02.]
+ (if lisp-find-definition-verbose-p
+ (message "[lfnp %swards in %s:]"
+ (if back-p "back" "for") original-buffer))
(unwind-protect
(progn
- (set-buffer (get-buffer-create "*Edit-Definitions*"))
+ (set-buffer (or (get-buffer "*Edit-Definitions*")
+ (error "Bug: No *Edit-Definitions* buffer.")))
(if back-p
(forward-line -1))
(while (not (or result
@@ -694,9 +701,15 @@
(forward-line -1))
(cond ((looking-at "\n"))
((looking-at "^;+ *\\(.*\\)")
+ (if lisp-find-definition-verbose-p
+ (message " [p4: msg, point is now %s in %s]"
+ (point) (buffer-name)))
(cond ((not back-p)
(message "%s" (match-string 1))
- (sit-for 1))))
+ (sit-for 1)))
+ (if lisp-find-definition-verbose-p
+ (message " [p4b: msg, point is now %s in %s]"
+ (point) (buffer-name))))
((looking-at "^!+ *\\(.*\\)")
(cond (back-p
;; [***bug***: we don't find these right when
|
|
From: Lynn Q. <qu...@AI...> - 2003-12-20 13:35:20
|
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).]
Searching /m/opt/IU/FREEDIUS/lisp/basic-gui/interactor.lisp for function (METHOD GUI::SELECTED-OBJECT NIL)
[doing (lisp-locate-clisp (nil nil "(METHOD GUI::SELECTED-OBJECT NIL)") "function" t nil).]
lisp-make-cl-method-definition-regexp:
Entering debugger...
_______________________________
Backtrace:
Debugger entered--Lisp error: (wrong-type-argument consp NIL)
reverse(NIL)
lisp-make-cl-method-definition-regexp("(METHOD GUI::SELECTED-OBJECT NIL)")
lisp-make-cl-method-fspec-finder([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])
lisp-make-cl-definition-regexp([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])
lisp-locate-clisp((nil nil "(METHOD GUI::SELECTED-OBJECT NIL)") "function" t nil)
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)
lisp-next-definition(nil t)
next-definition-lisp(nil t)
lisp-edit-definitions-normal(("GUI" "::" "selected-object") "any" nil nil)
edit-definitions-lisp(("GUI" "::" "selected-object") "any")
call-interactively(edit-definitions-lisp)
_______________________________
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.)
null(intern("NIL")) = nil
Thus lisp-make-cl-method-definition-regexp("(METHOD GUI::SELECTED-OBJECT NIL)")
calls reverse(NIL).
BTW: I appreciate your suggestion to consider using SLIME. I have
downloaded the cvs sources for SLIME, studied the sources and
have tried using it. My impressions are:
. The SLIME communication architecture is a major improvement over
that in ILISP.
. SLIME offers a better integrated debugging environment.
. SLIME is currently not ready for "prime time" use.
. SLIME is a serious project and is likely to produce a far
superior replacement for ILISP.
|
|
From: Bob R. <rog...@rg...> - 2003-12-20 03:34:36
|
From: Lynn Quam <qu...@AI...> 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: (cond ((not back-p) (message "%s" (match-string 1)) (sit-for 1))) If I add a call to message to report the current buffer just before and after this fragment (back-p is always false), I find it changes from *Edit-Definitions* back to the Lisp buffer I started in, which certainly explains why it wasn't finding any definitions. 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. So wrapping a save-excursion around the sit-for ought to paper over the problem, but is bloody ugly -- and besides, clearing up the real problem may fix other intermittent bugs. But I've run out of time for tracking it down further. I'll pick it up again tomorrow, but if anybody else has suggestions in the mean time, I'd love to hear them. This problem appears to be specific to the setf methods. Doing M-. on FOO sucessfully finds the function definition for foo. Yes and no; it's not about setf methods, but methods in general. When you M-. on BAR, and BAR is a macro or ordinary function name, or the name of a generic function with an explicit defgeneric form, M-. takes you right to it. When BAR is a GF with only methods, M-. inserts a "BAR is a GF with x methods" message in *Edit-Definitions* in order to advise you that it has taken the liberty of expanding the interpretation of the name you gave it. Displaying this message is what triggers the fateful sit-for. (Assuming of course that we are really talking about the same problem; please let me know if you find otherwise.) -- Bob Rogers http://rgrjr.dyndns.org/ |
|
From: Lynn Q. <qu...@AI...> - 2003-12-18 17:43:10
|
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)
|#
#########################################
Again, starting emacs -q and evaluating:
(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")
)
followed by M-. on BAR gives:
*Messages* buffer:
Finding any bar definitions
COMMON-LISP-USER::BAR is a generic function with 1 method.
lisp-find-next-possibility returned nil.
No more bar definitions in *cmulisp*.
lisp-next-definition returns nil.
Can't find any bar.
In Lisp:
(ilisp::source-file "BAR" "CL-USER" "any")
((:COMMENT "COMMON-LISP-USER::BAR is a generic function with 1 method.")
(:DEFINITION :NAME (METHOD COMMON-LISP-USER::BAR (COMMON-LISP-USER::FOO))
:TYPE :FUNCTION :FILES ("/r/tmp/ilisp-test.lisp"))
(:COMMENT "(SETF COMMON-LISP-USER::BAR) is a generic function with 1 method.")
(:DEFINITION :NAME
(METHOD (SETF COMMON-LISP-USER::BAR) (T COMMON-LISP-USER::FOO)) :TYPE
:FUNCTION :FILES ("/r/tmp/ilisp-test.lisp")))
T
So, ILISP::SOURCE-FILE is doing the right thing, but
LISP-FIND-NEXT-POSSIBILITY is losing.
This problem appears to be specific to the setf methods.
Doing M-. on FOO sucessfully finds the function definition for foo.
|
|
From: Bob R. <rog...@rg...> - 2003-12-18 02:58:45
|
From: Lynn Quam <qu...@AI...>
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.
In the process, though, I found it sometimes finds the bar method,
and sometimes it thinks it can't, depending perhaps on the cursor
position, and maybe the cache state (though I did try to rule that out).
Something else for me to track down . . .
Thanks for hanging in there,
-- Bob Rogers
http://rgrjr.dyndns.org/
|
|
From: <as...@ma...> - 2003-12-17 16:31:44
|
This is a patch and two files which provide some support for Armedbear
Lisp. Would it be possible to include this in ilisp?
Andras
First the patch:
Index: cl-ilisp.lisp
===================================================================
RCS file: /cvsroot/ilisp/ILISP/cl-ilisp.lisp,v
retrieving revision 1.21
diff -c -r1.21 cl-ilisp.lisp
*** cl-ilisp.lisp 3 Nov 2003 04:40:16 -0000 1.21
--- cl-ilisp.lisp 17 Dec 2003 15:55:27 -0000
***************
*** 151,157 ****
;; MNA: ecl (ecls-0.5) still had special-form-p in COMMON-LISP,
;; which produced an error, when redefined.
! #+(and (or :cormanlisp :ansi-cl) (not :ecl))
(defun special-form-p (symbol)
"Backward compatibility for non ANSI CL's."
(special-operator-p symbol))
--- 151,157 ----
;; MNA: ecl (ecls-0.5) still had special-form-p in COMMON-LISP,
;; which produced an error, when redefined.
! #+(and (or :armedbear :cormanlisp :ansi-cl) (not :ecl))
(defun special-form-p (symbol)
"Backward compatibility for non ANSI CL's."
(special-operator-p symbol))
***************
*** 499,504 ****
--- 499,507 ----
#+allegro
(excl::arglist symbol)
+ #+armedbear
+ (ignore-errors (ext:arglist symbol))
+
#+(or ibcl kcl gcl)
(help symbol)
***************
*** 523,529 ****
#+:openmcl
(arglist symbol (symbol-package symbol))
! #-(or allegro lucid kcl ibcl ecl gcl lispworks clisp cmu :sbcl :openmcl)
(documentation symbol 'function)))))
--- 526,532 ----
#+:openmcl
(arglist symbol (symbol-package symbol))
! #-(or allegro armedbear lucid kcl ibcl ecl gcl lispworks clisp cmu :sbcl :openmcl)
(documentation symbol 'function)))))
***************
*** 540,546 ****
--- 543,551 ----
;; (ilisp-message t "symbol ~S not present in ~S." symbol package)
(values))
((special-form-p real-symbol)
+ #-armedbear
(format t "~S: special-operator." real-symbol)
+ #+armedbear (print-function-arglist real-symbol)
(values))
((fboundp real-symbol)
(print-function-arglist real-symbol))
Index: ilisp.el
===================================================================
RCS file: /cvsroot/ilisp/ILISP/ilisp.el,v
retrieving revision 1.10
diff -c -r1.10 ilisp.el
*** ilisp.el 13 Dec 2003 23:43:44 -0000 1.10
--- ilisp.el 17 Dec 2003 15:55:28 -0000
***************
*** 143,148 ****
--- 143,149 ----
(load "ilisp-sbcl")
(load "ilisp-chs")
(load "ilisp-acl")
+ (load "ilisp-armedbear")
(load "ilisp-hlw")
(load "ilisp-kcl")
(load "ilisp-luc")
Now the files:
;;armedbear.lisp
;;; -*- Mode: Lisp -*-
;;; armedbear.lisp --
;;; ILISP Armedbear Lisp dialect support definitions.
;;;
;;; This file is part of ILISP.
;;; Please refer to the file COPYING for copyrights and licensing
;;; information.
;;; Please refer to the file ACKNOWLEGDEMENTS for an (incomplete) list
;;; of present and past contributors.
(in-package :cl)
(defun pprint (object &optional stream)
(print object stream))
;;; end of file -- armedbear.lisp --
;;ilisp-armedbear.el
;;;;; -*- Mode: Emacs-Lisp -*-
;;; ilisp-armedbear.el --
;;; ILISP Armedbear Lisp dialect definition
;;;
;;; This file is part of ILISP.
;;; Please refer to the file COPYING for copyrights and licensing
;;; information.
;;; Please refer to the file ACKNOWLEGDEMENTS for an (incomplete) list
;;; of present and past contributors.
;;;
;;;%%%Armedbear
(defvar ilisp-armedbear-init-file "armedbear.lisp")
(defun armedbear-check-prompt (old new)
"Compare the break level printed at the beginning of the prompt."
(let* ((old-level (if (and old (eq 1 (string-match "[0-9]+" old)))
(string-to-int (substring old 1))
0))
(new-level (if (eq 1 (string-match "[0-9]+" new))
(string-to-int (substring new 1))
0)))
(<= new-level old-level)))
;;;
(defdialect armedbear "Armedbear LISP"
common-lisp
(ilisp-load-init 'armedbear ilisp-armedbear-init-file)
;; (ilisp-load-init 'new-edit-definitions "find-src") not yet
(setq comint-fix-error ":pop"
ilisp-reset ":reset"
comint-continue ":cont"
comint-interrupt-regexp "Error: [^\n]* interrupt\)")
(setq comint-prompt-status
(function (lambda (old line)
(comint-prompt-status old line 'armedbear-check-prompt))))
;; <cl> or package> at top-level
;; [0-9c] <cl> or package> in error
;; (setq comint-prompt-regexp "^\\(\\[[0-9]*c*\\] \\|\\)\\(<\\|\\)[^>]*> ")
;; (setq comint-prompt-regexp "^\\(\\[[0-9]+i?c?\\] \\|\\[step\\]\\)?\\(<?[-A-Za-z]* ?[0-9]*?>\\|[-A-Za-z0-9]+([0-9]+):\\) ")
;; Patch by kpc 94/8/30: allow prompts that look like this:
;; USER(23): USER(23):
(setq comint-prompt-regexp "^\\(\\(\\[[0-9]+i?c?\\] \\|\\[step\\] \\)?\\(<?[-A-Za-z]* ?[0-9]*?>\\|[-A-Za-z0-9]+([0-9]+):\\) \\)+")
(setq ilisp-error-regexp
"\\(ILISP:[^\"]*\\)\\|\\(Error:[^\n]*\\)\\|\\(Break:[^\n]*\\)")
(setq ilisp-source-types (append ilisp-source-types '(("any"))))
;; [use new protocol. -- rgr, 24-Mar-03.]
(setq ilisp-find-source-command "(ilisp::source-file %S %S %S)")
;; FI:CLMAN support
(setf ilisp-*use-fi-clman-interface-p* nil)
;; ILD Support
(setq ild-abort-string ":pop"
ild-continue-string ":cont"
ild-next-string ":dn"
ild-next-string-arg ":dn %s"
ild-previous-string ":up"
ild-previous-string-arg ":up %s"
ild-top-string ":to"
ild-bottom-string ":bo"
ild-backtrace-string ":bt"
ild-locals-string ":local"
ild-local-string-arg ":local %s"
ild-return-string nil ;needs work
ild-retry-string ":rest"
ild-trap-on-exit-string ":boe")
)
(unless armedbear-program (setq armedbear-program "abl"))
;;; end of file -- ilisp-armedbear.el --
|
24 messages has been excluded from this view by a project administrator.
