ruby-x.github.io/app/views/posts/_2015-07-25-i-like-not-playing-computer.html.haml

73 lines
3.4 KiB
Plaintext
Raw Normal View History

2018-04-10 18:50:07 +02:00
%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 thats what im doing.
%p
But when it got to debugging, it got a bit much. Using gdb for non C code, i mean its 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 couldnt 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 its 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. Ill 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 wasnt 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
cpus, 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 wasnt really happy with tests, and that was because i didnt 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 dont know how this goes, im 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.