| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
It's still a bit simple-minded. Most software will keep the first bound
fixed and move the second. Lines currently has the bounds in a queue of
sorts. But I have a test to indicate the behavior that is definitely
desired. We'll see if we need it to get more complex.
|
|
|
|
| |
Doesn't yet highlight while dragging.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Along with the App helpers needed for them.
|
|
|
|
| |
https://www.hogbaysoftware.com/posts/moby-dick-workout
|
| |
|
|
|
|
| |
Why the fuck is this so fucking hard?
|
|
|
|
|
| |
Setting up the test just right to test the thing I want to test was a
rube goldberg machine of constants.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I also really need to rethink how people debug my programs. My approach
of inserting and deleting print() takes a lot of commitment. I need my
old trace-based whitebox testing idea. However, in my past projects I
never did figure out a good framework for tweaking how verbose a trace
to emit.
Perhaps that's too many knobs. Perhaps we just need a way to run a
single test with the most verbose trace possible. Then it's just a
matter of having the trace tell a coherent story? But even if the trace
stays out of program output in that situation, it's still in the
programmer's face in the _code_. Ugh.
Current plan: ship program with maximum tests and zero commented-out
prints. If you want to debug, insert prints. This is better than
previous, text-mode, projects just by virtue of the stdout channel being
dedicated to debug stuff.
|
| |
|
|
|
|
|
| |
Tests still have a lot of side-effects on the real screen. We'll
gradually clean those up.
|
|
|