Hi all seasoned lisp developers,
I need some help to be indoctrinated into the lisp way. Newbie
questions (somewhat lengthy...) - I cannot figure out why the simple
example coming with araneida does not work and how to debug by setting
breakpoints.
Here's what I have - fedora 2 + sbcl 8.1.5 (rpm) + araneida_0.85 +
slime 1.0 (i tried to use sbcl directly on sh to learn the underlying
working from time to time)
I did the following -
$ sbcl
* (require 'asdf)
* (require 'araneida)
* (load ".../doc/example.lisp") ;; I have the read macro #{ #}
removed.
;; or C-x C-f .../doc/example.lisp C-c C-k in slime
http://localhost:8000/hello returns NOT FOUND
A look at sbcl documentation puts me at loss on how to set breakpoint
- any pointers?
Googling shows that seasoned lisp devs prefer other means of debugging
than breakpoints i.e. (break) & (trace) etc... some also talked about
bottom-up programming style reduces the need to do debugging - I
wonder if this holds when using other's code or library?
To continue down that path - I manually insert (break) to
araneida_0.85/handler.lisp's (handle-requst) and it works this way.
But I cannot figure out how to find the values of the local variables,
etc... list-locals did nothing, step just step out of the code.
The "... according to" documentation shows that things should just
work by following the examples, which would make more sense than where
I am right now.
My suspicions are
1) I am missing a step somewhere to fully use the examples
2) The handler is looking for exact match of the url and I am typing
in the wrong url
3) somehow the example does not register the handler
4) I had a feeling I am very close...
I read through most of the code in araneida, and I understood most of
it, but I am at a loss to figure out how to do simple things, like
setting up environments, debugging, etc. One post mentioned ability
to set breakpoint in cmucl (listed in debugger help) - but I can't
find the equivalent in sbcl doc - surprising since sbcl was derived
from cmucl. I am probably missing something here.
From what I gathered sbcl is a high quality & widely used
implementation - surely someone can point me to the right places? I
have been to cliki, sbcl doc, and other high quality docs, but it's
difficult to find ones that can help me jump to get started on lisp
easily for some reason. If anyone can help me with getting started,
that's much appreciated.
Thanks,
yin-so
From: Svein Ove Aas
Subject: Re: lisp newbie: how to debug sbcl + araneida + (slime)
Date:
Message-ID: <ck62kv$iu9$1@services.kq.no>
Yin-So Chen wrote:
> Hi all seasoned lisp developers,
>
> I need some help to be indoctrinated into the lisp way. Newbie
> questions (somewhat lengthy...) - I cannot figure out why the simple
> example coming with araneida does not work and how to debug by setting
> breakpoints.
>
In my experience, threads are problematic with Araneida. Try an SBCL without
them, if yours has threads. (Read *features*)
> Here's what I have - fedora 2 + sbcl 8.1.5 (rpm) + araneida_0.85 +
> slime 1.0 (i tried to use sbcl directly on sh to learn the underlying
> working from time to time)
>
That's SBCL 0.8.15, right?
> I did the following -
> * (require 'asdf)
No need to do that in sbcl.
> * (require 'araneida)
> * (load ".../doc/example.lisp") ;; I have the read macro #{ #}
> removed.
> ;; or C-x C-f .../doc/example.lisp C-c C-k in slime
>
> http://localhost:8000/hello returns NOT FOUND
>
Araneida does virtual hosts, and by default doesn't map anything to
localhost. Run (my-araneida-example::my-fqdn) to find the appropriate host.
> A look at sbcl documentation puts me at loss on how to set breakpoint
> - any pointers?
>
SBCL doesn't do breakpoints; it does (break), (trace) and so on. SLIME may
or may not do breakpoints, that is to say, automatic insertion of breaks,
but if it does it should be in the documentation.
For what it's worth, my copy of slime (CVS HEAD) doesn't have anything
resembling breakpoints on the menu.
> Googling shows that seasoned lisp devs prefer other means of debugging
> than breakpoints i.e. (break) & (trace) etc... some also talked about
> bottom-up programming style reduces the need to do debugging - I
> wonder if this holds when using other's code or library?
>
Nope, but with any luck it'll already be sufficiently error-free.
It does help with the actual debugging if you find a need, though.
> To continue down that path - I manually insert (break) to
> araneida_0.85/handler.lisp's (handle-requst) and it works this way.
> But I cannot figure out how to find the values of the local variables,
> etc... list-locals did nothing, step just step out of the code.
>
Step isn't supported in SBCLs older than 0.8.15, but it should work if you
have it. You may need to compile the code with debugging support, though,
which I don't know how to do. (There *ought* to be an ASDF op to do that.
Anyone?)
To make Araneida use SLIME's debugger, you need to do
(setf araneida::*restart-on-handler-errors* *debugger-hook*), though.
> The "... according to" documentation shows that things should just
> work by following the examples, which would make more sense than where
> I am right now.
>
> My suspicions are
> 1) I am missing a step somewhere to fully use the examples
> 2) The handler is looking for exact match of the url and I am typing
> in the wrong url
Bingo!
> 3) somehow the example does not register the handler
> 4) I had a feeling I am very close...
Svein Ove Aas <·········@aas.no> wrote in message news:<············@services.kq.no>...
>
> In my experience, threads are problematic with Araneida. Try an SBCL without
> them, if yours has threads. (Read *features*)
Mine does not appear to have threads built-in at this time.
>
> > Here's what I have - fedora 2 + sbcl 8.1.5 (rpm) + araneida_0.85 +
> > slime 1.0 (i tried to use sbcl directly on sh to learn the underlying
> > working from time to time)
> >
> That's SBCL 0.8.15, right?
yes - typo ;)
>
> > I did the following -
> > * (require 'asdf)
> No need to do that in sbcl.
great! didn't know that.
> SBCL doesn't do breakpoints; it does (break), (trace) and so on. SLIME may
> or may not do breakpoints, that is to say, automatic insertion of breaks,
> but if it does it should be in the documentation.
So sbcl removed the breakpoints capability or did cmucl add it after
the fork?
> Step isn't supported in SBCLs older than 0.8.15, but it should work if you
> have it. You may need to compile the code with debugging support, though,
> which I don't know how to do. (There *ought* to be an ASDF op to do that.
> Anyone?)
>
> To make Araneida use SLIME's debugger, you need to do
> (setf araneida::*restart-on-handler-errors* *debugger-hook*), though.
I suspect there is a standard way of lisp documentation that i don't
realize - would love to get my hands on finding out these features and
how they should all hook together.
> > The "... according to" documentation shows that things should just
> > work by following the examples, which would make more sense than where
> > I am right now.
> >
> > My suspicions are
> > 1) I am missing a step somewhere to fully use the examples
> > 2) The handler is looking for exact match of the url and I am typing
> > in the wrong url
>
> Bingo!
I took a look @ (my-araneida-example::my-fdqn) and it returns my
hostname ("CALLANDOR" if anyone cares) - is lisp string case
sensitive? when using mozilla it translates all upper case letters in
url to lower case (but the page returns)...
Thanks,
From: Svein Ove Aas
Subject: Re: lisp newbie: how to debug sbcl + araneida + (slime)
Date:
Message-ID: <ck8ko6$eah$1@services.kq.no>
Yin-So Chen wrote:
> Svein Ove Aas <·········@aas.no> wrote in message
> news:<············@services.kq.no>...
>>
>> In my experience, threads are problematic with Araneida. Try an SBCL
>> without them, if yours has threads. (Read *features*)
>
> Mine does not appear to have threads built-in at this time.
>
As has been stated, you wouldn't actually need a thread-less SBCL to run
Araneida without threads. Having one does make it a bit more certain,
though.
>> > I did the following -
>> > * (require 'asdf)
>> No need to do that in sbcl.
>
> great! didn't know that.
>
Apparently, that's a Gentooism and you probably need to do it anyway.
From: Christophe Rhodes
Subject: Re: lisp newbie: how to debug sbcl + araneida + (slime)
Date:
Message-ID: <sqoejcarut.fsf@cam.ac.uk>
··········@gmail.com (Yin-So Chen) writes:
> Svein Ove Aas <·········@aas.no> wrote in message news:<············@services.kq.no>...
>> SBCL doesn't do breakpoints; it does (break), (trace) and so on. SLIME may
>> or may not do breakpoints, that is to say, automatic insertion of breaks,
>> but if it does it should be in the documentation.
>
> So sbcl removed the breakpoints capability or did cmucl add it after
> the fork?
(trace foo :break t) works for me. As ever, reading the documentation
comes highly recommended.
Christophe
Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@cam.ac.uk>...
> ··········@gmail.com (Yin-So Chen) writes:
>
> (trace foo :break t) works for me. As ever, reading the documentation
> comes highly recommended.
>
That's great & cool information - agreed that reading documentation
helps - however, I don't really know what documentation I am looking
for or where to find them. Would you mind giving me some pointers?
Thx,
yin-so
From: Peter Seibel
Subject: Re: lisp newbie: how to debug sbcl + araneida + (slime)
Date:
Message-ID: <m3ekk9rzd0.fsf@javamonkey.com>
Svein Ove Aas <·········@aas.no> writes:
> Yin-So Chen wrote:
>> A look at sbcl documentation puts me at loss on how to set
>> breakpoint - any pointers?
>>
> SBCL doesn't do breakpoints; it does (break), (trace) and so on.
> SLIME may or may not do breakpoints, that is to say, automatic
> insertion of breaks, but if it does it should be in the
> documentation.
Another standard debugging tool (part of the "and so on") is
*BREAK-ON-SIGNALS*. If Araneida (or some other code you didn't write)
is signalling a condition down in its guts you can set
*BREAK-ON-SIGNALS* to an appropriate value to get dropped in the
debugger just as it is signaled and before the condition handling
machinery takes over.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> Svein Ove Aas <·········@aas.no> writes:
>
> Another standard debugging tool (part of the "and so on") is
> *BREAK-ON-SIGNALS*. If Araneida (or some other code you didn't write)
> is signalling a condition down in its guts you can set
> *BREAK-ON-SIGNALS* to an appropriate value to get dropped in the
> debugger just as it is signaled and before the condition handling
> machinery takes over.
>
does break on condition work when there are no signals (i.e. similar
to break when a variable value is such and such)? I couldn't really
find any condition code in araneida (I am assuming that condition =
exception in this case - I read condition is more than exceptions) to
see that the condition will be signaled.
thanks,
From: Peter Seibel
Subject: Re: lisp newbie: how to debug sbcl + araneida + (slime)
Date:
Message-ID: <m3u0t4r11t.fsf@javamonkey.com>
··········@gmail.com (Yin-So Chen) writes:
> Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
>> Svein Ove Aas <·········@aas.no> writes:
>>
>> Another standard debugging tool (part of the "and so on") is
>> *BREAK-ON-SIGNALS*. If Araneida (or some other code you didn't write)
>> is signalling a condition down in its guts you can set
>> *BREAK-ON-SIGNALS* to an appropriate value to get dropped in the
>> debugger just as it is signaled and before the condition handling
>> machinery takes over.
>>
>
> does break on condition work when there are no signals (i.e. similar
> to break when a variable value is such and such)?
No. It's only useful in the case where some code is signalling a
condition that will otherwise be handled but you want to drop into the
debugger before it is handled to see why it's getting signaled in the
first place. For instance an app might signal a condition to indicate
some sort of error and it might be "handled" by logging something to
an error log and unwinding the stack. But you want to prevent the
error in the first place so you use *break-on-signals* to get dropped
into the debugger at the point the error is signaled.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Svein Ove Aas <·········@aas.no> writes:
> In my experience, threads are problematic with Araneida. Try an SBCL
> without them, if yours has threads. (Read *features*)
The unithread ("serve-event") model in araneida is much
better-tested than the threaded version, but will run in both threaded
and unthreaded systems, so you don't need a whole new single-thread
sbcl just for running Araneida.
I don't know precisely what the issues are (or for that matter,
whether there are issues) with the threaded version, because I don't
use it myself and haven't seen useful bug reports.
I do know that there is some odd interaction between SLIME's use of
threads and Araneida (in, I suspect, either model), such that araneida
doesn't answer requests at all when started from slime. I haven't
found what exactly is to blame here, but it's probably Araneida
(i.e. my fault) or SBCL (also my fault). The workaround is
(setf swank:*communication-style* :fd-handler)
in $HOME/.swank.lisp
>> * (load ".../doc/example.lisp") ;; I have the read macro #{ #}
>> removed.
What is this read macro of which you speak?
-dan
--
"please make sure that the person is your friend before you confirm"
Daniel Barlow <···@telent.net> writes:
> I do know that there is some odd interaction between SLIME's use of
> threads and Araneida (in, I suspect, either model), such that araneida
> doesn't answer requests at all when started from slime. I haven't
> found what exactly is to blame here, but it's probably Araneida
> (i.e. my fault) or SBCL (also my fault). The workaround is
>
> (setf swank:*communication-style* :fd-handler)
>
> in $HOME/.swank.lisp
FWIW, to use SLIME to debug Araneida request handlers, I use :sigio
and the following method:
(defmethod handle-request :around ((handler my-handler) request)
(if *debug*
(let ((*debugger-hook* 'swank:swank-debugger-hook))
(handler-bind ((error #'invoke-debugger))
(call-next-method)))
(call-next-method)))
Because Araneida blocks any other serve-event handlers from running
while it's handling a request, it doesn't mix well with :fd-handler if
you try to invoke the SLIME debugger.
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> Svein Ove Aas <·········@aas.no> writes:
>
> > In my experience, threads are problematic with Araneida. Try an SBCL
> > without them, if yours has threads. (Read *features*)
>
> The unithread ("serve-event") model in araneida is much
> better-tested than the threaded version, but will run in both threaded
> and unthreaded systems, so you don't need a whole new single-thread
> sbcl just for running Araneida.
I got mine sbcl rpm from the net somewhere (can't find the link right
now) and it does not have threads built-in. would you consider
threads to be experimental or production at this time? or is there a
way to fork processes in lisp in order to handle multiple requests?
> I don't know precisely what the issues are (or for that matter,
> whether there are issues) with the threaded version, because I don't
> use it myself and haven't seen useful bug reports.
>
> I do know that there is some odd interaction between SLIME's use of
> threads and Araneida (in, I suspect, either model), such that araneida
> doesn't answer requests at all when started from slime. I haven't
> found what exactly is to blame here, but it's probably Araneida
> (i.e. my fault) or SBCL (also my fault). The workaround is
>
> (setf swank:*communication-style* :fd-handler)
Sorry - what would this line do? Newbies have lots of questions... ;)
>
> in $HOME/.swank.lisp
>
> >> * (load ".../doc/example.lisp") ;; I have the read macro #{ #}
> >> removed.
>
> What is this read macro of which you speak?
I meant I have removed (note I missed the word "remove" above) the
comment surrounding the (start-listening) line :) in Ansi Common Lisp
PG calls it part of the read macros, so I learned to call them that -
let me know if I am mistaken...
Thanks,
yin-so
··········@gmail.com (Yin-So Chen) writes:
>> (i.e. my fault) or SBCL (also my fault). The workaround is
>>
>> (setf swank:*communication-style* :fd-handler)
>
> Sorry - what would this line do? Newbies have lots of questions... ;)
This would tell SLIME not to attempt to use multiple threads for its
communication with SBCL. It should be described somewhere in the
SLIME manual.
>> >> * (load ".../doc/example.lisp") ;; I have the read macro #{ #}
>> >> removed.
>>
>> What is this read macro of which you speak?
>
> I meant I have removed (note I missed the word "remove" above) the
> comment surrounding the (start-listening) line :)
Ah. Those are #| |# not #{ }# , hence my confusion. When you said
you'd removed some read macros I thought you meant you'd removed the
definitions of some read macros, which threw me a bit because I don't
remember having written any.
-dan
--
"please make sure that the person is your friend before you confirm"
··········@gmail.com (Yin-So Chen) writes:
> I got mine sbcl rpm from the net somewhere (can't find the link right
> now) and it does not have threads built-in. would you consider
> threads to be experimental or production at this time? or is there a
> way to fork processes in lisp in order to handle multiple requests?
I believe that threads in themselves are pretty robust these days, at
least for "normal" use. I know of one sure way to break them; it
involves repeated calls to interrupt-thread and you're probably not
likely to hit it unless something is already broken.
There are likely to still be parts of the SBCL internals that are not
thread-safe: I would treat things like the pretty-printer with
suspicion until convinced otherwise.
Thread support in Araneida is still new, or newish: there's probably
still quite a lot of work to be done on issues like timeouts,
maintaining a reasonably sized pool of idle threads, etc etc.
And, yeah, threads and serve-event don't mesh well together. I'm
thinking about that at the moment.
-dan
--
"please make sure that the person is your friend before you confirm"
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> ··········@gmail.com (Yin-So Chen) writes:
> I believe that threads in themselves are pretty robust these days, at
> least for "normal" use. I know of one sure way to break them; it
> involves repeated calls to interrupt-thread and you're probably not
> likely to hit it unless something is already broken.
Thanks Dan - if I want to enable threads on my rpm built of SBCL - is
that a config setting or do I need to compile my own SBCL? I don't
see thread in the /usr/lib/sbcl so it seems more as a core module than
a contrib module.
Thanks,
yin-so
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> Svein Ove Aas <·········@aas.no> writes:
>
> I do know that there is some odd interaction between SLIME's use of
> threads and Araneida (in, I suspect, either model), such that araneida
> doesn't answer requests at all when started from slime. I haven't
> found what exactly is to blame here, but it's probably Araneida
> (i.e. my fault) or SBCL (also my fault). The workaround is
>
Google groups is not fast enough to have messages appear real-time, so
I can't reply to my own post but to the last message I have here
(offtopic - if anyone else have a better news server let me know).
As Svein pointed out - I don't have an exact match of fqdn - and it
turns out it's case-sensitivity issue. Apparently FC2's mozilla will
translate all upper case url to lower case, but Araneida appears to
match with case sensitivity built-in... when I switch to test with
lynx I was able to view the page without problems.
This rookie mistake might be caused by my being in MS world for a long
while(i.e. case-insensitive urls) - I can't remember the last time I
been to a case-sensitive website though. Is there a way to disable
case sensitivity in Araneida as a config, rather than adding new code?
or rather - what's the lisp way?
Thanks for Svein,Peter, and Dan to point me in the right direction so
far ;) Would love for people to continue to enlighten me on my other
posts if possible :)
yin-so
From: ·········@random-state.net
Subject: Re: lisp newbie: how to debug sbcl + araneida + (slime)
Date:
Message-ID: <ck8a7c$aue7g$2@midnight.cs.hut.fi>
Yin-So Chen <··········@gmail.com> wrote:
> A look at sbcl documentation puts me at loss on how to set breakpoint
> - any pointers?
a) Insert (break "foo!") in the code where-ever you like, and
recompile the function in question (C-c C-c in Slime).
b) In SBCL (trace foo :break t) will cause an entry to the debugger
when FOO is called. (trace foo :break t :wherein bar) will cause
the debugger entry only if the call to FOO occurs within a call
to BAR.
Use (untrace foo) to remove the breakpoint.
> setting up environments, debugging, etc. One post mentioned ability
> to set breakpoint in cmucl (listed in debugger help) - but I can't
> find the equivalent in sbcl doc - surprising since sbcl was derived
> from cmucl. I am probably missing something here.
CMUCL style breakpoints aren't supported in SBCL.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
·········@random-state.net wrote in message news:<··············@midnight.cs.hut.fi>...
> Yin-So Chen <··········@gmail.com> wrote:
>
> b) In SBCL (trace foo :break t) will cause an entry to the debugger
> when FOO is called. (trace foo :break t :wherein bar) will cause
> the debugger entry only if the call to FOO occurs within a call
> to BAR.
>
> Use (untrace foo) to remove the breakpoint.
Thanks for all whom responded - it's been great help to untangle the
mystery for me and now I feel much more productive than a couple of
days ago! ;)
yin-so