Maybe you can share some skills about the debuging in Common Lisp.
I want to get a quick and useful method for debuging.
I am using Allegro CL 7.0 (w IDE, Modern).
Thanks in advance!
On Jan 3, 2:15 pm, ······@gmail.com wrote:
> Maybe you can share some skills about the debuging in Common Lisp.
> I want to get a quick and useful method for debuging.
> I am using Allegro CL 7.0 (w IDE, Modern).
> Thanks in advance!
I'm looking forward to Kenny's answer...
Leslie P. Polzer wrote:
> On Jan 3, 2:15 pm, ······@gmail.com wrote:
>
>>Maybe you can share some skills about the debuging in Common Lisp.
>>I want to get a quick and useful method for debuging.
>>I am using Allegro CL 7.0 (w IDE, Modern).
>>Thanks in advance!
>
>
> I'm looking forward to Kenny's answer...
Cells. :) But I mean the trc, trcx, eko, ekx utiltities therein.*
They are essentially print statements. Rarely I can use trace (generally
produces too much output) and for the same reason (too much) I have
never used the ACL breakpoint facility. Interactive debugging is too
slow and puts me in control, a bad idea when debuggiung because often
the problem is not where I think it is or it would not be a problem.
Better to have a crapload of output to scan. So this is the same answer
I would give for any language, more so because Lisp source debugging
sucks so bad.
kt
* I struggle with this, but there a couple of places where it helps for
those utils to be Cells-aware, so they end up in the Cells package.
Could be ripped out into standalone in minutes, I am sure.
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Thu, 03 Jan 2008 09:59:17 -0500, Ken Tilton <···········@optonline.net> wrote:
> more so because Lisp source debugging sucks so bad.
Remind me, what was the reason Lisp source debugging sucks so bad? I
think I forgot.
Thanks,
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Thu, 03 Jan 2008 09:59:17 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>more so because Lisp source debugging sucks so bad.
>
>
> Remind me, what was the reason Lisp source debugging sucks so bad? I
> think I forgot.
Oh, Christ, another graduate of the Ron Garret School of Usenet
Assinity. Did you have something you wanted to say before joining froggy
in my killfile? One more BS post like this and in you go. Hopefully you
will pull out of this death spin and offer something that helps noobs
with debugging, the topic if noticed not you have.
<sigh>
kxo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
> > Ken Tilton wrote:
> >>more so because Lisp source debugging sucks so bad.
> Edi Weitz wrote:
> > Remind me, what was the reason Lisp source debugging sucks so bad?
On Jan 3, 10:37 pm, Ken Tilton wrote:
> Oh, Christ, another graduate of the Ron Garret School of Usenet
> Assinity.
Shouldn't that be "Assininity"?
> BS post like this
I seem to recall using a C debugger that didn't even have an OUT
command. STEP seems nice so far.
> something that helps noobs with debugging
In the source:
(declaim (optimize debug))
(defun foo (args) ...)
In the repl:
* (step (foo args))
--Dan
www.prairienet.org/~dsb/
danb wrote:
>>>Ken Tilton wrote:
>>>
>>>>more so because Lisp source debugging sucks so bad.
>
>
>>Edi Weitz wrote:
>>
>>>Remind me, what was the reason Lisp source debugging sucks so bad?
>
>
> On Jan 3, 10:37 pm, Ken Tilton wrote:
>
>>Oh, Christ, another graduate of the Ron Garret School of Usenet
>>Assinity.
>
>
> Shouldn't that be "Assininity"?
Ah, thx, I always lose that syllalable.
>
>
>>BS post like this
>
>
> I seem to recall using a C debugger that didn't even have an OUT
> command. STEP seems nice so far.
I think I played with that in cmucl when porting RoboCells to Linux,
worked well IIRC.
What I missed recently was being able to see at which line in the source
something had gone horribly wrong, cuz I had uncharacteristically
written a humongous function and the failing mechanism was used therein
about a hundred places (and was a macro that had to serve as a place so
I could not just add some debugging code). ACL and IIRC MCL before it
never said much about where I had failed -- hmm, ISTR viewing the
disassembly in the MCL debugger to figure out where I was.
>
>
>>something that helps noobs with debugging
>
>
> In the source:
> (declaim (optimize debug))
> (defun foo (args) ...)
>
> In the repl:
> * (step (foo args))
Cool.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Fri, 04 Jan 2008 11:38:05 -0500, Ken Tilton <···········@optonline.net> wrote:
> What I missed recently was being able to see at which line in the
> source something had gone horribly wrong, cuz I had
> uncharacteristically written a humongous function and the failing
> mechanism was used therein about a hundred places (and was a macro
> that had to serve as a place so I could not just add some debugging
> code). ACL and IIRC MCL before it never said much about where I had
> failed -- hmm, ISTR viewing the disassembly in the MCL debugger to
> figure out where I was.
Really? What happens with a function like this?
(defun foo (x)
(let ((y (* x x)))
(decf y)
(let ((z (+ y 10)))
(loop for i below 10
collect (/ i (- z 18))))))
If I call it as (FOO 3), I get a division-by-zero error. If I click
on the FOO frame in the LispWorks debugger it not only opens the
source file for FOO, but it clearly marks
(/ i (- z 18))
as the offending form within FOO. No need to search or disassemble.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Fri, 04 Jan 2008 11:38:05 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>What I missed recently was being able to see at which line in the
>>source something had gone horribly wrong, cuz I had
>>uncharacteristically written a humongous function and the failing
>>mechanism was used therein about a hundred places (and was a macro
>>that had to serve as a place so I could not just add some debugging
>>code). ACL and IIRC MCL before it never said much about where I had
>>failed -- hmm, ISTR viewing the disassembly in the MCL debugger to
>>figure out where I was.
>
>
> Really? What happens with a function like this?
>
> (defun foo (x)
> (let ((y (* x x)))
> (decf y)
> (let ((z (+ y 10)))
> (loop for i below 10
> collect (/ i (- z 18))))))
>
> If I call it as (FOO 3), I get a division-by-zero error. If I click
> on the FOO frame in the LispWorks debugger it not only opens the
> source file for FOO, but it clearly marks
>
> (/ i (- z 18))
>
> as the offending form within FOO. No need to search or disassemble.
Nice. How does it handle macros?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Fri, 04 Jan 2008 14:59:17 -0500, Ken Tilton <···········@optonline.net> wrote:
> Nice. How does it handle macros?
See my reply to Rainer. It will usually locate the offending macro
form if a condition originated there.
What you can also do (see said example) - right-click on the QUUX
frame and select "Restart Frame Stepping". Then you can step through
this form (with helpful variations like "Step To Call", "Step Through
Call", "Step To Cursor", and so on) and at any time you can select to
macro-expand or "macro-collapse" the forms you're looking at.
It is probably better to try this out yourself than having me explain
this in my weird English. Download the Personal Edition of LispWorks
and work through the examples in the "Common LispWorks User Guide."
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Fri, 04 Jan 2008 11:38:05 -0500, Ken Tilton <···········@optonline.net> wrote:
>
> > What I missed recently was being able to see at which line in the
> > source something had gone horribly wrong, cuz I had
> > uncharacteristically written a humongous function and the failing
> > mechanism was used therein about a hundred places (and was a macro
> > that had to serve as a place so I could not just add some debugging
> > code). ACL and IIRC MCL before it never said much about where I had
> > failed -- hmm, ISTR viewing the disassembly in the MCL debugger to
> > figure out where I was.
>
> Really? What happens with a function like this?
>
> (defun foo (x)
> (let ((y (* x x)))
> (decf y)
> (let ((z (+ y 10)))
> (loop for i below 10
> collect (/ i (- z 18))))))
>
> If I call it as (FOO 3), I get a division-by-zero error. If I click
> on the FOO frame in the LispWorks debugger it not only opens the
> source file for FOO, but it clearly marks
>
> (/ i (- z 18))
>
> as the offending form within FOO. No need to search or disassemble.
LispWorks also tries to mark the current source
form for all the other stack frames (for which source is known).
(defun bar (x)
(+ x (third (foo x))))
(bar 3)
A double click on the 'bar' frame will highlight the (foo x) subform.
Very cool.
>
> Edi.
--
http://lispm.dyndns.org/
On Fri, 04 Jan 2008 19:20:38 +0100, Rainer Joswig <······@lisp.de> wrote:
> LispWorks also tries to mark the current source form for all the
> other stack frames (for which source is known).
>
> (defun bar (x)
> (+ x (third (foo x))))
>
> (bar 3)
>
> A double click on the 'bar' frame will highlight the (foo x)
> subform.
>
> Very cool.
Also, if you do something like this
(defmacro bar (y)
"Hide FOO with a macro."
`(foo (1- ,y)))
(defun quux (a)
(loop repeat 42
when (oddp a)
collect (bar (1+ a))
else collect (bar (+ a 2))))
and evaluate (QUUX 2), then of course if you click the QUUX frame in
the debugger, the /correct/ BAR form of the two which are in QUUX will
be highlighted.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> If I call it as (FOO 3), I get a division-by-zero error. If I click
> on the FOO frame in the LispWorks debugger it not only opens the
> source file for FOO, but it clearly marks
>
> (/ i (- z 18))
>
> as the offending form within FOO. No need to search or disassemble.
For the record, SLIME supports this as well. Likewise for the other
example involving macros. (I use it with SBCL, it might be supported in
other Lisps too.)
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Luís Oliveira wrote:
> Edi Weitz <········@agharta.de> writes:
>
>>If I call it as (FOO 3), I get a division-by-zero error. If I click
>>on the FOO frame in the LispWorks debugger it not only opens the
>>source file for FOO, but it clearly marks
>>
>> (/ i (- z 18))
>>
>>as the offending form within FOO. No need to search or disassemble.
>
>
> For the record, SLIME supports this as well. Likewise for the other
> example involving macros. (I use it with SBCL, it might be supported in
> other Lisps too.)
>
One of my fantasies for a good Lisp-NYC monthly event has long been an
IDE shoot-out in the format of the classic basketball game of Ghost*. I
think it would be a fun way to learn Slime.
kt
* where one player does any weird shot they like (complete with required
subcomponents, as made famous by a Nike Super Bowl commercial) and if
they succeed all the other players have to make it too or pick up a
letter form the word ghost. k
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Fri, 04 Jan 2008 22:10:14 +0000, ·············@deadspam.com (Lu�s Oliveira) wrote:
> For the record, SLIME supports this as well.
Fine. So we can probably agree that it is not Lisp source debugging
that sucks. Maybe some IDEs suck, but that's not a general problem of
Lisp.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Fri, 04 Jan 2008 22:10:14 +0000, ·············@deadspam.com (Lu�s Oliveira) wrote:
>
>
>>For the record, SLIME supports this as well.
>
>
> Fine. So we can probably agree that it is not Lisp source debugging
> that sucks. Maybe some IDEs suck, but that's not a general problem of
> Lisp.
In your puzzling eagerness to grind your AllegroCL/Kenny axe, you forgot
that the comparison is Lisp vs C debugging (and I presume Java). Or
maybe you are not familiar with what a C IDE offers in terms of source
debugging? As far back as Lightspeed C (twenty-plus years) the source
debugging far oustripped what I have heard so far about LW/Slime.
And let's not forget the poor OP, who just wants to learn about Lisp
debugging, not your unhappiness with my happiness with AllegroCL. Even
when I had great source debugging in C and Vax Basic I still just wrote
debugging output to the console. Lisp's introspective power makes that
even more effective, because one often needs to make the output
condiitonal so the important data stands out, and with Lisp one those
conditions can be metaconditions.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Fri, 04 Jan 2008 18:27:54 -0500, Ken Tilton <···········@optonline.net> wrote:
> Edi Weitz wrote:
>> Fine. So we can probably agree that it is not Lisp source
>> debugging that sucks. Maybe some IDEs suck, but that's not a
>> general problem of Lisp.
>
> In your puzzling eagerness to grind your AllegroCL/Kenny axe
I didn't even mention AllegroCL, nor did I mention you. My apologies
if you're still offended. Didn't know you were so touchy.
> you forgot that the comparison is Lisp vs C debugging (and I presume
> Java).
No, there's no Lisp/C comparison going on here. The topic of this
thread is "How to debug in Common Lisp." Dan mentioned C in passing,
but that was about it as far as I remember.
> And let's not forget the poor OP, who just wants to learn about Lisp
> debugging, not your unhappiness with my happiness with AllegroCL.
I'm not unhappy with you using and bragging about AllegroCL, but
sometimes I think the newbies reading your postings should look at
alternatives as well. Lots of your postings sound as if AllegroCL is
the only reasonable Lisp IDE on the planet. I don't agree. I also
happen to not agree with your opinion that Lisp source debugging
sucks. I hope you can live with that.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Fri, 04 Jan 2008 18:27:54 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>Edi Weitz wrote:
>>
>>>Fine. So we can probably agree that it is not Lisp source
>>>debugging that sucks. Maybe some IDEs suck, but that's not a
>>>general problem of Lisp.
>>
>>In your puzzling eagerness to grind your AllegroCL/Kenny axe
>
>
> I didn't even mention AllegroCL, nor did I mention you. My apologies
> if you're still offended. Didn't know you were so touchy.
>
>
>>you forgot that the comparison is Lisp vs C debugging (and I presume
>>Java).
>
>
> No, there's no Lisp/C comparison going on here. The topic of this
> thread is "How to debug in Common Lisp." Dan mentioned C in passing,
> but that was about it as far as I remember.
Puh-lease. You specifically challenged the assertion that "Lisp source
debugging sucks". What languages did you think I was contrasting it
with? Swahili? I hope so. No, sorry, the source debugging suckyness bar
is set by C/C++/Java IDEs, Lisp loses, deal with it.
>
>
>>And let's not forget the poor OP, who just wants to learn about Lisp
>>debugging, not your unhappiness with my happiness with AllegroCL.
>
>
> I'm not unhappy with you using and bragging about AllegroCL,
No? Repeatedly accusing me of shilling for Franz, challenging my
integrity, their integrity, and my intellectual honesty, and accusing me
of taking money for offering my opinions here, as in suggesting I am
secretly on the payroll? Happy people do not cast such gratuitous
aspersions.
Man, Amsterdam is gonna be a blast. Forget ECLM, have you yobbos lined
up a proper pub for the ineluctable donnybrook? Alert the bouncers!
but
> sometimes I think the newbies reading your postings should look at
> alternatives as well. Lots of your postings sound as if AllegroCL is
> the only reasonable Lisp IDE on the planet. I don't agree. I also
> happen to not agree with your opinion that Lisp source debugging
> sucks. I hope you can live with that.
This is a huge marketing mistake, Dr. Weitz. Noobs come to lisp from --
well, OK, no, not when they come from Python, Rucy, or Perl -- languages
where the IDEs are light years ahead of anything any Lisp IDEs have to
offer. Far better to say to them: don't freak out over the lame source
debugger, Lisp is so frickin awesome we just do not need
super-feature-rich debugging IDEs to get thru the day, so... no one has
bothered to create them!*
I mean, in the end the best we can do is congratulate the OP on asking a
tremendously perspicuitous (check me on that, Danno) question, because
Lisp debugging /is/ different. I have offered my approach, and
apparently Dr. Weitz's is step-step-step inspect-inspect step-step
inspect step-step-step... but that is not really Lisp debugging, that is
the mistake of treating Lisp as if it were C. Do not go there.
kt
* Quite clear in my mind is my own nooby reaction to Lisp IDEs, which
was simply one of horror, and I seem to recall actually dashing off an
epistle to someone somewhere saying, damn, this is an incredible
language, but you idiots need to spend a good three-day weekend on the
goddamn IDE, this is embarrassing. Soon after I found myself trivially
rolling my own kennyspecific debugging hacks and Got It(tm): Lisp's
introspective powers let us toss off ad hoc debuggery far more useful
than (yes) superpowerful but functionally static debugging tools.
Apologies in advance for returning to the OP's question. <sigh> k
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
danb <·········@gmail.com> writes:
>> > Ken Tilton wrote:
>> >>more so because Lisp source debugging sucks so bad.
>
>> Edi Weitz wrote:
>> > Remind me, what was the reason Lisp source debugging sucks so bad?
>
> On Jan 3, 10:37 pm, Ken Tilton wrote:
>> Oh, Christ, another graduate of the Ron Garret School of Usenet
>> Assinity.
>
> Shouldn't that be "Assininity"?
>
>> BS post like this
>
> I seem to recall using a C debugger that didn't even have an OUT
> command. STEP seems nice so far.
>
>> something that helps noobs with debugging
>
> In the source:
> (declaim (optimize debug))
> (defun foo (args) ...)
>
> In the repl:
> * (step (foo args))
Not only in the REPL!
If you determine that some inner form is closer to the bug, you can
enclose it in a STEP.
(defun f (x)
(if (p x)
(step (g x))
(h x)))
Lisp debugger should be more powerful than normal debuggers, because
you can step a specific sub-expression (gdb can only step lines, or
processor instructions), and you can step inside the macros (gdb can
still only step lines, and is totally useless to debug the expansion
of cpp macros).
There's the potential to implement very powerful debugging commands
for lisp code, since it could modify any form without having to
recompile the whole program. Click on a parenthesis, and tell it to
trace or step the subexpression, etc. But actually, it's so easy to
insert your own debugging forms (replace a LET by a TRACE-LET, insert
a PRINT or a STEP, etc) that, as always with lisp, you get 80% of the
features without the need for any external tool.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
On Fri, 04 Jan 2008 20:23:32 +0100, Pascal Bourguignon <···@informatimago.com> wrote:
> There's the potential to implement very powerful debugging commands
> for lisp code, since it could modify any form without having to
> recompile the whole program. Click on a parenthesis, and tell it to
> trace or step the subexpression, etc.
In LispWorks you can for example click on a form and tell the IDE to
set a breakpoint there. It will even be highlighted accordingly. Or
you can click an expression and tell the IDE to "Trace Inside" which
means that if you for example trace FOO inside QUUX only calls to FOO
from within QUUX will be traced.
There's lots more. Again, get yourself a trial version and play with
it. Spend a fair amount of time with it, you won't be able to
evaluate an IDE in a couple of hours or less.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Open source Lisp debugging sucks horribly. I've heard that cmucl has
a graphical debugger inside the hemlock package, which I couldn't get
to work, though I didn't try very hard. The interface looked kludgy.
Lispworks has a beautiful graphical debugger.
On Jan 3, 9:59 am, Ken Tilton <···········@optonline.net> wrote:
> Leslie P. Polzer wrote:
> > On Jan 3, 2:15 pm, ······@gmail.com wrote:
>
> >>Maybe you can share some skills about the debuging in Common Lisp.
> >>I want to get a quick and useful method for debuging.
> >>I am using Allegro CL 7.0 (w IDE, Modern).
> >>Thanks in advance!
>
> > I'm looking forward to Kenny's answer...
>
> Cells. :) But I mean the trc, trcx, eko, ekx utiltities therein.*
>
> They are essentially print statements. Rarely I can use trace (generally
> produces too much output) and for the same reason (too much) I have
> never used the ACL breakpoint facility. Interactive debugging is too
> slow and puts me in control, a bad idea when debuggiung because often
> the problem is not where I think it is or it would not be a problem.
> Better to have a crapload of output to scan. So this is the same answer
> I would give for any language, more so because Lisp source debugging
> sucks so bad.
>
> kt
>
> * I struggle with this, but there a couple of places where it helps for
> those utils to be Cells-aware, so they end up in the Cells package.
> Could be ripped out into standalone in minutes, I am sure.
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
On Jan 8, 8:08 pm, aneil <··········@gmail.com> wrote:
> Open source Lisp debugging sucks horribly. I've heard that cmucl has
> a graphical debugger inside the hemlock package, which I couldn't get
> to work, though I didn't try very hard. The interface looked kludgy.
You do not need Hemlock to use the CMUCL graphical debugger. You need
Motif installed and the Motif interface loaded.
The graphical debugger plus inspector of CMUCL is quite adequate. It
has that '90s look to it, but it is otherwise functional.
Cheers
Marco
>
> Lispworks has a beautiful graphical debugger.
>
> On Jan 3, 9:59 am, Ken Tilton <···········@optonline.net> wrote:
>
> > Leslie P. Polzer wrote:
> > > On Jan 3, 2:15 pm, ······@gmail.com wrote:
>
> > >>Maybe you can share some skills about the debuging in Common Lisp.
> > >>I want to get a quick and useful method for debuging.
> > >>I am using Allegro CL 7.0 (w IDE, Modern).
> > >>Thanks in advance!
>
> > > I'm looking forward to Kenny's answer...
>
> > Cells. :) But I mean the trc, trcx, eko, ekx utiltities therein.*
>
> > They are essentially print statements. Rarely I can use trace (generally
> > produces too much output) and for the same reason (too much) I have
> > never used the ACL breakpoint facility. Interactive debugging is too
> > slow and puts me in control, a bad idea when debuggiung because often
> > the problem is not where I think it is or it would not be a problem.
> > Better to have a crapload of output to scan. So this is the same answer
> > I would give for any language, more so because Lisp source debugging
> > sucks so bad.
>
> > kt
>
> > * I struggle with this, but there a couple of places where it helps for
> > those utils to be Cells-aware, so they end up in the Cells package.
> > Could be ripped out into standalone in minutes, I am sure.
>
> > --http://www.theoryyalgebra.com/
>
> > "In the morning, hear the Way;
> > in the evening, die content!"
> > -- Confucius
P� Wed, 09 Jan 2008 10:29:12 +0100, skrev Marco Antoniotti
<·······@gmail.com>:
> On Jan 8, 8:08�pm, aneil <··········@gmail.com> wrote:
>> Open source Lisp debugging sucks horribly. �I've heard that cmucl has
>> a graphical debugger inside the hemlock package, which I couldn't get
>> to work, though I didn't try very hard. �The interface looked kludgy.
>
> You do not need Hemlock to use the CMUCL graphical debugger. You need
> Motif installed and the Motif interface loaded.
>
> The graphical debugger plus inspector of CMUCL is quite adequate. It
> has that '90s look to it, but it is otherwise functional.
>
> Cheers
>
> Marco
>
I agree that the command based tools do the job. That being said I use
LispWorks..
--------------
John Thingstad
On Jan 9, 11:49 am, "John Thingstad" <·······@online.no> wrote:
> På Wed, 09 Jan 2008 10:29:12 +0100, skrev Marco Antoniotti
> <·······@gmail.com>:
>
> > On Jan 8, 8:08 pm, aneil <··········@gmail.com> wrote:
> >> Open source Lisp debugging sucks horribly. I've heard that cmucl has
> >> a graphical debugger inside the hemlock package, which I couldn't get
> >> to work, though I didn't try very hard. The interface looked kludgy.
>
> > You do not need Hemlock to use the CMUCL graphical debugger. You need
> > Motif installed and the Motif interface loaded.
>
> > The graphical debugger plus inspector of CMUCL is quite adequate. It
> > has that '90s look to it, but it is otherwise functional.
>
> > Cheers
>
> > Marco
>
> I agree that the command based tools do the job. That being said I use
> LispWorks..
>
Well, I am using mostly LW(WM) these days as well, but the *graphical*
Motif-based CMUCL debugger/inspector is pretty good too. It does not
do the fancy breaking that LW does these days, but it is still very
usable.
Cheers
--
Marco
On Jan 3, 6:15 am, ······@gmail.com wrote:
> Maybe you can share some skills about the debuging in Common Lisp.
> I want to get a quick and useful method for debuging.
> I am using Allegro CL 7.0 (w IDE, Modern).
> Thanks in advance!
Learning to debug in Lisp is definitely more of an art than a
science. Here's a collection of links to get you started:
Marco Baringer's Slime movie shows how to use Slime to develop and
debug a program. It shows how to use the debugger and inspector.
Even though it's Slime specific, the techniques and "mindset" are
applicable in any implementation:
http://www.cl-user.net/asp/web-sites/slime-video
Bill Clementson has several postings on his blog about debugging:
http://bc.tech.coop/blog/040628.html
http://bc.tech.coop/blog/040922.html
Out of the collection of links from Bill above, there's a couple I'd
like to point out:
http://www.gia.ist.utl.pt/~aml/debugging-allegro.ps (Antonio Menezes
Leitao's very hard to find paper on debugging Lisp programs, using the
Allegro tools -- this will probably be very useful to you)
http://groups.google.com/group/comp.lang.lisp/msg/9a06d7959cd6c941
http://groups.google.com/group/comp.lang.lisp/msg/8317e7376a9571c8?q=g:thl2447047009d&dq=&hl=en&lr=&ie=UTF-8
(Two great posts from Joel Ray Holveck that go into the "mindset" of
debugging Lisp. Very excellent reading.)
For extra credit, read the chapter on the condition system in Peter
Seibel's Practical Common Lisp to see how far you can go in dealing
with errors than you can in other languages.
The bottom line is that if there's an error, you'll automatically go
into the debugger from where you can view & inspect local variables,
parameters, etc. This is usually enough information to figure out
what's wrong and fix. If not, you can move up and down the call stack
to see how you got there, examining locals and parameters at each
stack frame of interest.
If that's not sufficient, then you insert a call to break at some
point of interest, i.e.,
(code
...
(break)
...)
You can also wrap a when around it to break conditionally:
(code
...
(when (= n 10) ; or some other test
(break))
...)
Of course, inserting calls to print or format work equally well.
The key is that you can edit calls to break or format into your code
and get the function or file recompiled so quickly and rerun your code
that it's a pretty painless process.
The thing that's different from Visual C++ or gdb style debugging is
that you don't usually "step" through expressions. It's definitely a
change in mindset. It may be useful to set up some toy debugging
problems to practice debugging techniques on. I do know that
Lispworks has a stepper where you can step through forms similar in
nature to Visual C++ or gdb. Allegro probably has one as well. My
personal experience is that the break or format techniques mentioned
above are faster for me than "stepping" although there's been a couple
of times when stepping has been indispensible. Your mileage may of
course vary.
Glenn
A good advice not often heard is to compile your code in as many CL
implementations as you could.
(Try at least all the free ones). It is a more preventive than
strictly debugging measure, but very effective and usually instructive
as well.
On Jan 3, 8:15 am, ······@gmail.com wrote:
> Maybe you can share some skills about the debuging in Common Lisp.
> I want to get a quick and useful method for debuging.
> I am using Allegro CL 7.0 (w IDE, Modern).
> Thanks in advance!
trace does all I need.
P� Thu, 03 Jan 2008 14:15:53 +0100, skrev <······@gmail.com>:
> Maybe you can share some skills about the debuging in Common Lisp.
> I want to get a quick and useful method for debuging.
> I am using Allegro CL 7.0 (w IDE, Modern).
> Thanks in advance!
First I use LispWorks which has a diferent GUI debugger.
Mostly I just write a function then test it. The exception is in web pages
where you need the session thread context and testing won't do. Then I
just set a breakpoint in the code and use the GUI debugger. I start by
looking at the stack. Checking local vars are as expected. Then I set a
new breakpoint past the point of some actions and test again. Sometimes I
run code using data in the local stack frame. Sometimes I want it to stop
before a particular set of data breaks the code so I use a conditional
breakpoint. In extreme cases where I can't locate the bug I comment half
the code out and check whether I still get the error. The offending line
is then effectively found by binary search. For checking data flow logging
data to a file is good alla "entered here with params" and "returned this
value". Indenting for each nested call helps visually. Finally like Kenny
I sometimes insert format statements at strategic points to check the data.
I don't know of any quick and useful way of debugging. Much of figuring
out errors is having seen a similar message before and having a idea what
caused it. Similar with technique's. Everyone seems to have their own way.
Only with experience does it become easier.
Nevertheless maybe the pointers above will give you some ideas.
But mostly learn how to use the debugger and be creative about it. See it
as a challenge rather than a burden and soon the skill will come naturally.
--------------
John Thingstad