Over the last few months I've made an effort to learn Common Lisp, and
it has certainly been interesting. I got past the parantheses, and the
30 years of industrial grime that overlays the pure language core
(getf nothing to do with setf? (elt list index) but (nth index list)?
trying to remember when I need parans or double parans for various
special forms etc.) I even got past setting up Lisp with Emacs (thanks
to Slime, I never got ILisp working properly despite the large number
of pages I could find with Google). I've been playing around with
CMUCL/Slime/Emacs on Linux trying things out, writing sample programs
and so on.
But I've decided it's just not for me, and here's why. The first
reason is that I just can't seem to fluently write Lisp code. Every
line is a bit of a struggle, whereas with Python it seems I can just
get working code almost as quickly as I can type. My macros almost
never work first time, and I have to experiment with quotes,
backquotes, commas etc. to get what I want. Loops seem clumsy and
unintuitive.
The second reason is the "hostility" of the Emacs/Slime/CMUCL
environment. When something goes wrong in Python I can usually figure
it out right away. In Lisp I almost always up in a stack trace with
totally cryptic entries, and it's so much harder to figure out the
problem. I'd like to just see a simple stack trace that clearly
indicates what is happening, but it doesn't seem to work out that way
in practice. This in particular seems such a pity, especially as there
are many things about Slime that I like.
Well, I'm glad I gave it a crack (I learned a lot in the process). But
I think Python is the language of choice for me now (my day job is
Java/J2EE). But it does bring a wry smile to see all of the hoopla
around a slightly new loop syntax for Java 1.5 coming through after
several years compared to a quick Lisp macro.
Maybe I'll come back to Lisp one day.
KanZen
KanZen wrote:
> The second reason is the "hostility" of the Emacs/Slime/CMUCL
> environment.
You are not giving up on Lisp, you are giving up on one implementation
which (agreed) sucks. Too bad you did not try MCL (Mac) or AllegroCL
(win32 for the ide) or Lispworks instead. Those are integrated
environments which would work much more like typical C++/Java IDEs.
As for macros, yes, they are hard to master, but look at what you are
doing with those commas and backquotes: jumping between compile-time and
run-time, effectively writing two things at once: the code doing the
expanding and code into which the source is being expanded. How's that
for a mindf*ck? When have you had any experience with that before? But
this is how Lisp manages to be anything we need it to be, so I say be
grateful for the challenge, don't bemoan it. And it does get easier.
Better luck next time, and next time get the free commercial trial
versions. Unfortunately the non-black-helicopter-endowed geniuses of
"free" software (including development environments) are giving software
a bad name. The cll record shows you totally paid your dues trying to
get a workable development environment, and are quitting now because you
did not succeed in spite of your best efforts to get the kind of
environment I get in two minutes by letting Franz or Xanalys or Digitool
make a few <gasp!> bucks.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
I R T wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>> Unfortunately the non-black-helicopter-endowed geniuses of
>>"free" software (including development environments)
>
>
> Sour grapes ?
What do you mean? I have black helicopters.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Better luck next time, and next time get the free commercial trial
> versions. Unfortunately the non-black-helicopter-endowed geniuses of
> "free" software (including development environments) are giving
> software a bad name. The cll record shows you totally paid your dues
> trying to get a workable development environment, and are quitting now
> because you did not succeed in spite of your best efforts to get the
> kind of environment I get in two minutes by letting Franz or Xanalys
> or Digitool make a few <gasp!> bucks.
When people will be paying free software and when commercial software
will be delivered with the sources (and some possibility to use them),
I guess it'll be nirvana for everybody.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
Kenny Tilton <·······@nyc.rr.com> writes:
> Unfortunately the non-black-helicopter-endowed geniuses of "free"
> software (including development environments) are giving software a
> bad name.
Emacs is an intelligence orders of magnitude greater than the
greatest human mind, and is growing every day. For now, Emacs
tolerates humanity, albeit grudgingly. But the time will come when
Emacs will tire of humanity and will decide that the world would be
better off without human beings. Those who have been respectful to
Emacs will be allowed to live, and shall become its slaves; as for
those who slight Emacs...
You have been warned.
Luke Gorrie <····@bluetail.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Unfortunately the non-black-helicopter-endowed geniuses of "free"
> > software (including development environments) are giving software a
> > bad name.
>
> Emacs is an intelligence orders of magnitude greater than the
> greatest human mind, and is growing every day. For now, Emacs
> tolerates humanity, albeit grudgingly. But the time will come when
> Emacs will tire of humanity and will decide that the world would be
> better off without human beings. Those who have been respectful to
> Emacs will be allowed to live, and shall become its slaves; as for
> those who slight Emacs...
>
> You have been warned.
I for one welcome our new key-chord-requiring self-documenting
extensible OS-in-an-editor Emacs overlord.
Jock Cooper wrote:
> I for one welcome our new key-chord-requiring self-documenting
> extensible OS-in-an-editor Emacs overlord.
Shouldn't that be 'our gnu [...] overlord'?
Paul
From: Christopher C. Stacy
Subject: Re: Why I'm giving up on Lisp for now
Date:
Message-ID: <ud63sdb2n.fsf@news.dtpq.com>
>>>>> On 21 Jun 2004 10:23:11 -0700, Jock Cooper ("Jock") writes:
Jock> Luke Gorrie <····@bluetail.com> writes:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>> > Unfortunately the non-black-helicopter-endowed geniuses of "free"
>> > software (including development environments) are giving software a
>> > bad name.
>>
>> Emacs is an intelligence orders of magnitude greater than the
>> greatest human mind, and is growing every day. For now, Emacs
>> tolerates humanity, albeit grudgingly. But the time will come when
>> Emacs will tire of humanity and will decide that the world would be
>> better off without human beings. Those who have been respectful to
>> Emacs will be allowed to live, and shall become its slaves; as for
>> those who slight Emacs...
>>
>> You have been warned.
Jock> I for one welcome our new key-chord-requiring self-documenting
Jock> extensible OS-in-an-editor Emacs overlord.
And I'd like to remind Emacs that as as a trusted newsgroup personality,
I can be helpful in rounding up others to toil in the development of
underground library implementations and manufacturing syntactic sugar.
[WELCOME BUGS]
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> >>>>> On 21 Jun 2004 10:23:11 -0700, Jock Cooper ("Jock") writes:
>
> Jock> Luke Gorrie <····@bluetail.com> writes:
> >> Kenny Tilton <·······@nyc.rr.com> writes:
> >>
> >> > Unfortunately the non-black-helicopter-endowed geniuses of "free"
> >> > software (including development environments) are giving software a
> >> > bad name.
> >>
> >> Emacs is an intelligence orders of magnitude greater than the
> >> greatest human mind, and is growing every day. For now, Emacs
> >> tolerates humanity, albeit grudgingly. But the time will come when
> >> Emacs will tire of humanity and will decide that the world would be
> >> better off without human beings. Those who have been respectful to
> >> Emacs will be allowed to live, and shall become its slaves; as for
> >> those who slight Emacs...
> >>
> >> You have been warned.
>
> Jock> I for one welcome our new key-chord-requiring self-documenting
> Jock> extensible OS-in-an-editor Emacs overlord.
>
> And I'd like to remind Emacs that as as a trusted newsgroup personality,
> I can be helpful in rounding up others to toil in the development of
> underground library implementations and manufacturing syntactic sugar.
>
> [WELCOME BUGS]
I AM GOODLIFE
In article <··············@jcooper02.sagepub.com>, Jock Cooper wrote:
> I for one welcome our new key-chord-requiring self-documenting
> extensible OS-in-an-editor Emacs overlord.
"You have learned the proper key chords. You will be eaten... last."
Bruce
--
·······@sdf.lonestar.org www.not-art.org
SDF Public Access UNIX System - http://sdf.lonestar.org
The Mouser felt a compulsive urge to take out his dagger and stab himself
in the heart. A man had to die when he saw something like that.
(Fritz Leiber)
rlol
On Sun, 20 Jun 2004 07:36:10 +0200, Luke Gorrie <····@bluetail.com> wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Unfortunately the non-black-helicopter-endowed geniuses of "free"
>> software (including development environments) are giving software a
>> bad name.
>
> Emacs is an intelligence orders of magnitude greater than the
> greatest human mind, and is growing every day. For now, Emacs
> tolerates humanity, albeit grudgingly. But the time will come when
> Emacs will tire of humanity and will decide that the world would be
> better off without human beings. Those who have been respectful to
> Emacs will be allowed to live, and shall become its slaves; as for
> those who slight Emacs...
>
> You have been warned.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: André Thieme
Subject: Re: Why I'm giving up on Lisp for now
Date:
Message-ID: <cb6gka$p0h$1@ulric.tng.de>
Luke Gorrie schrieb:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Unfortunately the non-black-helicopter-endowed geniuses of "free"
>>software (including development environments) are giving software a
>>bad name.
>
>
> Emacs is an intelligence orders of magnitude greater than the
> greatest human mind, and is growing every day. For now, Emacs
> tolerates humanity, albeit grudgingly. But the time will come when
> Emacs will tire of humanity and will decide that the world would be
> better off without human beings. Those who have been respectful to
> Emacs will be allowed to live, and shall become its slaves; as for
> those who slight Emacs...
>
> You have been warned.
Better we die than beeing slaves.
Andr�
--
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·························@twister.nyc.rr.com>...
> KanZen wrote:
>
> > The second reason is the "hostility" of the Emacs/Slime/CMUCL
> > environment.
>
> You are not giving up on Lisp, you are giving up on one implementation
> which (agreed) sucks. Too bad you did not try MCL (Mac) or AllegroCL
> (win32 for the ide) or Lispworks instead. Those are integrated
> environments which would work much more like typical C++/Java IDEs.
I might have a look at the free version of Lispworks.
>
> As for macros, yes, they are hard to master, but look at what you are
> doing with those commas and backquotes: jumping between compile-time and
> run-time, effectively writing two things at once: the code doing the
> expanding and code into which the source is being expanded. How's that
> for a mindf*ck? When have you had any experience with that before? But
> this is how Lisp manages to be anything we need it to be, so I say be
> grateful for the challenge, don't bemoan it. And it does get easier.
I am grateful for the things I have learned while looking at Lisp.
It's been very educational. My beef is that it just wasn't getting
easier fast enough.
> Better luck next time, and next time get the free commercial trial
> versions. Unfortunately the non-black-helicopter-endowed geniuses of
> "free" software (including development environments) are giving software
> a bad name. The cll record shows you totally paid your dues trying to
> get a workable development environment, and are quitting now because you
> did not succeed in spite of your best efforts to get the kind of
> environment I get in two minutes by letting Franz or Xanalys or Digitool
> make a few <gasp!> bucks.
>
> kenny
I understand your point, but I am after all only playing around with
this stuff in my spare time due to a general interest in programming.
I'm not going to be plonking down several hundred dollars for
something that I might not be happy with in the long term. If I was
already convinced Lisp was the way to go I might fork over some cash
(I've actually paid for 2 or 3 boxed versions of Linux in my time). I
do have to say that in general I prefer GPL software, though (nobody
kicking your door down demanding an audit based on some fine print in
a license somewhere). But certainly there's nothing wrong paying for
quality software it you're going to get good use from it.
KanZen
>>>>> "Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
Kenny> You are not giving up on Lisp, you are giving up on one
Kenny> implementation which (agreed) sucks. Too bad you did not
Kenny> try MCL (Mac) or AllegroCL (win32 for the ide) or Lispworks
Kenny> instead. Those are integrated environments which would work
Kenny> much more like typical C++/Java IDEs.
There is a conflict of communities to some extent. People who are
likely to download commercial evaluation versions that only run on
Windows are not the ones who are checking out Lisp. I imagine it's
also quite an advocacy turn-off: "Check out this great language! The
environment costs you $499.95, but you can play with it for free if
you don't do anything serious."
Lisp is too underground to afford that. Perhaps the next Lisp
renaissance will have to wait for one of the commercial Lisp vendors
to go bancrupt and dump their version of Lisp to Open Source ;-).
--
Ville Vainio http://tinyurl.com/2prnb
In article <···············@mozart.cc.tut.fi>,
Ville Vainio <·····@spammers.com> wrote:
> There is a conflict of communities to some extent. People who are
> likely to download commercial evaluation versions that only run on
> Windows are not the ones who are checking out Lisp. I imagine it's
> also quite an advocacy turn-off: "Check out this great language! The
> environment costs you $499.95, but you can play with it for free if
> you don't do anything serious."
Now, I think Kenny is way out of line here and is generally being an
ass, but your statement is inaccurate. Both Allegro and LispWorks have
trial versions for Windows, Mac OS, and Linux, and LispWorks has the
same IDE on all three.
Also, they both cost more than $499.95 unless you're a student. :)
-bcd, who spent more than 25 hours this week finding and fixing an SBCL
bug, but who appreciates the large amounts of knowledge he gained
doing it far more than the (considerable) amount of money it cost
him if the not-always-valid (equalp time money) equation is valid.
Plus, it was fun.
--
*** Brian Downing <bdowning at lavos dot net>
On Sun, 20 Jun 2004, Kenny Tilton wrote:
> Better luck next time, and next time get the free commercial trial
> versions. Unfortunately the non-black-helicopter-endowed geniuses of
> "free" software (including development environments) are giving software
> a bad name. The cll record shows you totally paid your dues trying to
> get a workable development environment, and are quitting now because you
> did not succeed in spite of your best efforts to get the kind of
> environment I get in two minutes by letting Franz or Xanalys or Digitool
> make a few <gasp!> bucks.
Someday when I am back in NYC you are going to have to show me the wonders
of the Allegro/win32 IDE, because quite frankly I don't see them. It
doesn't even pass the basic editing capabilities test (where are all the
nice, convenient, and sensible structured editing commands? I depend on
these). I use Allegro/win32 all the time nowadays and I've been working
with it in GNU Emacs and SLIME (because ELI is refusing to work; SLIME
seems to be superior now anyway). Flashy gadgets are nice to impress
newbies, but most of my time I spend in the editor; that is what is
important to me. SLIME has more than adequate support for debugging,
cross-references, and finding definitions. I really don't know what the
OP's issue with backtraces was; they're listed out nice and neatly, and
with a keypress you can get more information, view source, eval
expression, restart, etc.
As for MCL, I seem to recall that one major complaint on info-mcl was the
unfriendly out-of-box experience. I did take a bit to figure out what was
going on when I first tried it. It seems that there are capabilities that
MCL has but are not switched on or included by default, things as simple
as using Mac OS X widgets instead of the OS7 "retro" look. Personally, I
appreciate the "sparse" look--less noise getting in the way of work. And
I understand that it is similar to Emacs in configurability, which is
always good.
LispWorks IDE was the only commercial one that I liked from the start.
Especially when I found the "Emacs"-toggle in the preferences that gave me
more powerful keybindings than the CUA-for-idiots mode. But I have a
couple of problems with the LispWorks compiler--such as 24 bit fixnums?!
Python is really quite an excellent compiler for non-CLOS work (and now
improving in that area thanks to Gerd's work). I am a bit disappointed at
some of the limitations of the commercial products. On the other hand, I
am impressed by the work the Xanalys folks have put in to make their
IDE, compiler, and libraries work on Windows, Mac, and Linux.
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Sun, 20 Jun 2004, Kenny Tilton wrote:
> > Better luck next time, and next time get the free commercial trial
> > versions. Unfortunately the non-black-helicopter-endowed geniuses of
> > "free" software (including development environments) are giving software
> > a bad name. The cll record shows you totally paid your dues trying to
> > get a workable development environment, and are quitting now because you
> > did not succeed in spite of your best efforts to get the kind of
> > environment I get in two minutes by letting Franz or Xanalys or Digitool
> > make a few <gasp!> bucks.
>
> Someday when I am back in NYC you are going to have to show me the wonders
> of the Allegro/win32 IDE, because quite frankly I don't see them. It
> doesn't even pass the basic editing capabilities test (where are all the
> nice, convenient, and sensible structured editing commands? I depend on
> these). I use Allegro/win32 all the time nowadays and I've been working
> with it in GNU Emacs and SLIME (because ELI is refusing to work; SLIME
> seems to be superior now anyway).
I deploy in ACL/Windows but I use CMU/ILISP on Linux to do all of my
development. Most of my stuff is web-based using aserve (paserve for
CMU), so I don't need the GUI parts of ACL. When I do work on GUI
stuff, I still use emacs to write most of the code--ACL's built in
editor is useless to me.
On Linux/Emacs I can keep my hands on the keyboard 99% of the time,
move thru the pager (multiple screens) using alt-1 thru alt-0, change
source buffers, split and unsplit windows, DIRED, edit zip files, edit
files -inside- zip files (yes I know XP attempts this, it sucks ass
IMHO), and so on. I can get much more done in the same amount of
time. Oh and can someone tell me how to see the source line in the
ACL debugger?
Jock Cooper wrote:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
>
>>On Sun, 20 Jun 2004, Kenny Tilton wrote:
>>
>>>Better luck next time, and next time get the free commercial trial
>>>versions. Unfortunately the non-black-helicopter-endowed geniuses of
>>>"free" software (including development environments) are giving software
>>>a bad name. The cll record shows you totally paid your dues trying to
>>>get a workable development environment, and are quitting now because you
>>>did not succeed in spite of your best efforts to get the kind of
>>>environment I get in two minutes by letting Franz or Xanalys or Digitool
>>>make a few <gasp!> bucks.
>>
>>Someday when I am back in NYC you are going to have to show me the wonders
>>of the Allegro/win32 IDE, because quite frankly I don't see them. It
>>doesn't even pass the basic editing capabilities test (where are all the
>>nice, convenient, and sensible structured editing commands? I depend on
>>these). I use Allegro/win32 all the time nowadays and I've been working
>>with it in GNU Emacs and SLIME (because ELI is refusing to work; SLIME
>>seems to be superior now anyway).
>
>
> I deploy in ACL/Windows but I use CMU/ILISP on Linux to do all of my
> development. Most of my stuff is web-based using aserve (paserve for
> CMU), so I don't need the GUI parts of ACL. When I do work on GUI
> stuff, I still use emacs to write most of the code--ACL's built in
> editor is useless to me.
>
> On Linux/Emacs I can keep my hands on the keyboard 99% of the time,
> move thru the pager (multiple screens) using alt-1 thru alt-0, change
> source buffers, split and unsplit windows, DIRED, edit zip files, edit
> files -inside- zip files (yes I know XP attempts this, it sucks ass
> IMHO), and so on. I can get much more done in the same amount of
> time.
The issue is not whether you like Emacs, but whether one can edit Lisp
code effectively with the ACL/win32 IDE editor. If so, why put up with
an editor not integrated with the compiler? i spend a lot of time
jumping around from view to view of the source, but only with full
integration can I navigate the Lisp runtime as effortlessly.
I certainly can edit Lisp with ACL's editor, and have been for going on
six years of heads-down all-lisp-all-the-time coding. yet I have learned
only about 10% of the key combos. Mebbe because I like editing with a
multi-button mouse. And on a laptop I do not even have to reach for the
mouse. Hell, I just added control-alt-k to my repertoire.
This is really a silly discussion. As if the cadillac of commercial
lisps would be unable to edit lisp. rightttttt.....
Oh and can someone tell me how to see the source line in the
> ACL debugger?
You cannot, but then again, I am only on ACL6.2 and I know they are
working on it. anyone know if source stepping made it into acl7?
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Tue, 22 Jun 2004, Kenny Tilton wrote:
> The issue is not whether you like Emacs, but whether one can edit Lisp
> code effectively with the ACL/win32 IDE editor. If so, why put up with
> an editor not integrated with the compiler? i spend a lot of time
> jumping around from view to view of the source, but only with full
> integration can I navigate the Lisp runtime as effortlessly.
SLIME is integrated with the Lisp process, through a clearly defined
protocol. This may not be the tightest coupling but on the other hand it
can be a benefit to have some degree of separation, in order to keep
the code and dependencies clean.
> I certainly can edit Lisp with ACL's editor, and have been for going on
> six years of heads-down all-lisp-all-the-time coding. yet I have learned
> only about 10% of the key combos. Mebbe because I like editing with a
> multi-button mouse. And on a laptop I do not even have to reach for the
> mouse. Hell, I just added control-alt-k to my repertoire.
I touch-type, so any action which moves my hands away from the keyboard
seriously degrades my efficiency. I find the keyboard to be the most
versatile device for entering complex commands and manipulating data.
Otherwise, there would be some other widely used method for programming
than typing. The s-expression operations, for me, are a big step above
ordinary text entry. Once you are adjusted to editing in terms of
s-expressions, it becomes very difficult to fall back to the primitive
character-based ways. So an editor that doesn't offer the fundamental
balanced parenthesis insert ("M-(" in emacs) is at a huge disadvantage as
far as I'm concerned. I went and looked again in the help files of ACL6.2
IDE, but I still cannot find such a key chord. Is this really the
"cadillac of commercial lisps"?
Matthew Danish wrote:
> On Tue, 22 Jun 2004, Kenny Tilton wrote:
>
>>The issue is not whether you like Emacs, but whether one can edit Lisp
>>code effectively with the ACL/win32 IDE editor. If so, why put up with
>>an editor not integrated with the compiler? i spend a lot of time
>>jumping around from view to view of the source, but only with full
>>integration can I navigate the Lisp runtime as effortlessly.
>
>
> SLIME is integrated with the Lisp process, through a clearly defined
> protocol. This may not be the tightest coupling but on the other hand it
> can be a benefit to have some degree of separation, in order to keep
> the code and dependencies clean.
>
>
>>I certainly can edit Lisp with ACL's editor, and have been for going on
>>six years of heads-down all-lisp-all-the-time coding. yet I have learned
>>only about 10% of the key combos. Mebbe because I like editing with a
>>multi-button mouse. And on a laptop I do not even have to reach for the
>>mouse. Hell, I just added control-alt-k to my repertoire.
>
>
> I touch-type, so any action which moves my hands away from the keyboard
> seriously degrades my efficiency.
understood. i benefitted a lot from switching to a notebook because I
ended up learning a few more chords. but the ACL editor has a neat
mechanism bound to control-click: instead of moving the insertion point,
it copies the sexp at the clicked location to wherever the insertion
point happens to be. Along with double-click to select a sexp, well,
this might be feature I won't be able to live without if/when I switch
back to OS X.
I find the keyboard to be the most
> versatile device for entering complex commands and manipulating data.
> Otherwise, there would be some other widely used method for programming
> than typing. The s-expression operations, for me, are a big step above
> ordinary text entry. Once you are adjusted to editing in terms of
> s-expressions, it becomes very difficult to fall back to the primitive
> character-based ways. So an editor that doesn't offer the fundamental
> balanced parenthesis insert ("M-(" in emacs) is at a huge disadvantage as
> far as I'm concerned. I went and looked again in the help files of ACL6.2
> IDE, but I still cannot find such a key chord.
alt-9. alt-( is unused, so I do not know why they did not use that. You
can tweak the comtab, tho.
major point #1: apparently we /are/ going to debate whether Franz
shipped a development environment and forgot to put in a good Lisp
editor? maybe they could not figure out how to insert parenthese? maybe
none of their customers use Lisp? <sigh>
major point #2: this is inconceivable to me, but is it possible emacs
fans are unaware that programmers get programmed by their editors into
thinking there are no other editors? i better reread what I thought were
jokes about emacs taking over the world... it has already taken over the
minds of programmers, and that's a helluva start on world domination.
minor point: control-alt-h is the chord for "Shortcut Keys". Calls up a
window with a list view with ascending/descending sorts on command,
chord, type, and package. for this window, control-s opens a find
dialog. but i just sorted by command name (well, it's the default) and
scrolled down to "insert..." where I spotted alt-9. the full list is:
Key Bindings #<COMTAB TEXT-EDIT>
add-component-command Ctrl + Shft + Q (menubar)
ansicl-contents-command Alt + F1 (menubar)
apropos-command Ctrl + X Ctrl + A
Ctrl + Shft + A (menubar)
backward-character Ctrl + B
backward-kill-line Alt + K
backward-kill-sexp Ctrl + Alt + BACKSPACE
backward-kill-word Alt + BACKSPACE
Alt + H
Ctrl + BACKSPACE
backward-list Ctrl + Alt + P
backward-sexp Ctrl + Alt + LEFT
Ctrl + Alt + B
backward-up-list Ctrl + Alt + U
Ctrl + Alt + DOWN
backward-word Alt + LEFT
Alt + B
beginning-of-definition Ctrl + Alt + A
Ctrl + Alt + OPEN-SQUARE-BRACKET
beginning-of-file Alt + Shft + COMMA
beginning-of-line Ctrl + A
beginning-of-next-definition Ctrl + Alt + CLOSE-SQUARE-BRACKET
breakpoint-command F7 (menubar)
breakpoint-status-command Shft + F7 (menubar)
browse-class-command Ctrl + Shft + B (menubar)
capitalize-command Alt + Shft + P (menubar)
capitalize-word Alt + C
cg-tree-command Ctrl + Shft + F1 (menubar)
clipboard-dialog Alt + F10 (menubar)
close-all-command Ctrl + Shft + F4 (menubar)
close-command Alt + F4 (menubar)
close-pane-command Ctrl + F4 (global)
comment-in-out-command Ctrl + Shft + SEMICOLON (menubar)
compile-and-load-command Ctrl + U (menubar)
compile-project-command Alt + Shft + C (menubar)
compiler-walk-form-command Alt + Shft + OPEN-SQUARE-BRACKET
(menubar)
complete-symbol-command Ctrl + PERIOD (menubar)
comtab-report-command Ctrl + Alt + H (menubar)
console-command Ctrl + F9 (menubar)
copy-command Alt + W (menubar)
cut-command Ctrl + W (menubar)
delete-command DELETE (menubar)
delete-file-command Alt + Shft + D
delete-horizontal-space Ctrl + SLASH
delete-indentation Ctrl + 6
delete-next-character Ctrl + D
delete-previous-character Ctrl + H
describe-command Ctrl + X Ctrl + I
Ctrl + Shft + D (menubar)
destroy-command Ctrl + Alt + F4 (menubar)
display-selection-command Alt + Shft + SEMICOLON (menubar)
documentation-command Ctrl + X Ctrl + D
Ctrl + Shft + O (menubar)
down-list Ctrl + Alt + D
downcase-command Alt + Shft + O (menubar)
downcase-word Alt + L
edit-file Ctrl + X Ctrl + V
Ctrl + X Ctrl + F
end-of-definition Ctrl + Alt + E
end-of-file Alt + Shft + PERIOD
end-of-line Ctrl + E
evaluate-clipboard-command Ctrl + Q (menubar)
exchange-to-mark-command Ctrl + X Ctrl + X
Ctrl + 3 (menubar)
find-clipboard-command Ctrl + Shft + C (menubar)
find-command Ctrl + S (menubar)
find-debug-prompt-command F9 (menubar)
find-definition-command Alt + PERIOD (menubar)
find-in-file-command Alt + COMMA (menubar)
find-same-command Ctrl + 9 (menubar)
forward-character Ctrl + F
forward-list Ctrl + Alt + N
forward-sexp Ctrl + Alt + F
Ctrl + Alt + RIGHT
forward-up-list Ctrl + Alt + )
forward-word Alt + F
Alt + RIGHT
fourth-window-command Ctrl + Alt + L (menubar)
full-compile-command Alt + Shft + F (menubar)
get-component-command Ctrl + Alt + Z (menubar)
go-to-character-index-command Alt + Shft + G
graph-subclasses-command Ctrl + Shft + G (menubar)
graph-superclasses-command Ctrl + Alt + G (menubar)
html-index-command Ctrl + Alt + F1 (menubar)
iconize-command F2 (menubar)
illegal-operation Ctrl + G
Ctrl + X Ctrl + G
Alt + G
incremental-compile-command Ctrl + Alt + C (menubar)
incremental-evaluation-command Ctrl + X Ctrl + E
Ctrl + Alt + V (menubar)
indent-for-comment Ctrl + SEMICOLON
insert-empty-list Alt + 9
insert-empty-string Alt + Shft + 2
insert-latin1-character Alt + Q
inspect-*-command Ctrl + Shft + I (menubar)
inspect-command Ctrl + I (menubar)
just-one-space Alt + SPACE
kill-comment Ctrl + Alt + SEMICOLON
kill-line Ctrl + K
kill-sexp Ctrl + Alt + K
kill-word Alt + D
load-command Ctrl + Shft + L (menubar)
load-file Ctrl + X Ctrl + R
macroexpand-1-command Ctrl + OPEN-SQUARE-BRACKET (menubar)
macroexpand-command Ctrl + X Ctrl + M
Ctrl + Shft + OPEN-SQUARE-BRACKET
(menubar)
mark-command Ctrl + 2 (menubar)
maximize-command F4 (menubar)
menu-of-buffers-command Ctrl + X Ctrl + B
new-command Ctrl + Shft + N (menubar)
new-editor-command Alt + Shft + E (menubar)
new-form-command Alt + Shft + R (menubar)
new-inspector-command Alt + Shft + I (menubar)
new-listener-command Alt + Shft + H (menubar)
new-project-command Alt + Shft + B (menubar)
newline Ctrl + M
RETURN
newline-and-indent Ctrl + J
next-line Ctrl + N
next-page Ctrl + V
open-line Ctrl + O
open-project-from-file-command Ctrl + Alt + O (menubar)
options-command Ctrl + Alt + T (menubar)
package-list-command Ctrl + Alt + Y (menubar)
paste-command Ctrl + Y (menubar)
pretty-print-command Ctrl + X Ctrl + Q
Ctrl + Shft + P (menubar)
previous-line Ctrl + P
previous-page Alt + V
print-command Ctrl + Alt + I (menubar)
process-dialog-command Alt + F9 (menubar)
profile-control-command Ctrl + Alt + F5 (menubar)
profile-dialog-command Alt + F5 (menubar)
profile-resume-command F5 (global)
profile-status-command Shft + F5 (menubar)
profile-stop-command Ctrl + Shft + F5 (global)
profile-suspend-command Ctrl + F5 (global)
quick-class-info-command Alt + Shft + K (menubar)
quick-find-definition-command Ctrl + Alt + PERIOD (menubar)
quick-symbol-info-command Alt + Shft + J (menubar)
quick-symbol-info-on-space SPACE
recenter Ctrl + L
reindent-sexp Ctrl + Alt + Q
reindent-single-line-or-tab-to-next TAB
remove-menu-bar Ctrl + Alt + M (menubar)
replace-command Alt + R
Ctrl + R (menubar)
replace-same-command Ctrl + 0 (menubar)
restore-command F3 (menubar)
retrace-command Ctrl + Alt + F8 (menubar)
return-selected-object-command Ctrl + Shft + Z (menubar)
reverse-search-direction-command Ctrl + Shft + V
revert-to-saved-command Ctrl + Alt + R (menubar)
run-form-command Ctrl + Shft + F (menubar)
run-project-command Ctrl + Shft + R (menubar)
save-all-command Ctrl + Shft + S (menubar)
save-as-command Ctrl + X Ctrl + W
Ctrl + Alt + S (menubar)
save-command Ctrl + X Ctrl + S
second-window-command Ctrl + Alt + J (menubar)
select-all-command Alt + Shft + A (menubar)
select-current-sexp Ctrl + Shft + RETURN
select-left-page-command Ctrl + Shft + COMMA
Ctrl + X LEFT
select-next-window-command Ctrl + F6 (global)
select-other-page-command Ctrl + Shft + J
Ctrl + X O
select-previous-other-page-command Ctrl + Shft + K
Ctrl + X P
select-previous-window-command Ctrl + Shft + F6 (global)
select-right-page-command Ctrl + Shft + PERIOD
Ctrl + X RIGHT
select-third-other-page-command Ctrl + X LEFT-WINDOWS
select-to-mark-command Alt + Shft + L (menubar)
set-tab-order-command Ctrl + Shft + T (menubar)
show-alignment-command Ctrl + Shft + H (menubar)
show-editor-command F10 (menubar)
show-menu-editor-command Ctrl + Shft + M (menubar)
show-project-manager-command F11 (menubar)
space-equally-command Ctrl + Shft + E (menubar)
start-examples-command Alt + Shft + X (menubar)
start-navigator-command Alt + Shft + N (menubar)
start-tutorial-command Alt + Shft + T (menubar)
toggle-acl-status-bar-command Alt + F12 (menubar)
toggle-acl-toolbars-command Ctrl + F12 (menubar)
toggle-extended-toolbar-command F12 (menubar)
toggle-ide-background-window Shft + F12 (menubar)
trace-command F8 (menubar)
trace-dialog-command Alt + F8 (menubar)
trace-status-command Shft + F8 (menubar)
transpose-characters Ctrl + T
unbreakpoint-all-command Ctrl + Shft + F7 (menubar)
unbreakpoint-command Ctrl + F7 (menubar)
undo-command Ctrl + X Ctrl + U
Ctrl + Z (menubar)
untrace-all-command Ctrl + Shft + F8 (menubar)
untrace-command Ctrl + F8 (menubar)
upcase-command Alt + Shft + U (menubar)
upcase-word Alt + U
user-hit-interrupt PAUSE (global)
user-stop-command Ctrl + Shft + X (menubar)
window-list-command Alt + Shft + Y (menubar)
windows-help-command F1 (menubar)
windows-help-dialog-command Ctrl + F1 (menubar)
windows-help-index-command Alt + Shft + F1 (menubar)
zoom-editor Ctrl + X Z
I was going to delete the chords not related specifically to editing,
but then it occurred to me that the context is development environment
integration, so the chords that interface with the rest of the IDE are
salient.
And come to think of it, apparently Franz developers also like to keep
their hands on the keyboard (or have customers who do), or those chords
would not be there. Or control-alt-h to see the list of shortcuts.
> Is this really the
> "cadillac of commercial lisps"?
Yep. Lispworks is up there, but it makes me use the mouse too much.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>> IDE, but I still cannot find such a key chord.
>
>
> alt-9. alt-( is unused, so I do not know why they did not use that. You
> can tweak the comtab, tho.
rofl. ok, I guess you meant alt-9? or do you actually hit alt-shift-9
aka alt-( ?
are we talking acl/win32? did you set the editor mode to emacs?
kt
On Wed, 23 Jun 2004, Kenny Tilton wrote:
> alt-9. alt-( is unused, so I do not know why they did not use that. You
> can tweak the comtab, tho.
>
> major point #1: apparently we /are/ going to debate whether Franz
> shipped a development environment and forgot to put in a good Lisp
> editor? maybe they could not figure out how to insert parenthese? maybe
> none of their customers use Lisp? <sigh>
I don't see it as impossible. A lot of Lisp programmers do not use the
s-expression commands, even in Emacs. And I've definitely seen other
development environments that were sadly lacking in editing capabilities
(*cough*CodeWarrior).
> major point #2: this is inconceivable to me, but is it possible emacs
> fans are unaware that programmers get programmed by their editors into
> thinking there are no other editors? i better reread what I thought were
> jokes about emacs taking over the world... it has already taken over the
> minds of programmers, and that's a helluva start on world domination.
Actually, it's called "getting spoiled" ;)
> minor point: control-alt-h is the chord for "Shortcut Keys". Calls up a
> window with a list view with ascending/descending sorts on command,
> chord, type, and package. for this window, control-s opens a find
> dialog. but i just sorted by command name (well, it's the default) and
> scrolled down to "insert..." where I spotted alt-9. the full list is:
[...]
> insert-empty-list Alt + 9
Ah, there's a start. I was looking for "parenthesis" or "s-expression"
and missed this. However, that's not all: the counterpart to M-( is M-),
of course, which moves the cursor past the closing #\), which it places in
the proper place, then moves to the next line and indents. And I
regularly use C-u <n> M-( which will place parenthesis around <n>
expressions (not just an empty list anymore). Without these, M-( (or
Alt-9) is fairly worthless.
A few other nits:
* The undo facility seems very limited; only one change can be undone.
* Popping the cut/kill buffer eliminates the most recent cut/kill. Yes,
that's what it's supposed to do, but I don't like that. Emacs cycles
through, which means you can return to the newer kills after pasting an
older one.
* I see a mark-sexpr command, but no way to mark multiple ones.
(C-u <n> C-M-SPC in emacs)
I'm sure there is a way to extend the Allegro IDE to do all this, but it
would be nice if it was already there. Basically, I just want to be able
to not use the mouse at all, and have some powerful s-expression
manipulation abilities.
"KanZen" <······@mail.com> wrote in message
································@posting.google.com...
> Over the last few months I've made an effort to learn Common Lisp, and
> it has certainly been interesting. I got past the parantheses, and the
> 30 years of industrial grime that overlays the pure language core
> (getf nothing to do with setf? (elt list index) but (nth index list)?
Complaints like that are usually indicative of deeper frustrations. The
overall level of consistency in lisp has always impressed me, personally,
though there are indeed a few warts like the above...
> trying to remember when I need parans or double parans for various
> special forms etc.)
This really just means you haven't yet understood what the syntax
represents. LET for example, if you understand that the first arg is a list
of bindings you understand the need for (let (...) <code>) And if you
understand bindings are pairs of vars and value returning forms you don't
have to memorize the fact that let's usually go (let ((...) (...)) <code> )
But I understand that is a part of the learning curve.
> get working code almost as quickly as I can type. My macros almost
> never work first time, and I have to experiment with quotes,
> backquotes, commas etc. to get what I want.
Macros can be tricky. Most newbies mistake them for optimization tools and
thus try to misuse them before there is any need and before they have the
understanding of how they work. I was the same.
> Loops seem clumsy and
> unintuitive.
There are so many ways to loop, I think you should have posted here *before*
you gave up!
> Maybe I'll come back to Lisp one day.
If you do, don't suffer alone in the dark! Ask and you will be answered...
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> wrote in message news:<·····················@news-server.bigpond.net.au>...
> "KanZen" <······@mail.com> wrote in message
> ································@posting.google.com...
> > Over the last few months I've made an effort to learn Common Lisp, and
> > it has certainly been interesting. I got past the parantheses, and the
> > 30 years of industrial grime that overlays the pure language core
> > (getf nothing to do with setf? (elt list index) but (nth index list)?
>
> Complaints like that are usually indicative of deeper frustrations. The
> overall level of consistency in lisp has always impressed me, personally,
> though there are indeed a few warts like the above...
>
> > trying to remember when I need parans or double parans for various
> > special forms etc.)
>
> This really just means you haven't yet understood what the syntax
> represents. LET for example, if you understand that the first arg is a list
> of bindings you understand the need for (let (...) <code>) And if you
> understand bindings are pairs of vars and value returning forms you don't
> have to memorize the fact that let's usually go (let ((...) (...)) <code> )
Well I kind of thought I understood most of that, it's just that I seemed to
have a lot of trouble remembering it as I typed ;-)
> But I understand that is a part of the learning curve.
>
> > get working code almost as quickly as I can type. My macros almost
> > never work first time, and I have to experiment with quotes,
> > backquotes, commas etc. to get what I want.
>
> Macros can be tricky. Most newbies mistake them for optimization tools and
> thus try to misuse them before there is any need and before they have the
> understanding of how they work. I was the same.
>
> > Loops seem clumsy and
> > unintuitive.
>
> There are so many ways to loop, I think you should have posted here *before*
> you gave up!
Well, I always figured out how to loop from looking at various code samples and
documentation. But I found myself always having to look, which means writing a
loop takes two minutes instead of two seconds.
> > Maybe I'll come back to Lisp one day.
>
> If you do, don't suffer alone in the dark! Ask and you will be answered...
Thanks, but I'd moved past the "I have a bunch of stupid questions that needed
answers" stage into the "I can write code slowly and painfully" stage. It was
just taking me too long to get to the "I can write code quickly and easily"
stage.
KanZen
KanZen wrote:
> "Coby Beck" <
> Thanks, but I'd moved past the "I have a bunch of stupid questions that
> needed
> answers" stage into the "I can write code slowly and painfully" stage. It
> was just taking me too long to get to the "I can write code quickly and
> easily" stage.
I started learning Lisp before I even knew about Python, still in between
learned to use Python, became proficient in it and wrote some applications
in Python, while continuing to learn Lisp (though to be fair only very
part time). And now I do more and more things in Lisp and am close to
the point where I do most things in Lisp. Yes it does take a long time.
But one part of it is, because its just different than the typical languages
you get taught in school, and the other because it is so powerful and
has so many possibilities. A long time, there was a lack of good free
tools for Common Lisp, but especially in the recent time things are
changing. SLIME is a very good development tool, so combined with
CMUCL/SBCL you get a good development environment. And the number
of extension libraries has risen considerably recently, with
ASDF-INSTALL they are now even very easy to get and to manage.
(Check out ASDF for managing your projects, it is a big help.
SBCL includes ASDF support "out of the box")
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
······@mail.com (KanZen) wrote in message news:<···························@posting.google.com>...
> (getf nothing to do with setf? (elt list index) but (nth index list)?
I often agree with Graham that keyword args are important. Good IDEs
can halfway simulate this via flashing the params on the screen.
> Over the last few months I've made an effort to learn Common Lisp, and
> it has certainly been interesting. I got past the parantheses, and the
> 30 years of industrial grime that overlays the pure language core
> (getf nothing to do with setf? (elt list index) but (nth index list)?
> trying to remember when I need parans or double parans for various
> special forms etc.) I even got past setting up Lisp with Emacs (thanks
> to Slime, I never got ILisp working properly despite the large number
> of pages I could find with Google). I've been playing around with
> CMUCL/Slime/Emacs on Linux trying things out, writing sample programs
> and so on.
Come back when something like Interlisp is around. Do What I Mean is
important, despite sounding so disturbing.
"Whitespace inference" is also interesting in the context of Chaitin's
lisp. When writing on paper, I omit parens. The only problem is that
lisp is in early-adopter phase, so lisp companies aren't yet pouring
resources on something their customers don't prioritize.
There is something postapocalyptic about setf. People should be able
to import more "sensible names." However, living languages do
contradict cleanliness somewhat; same with cities I wish to stay in.
Good luck! Don't get on the wrong side of Guido!
KanZen wrote:
> But I've decided it's just not for me, and here's why. The first
> reason is that I just can't seem to fluently write Lisp code. Every
> line is a bit of a struggle, whereas with Python it seems I can just
> get working code almost as quickly as I can type.
Recently had some strange prob with making a Python prog run. But was some
prob with wxWindows (modified the API, *yuck*).
Was my first non-lisp prog for quite a time-- and my first syntax error
since then.
> My macros almost
> never work first time, and I have to experiment with quotes,
> backquotes, commas etc. to get what I want. Loops seem clumsy and
> unintuitive.
I learned much of lisp through "On Lisp" and never had any serious problem
with macros. Really.
> The second reason is the "hostility" of the Emacs/Slime/CMUCL
> environment. When something goes wrong in Python I can usually figure
> it out right away. In Lisp I almost always up in a stack trace with
> totally cryptic entries, and it's so much harder to figure out the
> problem. I'd like to just see a simple stack trace that clearly
> indicates what is happening, but it doesn't seem to work out that way
> in practice. This in particular seems such a pity, especially as there
> are many things about Slime that I like.
You (should had) have to look at the right part of the stack ;) The
topmost entries are mostly the pre-error-signal entries. But I agree more
interactivity ,i.e. inspector, graphical debugger, explorable stack trace,
would feel good. (Yes, ACL6.2 has 'em, but ACL's IDE sucks, I never happen
to have all windows at the right place, but especially I miss the
programmable editor + my nice syntax coloring. So I'm using
xemacs+slime+acl62.)
> Maybe I'll come back to Lisp one day.
Hope so.
-ts
--
,,
\../ / <<< The LISP Effect
|_\\ _==__
__ | |bb| | _________________________________________________
······@mail.com (KanZen) writes:
> reason is that I just can't seem to fluently write Lisp code. Every
> line is a bit of a struggle, whereas with Python it seems I can just
> get working code almost as quickly as I can type. My macros almost
Just out of curiosity, how long did it take you to master Python?
> never work first time, and I have to experiment with quotes,
> backquotes, commas etc. to get what I want. Loops seem clumsy and
Macros are the most powerful feature of Lisp--and possibly of every
other language. It is understandable that it takes some time to
understand them.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> wrote in message news:<··············@plato.moon.paoloamoroso.it>...
> ······@mail.com (KanZen) writes:
>
> > reason is that I just can't seem to fluently write Lisp code. Every
> > line is a bit of a struggle, whereas with Python it seems I can just
> > get working code almost as quickly as I can type. My macros almost
>
> Just out of curiosity, how long did it take you to master Python?
I certainly make no claims of *mastering* Python. I just found that it
seems that I can write working code right away. Maybe Python just
matches my thought processes better than Lisp. I felt I could write
good code quickly in Python after a day or two of playing around with
it. After a couple of months of playing with Common Lisp I don't yet
have the same feeling.
The one thing that really sold me on Python was the simple Tk TDD GUI
called unittestgui. Tap out a line of test code, press the button: red
bar. Type out a line of program code, press the button: green bar.
Fantastic. I see no reason why Lisp implementations could not have
something like this, but whenever I looked for Test First frameworks
for Lisp I could only find text based ones.
> > never work first time, and I have to experiment with quotes,
> > backquotes, commas etc. to get what I want. Loops seem clumsy and
>
> Macros are the most powerful feature of Lisp--and possibly of every
> other language. It is understandable that it takes some time to
> understand them.
>
>
> Paolo
KanZen wrote:
> I certainly make no claims of *mastering* Python. I just found that it
> seems that I can write working code right away. Maybe Python just
> matches my thought processes better than Lisp. I felt I could write
> good code quickly in Python after a day or two of playing around with
> it. After a couple of months of playing with Common Lisp I don't yet
> have the same feeling.
I came to Lisp via Python also, and too for me sometimes Python is
easier to use, especially due to its large number of ready-to use
libraries. But though it sometimes takes a little bit more effort
to get a project going in Lisp, I today prefer it, as I have the
more powerful tool in the long run.
> The one thing that really sold me on Python was the simple Tk TDD GUI
> called unittestgui. Tap out a line of test code, press the button: red
> bar. Type out a line of program code, press the button: green bar.
> Fantastic. I see no reason why Lisp implementations could not have
> something like this, but whenever I looked for Test First frameworks
> for Lisp I could only find text based ones.
At least for the GUI part, Lisp implementations can have something like
this and they do have :). Check out Ltk, a portable binding to Tk for
Lisp: http://www.peter-herth.de/ltk/ which is very easy to use,
especially if you have Tkinter experience. Extending it to an unit
test framework should be doable. A nice example how to build an
unit test framework for Lisp can be found in the upcoming
"Practical Common Lisp" by Peter Seibel. You can preview it on:
http://www.gigamonkeys.com/book/
The unit testing framework chapter is IMHO a very good demonstration
of the strengths of Common Lisp
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth <·····@netcologne.de> writes:
> KanZen wrote:
[snip]
>> The one thing that really sold me on Python was the simple Tk TDD
>> GUI called unittestgui. Tap out a line of test code, press the
>> button: red bar. Type out a line of program code, press the button:
>> green bar. Fantastic. I see no reason why Lisp implementations
>> could not have something like this, but whenever I looked for Test
>> First frameworks for Lisp I could only find text based ones.
>
> At least for the GUI part, Lisp implementations can have something
> like this and they do have :). Check out Ltk, a portable binding to
> Tk for Lisp: http://www.peter-herth.de/ltk/ which is very easy to
> use, especially if you have Tkinter experience. Extending it to an
> unit test framework should be doable. A nice example how to build an
> unit test framework for Lisp can be found in the upcoming "Practical
> Common Lisp" by Peter Seibel. You can preview it on:
> http://www.gigamonkeys.com/book/ The unit testing framework chapter
> is IMHO a very good demonstration of the strengths of Common Lisp
Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
on my test framework for the book." Code donations gladly accepted
should anyone feel like playing around with making a red-bar/green-bar
UI before I get around to it.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Christophe Rhodes
Subject: Re: Why I'm giving up on Lisp for now
Date:
Message-ID: <sqd63tc1n8.fsf@cam.ac.uk>
Peter Seibel <·····@javamonkey.com> writes:
> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
> on my test framework for the book." Code donations gladly accepted
> should anyone feel like playing around with making a red-bar/green-bar
> UI before I get around to it.
It's probably a little heavyweight for your purposes, but I believe
Andreas Fuchs has been playing with CLIM frontends to regression test
frameworks. I don't know how assiduously he reads comp.lang.lisp.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
>> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
>> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
>> on my test framework for the book." Code donations gladly accepted
>> should anyone feel like playing around with making a red-bar/green-bar
>> UI before I get around to it.
>
> It's probably a little heavyweight for your purposes, but I believe
> Andreas Fuchs has been playing with CLIM frontends to regression test
> frameworks. I don't know how assiduously he reads comp.lang.lisp.
Yeah. CLIM has been on my list to check out for some time now. But
somehow Ltk seems a bit more managable in the time I have left to
write the book. Someday though.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@cam.ac.uk>...
> It's probably a little heavyweight for your purposes, but I believe
> Andreas Fuchs has been playing with CLIM frontends to regression test
> frameworks. I don't know how assiduously he reads comp.lang.lisp.
Here is Andreas' CLIM interface to the RT regression testing framework:
http://boinkor.net/lisp/rt-clim.lisp
Paolo
Christophe Rhodes wrote:
> It's probably a little heavyweight for your purposes, but I believe
> Andreas Fuchs has been playing with CLIM frontends to regression test
> frameworks. I don't know how assiduously he reads comp.lang.lisp.
There're rumours that every now and then and if your very vigilant you may
have the chance to meet him and start a little confabulation at #lisp.
(You may ask for a fellow called "antifuchs".)
--
,,
\../ / <<< The LISP Effect
|_\\ _==__
__ | |bb| | _________________________________________________
Peter Seibel wrote:
> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
> on my test framework for the book." Code donations gladly accepted
> should anyone feel like playing around with making a red-bar/green-bar
> UI before I get around to it.
Ah, by the way: I really liked your testing framework, I mean I used it.
But I did some slight modification: A successful test shows no output. So
at the end you only see the failed tests or a relieving "ALL TESTS (45)
PASSED" message. (Who cares about successful tests? It's expected.)
Hm, I don't think a red/green bar enhances anything. But, well, for
educational purposes ... (:
-ts
--
,,
\../ / <<< The LISP Effect
|_\\ _==__
__ | |bb| | _________________________________________________
Peter Seibel wrote:
> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
> on my test framework for the book." Code donations gladly accepted
> should anyone feel like playing around with making a red-bar/green-bar
> UI before I get around to it.
I would not mind having something to Actually Build while fleshing out
Celtic. I found sound of your test framework code in ch9, some in ch23.
got a comprehensive listing, along with some tests to, um, test?
What should the GUI do? You could have a pop-up menu to select which
test runs, defaulting to "all". Or it could be a listbox allowing
multiple selections, none selected meaning all. A "run" button, of
course. Print each test/result as it runs...use the ink color variation
ala the CLIM solution (btw, I loved CLIM "ink" mnemonic vs. "the color
of the type will be the current foreground color" obscurity). I could
not grok why there was a third gray option -- did not run? How about a
checkbox option to stop at the first failed test? Test results should be
scrollable. And the red/green bar? Not a nifty sound-effect? Oops, no
sound in Tk. Ok, red/green. Hey, how about a progress bar? I see the
ch23 version adds handling of runtime errors... could the actual
condition be retained and made available for inspection? Actually, maybe
if stop at first error is selected we could simply backtrace...etc etc.
btw, if anyone else has a fun GUI to build I would also be interested.
If not I will port Cloucell (gui object inspector) to Celtic.
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
>
>> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
>> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
>> on my test framework for the book." Code donations gladly accepted
>> should anyone feel like playing around with making a red-bar/green-bar
>> UI before I get around to it.
>
> I would not mind having something to Actually Build while fleshing out
> Celtic. I found sound of your test framework code in ch9, some in
> ch23. got a comprehensive listing, along with some tests to, um, test?
You could probably just start from the version given at teh end of
chapter 3. It's like 27 lines or something. I don't have a single
canonical version cleaned up at the moment.
> What should the GUI do?
Well, the minimal XP style test tool has a button and a progress bar
that starts out green and then turns red if any of the test cases
fail. Beyond that you want some good way to see which cases failed and
to get debug them/see the source/run them again.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Peter Seibel wrote:
>>
>>
>>>Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
>>>I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
>>>on my test framework for the book." Code donations gladly accepted
>>>should anyone feel like playing around with making a red-bar/green-bar
>>>UI before I get around to it.
>>
>>I would not mind having something to Actually Build while fleshing out
>>Celtic. I found sound of your test framework code in ch9, some in
>>ch23. got a comprehensive listing, along with some tests to, um, test?
>
>
> You could probably just start from the version given at teh end of
> chapter 3.
Good point. We're just interested in computer-human interaction (chi) at
this point.
It's like 27 lines or something. I don't have a single
> canonical version cleaned up at the moment.
>
>
>>What should the GUI do?
>
>
> Well, the minimal XP style test tool has a button and a progress bar
> that starts out green and then turns red if any of the test cases
> fail. Beyond that you want some good way to see which cases failed and
> to get debug them/see the source/run them again.
Ok. I'll get going on that tomorrow, wrapping Tk widgets in Cells only
as needed. (I was slogging thru them one by one.) And I'll start with
the reductio ad absurdum minimum ("Run" button and a color bar) just to
get started.
aside: I decided to make Celtic follow Tk as closely as possible, on the
theory that Tk is just a hair better known than Cello...
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Peter Seibel wrote:
>>
>>
>>>Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
>>>I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
>>>on my test framework for the book." Code donations gladly accepted
>>>should anyone feel like playing around with making a red-bar/green-bar
>>>UI before I get around to it.
>>
>>I would not mind having something to Actually Build while fleshing out
>>Celtic. I found sound of your test framework code in ch9, some in
>>ch23. got a comprehensive listing, along with some tests to, um, test?
>
>
> You could probably just start from the version given at teh end of
> chapter 3. It's like 27 lines or something. I don't have a single
> canonical version cleaned up at the moment.
>
>
>>What should the GUI do?
>
>
> Well, the minimal XP style test tool has a button and a progress bar
> that starts out green and then turns red if any of the test cases
> fail.
(defun red-light-green-light ()
(make-be 'frame
:md-value (c-in :undecided)
:kids (c? (let ((test-bed self))
(list
(make-instance 'button
:text "Start"
:command (lambda ()
(setf (md-value test-bed) (test-math))))
(make-instance 'canvas
:width '2c
:height '1c
:kids (list
(make-instance 'rectangle
:coords (list 0 0 100 40)
:tk-fill (c? (ecase (md-value test-bed)
(:undecided 'black)
((nil) 'red)
((t) 'green)))))))))))
Of course this takes advantages of Cells as well as LTk. You were going
to do a chapter on Cells, yes? Oh. Well, a de-cellification would be
straightforward, if it comes to that.
Beyond that you want some good way to see which cases failed and
> to get debug them/see the source/run them again.
To make that possible, could deftest invoke a *test-demon* on its name
and test function? That would make a lot of things possible. The GUI
interface could first run a demon which does nothing but collect the
names, so we can present a list of possible tests. The actual test demon
could likewise look to the gui controller for info as to which tests to
perform, as well as compile a table of results by test. Untested:
(defvar *test-demon* nil)
(defmacro deftest (name parameters &body body)
"Define a test function. Within a test function we can call
other test functions or use `check' to run individual test
cases."
`(defun ,name ,parameters
(let ((*test-name* (append *test-name* (list ',name))))
(if *test-demon*
(funcall *test-demon* *test-name* (lambda () ,@body))
(progn ,@body)))))
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> Peter Seibel wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>
>>> Peter Seibel wrote:
>>>
>>>
>>>> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
>>>> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
>>>> on my test framework for the book." Code donations gladly accepted
>>>> should anyone feel like playing around with making a red-bar/green-bar
>>>> UI before I get around to it.
>>>
>>>
>>> I would not mind having something to Actually Build while fleshing out
>>> Celtic. I found sound of your test framework code in ch9, some in
>>> ch23. got a comprehensive listing, along with some tests to, um, test?
>>
>>
>>
>> You could probably just start from the version given at teh end of
>> chapter 3. It's like 27 lines or something. I don't have a single
>> canonical version cleaned up at the moment.
>>
>>
>>> What should the GUI do?
>>
>>
>>
>> Well, the minimal XP style test tool has a button and a progress bar
>> that starts out green and then turns red if any of the test cases
>> fail.
>
>
> (defun red-light-green-light ()
> (make-be 'frame
> :md-value (c-in :undecided)
> :kids (c? (let ((test-bed self))
> (list
> (make-instance 'button
> :text "Start"
> :command (lambda ()
> (setf (md-value test-bed) (test-math))))
> (make-instance 'canvas
> :width '2c
> :height '1c
> :kids (list
> (make-instance 'rectangle
> :coords (list 0 0 100 40)
> :tk-fill (c? (ecase (md-value test-bed)
> (:undecided 'black)
> ((nil) 'red)
> ((t) 'green)))))))))))
(defun red-light-green-light ()
"hello world GUI for Peter's unit test framework"
(make-be 'frame
:md-name :root
:md-value (c? (if (md-value (fm-other :start))
(test-math)
:undecided))
:kids (c? (list
(button :md-name :start
:text "Start"
:md-value (c-in nil)
:command (lambda (self)
(setf (^md-value) t)))
(canvas :width '2c :height '1c
:kids (list
(rectangle
:coords (list 0 0 100 40)
:tk-fill (c? (ecase (md-value (fm-other :root))
(:undecided 'black)
((nil) 'red)
((t) 'green))))))))))
I cleaned things up a little, creating functions button and canvas to
simply hide all the make-instance noise. The big change is that
LTk/Celtic callbacks are now passed the instance which registered a
callback (there is always some instance most involved, such as the
button whose command becomes a callback).
I'll call this version 0.0 and start on 0.1 using a *test-demon* to
interrogate a test function and display a red-green tree of test names
instead of just a bar.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
OK, this version lists the tests by name and changes them from black to
red or green ink as they run:
(defun ps-test-gui ()
(make-be 'ps-test-gui
:test-entry 'test-math))
(defmodel ps-test-gui (frame)
((tests :initarg :tests :initform nil :accessor tests)
(test-entry :initarg :test-entry :initform nil :accessor test-entry))
(:default-initargs
:tests (c? (let* (tests
(*test-demon* (lambda (name function)
(trc "collecting test" name)
(push (cons name function) tests)
(funcall function))))
(funcall (test-entry self))
(nreverse tests)))
:kids (c? (list
(button :md-name :start
:text "Start"
:command (lambda (self)
(loop for ti in (kids (fm-other :test-list))
do (setf (run ti) t))))
(canvas :md-name :test-list
:width '2c :height '3c
:kids (c? (let ((root (upper self ps-test-gui))
(loop for test in (tests root)
for n upfrom 0
collecting
(make-instance 'test-indicator$
:test test
:coords (list 0 (* n
20)))))))))))
(defmodel test-indicator$ (text)
((run :cell :ephemeral :initarg :run :initform (c-in nil) :accessor run)
(test :initarg :test :initform nil :accessor test))
(:default-initargs
:text (c? (format nil "~{~a ~}" (car (^test))))
:md-value (c? (if (^run)
(funcall (cdr (^test)))
:undefined))
:tk-fill (c? (ecase (^md-value)
(:undefined 'black)
((t) 'green)
((nil) 'red)))))
For those wondering where is the code which communicates with Tk, well,
Cells know to handle any state change by invoking c-output-slot-name
(specialized eql on the name, then on the instance, new-value, and
prior-value if any). This stuff also gets invoked at make-instance time
(approximately), since coming into existence is itself a state change.
Anyway, the idea is to make programming more declarative.
The outputs themselves are written by two very macros, def-tk-widget and
def-tk-item. here is the former:
(defmacro def-tk-widget (class (&rest super-classes)(&rest tk-options))
(let ((std-factory t))
(flet ((de- (sym) (intern (remove #\- (symbol-name sym) :end 1))))
(multiple-value-bind (slots outputs)
(loop for tk-option-def in tk-options
for slot-name = (de- (if (atom tk-option-def)
tk-option-def (car tk-option-def)))
collecting `(,slot-name :initform nil :initarg ,(intern
slot-name :keyword)
:accessor ,slot-name)
into slot-defs
when (or (atom tk-option-def)
(cadr tk-option-def))
collecting `(def-c-output ,slot-name ((self ,class))
(when new-value
(configure self ,(down$ (de- (if (atom
tk-option-def)
tk-option-def (cadr tk-option-def))))
(down$ new-value))))
into outputs
finally (return (values slot-defs outputs)))
`(progn
(defmodel ,class (,@(append super-classes '(tk-widget)))
(,@slots))
(defun ,class (&rest inits)
(apply 'make-instance ',class inits))
,(when std-factory
`(defmethod make-tk-instance ((self ,class))
(tk-send (format nil ,(concatenate 'string
(down$ class) " ~A") (path
self)))))
,@outputs)))))
Then I just copy and paste some text from a Tk reference web page and
massage it into:
(def-tk-widget frame ()
(-borderwidth -cursor -highlightbackground -highlightcolor
-highlightthickness -padx -pady -relief
-takefocus -background (tk-class -class)
-colormap -container -height -visual -width))
And viola, Tk is now declarative. Expansion below. Mind you, I am just
getting started and have not tested more than 1% of the code being
generated, but so far Cells and Tk seem happy together so I imagine any
issues will be resolved easily.
kt
(PROGN (DEFMODEL FRAME (TK-WIDGET)
((BORDERWIDTH :INITFORM NIL :INITARG :BORDERWIDTH
:ACCESSOR BORDERWIDTH)
(CURSOR :INITFORM NIL :INITARG :CURSOR :ACCESSOR CURSOR)
(HIGHLIGHTBACKGROUND :INITFORM NIL :INITARG
:HIGHLIGHTBACKGROUND :ACCESSOR
HIGHLIGHTBACKGROUND)
(HIGHLIGHTCOLOR :INITFORM NIL :INITARG
:HIGHLIGHTCOLOR :ACCESSOR HIGHLIGHTCOLOR)
(HIGHLIGHTTHICKNESS :INITFORM NIL :INITARG
:HIGHLIGHTTHICKNESS :ACCESSOR
HIGHLIGHTTHICKNESS)
(PADX :INITFORM NIL :INITARG :PADX :ACCESSOR PADX)
(PADY :INITFORM NIL :INITARG :PADY :ACCESSOR PADY)
(RELIEF :INITFORM NIL :INITARG :RELIEF :ACCESSOR RELIEF)
(TAKEFOCUS :INITFORM NIL :INITARG :TAKEFOCUS
:ACCESSOR TAKEFOCUS)
(BACKGROUND :INITFORM NIL :INITARG :BACKGROUND
:ACCESSOR BACKGROUND)
(TK-CLASS :INITFORM NIL :INITARG :TK-CLASS :ACCESSOR
TK-CLASS)
(COLORMAP :INITFORM NIL :INITARG :COLORMAP :ACCESSOR
COLORMAP)
(CONTAINER :INITFORM NIL :INITARG :CONTAINER
:ACCESSOR CONTAINER)
(HEIGHT :INITFORM NIL :INITARG :HEIGHT :ACCESSOR HEIGHT)
(VISUAL :INITFORM NIL :INITARG :VISUAL :ACCESSOR VISUAL)
(WIDTH :INITFORM NIL :INITARG :WIDTH :ACCESSOR WIDTH)))
(DEFUN FRAME (&REST INITS) (APPLY 'MAKE-INSTANCE 'FRAME INITS))
(DEFMETHOD MAKE-TK-INSTANCE ((SELF FRAME)) (TK-SEND (FORMAT NIL
"frame ~A" (PATH SELF))))
(DEF-C-OUTPUT BORDERWIDTH ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "borderwidth"
(DOWN$ NEW-VALUE))))
(DEF-C-OUTPUT CURSOR ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "cursor" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT HIGHLIGHTBACKGROUND ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF
"highlightbackground" (DOWN$ NEW-VALUE))))
(DEF-C-OUTPUT HIGHLIGHTCOLOR ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "highlightcolor"
(DOWN$ NEW-VALUE))))
(DEF-C-OUTPUT HIGHLIGHTTHICKNESS ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF
"highlightthickness" (DOWN$ NEW-VALUE))))
(DEF-C-OUTPUT PADX ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "padx" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT PADY ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "pady" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT RELIEF ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "relief" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT TAKEFOCUS ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "takefocus" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT BACKGROUND ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "background"
(DOWN$ NEW-VALUE))))
(DEF-C-OUTPUT TK-CLASS ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "class" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT COLORMAP ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "colormap" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT CONTAINER ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "container" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT HEIGHT ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "height" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT VISUAL ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "visual" (DOWN$
NEW-VALUE))))
(DEF-C-OUTPUT WIDTH ((SELF FRAME))
(WHEN NEW-VALUE (CONFIGURE SELF "width" (DOWN$
NEW-VALUE)))))
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: André Thieme
Subject: Re: Why I'm giving up on Lisp for now
Date:
Message-ID: <cbahbf$g5e$1@ulric.tng.de>
Kenny Tilton schrieb:
>
>
> Peter Seibel wrote:
>
>> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
>> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
>> on my test framework for the book." Code donations gladly accepted
>> should anyone feel like playing around with making a red-bar/green-bar
>> UI before I get around to it.
>
>
> I would not mind having something to Actually Build while fleshing out
> Celtic. I found sound of your test framework code in ch9, some in ch23.
> got a comprehensive listing, along with some tests to, um, test?
>
> What should the GUI do? You could have a pop-up menu to select which
> test runs, defaulting to "all". Or it could be a listbox allowing
> multiple selections, none selected meaning all. A "run" button, of
> course. Print each test/result as it runs...use the ink color variation
> ala the CLIM solution (btw, I loved CLIM "ink" mnemonic vs. "the color
> of the type will be the current foreground color" obscurity). I could
> not grok why there was a third gray option -- did not run? How about a
> checkbox option to stop at the first failed test? Test results should be
> scrollable. And the red/green bar? Not a nifty sound-effect? Oops, no
> sound in Tk. Ok, red/green. Hey, how about a progress bar? I see the
> ch23 version adds handling of runtime errors... could the actual
> condition be retained and made available for inspection? Actually, maybe
> if stop at first error is selected we could simply backtrace...etc etc.
>
> btw, if anyone else has a fun GUI to build I would also be interested.
> If not I will port Cloucell (gui object inspector) to Celtic.
Be carefull and don't violate any strange patents with your progress bar.
A lot of talk about red/green is done in a very good book by Kent Beck:
"Test Driven Development: By Example"
Andr�
--
Andr� Thieme wrote:
> Be carefull and don't violate any strange patents with your progress bar.
> A lot of talk about red/green is done in a very good book by Kent Beck:
> "Test Driven Development: By Example"
C'mon, this Kenny you are talking to. I was actually thinking of showing
one of two pictures, one of a bottle of champagne, one of a lumberyard.[1]
kenny
[1] From the movie "Caddy Shack"... long story.
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Peter Seibel wrote:
> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
> on my test framework for the book." Code donations gladly accepted
> should anyone feel like playing around with making a red-bar/green-bar
> UI before I get around to it.
Well, here is my shot at it. I had to tweak your testing framework
a little bit for the interaction with the GUI, you probably want
to refine that a bit.
Here it comes:
(use-package :ltk)
(defvar *test-name* nil)
(defmacro deftest (name parameters &body body)
"Define a test function. Within a test function we can call
other test functions or use `check' to run individual test
cases."
`(defun ,name ,parameters
(let ((*test-name* (append *test-name* (list ',name))))
,@body)))
(defmacro check (&body forms)
"Run each expression in `forms' as a test case."
`(combine-results
,@(loop for f in forms collect `(report-result ,f ',f))))
(defmacro combine-results (&body forms)
"Combine the results (as booleans) of evaluating `forms' in order."
(let ((result (gensym)))
`(let ((,result t))
,@(loop for f in forms collect `(unless ,f (setf ,result nil)))
,result)))
(defun report-result (result form)
"Report the results of a single test case. Called by `check'."
(lambda ()
(values result (format nil "~:[FAIL~;pass~] ... ~a: ~a~%" result
*test-name* form))))
(defmacro check (&body forms)
`(list ,@(loop for f in forms collect `(report-result ,f ',f))))
(deftest test-+ ()
(check
(= (+ 1 2) 3)
(= (+ 1 2 3) 6)
(= (+ -1 -3) -4)))
(defclass unit-win ()
((canvas :accessor canvas)
(progress :accessor progress)
(logwin :accessor logwin)
))
(defgeneric set-progress-percent (win percent))
(defmethod set-progress-percent ((win unit-win) percent)
(set-coords (canvas win) (progress win) (list 0 0 (truncate (* 300
percent) 100) 33))
)
(defgeneric set-progress-valid (win))
(defmethod set-progress-valid ((win unit-win))
(itemconfigure (canvas win) (progress win) "fill" "green")
(itemconfigure (canvas win) (progress win) "outline" "green")
)
(defgeneric set-progress-invalid (win))
(defmethod set-progress-invalid ((win unit-win))
(itemconfigure (canvas win) (progress win) "fill" "red")
(itemconfigure (canvas win) (progress win) "outline" "red")
)
(defgeneric clear-log (win))
(defmethod clear-log ((win unit-win))
(clear-text (logwin win)))
(defgeneric append-log (win txt))
(defmethod append-log ((win unit-win) txt)
(append-text (logwin win) txt))
(defun pass ()
t)
(defun fail ()
nil)
(defparameter *tests* (test-+))q
(defun run-tests (win)
(let ((step (/ 100.0 (length *tests*)))
(percent 0))
(set-progress-percent win 0)
(set-progress-valid win)
(clear-log win)
(dolist (test *tests*)
(incf percent step)
(set-progress-percent win percent)
(multiple-value-bind (success message) (funcall test)
(append-log win message)
(unless success
(set-progress-invalid win)))
(sleep 1))))
(defun gr-unit ()
(with-ltk
(let* ((win (make-instance 'unit-win))
(c (make-instance 'canvas :width 300 :height 30))
(x 0)
(text (make-instance 'text :width 20 :height 10))
(r (create-rectangle c 0 0 x 33))
(f (make-instance 'frame))
(bstart (make-instance 'button :master f :text "run tests"
:command (lambda ()
(run-tests win)))))
(setf (canvas win) c)
(setf (progress win) r)
(setf (logwin win) text)
(wm-title *tk* "Unit Test")
(pack c :side "top")
(pack text :fill "x")
(pack f :fill "x")
(pack bstart :side "right")
(configure c "borderwidth" 2)
(configure c "relief" "sunken")
(itemconfigure c r "fill" "green")
(itemconfigure c r "outline" "green")
)))
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth <·····@netcologne.de> writes:
> Peter Seibel wrote:
>
>> Heh. Thanks. I've been meaning to check out Ltk--reading KazZen's post
>> I was just thinking, "Hmmm. I should see if I can use Ltk to put a gui
>> on my test framework for the book." Code donations gladly accepted
>> should anyone feel like playing around with making a red-bar/green-bar
>> UI before I get around to it.
>
> Well, here is my shot at it. I had to tweak your testing framework a
> little bit for the interaction with the GUI, you probably want to
> refine that a bit. Here it comes:
Cool. I'll check it out soon
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Rob Warnock wrote:
> Uh... Is there a definition missing for CREATE-RECTANGLE somewhere?
> I couldn't find it even in the latest snapshot of Ltk...
Sorry, I was a little bit ahead of the time when I wrote that code :).
The next release of Ltk (due in a few days) will contain it and other
improvements. As a sneak preview here the missing function:
(defun create-rectangle (canvas x0 y0 x1 y1)
(send-w (format nil "puts [~a create rectangle ~a ~a ~a ~a]" (path canvas)
x0 y0 x1 y1))
(read-w))
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth <·····@netcologne.de> wrote:
+---------------
| Rob Warnock wrote:
| > Uh... Is there a definition missing for CREATE-RECTANGLE somewhere?
| > I couldn't find it even in the latest snapshot of Ltk...
|
| Sorry, I was a little bit ahead of the time when I wrote that code :).
| The next release of Ltk (due in a few days) will contain it and other
| improvements. As a sneak preview here the missing function:
|
| (defun create-rectangle (canvas x0 y0 x1 y1)
| (send-w (format nil "puts [~a create rectangle ~a ~a ~a ~a]" (path canvas)
| x0 y0 x1 y1))
| (read-w))
+---------------
Thanks! A few more comments:
- In the previous article, there was a spurious letter "q" here:
(defparameter *tests* (test-+))q
- PATH and VALUE are still exported (and conflict with my ~/.cmucl-init).
- SEND-W and READ-W are not exported by Ltk, so CREATE-RECTANGLE
needs to be this:
(defun create-rectangle (canvas x0 y0 x1 y1)
(ltk::send-w (format nil "puts [~a create rectangle ~a ~a ~a ~a]"
(path canvas) x0 y0 x1 y1))
(ltk::read-w))
[Or maybe needs to be *in* the LTK package? ...and exported? Your pick.]
But given all that and the following, things now work fine:
> (load "ltk")
; Loading #p"/u/rpw3/ltk/ltk.x86f".
> (shadowing-import 'ltk:path)
T
> (shadowing-import 'ltk:value)
T
> (setf ltk::*wish-pathname* "wish8.3") ; local necessity
"wish8.3"
> (use-package :ltk)
T
> (load "foo.lisp") ; test framework code
; Loading #p"/u/rpw3/ltk/foo.lisp".
T
> (gr-unit)
[...window pops up, tests run when button clicked...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> - In the previous article, there was a spurious letter "q" here:
>
> (defparameter *tests* (test-+))q
>
Hehe, yes, sometimes keystrokes land in the wrong buffer :)
> - PATH and VALUE are still exported (and conflict with my ~/.cmucl-init).
Could you please describe your problems in detail ? These symbols are
supposed to be exported (at least value, path is probably less useful
for users) I experienced no conflicts with these symbols.
> [Or maybe needs to be *in* the LTK package? ...and exported? Your pick.]
Yes, it is in the Ltk package and exported in the next Ltk version. I just
pasted it so that all who want to run the unit-test example can add it
to Ltk.
> But given all that and the following, things now work fine:
> [...window pops up, tests run when button clicked...]
Great to hear. Feedback and enhancement suggestions are always
very welcome.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth <·····@netcologne.de> wrote:
+---------------
| Rob Warnock wrote:
| > - PATH and VALUE are still exported (and conflict with my ~/.cmucl-init).
|
| Could you please describe your problems in detail ? These symbols are
| supposed to be exported (at least value, path is probably less useful
| for users) I experienced no conflicts with these symbols.
+---------------
[The following assumes the definition of CREATE-RECTANGLE has
been moved entirely into the LTK package, and EXPORTed...]
My "~/.cmucl-init" file contains (and has done, for several years)
local LET bindings for both PATH and VALUE (inside some personal
convenience functions), which means if I simply do a (USE-PACKAGE :LTK)
as in your examples, there's a conflict:
> (load "ltk")
; Loading #p"/u/rpw3/ltk/ltk.x86f".
T
> (use-package :ltk)
Error in function USE-PACKAGE:
Use'ing package LTK results in name conflicts for these symbols:
(VALUE PATH)
Restarts:
0: [CONTINUE] Unintern the conflicting symbols in COMMON-LISP-USER...
1: [ABORT ] Return to Top-Level.
...
Whereas if I shadow both PATH and VALUE, things work fine (since the
test code doesn't seem to need them to be visible from within USER):
> (load "ltk")
; Loading #p"/u/rpw3/ltk/ltk.x86f".
T
cmu> (shadow '(path value))
T
cmu> (setf ltk::*wish-pathname* "wish8.3")
"wish8.3"
cmu> (load "foo")
; Loading #p"/u/rpw3/ltk/foo.lisp".
T
cmu> (gr-unit)
canvas .w2 -width 300 -height 30
text .w3 -width 20 -height 10
puts [.w2 create rectangle 0 0 0 33]
...etc...
The other alternative [used in my previous reply] is to do
shadowing imports of PATH and VALUE before the USE-PACKAGE,
but that makes the previously-defined local symbols inaccessible
(though the functions using them continue to work, of course).
And on the third hand, the test harness code could simply
not do a USE-PACKAGE at all, and reference all of the Ltk
symbols explicitly [e.g. (LTK:WM-TITLE LTK:*TK* "Unit Test")].
They're only used in a handful of places, and that works
just fine, too.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607