On Thu, 09 Mar 2017 20:53:48 +0100, Evan Donahue <emdon...@gmail.com>
wrote:
I actually have a whole class of bugs and elements of a very Pharo-y
solution.
I do a lot of work in a logic programming framework. Being a logic
programming framework, it does not execute the code you write in a
start-to-finish manner, but executes a few lines here, then jumps around
and
executes a few lines there. As a result, if you are trying to trace the
evolution of a particular branch in the search tree, you can only follow
one
or two operations at a time in the debugger, then that branch gets put in
the queue and you may have to step through tens or hundreds of other
searches before you get back to it (if you can even recognize which
branch
you were following when it comes around again). This makes debugging
basically impossible in every other language this framework has been
ported
to, and the standard strategy is just to stare at the code. Pharo's
debugger
was already a step up, but it still wasn't nearly up to the task.
did you think about adapting the debugger to your execution semantics?
... I read that you did it
Excellent!
I had been trying to get a particularly complex program to work for
several
days with no success, at which point I decided to investigate the
moldable
debugger framework. It took me several more days of going through the
debugger code in different versions and emailing with its developers to
get
something working, which just speaks to the state that framework and
documentation happened to be in at the time, but when I did get it
working I
found the bug in a few minutes. I essentially set up a visual depiction
of
the search tree where I could click on a branch and have the framework
run until that branch came up again to the front of the queue. This
meant I
could trace execution linearly by giving myself a way to get a handle on
the control flow via a visual interface. I have since changed my
framework
and broken the debugger code, but I definitely intend to try to get that
rigged up again when the logic system is in a more polished form.
Admittedly, many programs probably do not have the problem that their
control flow is so complex that a normal linear debugger is too
difficult to
understand, but on some level the ability to specify a debugging control
flow outside the execution of the program itself seems like a pretty
powerful idea, and something Pharo should be very well suited for with
its
interactivity/reflectivity. Maybe there would be more complex,
logic-based
programs if they weren't so hard to write!
Evan
--
View this message in context:
http://forum.world.st/What-is-the-craziest-bug-you-ever-face-tp4937984p4938039.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
--
Using Opera's mail client: http://www.opera.com/mail/
