73 lines
3.4 KiB
Plaintext
73 lines
3.4 KiB
Plaintext
%p
|
||
It really is like
|
||
%a{:href => "http://worrydream.com/#!/InventingOnPrinciple"} Bret Victor
|
||
says in his video:
|
||
good programmers are the ones who play computer in their head well.
|
||
%p Why? Because you have to, to program. And off course that’s what i’m doing.
|
||
%p
|
||
But when it got to debugging, it got a bit much. Using gdb for non C code, i mean it’s bad enough
|
||
for c code.
|
||
%h2#the-debugger The debugger
|
||
%p
|
||
The process of getting my “hello world” to work was quite hairy, what with debugging with gdb
|
||
and checking registers and stuff. Brr.
|
||
%p
|
||
The idea for a “solution”, my own debugger, possibly graphical, came quite quickly. But the effort seemed a
|
||
little big. It took a little, but then i started.
|
||
%p
|
||
I fiddled a little with fancy 2 or even 3d representations but couldn’t get things to work.
|
||
Also getting used to running ruby in the browser, with opal, took a while.
|
||
%p
|
||
But now there is a
|
||
%a{:href => "https://github.com/ruby-x/salama-debugger"} basic frame
|
||
up,
|
||
and i can see registers swishing around and ideas of what needs
|
||
to be visualized and partly even how, are gushing. Off course it’s happening in html,
|
||
but that ok for now.
|
||
%p
|
||
And the best thing: I found my first serious
|
||
%strong bug
|
||
visually. Very satisfying.
|
||
%p
|
||
I do so hope someone will pick this up and run with it. I’ll put it on the site as soon as the first
|
||
program runs through.
|
||
%h2#interpreter Interpreter
|
||
%p
|
||
Off course to have a debugger i needed to start on an interpreter.
|
||
Now it wasn’t just the technical challenge, but some resistance against interpreting, since the whole
|
||
idea of salama was to compile. But in the end it is a very different level that the interpreter
|
||
works at. I chose to put it at the register level (not the arm), so it would be useful for future
|
||
cpu’s, and because the register to arm mapping is mainly about naming, not functionality. Ie it is
|
||
pretty much one to one.
|
||
%p
|
||
But off course (he says after the fact), the interpreter solves a large part of the testing
|
||
issue. Because i wasn’t really happy with tests, and that was because i didn’t have a good
|
||
idea how to test. Sure unit tests, fine. But to write all the little unit tests and hope the
|
||
total will result in what you want never struck me as a good plan.
|
||
%p
|
||
Instead i tend to write system tests, and drop down to unit tests to find the bugs in system tests.
|
||
But i had no good system tests, other than running the executable. But
|
||
= succeed "." do
|
||
%strong now i do
|
||
%p
|
||
So two flies with one (oh i don’t know how this goes, i’m not english), better test, and visual
|
||
feedback, both driving the process at double speed.
|
||
%p
|
||
Now i “just” need a good way to visualize a static and running program. (implement breakpoints,
|
||
build a class and object inpector, recompile on edit . . .)
|
||
%h2#debugger-rewritten-thrice Debugger rewritten, thrice
|
||
%p
|
||
Update: after trying around with a
|
||
%a{:href => "https://github.com/orbitalimpact/opal-pixi"} 2d graphics
|
||
implementation i have rewritten the ui in
|
||
%a{:href => "https://github.com/catprintlabs/react.rb"} react
|
||
,
|
||
%a{:href => "https://github.com/voltrb/volt"} Volt
|
||
and
|
||
= succeed "." do
|
||
%a{:href => "https://github.com/opal/opal-browser"} OpalBrowser
|
||
%p
|
||
The last is what got the easiest to understand code. Also has the least dependencies, namely
|
||
only opal and opal-browser. Opal-browser is a small opal wrapper around the browsers
|
||
javascript functionality.
|