I'm just starting on learning Lisp. I'm using Clisp. Specifically I'm
using the Clisp interpreter to run my programs, like this:
(load (compile-file "foo.lsp"))
This works great on the rare occasion that I have written error-free
code. But often when I have made some buggy code I end up in locked in
a situation where I can't load new code into the interpreter. I'll
make some changes, save, then run the above "load" function again, and
I'll get the same error results, regardless of how I changed my code.
The only way I've found to break out of this is to terminate my
interpreter session, fire up the interpreter again, and then load the
program again.
This is a really slow cycle. Surely there is a better way! Any help
is appreciated. Thanks!
lisp-unternewbie
(message (Hello 'lisp-unternewbie)
(you :wrote :on '(1 Apr 2005 01:24:20 -0800))
(
lu> This works great on the rare occasion that I have written error-free
lu> code. But often when I have made some buggy code I end up in locked in
lu> a situation where I can't load new code into the interpreter. I'll
lu> make some changes, save, then run the above "load" function again, and
lu> I'll get the same error results, regardless of how I changed my code.
lu> The only way I've found to break out of this is to terminate my
lu> interpreter session, fire up the interpreter again, and then load the
lu> program again.
you're doing something wrong, that shouldn't be happening. and you don't
really need compiler-file there..
lu> This is a really slow cycle. Surely there is a better way! Any help
lu> is appreciated. Thanks!
use xemacs and slime. there's no need to reload whole file each time -- you
can develop it function-by-function.
there are some tutorials on this..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"lisp-unternewbie" <···············@yahoo.com> writes:
> I'm just starting on learning Lisp. I'm using Clisp. Specifically I'm
> using the Clisp interpreter to run my programs, like this:
>
> (load (compile-file "foo.lsp"))
>
> This works great on the rare occasion that I have written error-free
> code. But often when I have made some buggy code I end up in locked in
> a situation where I can't load new code into the interpreter. I'll
> make some changes, save, then run the above "load" function again, and
> I'll get the same error results, regardless of how I changed my code.
> The only way I've found to break out of this is to terminate my
> interpreter session, fire up the interpreter again, and then load the
> program again.
Yes, that's the way.
> This is a really slow cycle. Surely there is a better way! Any help
> is appreciated. Thanks!
Don't muck the system!
Why cannot you load again?
Did you shadow load in the current package?
You could still use: (cl:load (cl:compile-file "foo.lsp"))
Did you change the definition of cl:load?
You should not. (quit) and restart clisp is the only way to reload the
COMMON-LISP package.
In some occasions, you could "reset" part of the current image just by
forgetting the package containing what you want to forget, using
DELETE-PACKAGE. But this only garbage-collect what can't be reached
by any other mean.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon wrote:
> "lisp-unternewbie" <···············@yahoo.com> writes:
>
>
>>I'm just starting on learning Lisp. I'm using Clisp. Specifically I'm
>>using the Clisp interpreter to run my programs, like this:
>>
>>(load (compile-file "foo.lsp"))
>>
>>This works great on the rare occasion that I have written error-free
>>code. But often when I have made some buggy code I end up in locked in
>>a situation where I can't load new code into the interpreter. I'll
>>make some changes, save, then run the above "load" function again, and
>>I'll get the same error results, regardless of how I changed my code.
>>The only way I've found to break out of this is to terminate my
>>interpreter session, fire up the interpreter again, and then load the
>>program again.
>
>
> Yes, that's the way.
Point of information: are you out of your fucking mind?????
:)
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Pascal Bourguignon wrote:
> > "lisp-unternewbie" <···············@yahoo.com> writes:
> >
> >>I'm just starting on learning Lisp. I'm using Clisp. Specifically I'm
> >>using the Clisp interpreter to run my programs, like this:
> >>
> >>(load (compile-file "foo.lsp"))
> >>
> >>This works great on the rare occasion that I have written error-free
> >>code. But often when I have made some buggy code I end up in locked in
^^^^^^^^
> >>a situation where I can't load new code into the interpreter. I'll
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>make some changes, save, then run the above "load" function again, and
> >>I'll get the same error results, regardless of how I changed my code.
> >>The only way I've found to break out of this is to terminate my
> >>interpreter session, fire up the interpreter again, and then load the
> >>program again.
> > Yes, that's the way.
>
> Point of information: are you out of your fucking mind?????
Kenny, please explain yourself. What have you in mind?
> :)
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
From: Harald Hanche-Olsen
Subject: Re: How do I "reset" the Clisp interpreter after loading buggy code?
Date:
Message-ID: <pco7jjlcrme.fsf@shuttle.math.ntnu.no>
+ Pascal Bourguignon <····@mouse-potato.com>:
| Kenny Tilton <·······@nyc.rr.com> writes:
|
| > Point of information: are you out of your fucking mind?????
|
| Kenny, please explain yourself. What have you in mind?
Only Kenny speaks for Kenny. I certainly don't, but I'll try to make
a point anyway. The OP gets into a situation where he has managed to
screw up the state of his Lisp system to the point where he is unable
to load code. In that situation, oc course you have no choice but to
restart the Lisp system. But I believe Kenny's point is that you
should never find yourself in that situation in the first place. If
you do, you have either managed to trigger a serious bug in the Lisp
system, or (much more likely) you have done something really stupid,
like making changes in the COMMON-LISP package. (Never mind that this
is usually difficult to do, as Lisp systems tend to protect the
contents of the COMMON-LISP package from abuse.) Newbies often do
really stupid things like that, not because they're stupid but because
they're newbies. So the advice to the OP would be to (a) restart his
Lisp system, and (b) try to understand what he did wrong, so he
doesn't have to keep restarting his system in the future.
Unfortunately, we don't have quite enough information availabe to help
him out with part (b) at the moment. But if Kenny was saying that
just telling the OP to keep restarting his system whenever he runs
into trouble, without trying to guide him towards a state of
enlightenment wherein he will not have to do that, is nonsensical, I
concur.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Pascal Bourguignon <····@mouse-potato.com>:
>
> | Kenny Tilton <·······@nyc.rr.com> writes:
> |
> | > Point of information: are you out of your fucking mind?????
> |
> | Kenny, please explain yourself. What have you in mind?
>
> Only Kenny speaks for Kenny. I certainly don't, but I'll try to make
> a point anyway. The OP gets into a situation where he has managed to
> screw up the state of his Lisp system to the point where he is unable
> to load code. In that situation, oc course you have no choice but to
> restart the Lisp system. But I believe Kenny's point is that you
> should never find yourself in that situation in the first place. If
> you do, you have either managed to trigger a serious bug in the Lisp
> system, or (much more likely) you have done something really stupid,
> like making changes in the COMMON-LISP package. (Never mind that this
> is usually difficult to do, as Lisp systems tend to protect the
> contents of the COMMON-LISP package from abuse.) Newbies often do
> really stupid things like that, not because they're stupid but because
> they're newbies. So the advice to the OP would be to (a) restart his
> Lisp system, and (b) try to understand what he did wrong, so he
> doesn't have to keep restarting his system in the future.
> Unfortunately, we don't have quite enough information availabe to help
> him out with part (b) at the moment. But if Kenny was saying that
> just telling the OP to keep restarting his system whenever he runs
> into trouble, without trying to guide him towards a state of
> enlightenment wherein he will not have to do that, is nonsensical, I
> concur.
There are a lot of operations that are not reversible.
Moreover, if you try to keep the same image too much you might be
inheriting state that is not reflected in your source files, which
makes your sources work in this image but they would not in a fresh
image (eg. a scratch variable declared on the REPL is used in a
function but should not).
For these reasons, I deem it a perfectly valid procedure to start
fresh images and reload the program from the sources often, build the
system cleanly and be sure that further bugs are only due to what is
in your sources, not what cruft remains in the image used for
debugging.
--
__pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
lisp-unternewbie wrote:
> I'm just starting on learning Lisp. I'm using Clisp. Specifically I'm
> using the Clisp interpreter to run my programs, like this:
>
> (load (compile-file "foo.lsp"))
>
> This works great on the rare occasion that I have written error-free
> code. But often when I have made some buggy code I end up in locked in
> a situation where I can't load new code into the interpreter. I'll
> make some changes, save, then run the above "load" function again, and
> I'll get the same error results, regardless of how I changed my code.
This sounds wrong. If you changed your code to make it correct, it will
compile and/or load. But as others have noted you anyway should be using
some combo of emacs, slime/ilisp. then you can just fix and compile a
broken function and have everything work (except the next bug inb line).
Note, however, that once you land in the debugger you will stay there
even if you correct your code. That is a feature, not a bug. It lets you
keep the backtrace context even as you repair and retest the new code.
Maybe at some point you realize you should have examined stack variable
XXX instead of YYY.
A decent debugger will even save you a little or lot of trouble and
allow you to "retry" the original failed code. Super. You hit the next
bug, rinse, repeat. Or it runs to completion AOK.
But some deep fixes require you to restart the whole calculation. Then
we simply abort the computation and return to the toplevel, edit, save,
load and retest.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> wrote:
> This sounds wrong. If you changed your code to make it correct, it
> will compile and/or load. But as others have noted you anyway should
> be using some combo of emacs, slime/ilisp. then you can just fix and
> compile a broken function and have everything work (except the next bug
> inb line).
this is not possible for every case, at least with LispWorks, but
perhaps I only don't know how to do it.
First I define a struct:
(defstruct foo (x))
Later I decide to change it to a class:
(defclass foo () (x))
but then LispWorks say this:
Error: The metaclass of #<STRUCTURE-CLASS FOO 206A15C4> cannot be
changed from #<STANDARD-CLASS STRUCTURE-CLASS 20738F24> to
#<STANDARD-CLASS STANDARD-CLASS 20738F84>
1 (continue) Do it anyway
2 (abort) Return to level 0.
3 Return to top loop level 0.
Ok, I want this class, so I choose 1, but then I get this error:
Error: #<STRUCTURE-CLASS STRUCTURE-OBJECT 2034869C> is an invalid
superclass of #<STANDARD-CLASS FOO 206A15C4>.
1 (abort) Return to level 0.
2 Return to top loop level 0.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Harald Hanche-Olsen
Subject: Re: How do I "reset" the Clisp interpreter after loading buggy code?
Date:
Message-ID: <pcoy8c1b83s.fsf@shuttle.math.ntnu.no>
+ Frank Buss <··@frank-buss.de>:
| First I define a struct:
|
| (defstruct foo (x))
|
| Later I decide to change it to a class:
|
| (defclass foo () (x))
[and you get a whole heap of trouble]. Maybe in this case, your best
bet is to unintern foo, then do the defclass and reload everything
that might possibly reference foo in any way? I guess the next step
up in severity, short of restarting your lisp, is to remove and
rebuild whole packages.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Thanks everyone, for the good advice.
I'm not going to be switching to emacs anytime soon, as I don't want to
be simultaneously learning lisp and the usage of emacs.
Harald: I'm not causing this by defining a class with the same name as
a already-defined struct or funciton because I am too much of newbie to
have learned anything of classes or structs.
Pascal: I'm sure I haven't been doing anything like re-defining
cl:load or anything like that. The source file that was causing my
problem contained only functions named "myfunc" (which I defined twice)
"askem", "show-squares" and "show-squares-recurse". I wish I could
post the code that was causing this, but I fixed it before I started
this thread, thinking that my problem was a common one. Now I can't
reproduce it. If I have such a problem again, and I think I will,
I'll either post it or email one of you guys.
Thanks again, everyone, I have learned quite a bit from this.
-Ethan
From: Harald Hanche-Olsen
Subject: Re: How do I "reset" the Clisp interpreter after loading buggy code?
Date:
Message-ID: <pcor7hsz5oz.fsf@shuttle.math.ntnu.no>
+ "lisp-unternewbie" <···············@yahoo.com>:
| Thanks everyone, for the good advice.
You're welcome.
| I'm not going to be switching to emacs anytime soon, as I don't want
| to be simultaneously learning lisp and the usage of emacs.
Your choice. But put it high on your list of stuff to learn.
| I wish I could post the code that was causing this, but I fixed it
| before I started this thread, thinking that my problem was a common
| one. Now I can't reproduce it.
Ha! A familiar problem. I seem to have a knack for making software
lock up or crash when it's new to me, but after I have gotten used to
the software, it somehow never happens. And not because I have
learned to work around the bug: I usually never learn what triggers
it. I even managed to crash my current Palm twice in the first two
months I had it. This being my second Palm, it's certainly not
because I didn't know how to use one. But now it's been 380 days
since the last reset. This is typical. Newbies would be great
software testers if they could only report what they did.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Here is a good example of the problem I'm having. I wrote a buggy
source file, loaded it into the toplevel, got an error, removed the
line of code that had the first bug (line 1) , saved, tried to reload
into the toplevel, but kept seeing the same error. This was an error
in a line of code that was no longer there!
Here are the entire contents of my (buggy) source file, "fifth2.lsp" :
(let (seq (list 1 2 3 4 5 )))
(format t "~A ~%" (listp 'seq))
(defun show-squares-recurse (seqnce)
(format t "~A ~A~%" (car seqnce ) )
(show-squares-recurse (cdr seqnce )))
(show-squares-recurse (list 1 2 3 4 5 ))
(print "end of fifth.lsp")
Here is the exerpt of my interaction with the CLisp toplevel.:
Break 3 [4]> (load (compile-file "src/ethan/fifth2.lsp"))
Compiling file (long path deleted)src\ethan\fifth2.lsp ...
ERROR in #:|(LET (SEQ #))-1| in line 1 :
Illegal syntax in LET/LET*: (LIST 1 2 3 4 5)
WARNING in (LET (SEQ #))-1 in line 1 :
variable SEQ is not used.
Misspelled or missing IGNORE declaration?
Deleted file (long path deleted)src\ethan\fifth2.fas
There were errors in the following functions:
#:|(LET (SEQ #))-1|
1 error, 1 warning
*** - cannot delete file #P"(path deleted)src\\ethan\\fifth2.fas" since
there is file stream open to it
Break 4 [5]> (let (seq (list 1 2 3 4 5 )))
*** - LET: illegal variable specification (LIST 1 2 3 4 5)
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead.
Break 5 [6]> (let (seq (list 1 2 3 4 5 )))
*** - LET: illegal variable specification (LIST 1 2 3 4 5)
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead.
USE-VALUE :R2 You may input a value to be used instead.
Break 6 [7]> (let (seq (list 1 2 3 4 5 )))
*** - LET: illegal variable specification (LIST 1 2 3 4 5)
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead.
USE-VALUE :R2 You may input a value to be used instead.
USE-VALUE :R3 You may input a value to be used instead.
Break 7 [8]> (load (compile-file "src/ethan/fifth2.lsp"))
Compiling file (long path deleted)src\ethan\fifth2.lsp ...
ERROR in #:|(LET (SEQ #))-1| in line 1 :
Illegal syntax in LET/LET*: (LIST 1 2 3 4 5)
WARNING in (LET (SEQ #))-1 in line 1 :
variable SEQ is not used.
Misspelled or missing IGNORE declaration?
Deleted file (long path)src\ethan\fifth2.fas
There were errors in the following functions:
#:|(LET (SEQ #))-1|
1 error, 1 warning
*** - cannot delete file #P"(long path deleted)src\\ethan\\fifth2.fas"
since there is file stream open to it
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead.
USE-VALUE :R2 You may input a value to be used instead.
USE-VALUE :R3 You may input a value to be used instead.
Break 8 [9]>
(The lines preceded by "Break 4" "Break 5" and "Break 6" were
accidental, but I don't think they are the culprit.) I changed the
source file, deleteing line 1 which contained the "let" expression,
before trying to reload the source on the line of the toplevel
interaction starting with "Break 7". But as you can see, the new
version of the source file was not loaded.
What's going on? Again, any help or comments are appreciated.
(Yes, I know that show-squares-recurse doesn't do any squaring. I'm
not done with it yet.)
From: Sam Steingold
Subject: Re: How do I "reset" the Clisp interpreter after loading buggy code?
Date:
Message-ID: <upsxaz94k.fsf@gnu.org>
> * ········@gmail.com <········@tznvy.pbz> [2005-04-04 11:01:55 -0700]:
>
> (let (seq (list 1 2 3 4 5 )))
> (format t "~A ~%" (listp 'seq))
wrong parens.
you must write
(let ((seq (list 1 2 3 4 5 )))
(format t "~A ~%" (listp 'seq)))
actually, you probably do not want to quote "seq":
(let ((seq (list 1 2 3 4 5 )))
(format t "~A ~%" (listp seq)))
'seq evaluates to the symbol CL-USER:SEQ
without the quotes it's a variable, bound to the list (1 2 3 4 5).
> #:|(LET (SEQ #))-1|
> 1 error, 1 warning
>
> *** - cannot delete file #P"(path deleted)src\\ethan\\fifth2.fas" since
> there is file stream open to it
abort out of the error before proceeding with your debugging.
":q" will get you out to the top level.
try ":h" for help at the prompt (without the quotes).
at the "break" prompt there will be more commands,
it should help you with your debugging.
> Break 5 [6]>
> Break 6 [7]>
> Break 7 [8]> (load (compile-file "src/ethan/fifth2.lsp"))
":q" before this!
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://pmw.org.il/> <http://www.iris.org.il>
<http://www.mideasttruth.com/> <http://www.memri.org/> <http://www.camera.org>
In every non-trivial program there is at least one bug.
From: Thomas A. Russ
Subject: Re: How do I "reset" the Clisp interpreter after loading buggy code?
Date:
Message-ID: <ymid5taxdte.fsf@sevak.isi.edu>
Well, I think part of the problem is that you never aborted out of the
initial error. Without looking too closely, it seems there is some
locking issue with the stream connected to your file. When you tried to
compile the file again, there was still an open file stream (from the
earlier error that you are still in the middle of).
What may be unusual to new Lisp users is that if the code breaks, you
are typically put into an interactive debugger, with the particular code
execution suspended. This interactive debugger lets you use all of the
normal lisp expressions, as well as often some special debugger commands
as well.
When you get an error and wish to try to continue working, it is a good
habit to abort to top level and then start again from there. That puts
you in a much better state to try continuing your work.
I don't happen to recognize the prompt from your lisp, but someone else
may and perhaps they could share the command for returning to the top
level of your lisp system. If now one answers, you could try reading
the documentation on the debugger or experimenting with typing something
like :abort at the debugger prompt.
--
Thomas A. Russ, USC/Information Sciences Institute
·········@gmail.com" <········@gmail.com> writes:
> Here is a good example of the problem I'm having. I wrote a buggy
> source file, loaded it into the toplevel, got an error, removed the
> line of code that had the first bug (line 1) , saved, tried to reload
> into the toplevel, but kept seeing the same error. This was an error
> in a line of code that was no longer there!
>
> Here are the entire contents of my (buggy) source file, "fifth2.lsp" :
>
>
> (let (seq (list 1 2 3 4 5 )))
> (format t "~A ~%" (listp 'seq))
>
> (defun show-squares-recurse (seqnce)
> (format t "~A ~A~%" (car seqnce ) )
> (show-squares-recurse (cdr seqnce )))
>
> (show-squares-recurse (list 1 2 3 4 5 ))
>
>
> (print "end of fifth.lsp")
>
>
>
> Here is the exerpt of my interaction with the CLisp toplevel.:
>
> Break 3 [4]> (load (compile-file "src/ethan/fifth2.lsp"))
You are reloading while still evaluating the buggy expression!
> Compiling file (long path deleted)src\ethan\fifth2.lsp ...
> ERROR in #:|(LET (SEQ #))-1| in line 1 :
> Illegal syntax in LET/LET*: (LIST 1 2 3 4 5)
> WARNING in (LET (SEQ #))-1 in line 1 :
> variable SEQ is not used.
> Misspelled or missing IGNORE declaration?
>
> Deleted file (long path deleted)src\ethan\fifth2.fas
> There were errors in the following functions:
> #:|(LET (SEQ #))-1|
> 1 error, 1 warning
------------------------------------------------------------------------
> *** - cannot delete file #P"(path deleted)src\\ethan\\fifth2.fas" since
> there is file stream open to it
------------------------------------------------------------------------
Read it again!
You've been trying to compile fifth2.lisp into fifth2.fas while still
reading fifth2.fas. clisp refused to erase the file since it was still
open for reading. So next time you'll try to load it, you'll get the
same old content.
> Break 4 [5]> (let (seq (list 1 2 3 4 5 )))
>
> *** - LET: illegal variable specification (LIST 1 2 3 4 5)
> The following restarts are available:
> USE-VALUE :R1 You may input a value to be used instead.
Why do you type this erroneous expression again?
> Break 5 [6]> (let (seq (list 1 2 3 4 5 )))
>
> *** - LET: illegal variable specification (LIST 1 2 3 4 5)
> The following restarts are available:
> USE-VALUE :R1 You may input a value to be used instead.
> USE-VALUE :R2 You may input a value to be used instead.
Why do you type this erroneous expression again?
> Break 6 [7]> (let (seq (list 1 2 3 4 5 )))
>
> *** - LET: illegal variable specification (LIST 1 2 3 4 5)
> The following restarts are available:
> USE-VALUE :R1 You may input a value to be used instead.
> USE-VALUE :R2 You may input a value to be used instead.
> USE-VALUE :R3 You may input a value to be used instead.
Why do you type this erroneous expression again?
> Break 7 [8]> (load (compile-file "src/ethan/fifth2.lsp"))
>
> Compiling file (long path deleted)src\ethan\fifth2.lsp ...
> ERROR in #:|(LET (SEQ #))-1| in line 1 :
> Illegal syntax in LET/LET*: (LIST 1 2 3 4 5)
> WARNING in (LET (SEQ #))-1 in line 1 :
> variable SEQ is not used.
> Misspelled or missing IGNORE declaration?
>
> Deleted file (long path)src\ethan\fifth2.fas
> There were errors in the following functions:
> #:|(LET (SEQ #))-1|
> 1 error, 1 warning
>
> *** - cannot delete file #P"(long path deleted)src\\ethan\\fifth2.fas"
> since there is file stream open to it
> The following restarts are available:
> USE-VALUE :R1 You may input a value to be used instead.
> USE-VALUE :R2 You may input a value to be used instead.
> USE-VALUE :R3 You may input a value to be used instead.
>
> Break 8 [9]>
You're doing it again!
> (The lines preceded by "Break 4" "Break 5" and "Break 6" were
> accidental, but I don't think they are the culprit.) I changed the
> source file, deleteing line 1 which contained the "let" expression,
> before trying to reload the source on the line of the toplevel
> interaction starting with "Break 7". But as you can see, the new
> version of the source file was not loaded.
>
> What's going on? Again, any help or comments are appreciated.
The problem is that you're trying to compile into a file that is being
read and debugged.
When you break into the debugger, which you can see for the prompt
"Break ...", you have some additionnal commands available. Type:
? RETURN
get the list. The :i command is useful when the error message is not
clear enough to inspect the error condition. The :bt command (and its
brothers) is useful to see the stack backtrace, which can help
identify the location and context of the error.
In you case, since you're correcting the source and want to reload,
you must leave the debugger, using the :q command.
From the debugger, you have a REPL where you can type any expression,
eg to inspect or set variable values, or to call any function, from
the context where the error occured (or from the callers' environment,
if you move up the frame with :u (or back down the stack with :d)).
There may have several debugging levels. When you are in the debugger
and you type an erroneous expression, you enter a second debugging
level. The debugging level is the number displayed just after
"Break". The backtrace relates to the current debugging level: if you
want to see the stack relative of the initial error, you must be in
the first debugging level. To go back to the previous debugging
level, you can use the :a command.
So, in conclusion, before compiling and reloading a source, use :q to
leave the debugger.
> (Yes, I know that show-squares-recurse doesn't do any squaring. I'm
> not done with it yet.)
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
From: David Steuber
Subject: Re: How do I "reset" the Clisp interpreter after loading buggy code?
Date:
Message-ID: <874qem3hu9.fsf@david-steuber.com>
"lisp-unternewbie" <···············@yahoo.com> writes:
> I'm not going to be switching to emacs anytime soon, as I don't want to
> be simultaneously learning lisp and the usage of emacs.
You should reconsider. I didn't start to make any real forward
progress with Lisp until I had Emacs + SLIME setup. I am not an Emacs
power user by any stretch of the imagination. I use perhaps a dozen
Emacs commands in all. The auto-indentation, auto-doc-mode, and
show-matching-paren mode are all winners for me.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Randall Randall
Subject: Re: How do I "reset" the Clisp interpreter after loading buggy code?
Date:
Message-ID: <4251b2e3$1_3@alt.athenanews.com>
David Steuber wrote:
> "lisp-unternewbie" <···············@yahoo.com> writes:
>
>
>>I'm not going to be switching to emacs anytime soon, as I don't want to
>>be simultaneously learning lisp and the usage of emacs.
>
>
> You should reconsider. I didn't start to make any real forward
> progress with Lisp until I had Emacs + SLIME setup. I am not an Emacs
> power user by any stretch of the imagination. I use perhaps a dozen
> Emacs commands in all. The auto-indentation, auto-doc-mode, and
> show-matching-paren mode are all winners for me.
I had the opposite experience, in which trying to learn
enough emacs to be useful turned out to be much more
frustration-intensive than just using a GUI editor such
as J (my preferred editor). In any case, I never did
get SLIME working correctly in emacs on OS X Panther
with CMUCL.
For a rant about my emacs experience, see
http://www.livejournal.com/users/randallsquared/7219.html
--
Randall Randall <·······@randallsquared.com>
"And no practical definition of freedom would be complete
without the freedom to take the consequences. Indeed, it
is the freedom upon which all the others are based."
- Terry Pratchett, _Going Postal_
Sam, Harald, and Thomas - thanks for the the info about the debugger.
I am a clueless newbie and didn't know the difference between being in
debugger mode and being in the normal toplevel. This is exactly what I
needed to know, without knowing what to ask. So thanks for setting me
straight.
David - Thanks for the moral support. I'm actually going to give emacs
a try for a few coding sessions in a side-by-side experiment with
VisualClisp. We'll see.
Thank you, all!
Sam, Harald, and Thomas - thanks for the the info about the debugger.
I am a clueless newbie and didn't know the difference between being in
debugger mode and being in the normal toplevel. This is exactly what I
needed to know, without knowing what to ask. Thanks much for setting
me straight.
David - Thanks for the moral support. I'm actually going to give emacs
a try for a few coding sessions in a side-by-side experiment with
VisualClisp. We'll see.
Thank you, all!