On Wed, 2007-04-04 at 11:34 +0400, Artem Gr wrote:
> > Well two points: I personally do not use debuggers, stack traces,
> > or any other debugging aids .. I use print statements.
>
> Stack trace is just an improved print statements: print statements which
> gets into the log on demand. In the functional languages, due to heavy
> optimizations, instead of a "stack" trace there might be just a
> "function call trace", providing it omits simple loops. Or it might be a
> "print" trace! Say, we have a size-limited queue (for every thread?),
> that's get the print statements pushed to it (preferably with file and
> line number attached!), then, if a error occurs, we jump to the catch
> block and log the queue contents for examination. No error - no crap in
> the logs. Error - and we have the history of what happened. Given that
> some errors occur once in a while (say, some months of work) that's a
> very important difference from simple print statements.
Yep, it's roughly
proc 2> bugs; tail bugs
.. :)
There are some 'pro' debugging libraries around which presumably
can handle this sort of thing, including annotating messages
with time, thread-id, and location information. Actually one is made
by a guy up the road from me .. though I have no idea how good it is.
> > Still other people like that stuff. Felix is in a better position
> > than many other systems, in that we can instrument the generated
> > code .. for example, to record function entry/exit.
>
> That's great!
> BTW, tail recursion should not be a problem with some support from the
> language: tail-recursive call is a goto to the same function and
> shouldn't be treated as a function entry/exit by the stack tracing
> machinery...
I can probably generate code that does:
blah X::apply(argt arg) {
ENTER("X","102",'fred.flx',repr(arg))
..
LEAVE("X","102",'fred.flx', repr(ret))
return ret;
}
and then use
#define ENTER(a,b,c,d)
#define LEAVE(a,b,c,d)
in the standard header. That way if your felix says
requires header "debug.hpp"
the macros get expanded to an arbitrary user defined value,
without compromising the portability of the code, but at
the same time the default runs at full speed. The macros
might print their args to stderr, or they might call
a logging function which makes a record and puts in a
circular buffer. This is a C++ level solution, similar Felix
level solutions are also possible.
You might also write the information to a socket,
and have a GUI program displaying the Felix code
with the cursor sitting on the currently executing line
number, in real time, in slowed down time, or step-wise.
The problem with debugging is getting the information
you want, and removing the rest .. and it's hard to know
what that is not only because it is application dependent,
but because the bug is unknown (otherwise you wouldn't
need a D-bugga ..)
Note that Felix DOES currently report both C++ and Felix
locations when an exception terminates the program
(provided it is a Felix exception such as an assertion
failure or a match failure).
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
