Ok, here is the error I got from SBCL 1.0.12:
===
The value #2A((0 2) (4 6)) is not of type SEQUENCE.
[Condition of type TYPE-ERROR]
Restarts:
0: [ABORT-REQUEST] Abort handling SLIME request.
1: [ABORT] Exit debugger, returning to top level.
Backtrace:
0: (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
1: (DOUBLE #2A((0 2) (4 6)))
2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (DOUBLE A) #<NULL-LEXENV>)
===
Now, the very last thing in this trace is
(MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
Unfortunately, the error occurred 7 forms into this function... and I
had to manually remove and add things until the error form was
isolated.
I have used many many languages, but never have encountered a language
where the error reporting was so vague. I'm assuming some of the
commercial distros have much nicer error reporting?
Per some suggestions on IRC, these vague error messages (they dont say
the file name, file line, or exact function evaluation which caused
the error) are occurring even with this in effect:
(declaim (optimize debug))
Just FYI, the full monad-apply function is here -
http://hg.metaperl.com/redick?f=198e18b64d89;file=lisp/monad/apply.lsp;style=gitweb
From: Maciej Katafiasz
Subject: Re: quality of error reporting in various lisp distros
Date:
Message-ID: <fjsj6a$p6$1@news.net.uni-c.dk>
Den Thu, 13 Dec 2007 15:58:31 -0800 skrev metaperl.com:
> Now, the very last thing in this trace is
> (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
>
> Unfortunately, the error occurred 7 forms into this function... and I
> had to manually remove and add things until the error form was isolated.
>
> I have used many many languages, but never have encountered a language
> where the error reporting was so vague. I'm assuming some of the
> commercial distros have much nicer error reporting?
You get what you ask for, you just need to know how to ask.
(declaim (optimize (debug 3) (safety 3))) and recompile.
Now press v on the offending frame and enjoy precise location reporting.
So, instead of blaming the tool, you should learn how to use it.
Cheers,
Maciej
On Dec 13, 7:36 pm, Maciej Katafiasz <········@gmail.com> wrote:
>
> (declaim (optimize (debug 3) (safety 3))) and recompile.
recompile? I'm just interactively loading my source and evaluating
forms. I havent compiled anything. I made the change you suggested and
then reloaded that file (which reloaded the whole system), but I still
get the same vague error message.
From: Zach Beane
Subject: Re: quality of error reporting in various lisp distros
Date:
Message-ID: <m3mysde50l.fsf@unnamed.xach.com>
"metaperl.com" <········@gmail.com> writes:
> On Dec 13, 7:36 pm, Maciej Katafiasz <········@gmail.com> wrote:
>
>>
>> (declaim (optimize (debug 3) (safety 3))) and recompile.
>
> recompile? I'm just interactively loading my source and evaluating
> forms. I havent compiled anything.
Why do you think you haven't compiled anything?
> I made the change you suggested and then reloaded that file (which
> reloaded the whole system), but I still get the same vague error
> message.
What happens when you use "v" on the frame in SLIME?
Zach
On Dec 14, 9:15 am, Zach Beane <····@xach.com> wrote:
>
> What happens when you use "v" on the frame in SLIME?
I am put into a buffer called *Slime Source Form* with mode (Lisp
Slime | eval...)
which has the text:
(LAMBDA NIL (PROGN (SB-INT:NAMED-LAMBDA MONAD-APPLY (VERB NOUN VERB-
RANK) (BLOCK MONAD-APPLY #))))
From: Maciej Katafiasz
Subject: Re: quality of error reporting in various lisp distros
Date:
Message-ID: <fjunfb$p6$3@news.net.uni-c.dk>
Den Fri, 14 Dec 2007 10:40:13 -0800 skrev livingcosmos.org:
>> What happens when you use "v" on the frame in SLIME?
>
> I am put into a buffer called *Slime Source Form* with mode (Lisp Slime
> | eval...)
> which has the text:
>
> (LAMBDA NIL (PROGN (SB-INT:NAMED-LAMBDA MONAD-APPLY (VERB NOUN VERB-
> RANK) (BLOCK MONAD-APPLY #))))
This is exactly why you need to load apply.lsp explicitly. Otherwise not
enough info is recorded, SLIME gets confused and displays the best
approximation of source it can get, which happens to be temporary forms
used for communicating with inferior lisp. Either load the file, C-c C-k
it, or create an ASDF system for your code, as ASDF does enough mumbo-
jumbo with compilation for it to work.
Cheers,
Maciej
From: Maciej Katafiasz
Subject: Re: quality of error reporting in various lisp distros
Date:
Message-ID: <fju5ds$p6$2@news.net.uni-c.dk>
Den Fri, 14 Dec 2007 04:36:19 -0800 skrev metaperl.com:
>> (declaim (optimize (debug 3) (safety 3))) and recompile.
>
> recompile? I'm just interactively loading my source and evaluating
> forms. I havent compiled anything.
Too bad. And yes, you have, you're using SBCL, which compiles everything
until explicitly asked not to.
> I made the change you suggested and
> then reloaded that file (which reloaded the whole system), but I still
> get the same vague error message.
You need to tinker with it. C-c C-k in the file buffer should help. If
you insist on using LOAD directly, you need to (load "monad/apply.lsp"),
not just (load "load.lsp") before it reliably picks up changes.
Cheers,
Maciej
In article
<····································@d27g2000prf.googlegroups.com>,
"metaperl.com" <········@gmail.com> wrote:
> Ok, here is the error I got from SBCL 1.0.12:
>
> ===
>
> The value #2A((0 2) (4 6)) is not of type SEQUENCE.
> [Condition of type TYPE-ERROR]
>
> Restarts:
> 0: [ABORT-REQUEST] Abort handling SLIME request.
> 1: [ABORT] Exit debugger, returning to top level.
>
> Backtrace:
> 0: (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
> 1: (DOUBLE #2A((0 2) (4 6)))
> 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (DOUBLE A) #<NULL-LEXENV>)
>
> ===
>
> Now, the very last thing in this trace is
> (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
>
> Unfortunately, the error occurred 7 forms into this function... and I
> had to manually remove and add things until the error form was
> isolated.
>
> I have used many many languages, but never have encountered a language
Language and Implementation are two different things.
> where the error reporting was so vague. I'm assuming some of the
> commercial distros have much nicer error reporting?
LispWorks is quite good. You see the backtrace in the debugger.
If you request to see the source, it highlights the subform (!)
(of the stack frame) in the Lisp source.
You can check it out from www.lispworks.com . They have a 'Personal
Edition' for Windows, Linux, FreeBSD and Mac OS X.
http://www.lispworks.com/downloads/index.html
>
> Per some suggestions on IRC, these vague error messages (they dont say
> the file name, file line, or exact function evaluation which caused
> the error) are occurring even with this in effect:
>
> (declaim (optimize debug))
>
> Just FYI, the full monad-apply function is here -
> http://hg.metaperl.com/redick?f=198e18b64d89;file=lisp/monad/apply.lsp;style=gitweb
--
http://lispm.dyndns.org/
On Dec 13, 7:06 pm, Rainer Joswig <······@lisp.de> wrote:
>
> You can check it out fromwww.lispworks.com. They have a 'Personal
> Edition' for Windows, Linux, FreeBSD and Mac OS X.http://www.lispworks.com/downloads/index.html
If they had a version available for open source developers that would
be nice... 1300 bucks is quite a lot to move from Personal to Pro!
From: Edi Weitz
Subject: Re: quality of error reporting in various lisp distros
Date:
Message-ID: <uhcikkd3b.fsf@agharta.de>
On Fri, 14 Dec 2007 05:23:04 -0800 (PST), "redick.metaperl.com" <·········@gmail.com> wrote:
> If they had a version available for open source developers that
> would be nice... 1300 bucks is quite a lot to move from Personal to
> Pro!
1300 Dollars? Whooo!!! You have to pay 1200 Euros for it in Europe
which is more like 1750 Dollars at the current exchange rate.
And, no, 1300 Dollars or 1200 Euros is /not/ much for a good tool if
you make a living as a programmer.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"metaperl.com" <········@gmail.com> schrieb im Newsbeitrag ·········································@d27g2000prf.googlegroups.com...
> Ok, here is the error I got from SBCL 1.0.12:
>
> ===
>
> The value #2A((0 2) (4 6)) is not of type SEQUENCE.
> [Condition of type TYPE-ERROR]
>
> Restarts:
> 0: [ABORT-REQUEST] Abort handling SLIME request.
> 1: [ABORT] Exit debugger, returning to top level.
>
> Backtrace:
> 0: (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
> 1: (DOUBLE #2A((0 2) (4 6)))
> 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (DOUBLE A) #<NULL-LEXENV>)
>
> ===
>
> Now, the very last thing in this trace is
> (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
>
> Unfortunately, the error occurred 7 forms into this function... and I
> had to manually remove and add things until the error form was
> isolated.
>
> I have used many many languages, but never have encountered a language
> where the error reporting was so vague. I'm assuming some of the
> commercial distros have much nicer error reporting?
>
> Per some suggestions on IRC, these vague error messages (they dont say
> the file name, file line, or exact function evaluation which caused
> the error) are occurring even with this in effect:
>
> (declaim (optimize debug))
>
> Just FYI, the full monad-apply function is here -
> http://hg.metaperl.com/redick?f=198e18b64d89;file=lisp/monad/apply.lsp;style=gitweb
>
So what's the point? Do you want to suggest to use an inferior language because
it offers superior error reporting? Please ...
Andreas
"metaperl.com" <········@gmail.com> writes:
> Now, the very last thing in this trace is
> (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
>
> Unfortunately, the error occurred 7 forms into this function... and I
> had to manually remove and add things until the error form was
> isolated.
Why do you think you have to do that?
--
Juho Snellman
On Dec 13, 7:32 pm, Juho Snellman <······@iki.fi> wrote:
> "metaperl.com" <········@gmail.com> writes:
> > Now, the very last thing in this trace is
> > (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
>
> > Unfortunately, the error occurred 7 forms into this function... and I
> > had to manually remove and add things until the error form was
> > isolated.
>
> Why do you think you have to do that?
the backtrace did not tell me exactly what evaluation led to the
error, so I had to remove each evaluation until the error disappeared.
From: Daniel Weinreb
Subject: Re: quality of error reporting in various lisp distros
Date:
Message-ID: <MY89j.5780$c82.4120@trnddc01>
metaperl.com wrote:
> Ok, here is the error I got from SBCL 1.0.12:
>
> ===
>
> The value #2A((0 2) (4 6)) is not of type SEQUENCE.
> [Condition of type TYPE-ERROR]
>
> Restarts:
> 0: [ABORT-REQUEST] Abort handling SLIME request.
> 1: [ABORT] Exit debugger, returning to top level.
>
> Backtrace:
> 0: (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
> 1: (DOUBLE #2A((0 2) (4 6)))
> 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (DOUBLE A) #<NULL-LEXENV>)
>
> ===
>
> Now, the very last thing in this trace is
> (MONAD-APPLY #<FUNCTION DOUBLE-CORE> #2A((0 2) (4 6)) 0)
>
> Unfortunately, the error occurred 7 forms into this function... and I
> had to manually remove and add things until the error form was
> isolated.
>
> I have used many many languages, but never have encountered a language
> where the error reporting was so vague. I'm assuming some of the
> commercial distros have much nicer error reporting?
>
> Per some suggestions on IRC, these vague error messages (they dont say
> the file name, file line, or exact function evaluation which caused
> the error) are occurring even with this in effect:
>
> (declaim (optimize debug))
>
> Just FYI, the full monad-apply function is here -
> http://hg.metaperl.com/redick?f=198e18b64d89;file=lisp/monad/apply.lsp;style=gitweb
>
>
>
(Comment: "distos" isn't really the right word. Distributions
of Linux are based on the same kernel, whereas implementations
of Common Lisp generally (not always) don't have any code in
common. They're really different at the implementation level.
See my survey paper if you want to know what code is the
same and what is different between the existing implementations.)
The quality of error reporting, and of debugging information
that you'd like to have such as the values of arguments and
locals, varies between Lisp implementations.
In SBCL with the settings that we use for "debug" and "safety"
and so on, I have not been personally thrilled with the
amount of debugging into we get (values of locals and arguments).
It is debated among my co-workers how much better this gets
with different settings, and I admit that I have not tested
this enough.
SBCL also has some inherent difficulties with this kind of
reporting, when it is generating optimized code, because
its compiler is so good, ironically. It sometimes optimizes
out the very need for certain locals. It sometimes generates
tail-calls, which mean that some stack frames that you expect
to see aren't there. Again, this can be controlled with settings,
and I have been remiss in not exploring this well enough.
Our SBCL experts claim that with the right settings, it all
works much better.
In the rumor department, it is said that Clozure Common Lisp
(OpenMCL), LispWorks, and Allegro CL provide very good
debugging information. This is based on the experience of
my co-workers; I have only used CMUCL and SBCL in recent years.
Back in my previous stint of work on Lisp, I used Lisp machines,
which were extremely good in this respect. Like many people,
I really miss Lisp machines, and this is one of the reasons.
Perhaps someday we'll liberate the code and port Open Genera
to the Intel architecture, but there's no prospect of this
in the immediate future, and you'd have to buy in to the whole
Genera environment which would not be suitable for everyone.
From: lin8080
Subject: Re: quality of error reporting in various lisp distros
Date:
Message-ID: <4766E7B6.4A106EC1@freenet.de>
Daniel Weinreb schrieb:
> Perhaps someday we'll liberate the code and port Open Genera
> to the Intel architecture, but there's no prospect of this
> in the immediate future, and you'd have to buy in to the whole
> Genera environment which would not be suitable for everyone.
It is Christmastide. What about a collection to realize that?
New foodnote:
Spend for modern lispmachine (+number)