OK, so I get lispbox installed with clisp 2.37 ... it's all good
So, now I'm following along with the first practical from "Practical Common
Lisp". It all works great AND I'm understanding what I'm doing!
However, as I'm building up the functionality interactively via REPL, how
the heck do I save what I've accumulated in REPL to a .lisp file for later
use/modification?
I ended up saving the REPL buffer, but then I have to edit out the prompts,
commands and output to get a clean .lisp file. There must be an *easier*
way to do this.
Yes, I know, if I'm patient and retype stuff long enough I'll stumble
across this knowledge. Someone please help me with a shortcut <G>
Two things worth mentioning in case you've missed them, first you can
move around in the repl history using meta-P and meta-N (meta is
usually the Escape key, and also often the Alt key on PCs). If you
enter some code in the repl that you want to move into your source
file, just meta-P until you get to it then copy and paste it.
Second thing, you can compile individual methods in your source file by
putting the point somewhere in the method ant typing ctrl-C twice.
On 25 May 2006 17:56:53 -0700, petere wrote:
> Two things worth mentioning in case you've missed them, first you can
> move around in the repl history using meta-P and meta-N (meta is
> usually the Escape key, and also often the Alt key on PCs). If you
> enter some code in the repl that you want to move into your source
> file, just meta-P until you get to it then copy and paste it.
>
> Second thing, you can compile individual methods in your source file by
> putting the point somewhere in the method ant typing ctrl-C twice.
Thanks for the tip.
I appreciate the help guys.
BobF <·············@charter.net> writes:
> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>
> So, now I'm following along with the first practical from "Practical Common
> Lisp". It all works great AND I'm understanding what I'm doing!
>
> However, as I'm building up the functionality interactively via REPL, how
> the heck do I save what I've accumulated in REPL to a .lisp file for later
> use/modification?
Short version, you don't; you write your actual code in other files.
For a longer version, see Chapter 2 of PCL, starting from the header
"Saving Your Work".
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
For a good demonstration on using the REPL accompanied by emacs SLIME
mode, you should check out Marco Baringer's movie:
http://common-lisp.net/movies/slime.mov
It covers the basics of SLIME very well and is a great example of
excellent REPL usage.
On Thu, 25 May 2006 22:38:15 GMT, Peter Seibel wrote:
> BobF <·············@charter.net> writes:
>
>> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>>
>> So, now I'm following along with the first practical from "Practical Common
>> Lisp". It all works great AND I'm understanding what I'm doing!
>>
>> However, as I'm building up the functionality interactively via REPL, how
>> the heck do I save what I've accumulated in REPL to a .lisp file for later
>> use/modification?
>
> Short version, you don't; you write your actual code in other files.
> For a longer version, see Chapter 2 of PCL, starting from the header
> "Saving Your Work".
>
> -Peter
I guess that explains why Chapter 2-Saving Your Work says "retype". This
seems terribly inefficient to me. There must be a way to at least list a
from in REPL so it can be copied pasted into a source file. Oh well ...
On Thu, 25 May 2006 19:19:19 -0500, BobF <·············@charter.net> wrote:
> On Thu, 25 May 2006 22:38:15 GMT, Peter Seibel wrote:
>> BobF <·············@charter.net> writes:
>>> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>>>
>>> So, now I'm following along with the first practical from
>>> "Practical Common Lisp". It all works great AND I'm
>>> understanding what I'm doing!
>>>
>>> However, as I'm building up the functionality interactively
>>> via REPL, how the heck do I save what I've accumulated in
>>> REPL to a .lisp file for later use/modification?
>>
>> Short version, you don't; you write your actual code in other
>> files. For a longer version, see Chapter 2 of PCL, starting
>> from the header "Saving Your Work".
>
> I guess that explains why Chapter 2-Saving Your Work says
> "retype". This seems terribly inefficient to me. There must
> be a way to at least list a from in REPL so it can be copied
> pasted into a source file. Oh well ...
If you are using SLIME, you are already working in an Emacs
buffer. No need to `retype' anything then. Just move back
through your buffer's scrollback history and copy/paste :)
- Giorgos
On Fri, 26 May 2006 03:50:14 +0300, Giorgos Keramidas wrote:
> On Thu, 25 May 2006 19:19:19 -0500, BobF <·············@charter.net> wrote:
>> On Thu, 25 May 2006 22:38:15 GMT, Peter Seibel wrote:
>>> BobF <·············@charter.net> writes:
>>>> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>>>>
>>>> So, now I'm following along with the first practical from
>>>> "Practical Common Lisp". It all works great AND I'm
>>>> understanding what I'm doing!
>>>>
>>>> However, as I'm building up the functionality interactively
>>>> via REPL, how the heck do I save what I've accumulated in
>>>> REPL to a .lisp file for later use/modification?
>>>
>>> Short version, you don't; you write your actual code in other
>>> files. For a longer version, see Chapter 2 of PCL, starting
>>> from the header "Saving Your Work".
>>
>> I guess that explains why Chapter 2-Saving Your Work says
>> "retype". This seems terribly inefficient to me. There must
>> be a way to at least list a from in REPL so it can be copied
>> pasted into a source file. Oh well ...
>
> If you are using SLIME, you are already working in an Emacs
> buffer. No need to `retype' anything then. Just move back
> through your buffer's scrollback history and copy/paste :)
>
> - Giorgos
Thanks. I finally figured that one out.
O
Some entity AKA BobF <·············@charter.net>
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> > Short version, you don't; you write your actual code in other files.
> > For a longer version, see Chapter 2 of PCL, starting from the header
> > "Saving Your Work".
> >
> > -Peter
>
> I guess that explains why Chapter 2-Saving Your Work says "retype". This
> seems terribly inefficient to me. There must be a way to at least list a
> from in REPL so it can be copied pasted into a source file. Oh well ...
Or activate te the type-out-buffer in your .emacs.el like:
then editing it toshape, saving is hardly a burden.
like:
;; enhanced SLIME-settings
;(slime-setup :autodoc t)
;(add-hook 'slime-connected-hook 'slime-ensure-typeout-frame)
;(global-set-key "\C-cs" 'slime-selector)
Cor
--
I do not use Windows (tm) therefore I do not fear mail from strangers
If everything else failed to satisfy you, try reading The Frign' Manual
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
http://www.clsnet.nl
On 26 May 2006 05:22:27 +0000, Cor Gest wrote:
> O
> Some entity AKA BobF <·············@charter.net>
> wrote this mindboggling stuff:
>
> (selectively-snipped-or-not-p)
>
>>> Short version, you don't; you write your actual code in other files.
>>> For a longer version, see Chapter 2 of PCL, starting from the header
>>> "Saving Your Work".
>>>
>>> -Peter
>>
>> I guess that explains why Chapter 2-Saving Your Work says "retype". This
>> seems terribly inefficient to me. There must be a way to at least list a
>> from in REPL so it can be copied pasted into a source file. Oh well ...
>
> Or activate te the type-out-buffer in your .emacs.el like:
> then editing it toshape, saving is hardly a burden.
>
> like:
> ;; enhanced SLIME-settings
> ;(slime-setup :autodoc t)
> ;(add-hook 'slime-connected-hook 'slime-ensure-typeout-frame)
> ;(global-set-key "\C-cs" 'slime-selector)
>
> Cor
Thanks for the tip. I'll get to the cryptic stuff in a few years or so <g>
BobF <·············@charter.net> writes:
> On Thu, 25 May 2006 22:38:15 GMT, Peter Seibel wrote:
>
>> BobF <·············@charter.net> writes:
>>
>>> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>>>
>>> So, now I'm following along with the first practical from "Practical Common
>>> Lisp". It all works great AND I'm understanding what I'm doing!
>>>
>>> However, as I'm building up the functionality interactively via REPL, how
>>> the heck do I save what I've accumulated in REPL to a .lisp file for later
>>> use/modification?
>>
>> Short version, you don't; you write your actual code in other files.
>> For a longer version, see Chapter 2 of PCL, starting from the header
>> "Saving Your Work".
>>
>> -Peter
>
> I guess that explains why Chapter 2-Saving Your Work says "retype". This
> seems terribly inefficient to me. There must be a way to at least list a
> from in REPL so it can be copied pasted into a source file. Oh well ...
Once your comfortable with the basics, you can open a file under
emacs, set it to slime-mode with M-x slime-mode (this can be automated
based on file extensions and the use of the auto-model-alist
variable). Now, after you define a function, you can send it to the
repl in various ways. Often, you will split the screen in two with the
file in one window and the repl in the other. Then you can use the
repl to experiment and evaluate simple things - then write the
function in the file window, send it to the repl for evaluation and
move to the next bit etc.
Tim
--
tcross (at) rapttech dot com dot au
On Fri, 26 May 2006 17:33:00 +1000, Tim X wrote:
> BobF <·············@charter.net> writes:
>
>> On Thu, 25 May 2006 22:38:15 GMT, Peter Seibel wrote:
>>
>>> BobF <·············@charter.net> writes:
>>>
>>>> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>>>>
>>>> So, now I'm following along with the first practical from "Practical Common
>>>> Lisp". It all works great AND I'm understanding what I'm doing!
>>>>
>>>> However, as I'm building up the functionality interactively via REPL, how
>>>> the heck do I save what I've accumulated in REPL to a .lisp file for later
>>>> use/modification?
>>>
>>> Short version, you don't; you write your actual code in other files.
>>> For a longer version, see Chapter 2 of PCL, starting from the header
>>> "Saving Your Work".
>>>
>>> -Peter
>>
>> I guess that explains why Chapter 2-Saving Your Work says "retype". This
>> seems terribly inefficient to me. There must be a way to at least list a
>> from in REPL so it can be copied pasted into a source file. Oh well ...
>
> Once your comfortable with the basics, you can open a file under
> emacs, set it to slime-mode with M-x slime-mode (this can be automated
> based on file extensions and the use of the auto-model-alist
> variable). Now, after you define a function, you can send it to the
> repl in various ways. Often, you will split the screen in two with the
> file in one window and the repl in the other. Then you can use the
> repl to experiment and evaluate simple things - then write the
> function in the file window, send it to the repl for evaluation and
> move to the next bit etc.
>
> Tim
Thanks, Tim. I'm using the split window approach. I'm just looking for a
quick & easy way to move code back and forth between windows. Cut/Paste
has me moving along for now.
BobF <·············@charter.net> writes:
> I'm using the split window approach. I'm just looking for a quick &
> easy way to move code back and forth between windows.
Typically I type anything valuable into a (possibly) file-based buffer
and use `M-C-x' or `C-x e' to evaluate it, and only type into the REPL
for throwaway forms such as invoking test functions or checking values
of special variables. Even then, I tend to keep my test-invoking forms
with the "real code", guarded by "#+test".
(defun some-important-function (...)
...)
#+test
(some-important-function 1 2 'foo ...)
In short, don't bother investing too much effort with the REPL when
you already have the ability to evaluate arbitrary forms in any
buffer.
--
Steven E. Harris
Steven E. Harris wrote:
> Typically I type anything valuable into a (possibly) file-based buffer
> and use `M-C-x' or `C-x e' to evaluate it, and only type into the REPL
> for throwaway forms such as invoking test functions or checking values
> of special variables. Even then, I tend to keep my test-invoking forms
> with the "real code", guarded by "#+test".
>
> (defun some-important-function (...)
> ...)
>
> #+test
> (some-important-function 1 2 'foo ...)
>
>
> In short, don't bother investing too much effort with the REPL when
> you already have the ability to evaluate arbitrary forms in any
> buffer.
I am having difficulty employing this approach in emacs+slime.
When I evaluate a form in a file buffer, the result is printed in
the mini-buffer and it dissapears before I can copy the result.
And * does not hold the result.
Takehiko Abe wrote:
> Steven E. Harris wrote:
>
> > Typically I type anything valuable into a (possibly) file-based buffer
> > and use `M-C-x' or `C-x e' to evaluate it, and only type into the REPL
> > for throwaway forms such as invoking test functions or checking values
> > of special variables. Even then, I tend to keep my test-invoking forms
> > with the "real code", guarded by "#+test".
> >
> > (defun some-important-function (...)
> > ...)
> >
> > #+test
> > (some-important-function 1 2 'foo ...)
> >
> >
> > In short, don't bother investing too much effort with the REPL when
> > you already have the ability to evaluate arbitrary forms in any
> > buffer.
>
> I am having difficulty employing this approach in emacs+slime.
> When I evaluate a form in a file buffer, the result is printed in
> the mini-buffer and it dissapears before I can copy the result.
> And * does not hold the result.
I hardly ever type things into the REPL either - I just use (possibly
scratch) buffers.
M-x slime-ensure-typeout-frame
solves the problem with evaluated forms disappearing - it creates
another emacs frame into which results are put instead of the mini
buffer. Very useful.
-- David
····@gol.com (Takehiko Abe) writes:
> Steven E. Harris wrote:
>
>> Typically I type anything valuable into a (possibly) file-based buffer
>> and use `M-C-x' or `C-x e' to evaluate it, and only type into the REPL
>> for throwaway forms such as invoking test functions or checking values
>> of special variables. Even then, I tend to keep my test-invoking forms
>> with the "real code", guarded by "#+test".
>>
>> (defun some-important-function (...)
>> ...)
>>
>> #+test
>> (some-important-function 1 2 'foo ...)
>>
>>
>> In short, don't bother investing too much effort with the REPL when
>> you already have the ability to evaluate arbitrary forms in any
>> buffer.
>
> I am having difficulty employing this approach in emacs+slime.
> When I evaluate a form in a file buffer, the result is printed in
> the mini-buffer and it dissapears before I can copy the result.
> And * does not hold the result.
Sounds like your in emacs lisp mode in the file buffer and not emacs
slime mode. When in the file buffer type
M-x slime-mode
Tim
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> wrote:
> > I am having difficulty employing this approach in emacs+slime.
> > When I evaluate a form in a file buffer, the result is printed in
> > the mini-buffer and it dissapears before I can copy the result.
> > And * does not hold the result.
>
> Sounds like your in emacs lisp mode in the file buffer and not emacs
> slime mode. When in the file buffer type
>
> M-x slime-mode
The buffer is in the slime lisp mode. Evaluating a lisp form
produces a correct result. Only that the result is printed
in a mini buffer instead of REPL.
For instance, by evaluating (+ 23), I get:
"=> 23 (#x17, #o27, #b10111)"
printed at the bottom of a emacs window and I cannot
move a caret to that area.
····@gol.com (Takehiko Abe) writes:
> The buffer is in the slime lisp mode. Evaluating a lisp form
> produces a correct result. Only that the result is printed
> in a mini buffer instead of REPL.
>
> For instance, by evaluating (+ 23), I get:
>
> "=> 23 (#x17, #o27, #b10111)"
>
> printed at the bottom of a emacs window and I cannot
> move a caret to that area.
You can preface the C-x C-e evaluation with C-u and the result
will be printed at point.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
C-u slime-eval-defun [by default bound to C-M-x] will print the result
of the evaluation. if that value has a readable repsentation this
should be enough, unfortunetly for forms like (make-hash-table) it
won't work. try using this:
(defun slime-eval-defun-in-repl ()
(interactive)
(slime-repl-send-string (slime-defun-at-point))
(slime-eval-with-transcript `(swank:interactive-eval "CL:*")
(lambda (result)
(slime-message "%s" result))))
this will eval the current toplevel form (if you want something else
change the class to slime-defun-at-point), send it to the repl and
then display the result in the minibuffer. if you jump back to the
repl you'll have the result and you can use *, ** or the
presenentation magick or the inspector.
this still has some issues (you don't the see the form, only the
result; package confusion can happen; sometimes the repl buffer opens
up; etc.) but it should be a good start.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
> (defun slime-eval-defun-in-repl ()
> (interactive)
> (slime-repl-send-string (slime-defun-at-point))
> (slime-eval-with-transcript `(swank:interactive-eval "CL:*")
> (lambda (result)
> (slime-message "%s" result))))
>
> this will eval the current toplevel form (if you want something else
> change the class to slime-defun-at-point), send it to the repl and
> then display the result in the minibuffer. if you jump back to the
> repl you'll have the result and you can use *, ** or the
> presenentation magick or the inspector.
Thank you very much. It works nicely.
(now I need to figure out how to assign short cut keys for it.
knowledges re: emacs never seem to stick to my brain. strange.
emacs hates me.)
····@gol.com (Takehiko Abe) writes:
> Tim X <····@nospam.dev.null> wrote:
>
>> > I am having difficulty employing this approach in emacs+slime.
>> > When I evaluate a form in a file buffer, the result is printed in
>> > the mini-buffer and it dissapears before I can copy the result.
>> > And * does not hold the result.
>>
>> Sounds like your in emacs lisp mode in the file buffer and not emacs
>> slime mode. When in the file buffer type
>>
>> M-x slime-mode
>
> The buffer is in the slime lisp mode. Evaluating a lisp form
> produces a correct result. Only that the result is printed
> in a mini buffer instead of REPL.
>
> For instance, by evaluating (+ 23), I get:
>
> "=> 23 (#x17, #o27, #b10111)"
>
> printed at the bottom of a emacs window and I cannot
> move a caret to that area.
Your right. I must have remembered it wrong. There are two possible
ways around this I can think of
1. Wrap things in a prin1 or princ i.e
(prin1 (+ 21))
or use the pretty print option C-c C-p, which will put the result in
the SLIME describe buffer which you can then cut and paste or
whatever.
Tim
--
tcross (at) rapttech dot com dot au
> BobF <·············@charter.net> writes:
>
>> I'm using the split window approach. I'm just looking for a quick &
>> easy way to move code back and forth between windows.
>
Thanks to everybody for your responses. I have more than enough to go on
now.
BobF <·············@charter.net> writes:
> On Fri, 26 May 2006 17:33:00 +1000, Tim X wrote:
>
>> BobF <·············@charter.net> writes:
>>
>>> On Thu, 25 May 2006 22:38:15 GMT, Peter Seibel wrote:
>>>
>>>> BobF <·············@charter.net> writes:
>>>>
>>>>> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>>>>>
>>>>> So, now I'm following along with the first practical from "Practical Common
>>>>> Lisp". It all works great AND I'm understanding what I'm doing!
>>>>>
>>>>> However, as I'm building up the functionality interactively via REPL, how
>>>>> the heck do I save what I've accumulated in REPL to a .lisp file for later
>>>>> use/modification?
>>>>
>>>> Short version, you don't; you write your actual code in other files.
>>>> For a longer version, see Chapter 2 of PCL, starting from the header
>>>> "Saving Your Work".
>>>>
>>>> -Peter
>>>
>>> I guess that explains why Chapter 2-Saving Your Work says "retype". This
>>> seems terribly inefficient to me. There must be a way to at least list a
>>> from in REPL so it can be copied pasted into a source file. Oh well ...
>>
>> Once your comfortable with the basics, you can open a file under
>> emacs, set it to slime-mode with M-x slime-mode (this can be automated
>> based on file extensions and the use of the auto-model-alist
>> variable). Now, after you define a function, you can send it to the
>> repl in various ways. Often, you will split the screen in two with the
>> file in one window and the repl in the other. Then you can use the
>> repl to experiment and evaluate simple things - then write the
>> function in the file window, send it to the repl for evaluation and
>> move to the next bit etc.
>>
>> Tim
>
> Thanks, Tim. I'm using the split window approach. I'm just looking for a
> quick & easy way to move code back and forth between windows. Cut/Paste
> has me moving along for now.
Using the various 'send' commands in a lisp file buffer set to
slime-mode, you don't need to cut and paste to move code from that
buffer to the repl. For going the other direction, cut and paste will
probably suffice to start with, but therer was a post to this group a
couple of months ago where someone posted a bit of elisp which would
make it easier to grab the last block of code from the history in the
repl and paste it into another file. This is probably what you want in
the long run, but I'd suggest sticking with what you have until your
more comfortable with emacs as it is quite likely the posted code may
need some 'tweaking' (I'm not saying the original poster was a poor
coder or anything, but often code posted to a group has had only
minimal testing and requires additional work - its more often a proof
of concept rather than a finished job. Adding code like this before
you can understand how it works can easily create a flakey environment
that is difficult to get stable again)
HTH
Tim
--
tcross (at) rapttech dot com dot au
Thanks!
On Fri, 26 May 2006 16:20:54 +0200, Pascal Bourguignon wrote:
> BobF <·············@charter.net> writes:
>
>> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>>
>> So, now I'm following along with the first practical from "Practical Common
>> Lisp". It all works great AND I'm understanding what I'm doing!
>>
>> However, as I'm building up the functionality interactively via REPL, how
>> the heck do I save what I've accumulated in REPL to a .lisp file for later
>> use/modification?
>>
>> I ended up saving the REPL buffer, but then I have to edit out the prompts,
>> commands and output to get a clean .lisp file. There must be an *easier*
>> way to do this.
>
> You could prepare an image-based-common-lisp image with the following
> command and two files.
>
> % ibcl
>
<<SNIP for brevity>>
---- Forwarded Usenet-message ----
From:
Newsgroups: comp.lang.lisp
Subject: Re: getting started
Date: Fri, 26 May 2006 00:07:11 +0200
URL: news://
On Thu, 25 May 2006 23:43:55 +0200, BobF <·············@charter.net> wrote:
>
> OK, so I get lispbox installed with clisp 2.37 ... it's all good
>
> So, now I'm following along with the first practical from "Practical
> Common
> Lisp". It all works great AND I'm understanding what I'm doing!
>
> However, as I'm building up the functionality interactively via REPL, how
> the heck do I save what I've accumulated in REPL to a .lisp file for
> later
> use/modification?
>
> I ended up saving the REPL buffer, but then I have to edit out the
> prompts,
> commands and output to get a clean .lisp file. There must be an *easier*
> way to do this.
>
> Yes, I know, if I'm patient and retype stuff long enough I'll stumble
> across this knowledge. Someone please help me with a shortcut <G>
I'll give you a hint.
You can send funtion code from a lisp file directly to
the interpreter.
1. Create a lisp file (ex test.lisp) <ctrl>-x-f
2 write your fuinction the buffer
3. at the end of the function type <ctrl>-c-c
4. switch to the interpreter
<ctrl>-x-b lisp-shell-buffer if buffer not visible
<ctrl>-x-o switches to the other buffer if it is visible
Also in a lisp buffer type <crtl>-h-m
That gives you the keystrokes available in that mode.
(<ctrl>-x-k kills the buffer when you are finished
For the comands for compiling a buffer:
http://common-lisp.net/project/slime/doc/html/slime_16.html#SEC16
Better still read the whole manual.
http://common-lisp.net/project/slime/doc/html/slime.html
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/