Hi,
I am currently program in Scheme and I am considering reengineering
our web applications in Common Lisp (SBCL 1.0.10 on FreeBSD). We have
already started to use SBCL for smaller projects and are very pleased
with it.
The version of Scheme that we are using only supports stack traces if
you compile your program with error trace enabled. When this is done,
the applications performance significantly degrades. The error
traces that are created are very similar to the traces that are
generated by Java or Python.
Although we can use this to debug errors during development, we cannot
enable error traces in production. It has too big an impact on
performance. This makes it very difficult to track down latent bugs
in our production systems. We need to know the module name, line
number and error trace for the error.
Is it possible in Lisp to generate detailed error traces in production
systems that can used to help debug our systems? Is there another
approach to tracking down the location of a latent bug? We are very
open to any suggestions.
Thanks in advance,
Arend van der Veen
On 26 Okt., 23:32, Arend <················@gmail.com> wrote:
> Although we can use this to debug errors during development, we cannot
> enable error traces in production. It has too big an impact on
> performance. This makes it very difficult to track down latent bugs
> in our production systems. We need to know the module name, line
> number and error trace for the error.
During my tests in spring this year, i haven't found any way to get
this working.
Neither with the free lisps, nor with allegro or lisp works. I'm even
more demanding
because i also want to see a dump of the local variables (and member
variables for objects)
in the stacktrace.
Thats the main reason why i didn't move my system to lisp and still
using Eiffel.
In article <·······················@o80g2000hse.googlegroups.com>,
llothar <·······@web.de> wrote:
> On 26 Okt., 23:32, Arend <················@gmail.com> wrote:
>
> > Although we can use this to debug errors during development, we cannot
> > enable error traces in production. It has too big an impact on
> > performance. This makes it very difficult to track down latent bugs
> > in our production systems. We need to know the module name, line
> > number and error trace for the error.
>
> During my tests in spring this year, i haven't found any way to get
> this working.
> Neither with the free lisps, nor with allegro or lisp works. I'm even
> more demanding
> because i also want to see a dump of the local variables (and member
> variables for objects)
> in the stacktrace.
>
> Thats the main reason why i didn't move my system to lisp and still
> using Eiffel.
I use CL-HTTP with a LispWorks application. On warnings
and errors the server sends emails with backtraces.
In LispWorks we are using:
(let ((*print-pretty* t))
(dbg::output-backtrace :bug-form stream))
This runs from a special error handler. We also print the
condition into the mail.
On 27 Okt., 15:11, Rainer Joswig <······@lisp.de> wrote:
>
> I use CL-HTTP with a LispWorks application. On warnings
> and errors the server sends emails with backtraces.
It was not a question about if it is possible but "Is
it possible without paying a huge run time performance penalty."
??>> I use CL-HTTP with a LispWorks application. On warnings
??>> and errors the server sends emails with backtraces.
l> It was not a question about if it is possible but "Is
l> it possible without paying a huge run time performance penalty."
why do you think you need to pay something for making backtrace, have you
done any benchmarks or what?
as i understand, it does almost nothing to have backtrace in runtime -- when
error is triggered, it goes through stack to find out functions, parameters
and variables there.
you can see backtrace retrieved programmatically in SLIME debugger. it's not
detailed as you want, or what?
l> Thats the main reason why i didn't move my system to lisp and still
l> using Eiffel.
hm, shootout.alioth.debian.org says me that SmartEiffel is aprox 2x slower
than SBCL.
something says me that it should be possible to implement totally user-mode
backtraces having that 2x overhead..
l>> Thats the main reason why i didn't move my system to lisp and still
l>> using Eiffel.
AM> hm, shootout.alioth.debian.org says me that SmartEiffel is aprox 2x
AM> slower than SBCL.
ouch, i was wrong -- it's Eiffel 2x faster..
On Sun, 28 Oct 2007 23:50:29 +0200, "Alex Mizrahi"
<········@users.sourceforge.net> wrote:
> ??>> as i understand, it does almost nothing to have backtrace in runtime
> ??>> -- when error is triggered, it goes through stack to find out
> ??>> functions, parameters and variables there.
>
> RJ> As long as the information is there. With certain options
> RJ> a Lisp compiler will provide less debug information,
> RJ> will do more optimizations that make debugging harder,
> RJ> etc.
>
>the point is that _having_ information negligatable runtime performance
>overhead. probably only those who program for embedded systems would really
>worry about that.
Debug info is almost never deployed for small embedded systems (there
are exceptions though), but it is definitely useful for development.
Code for OTS chips is frequently debugged using simulators.
Simulation software (hardware simulators still have control software)
routinely include code browsers that access program debug info on
demand when you break into the code.
>in C++, for example, it's possible to have debugging information (mapping
>addresses to function names etc) in separate files. it's even possible to
>download such files for the Windows operating system, so you'll see all
>internal function names. such information for whole Windows XP is just 1 GB
>unpacked, not that terribly big..
Just about 20 times the size of the actual code 8-)
>another thing is that compiler optimizations obscure data on stack, such as
>tail-call optimization, internal jumps, variable allocation shared,
>variables in registers etc.
>
> RJ> Though generally I think Common Lisp code should run with
> RJ> full safety and enough debug infos by default. Only really
> RJ> (speed) critical sections should be run as optimized code.
> RJ> If you need fully optimized runtimes, then Lisp is possibly
> RJ> not the best tool for that.
>
>yup, probably optimizing everything would only have effect of obscuring
>backtraces..
I've rarely found back traces useful other than to tell me what
function calls led to the problem. I've never seen a back trace that
included enough information to recreate the problem so I can step
through and watch.
George
--
for email reply remove "/" from address
In article <··································@4ax.com>,
George Neuner <·········@/comcast.net> wrote:
> I've rarely found back traces useful other than to tell me what
> function calls led to the problem. I've never seen a back trace that
> included enough information to recreate the problem so I can step
> through and watch.
I don't use stepping much, but I use backtraces all the time.
>
> George
> --
> for email reply remove "/" from address
On Tue, 30 Oct 2007 10:01:37 +0100, Rainer Joswig <······@lisp.de>
wrote:
>In article <··································@4ax.com>,
> George Neuner <·········@/comcast.net> wrote:
>
>> I've rarely found back traces useful other than to tell me what
>> function calls led to the problem. I've never seen a back trace that
>> included enough information to recreate the problem so I can step
>> through and watch.
>
>I don't use stepping much, but I use backtraces all the time.
Like I said, I've found backtraces rarely include enough information
to debug a complicated problem. They end up just pointing me in the
right direction.
I would actually prefer to have some kind of replay debugger like the
(very expensive) systems I used to use for debugging embedded code. I
used two different kinds: a hardware based RT debugger that worked
from a code map and logged every function call and imaged any modified
data periodically as the function executed; and a software based
debugger that used instrumented code to do the same. For long running
programs you could create checkpoint images that could be restarted.
If the code broke, you could bring up the program up in the simulator
and replay the logs to recreate the problem exactly.
I've been missing that facility for many years. Stepping through a
program is boring and largely unproductive unless you do know the
conditions that led to the problem.
George
--
for email reply remove "/" from address
George Neuner <·········@/comcast.net> wrote:
+---------------
| Rainer Joswig <······@lisp.de> wrote:
| > George Neuner <·········@/comcast.net> wrote:
| >
| >> I've rarely found back traces useful other than to tell me what
| >> function calls led to the problem. I've never seen a back trace that
| >> included enough information to recreate the problem so I can step
| >> through and watch.
| >
| >I don't use stepping much, but I use backtraces all the time.
|
| Like I said, I've found backtraces rarely include enough information
| to debug a complicated problem. They end up just pointing me in the
| right direction.
+---------------
To use backtraces most profitably [for more than just a static
announcement that there *is* a problem in some area] you need to
be in your CL's debugger where, armed with the backtrace, you
can move up and down the stack frames, examining local variables,
looking at the corresponding source files, executing little bits
of interactively designed test code, etc.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Tue, Oct 30 2007, George Neuner wrote:
> ...
> I would actually prefer to have some kind of replay debugger like
> the (very expensive) systems I used to use for debugging embedded
> code. I used two different kinds: a hardware based RT debugger that
> worked from a code map and logged every function call and imaged any
> modified data periodically as the function executed; and a software
> based debugger that used instrumented code to do the same. For long
> running programs you could create checkpoint images that could be
> restarted.
>
> If the code broke, you could bring up the program up in the
> simulator and replay the logs to recreate the problem exactly.
While in certain cases in embeded systems that does not keep state
that is not such of a problem, it is impossible in a typical stateful
system.
However, it could be done with a not so typical system - one that
keeps track of the transactions in a log file. I'd love to have it
too.
--
�����
On Wed, 31 Oct 2007 11:40:30 +0200, Kamen TOMOV <·····@cybuild.com>
wrote:
>On Tue, Oct 30 2007, George Neuner wrote:
>
>> ...
>> I would actually prefer to have some kind of replay debugger like
>> the (very expensive) systems I used to use for debugging embedded
>> code. I used two different kinds: a hardware based RT debugger that
>> worked from a code map and logged every function call and imaged any
>> modified data periodically as the function executed; and a software
>> based debugger that used instrumented code to do the same. For long
>> running programs you could create checkpoint images that could be
>> restarted.
>>
>> If the code broke, you could bring up the program up in the
>> simulator and replay the logs to recreate the problem exactly.
>
>While in certain cases in embeded systems that does not keep state
>that is not such of a problem, it is impossible in a typical stateful
>system.
What makes you think embedded programs don't keep state?
"Embedded" doesn't mean "device", nor does it mean small ... it means
the program is designed to operate autonomously with little or no
direct user interaction. All the little daemons and services that
make up the typical OS qualify.
The RT aspect is orthogonal, it just happens to be where my own
experience lies. Much of my work was in industrial production
monitoring and control systems. I've implemented systems that
performed multiple HRT and SRT operations simultaneously, with
hundreds of kilobytes of rapid changing state and sometimes megabytes
of more slowly changing reference state.
>However, it could be done with a not so typical system - one that
>keeps track of the transactions in a log file. I'd love to have it
>too.
It could be, but the logs could be immense - fast computers can do a
lot very quickly 8-) I once had to debug an interrupt problem that
was crashing a multitask SRT system running on dual 68040s ... the
trace for the several minutes of full operation required to catch the
problem was ~50 megabytes. (This was a software trace system that
required compiler code instrumentation.)
The great thing about hardware based debuggers was that they are
outside the software and can record its operation or inspect data
without interfering with it. I've never really been happy with
software debuggers - even those that work rather well such as Lisp's -
because they are too closely coupled to the debuggee. On many
occasions I've had to debug problems that would crash the debugger
(and occasionally the whole computer).
I've often thought that a hardware level VM (like VMWare, etc.) would
make a great platform for a software debugger, being able to catch
illegal instructions and data accesses before they happen, monitor the
suspect program without requiring additional instrumentation code and
monitor it in an approximation of real time.
I've never seen a software debugging environment that uses a hardware
level VM (there may be some, I've just never seen them). Most
debuggers rely on VMM to isolate the debuggee and software breakpoints
to gain control over it.
George
--
for email reply remove "/" from address
On Thu, Nov 01 2007, George Neuner wrote:
> On Wed, 31 Oct 2007 11:40:30 +0200, Kamen TOMOV
> wrote:
>
>>On Tue, Oct 30 2007, George Neuner wrote:
>>
>>> ...
>>> I would actually prefer to have some kind of replay debugger like
>>> the (very expensive) systems I used to use for debugging embedded
>>> code. I used two different kinds: a hardware based RT debugger
>>> that worked from a code map and logged every function call and
>>> imaged any modified data periodically as the function executed;
>>> and a software based debugger that used instrumented code to do
>>> the same. For long running programs you could create checkpoint
>>> images that could be restarted.
>>>
>>> If the code broke, you could bring up the program up in the
>>> simulator and replay the logs to recreate the problem exactly.
>>
>>While in certain cases in embeded systems that does not keep state
>>that is not such of a problem, it is impossible in a typical
>>stateful system.
>
> What makes you think embedded programs don't keep state?
>
> "Embedded" doesn't mean "device", nor does it mean small ... it
> means the program is designed to operate autonomously with little or
> no direct user interaction. All the little daemons and services
> that make up the typical OS qualify.
Wrong. An embedded system is usually a device and it is typically
small. It is not defined in terms of user interaction. I interact with
my car more than you could imagine. It is quite not like daemons or
services that make up the typical OSes. The embedded system is not a
multipurpose computer. An embedded system is a hardware/software set
particularly designed to perform certain function(s).
> The RT aspect is orthogonal, it just happens to be where my own
> experience lies. Much of my work was in industrial production
> monitoring and control systems. I've implemented systems that
> performed multiple HRT and SRT operations simultaneously, with
> hundreds of kilobytes of rapid changing state and sometimes
> megabytes of more slowly changing reference state.
Good for you. By the way do you keep the state and where is the
embedded system? That reminds me I need to ensure I have RAID
installed in my car - I don't want it to leave me in the middle of the
road with "Hard disk failure". Traffic is getting nuts these days.
>>However, it could be done with a not so typical system - one that
>>keeps track of the transactions in a log file. I'd love to have it
>>too.
>
> It could be, but the logs could be immense - fast computers can do a
> lot very quickly 8-) I once had to debug an interrupt problem that
> was crashing a multitask SRT system running on dual 68040s ... the
> trace for the several minutes of full operation required to catch
> the problem was ~50 megabytes. (This was a software trace system
> that required compiler code instrumentation.)
Luckily they don't have to do stateful operations so often. Although
the Formula 1 software would be a challenge. Yeah it sounds like a
typical system you're talking about, while I talked about something
genius like CL.
> The great thing about hardware based debuggers was that they are
> outside the software and can record its operation or inspect data
> without interfering with it. I've never really been happy with
> software debuggers - even those that work rather well such as Lisp's
> - because they are too closely coupled to the debuggee. On many
> occasions I've had to debug problems that would crash the debugger
> (and occasionally the whole computer).
It's no wonder hardware debuggers are the preferred way with embedded
systems. As I said these systems are typically not multipurpose.
Now, could you tell us how Lisp is related with embedded systems? Is
someone out there using it for that purpose? That would be fun.
> I've often thought that a hardware level VM (like VMWare, etc.)
> would make a great platform for a software debugger, being able to
> catch illegal instructions and data accesses before they happen,
> monitor the suspect program without requiring additional
> instrumentation code and monitor it in an approximation of real
> time.
>
> I've never seen a software debugging environment that uses a
> hardware level VM (there may be some, I've just never seen them).
> Most debuggers rely on VMM to isolate the debuggee and software
> breakpoints to gain control over it.
--
�����
On Thu, 01 Nov 2007 12:49:34 +0200, Kamen TOMOV <·····@cybuild.com>
wrote:
>On Thu, Nov 01 2007, George Neuner wrote:
>
>> On Wed, 31 Oct 2007 11:40:30 +0200, Kamen TOMOV
>> wrote:
>>
>>>On Tue, Oct 30 2007, George Neuner wrote:
>>>
>>>> ...
>>>> I would actually prefer to have some kind of replay debugger like
>>>> the (very expensive) systems I used to use for debugging embedded
>>>> code. I used two different kinds: a hardware based RT debugger
>>>> that worked from a code map and logged every function call and
>>>> imaged any modified data periodically as the function executed;
>>>> and a software based debugger that used instrumented code to do
>>>> the same. For long running programs you could create checkpoint
>>>> images that could be restarted.
>>>>
>>>> If the code broke, you could bring up the program up in the
>>>> simulator and replay the logs to recreate the problem exactly.
>>>
>>>While in certain cases in embeded systems that does not keep state
>>>that is not such of a problem, it is impossible in a typical
>>>stateful system.
>>
>> What makes you think embedded programs don't keep state?
>>
>> "Embedded" doesn't mean "device", nor does it mean small ... it
>> means the program is designed to operate autonomously with little or
>> no direct user interaction. All the little daemons and services
>> that make up the typical OS qualify.
>
>Wrong. An embedded system is usually a device and it is typically
>small. It is not defined in terms of user interaction. I interact with
>my car more than you could imagine. It is quite not like daemons or
>services that make up the typical OSes. The embedded system is not a
>multipurpose computer. An embedded system is a hardware/software set
>particularly designed to perform certain function(s).
>
>> The RT aspect is orthogonal, it just happens to be where my own
>> experience lies. Much of my work was in industrial production
>> monitoring and control systems. I've implemented systems that
>> performed multiple HRT and SRT operations simultaneously, with
>> hundreds of kilobytes of rapid changing state and sometimes
>> megabytes of more slowly changing reference state.
>
>Good for you. By the way do you keep the state and where is the
>embedded system? That reminds me I need to ensure I have RAID
>installed in my car - I don't want it to leave me in the middle of the
>road with "Hard disk failure". Traffic is getting nuts these days.
>
>>>However, it could be done with a not so typical system - one that
>>>keeps track of the transactions in a log file. I'd love to have it
>>>too.
>>
>> It could be, but the logs could be immense - fast computers can do a
>> lot very quickly 8-) I once had to debug an interrupt problem that
>> was crashing a multitask SRT system running on dual 68040s ... the
>> trace for the several minutes of full operation required to catch
>> the problem was ~50 megabytes. (This was a software trace system
>> that required compiler code instrumentation.)
>
>Luckily they don't have to do stateful operations so often. Although
>the Formula 1 software would be a challenge. Yeah it sounds like a
>typical system you're talking about, while I talked about something
>genius like CL.
>
>> The great thing about hardware based debuggers was that they are
>> outside the software and can record its operation or inspect data
>> without interfering with it. I've never really been happy with
>> software debuggers - even those that work rather well such as Lisp's
>> - because they are too closely coupled to the debuggee. On many
>> occasions I've had to debug problems that would crash the debugger
>> (and occasionally the whole computer).
>
>It's no wonder hardware debuggers are the preferred way with embedded
>systems. As I said these systems are typically not multipurpose.
>
>Now, could you tell us how Lisp is related with embedded systems? Is
>someone out there using it for that purpose? That would be fun.
>
>> I've often thought that a hardware level VM (like VMWare, etc.)
>> would make a great platform for a software debugger, being able to
>> catch illegal instructions and data accesses before they happen,
>> monitor the suspect program without requiring additional
>> instrumentation code and monitor it in an approximation of real
>> time.
>>
>> I've never seen a software debugging environment that uses a
>> hardware level VM (there may be some, I've just never seen them).
>> Most debuggers rely on VMM to isolate the debuggee and software
>> breakpoints to gain control over it.
I'm not going to bother arguing because you haven't the slightest clue
what the hell you are talking about.
George
--
for email reply remove "/" from address
On Fri, Nov 02 2007, George Neuner wrote:
> On Thu, 01 Nov 2007 12:49:34 +0200, Kamen TOMOV <·····@cybuild.com>
> wrote:
>
>>On Thu, Nov 01 2007, George Neuner wrote:
>>
>>> On Wed, 31 Oct 2007 11:40:30 +0200, Kamen TOMOV
>>> wrote:
>>>
>>>>On Tue, Oct 30 2007, George Neuner wrote:
>>>>
>>>>> ...
>>>>> I would actually prefer to have some kind of replay debugger like
>>>>> the (very expensive) systems I used to use for debugging embedded
>>>>> code. I used two different kinds: a hardware based RT debugger
>>>>> that worked from a code map and logged every function call and
>>>>> imaged any modified data periodically as the function executed;
>>>>> and a software based debugger that used instrumented code to do
>>>>> the same. For long running programs you could create checkpoint
>>>>> images that could be restarted.
>>>>>
>>>>> If the code broke, you could bring up the program up in the
>>>>> simulator and replay the logs to recreate the problem exactly.
>>>>
>>>>While in certain cases in embeded systems that does not keep state
>>>>that is not such of a problem, it is impossible in a typical
>>>>stateful system.
>>>
>>> What makes you think embedded programs don't keep state?
>>>
>>> "Embedded" doesn't mean "device", nor does it mean small ... it
>>> means the program is designed to operate autonomously with little or
>>> no direct user interaction. All the little daemons and services
>>> that make up the typical OS qualify.
>>
>>Wrong. An embedded system is usually a device and it is typically
>>small. It is not defined in terms of user interaction. I interact with
>>my car more than you could imagine. It is quite not like daemons or
>>services that make up the typical OSes. The embedded system is not a
>>multipurpose computer. An embedded system is a hardware/software set
>>particularly designed to perform certain function(s).
>>
>>> The RT aspect is orthogonal, it just happens to be where my own
>>> experience lies. Much of my work was in industrial production
>>> monitoring and control systems. I've implemented systems that
>>> performed multiple HRT and SRT operations simultaneously, with
>>> hundreds of kilobytes of rapid changing state and sometimes
>>> megabytes of more slowly changing reference state.
>>
>>Good for you. By the way do you keep the state and where is the
>>embedded system? That reminds me I need to ensure I have RAID
>>installed in my car - I don't want it to leave me in the middle of the
>>road with "Hard disk failure". Traffic is getting nuts these days.
>>
>>>>However, it could be done with a not so typical system - one that
>>>>keeps track of the transactions in a log file. I'd love to have it
>>>>too.
>>>
>>> It could be, but the logs could be immense - fast computers can do a
>>> lot very quickly 8-) I once had to debug an interrupt problem that
>>> was crashing a multitask SRT system running on dual 68040s ... the
>>> trace for the several minutes of full operation required to catch
>>> the problem was ~50 megabytes. (This was a software trace system
>>> that required compiler code instrumentation.)
>>
>>Luckily they don't have to do stateful operations so often. Although
>>the Formula 1 software would be a challenge. Yeah it sounds like a
>>typical system you're talking about, while I talked about something
>>genius like CL.
>>
>>> The great thing about hardware based debuggers was that they are
>>> outside the software and can record its operation or inspect data
>>> without interfering with it. I've never really been happy with
>>> software debuggers - even those that work rather well such as Lisp's
>>> - because they are too closely coupled to the debuggee. On many
>>> occasions I've had to debug problems that would crash the debugger
>>> (and occasionally the whole computer).
>>
>>It's no wonder hardware debuggers are the preferred way with embedded
>>systems. As I said these systems are typically not multipurpose.
>>
>>Now, could you tell us how Lisp is related with embedded systems? Is
>>someone out there using it for that purpose? That would be fun.
>>
>>> I've often thought that a hardware level VM (like VMWare, etc.)
>>> would make a great platform for a software debugger, being able to
>>> catch illegal instructions and data accesses before they happen,
>>> monitor the suspect program without requiring additional
>>> instrumentation code and monitor it in an approximation of real
>>> time.
>>>
>>> I've never seen a software debugging environment that uses a
>>> hardware level VM (there may be some, I've just never seen them).
>>> Most debuggers rely on VMM to isolate the debuggee and software
>>> breakpoints to gain control over it.
>
> I'm not going to bother arguing because you haven't the slightest clue
> what the hell you are talking about.
Funny, I've had the same impression about you, but decided to bother
to point the crap out.
--
�����
On 30 Okt., 07:22, George Neuner <·········@/comcast.net> wrote:
> I've rarely found back traces useful other than to tell me what
> function calls led to the problem. I've never seen a back trace that
> included enough information to recreate the problem so I can step
> through and watch.
Bad luck for you. With Eiffel 90% of the crashs with backtraces are
extremely helpfull, 80% can fix the problem immediately. This is the
benefit
of DBC and printing out the local variables not only the function
names.
The latter is indeed almost useless.
In article <························@57g2000hsv.googlegroups.com>,
llothar <·······@web.de> wrote:
> On 30 Okt., 07:22, George Neuner <·········@/comcast.net> wrote:
>
> > I've rarely found back traces useful other than to tell me what
> > function calls led to the problem. I've never seen a back trace that
> > included enough information to recreate the problem so I can step
> > through and watch.
>
> Bad luck for you. With Eiffel 90% of the crashs with backtraces are
> extremely helpfull, 80% can fix the problem immediately. This is the
> benefit
> of DBC and printing out the local variables not only the function
> names.
>
> The latter is indeed almost useless.
Hmm, when I get backtraces from LispWorks, it prints
the condition and its slots. The backtrace contains
all kinds of stuff including all objects of the
stack frames. If necessary I can have
special printing routines invoked...
I don't think you need Eiffel to get meaningful
backtraces.
??>> in C++, for example, it's possible to have debugging information
??>> (mapping addresses to function names etc) in separate files. it's even
??>> possible to download such files for the Windows operating system, so
??>> you'll see all internal function names. such information for whole
??>> Windows XP is just 1 GB unpacked, not that terribly big..
GN> Just about 20 times the size of the actual code 8-)
probably same size as the code, if not less. it includes symbols for all
binaries of WINXP -- including IE, Outlook Express, all utils etc.
if source code of just one Firefox is about 200MB, and WINXP includes aprox
same thing -- IE -- as a part, whole sources of WINXP should be much larger,
few gigabytes, probably..
Arend <················@gmail.com> writes:
> Although we can use this to debug errors during development, we cannot
> enable error traces in production. It has too big an impact on
> performance. This makes it very difficult to track down latent bugs
> in our production systems. We need to know the module name, line
> number and error trace for the error.
You can trivially get that information from SBCL with basically no
runtime overhead (you just need to compile your code with (debug 2) to
get exact source location information). Assuming that by module name
you mean the file name, since CL has no concept of modules to report
about.
While the file name, the location inside the file and the local
variables are not included in the default backtrace output of SBCL,
building your own backtrace printer based on e.g. the semi-portable
debugger primitives in swank-backend would probably be 10 lines of
code.
It's probably safe to assume that similar things are possible with any
other serious CL implementation.
--
Juho Snellman
P� Sat, 27 Oct 2007 03:42:32 +0200, skrev Juho Snellman <······@iki.fi>:
> Assuming that by module name
> you mean the file name, since CL has no concept of modules to report
> about.
From the ANSI CL hyperspec on provide..
PROVIDE adds the module-name to the list held by *modules*, if such a name
is not already present.
REQUIRE tests for the presence of the module-name in the list held by
*modules*. If it is present, require immediately returns. Otherwise, an
attempt is made to load an appropriate set of files as follows: The
pathname-list argument, if non-nil, specifies a list of pathnames to be
loaded in order, from left to right. If the pathname-list is nil, an
implementation-dependent mechanism will be invoked in an attempt to load
the module named module-name; if no such module can be loaded, an error of
type error is signaled.
So there s a concept module in Lisp, abeit deprecated.
--
Sendt med Operas revolusjonerende e-postprogram: http://www.opera.com/mail/
"John Thingstad" <·······@online.no> writes:
> P� Sat, 27 Oct 2007 03:42:32 +0200, skrev Juho Snellman <······@iki.fi>:
>
> > Assuming that by module name you mean the file name,
> > since CL has no concept of modules to report about.
>
> From the ANSI CL hyperspec on provide..
>
> PROVIDE adds the module-name [...]
>
> REQUIRE tests for the presence of the module-name [...]
>
> So there s a concept module in Lisp, abeit deprecated.
Executive summary:
I didn't read upthread to be sure, but the modules that CL had were
very lightweight and may or may not be what is being discussed here,
but are generally not the thing most people are saying is missing
when they say CL is missing modules.
Details:
http://groups.google.com/group/comp.lang.lisp/msg/8fface1e0b839ae8
On Oct 29, 11:17 am, Juho Snellman <······@iki.fi> wrote:
> Arend <················@gmail.com> writes:
> > On Oct 26, 9:42 pm, Juho Snellman <······@iki.fi> wrote:
> > > While the file name, the location inside the file and the local
> > > variables are not included in the default backtrace output of SBCL,
> > > building your own backtrace printer based on e.g. the semi-portable
> > > debugger primitives in swank-backend would probably be 10 lines of
> > > code.
>
> > > It's probably safe to assume that similar things are possible with any
> > > other serious CL implementation.
>
> > Hi,
>
> > Since I am new to this, could you point me to a sample of these 10
> > lines of code that would generate my own backtrace?
>
> Sure. To get a backtrace in SBCL you'd normally call
> SB-DEBUG:BACKTRACE in your condition handler. That backtrace is
> intended to be used along with the Lisp debugger. To get trace with
> some of extra information useful for off-line debugging, you could
> call a function like this instead:
>
> (defun backtrace-with-extra-info (&optional (n 20))
> (swank-backend::call-with-debugging-environment
> (lambda ()
> (dotimes (i (length (swank-backend::compute-backtrace 0 n)))
> (destructuring-bind (&key file position &allow-other-keys)
> (apply #'append
> (remove-if-not #'consp
> (swank-backend:frame-source-location-for-emacs i)))
> (format t ···@a: ~s~%~:[~*~;~1:* At ~a:~a~%~] Local variables:~
> ~%~{ ~a = ~s~%~}"
> i (sb-debug::frame-call (swank-backend::nth-frame i))
> file position
> (mapcan (lambda (x) (list (getf x :name) (getf x :value)))
> (swank-backend::frame-locals i)))))))))
>
> This assumes that Swank has been loaded into your Lisp image. Just
> remember to compile your code with (debug 2) or higher. It will have
> minimal effect on performance.
>
> --
> Juho Snellman
Hi,
Thanks! I will give it a try.
Arend