Each one should provide a message that will show up within LÖVE. Stop
relying on nearby prints to the terminal.
I also found some unnecessary ones.
There is some potential here for performance regressions: the format()
calls will trigger whether or not the assertion fails, and cause
allocations. So far Lua's GC seems good enough to manage the load even
with Moby Dick, even in some situations that caused issues in the past
like undo.
In the process, I'm getting rid of the search/ directory that cached
results and that I never ever used. This might pose an additional
migration issue: someone might need to `rm -rf` the `search/`
subdirectory in their notes.
Before:
- notes directory is saveDir/data by default
where saveDir = love.filesystem.getSaveDirectory()
- providing a commandline arg of x makes the notes directory saveDir/data.x
Now:
- there is no default directory; you get an error message instead
telling you what to do.
- the commandline arg is the (preferably absolute) path of the notes
directory you want to load
Unchanged: once you set the notes directory it gets remembered for
future runs.
Now the Readme is a lot simpler.
I tried to make migrating simpler, but this is complicated enough (see
Manual_tests.md)
Broken since 2022-09 X-(
Scenario:
* switch to source editor
* draw a line
* wait 3 seconds
Before this commit the app would crash and then fail to restart until
you deleted the created .lua file from save dir.
This is not the first time I've confused Lua's files and LÖVE's
droppedFile objects. Just never rely on multiple args in file:write().
scenario: add note to a note in a column by itself
Before this commit, the new note would seem to be added fine, but the
old note's link would never be persisted.
It isn't enough just to fix run.lua, I also need to make add_note and
populate_unroll_column behave more composably. Which increases the risk
that this bugfix is going to introduce cascading bugs. (There must have
been some reason I was erroring out when trying to unroll a note with no
next link? And yet the check only occurs for the very first node in the
chain?) But hopefully we're going in the right direction and any
follow-on bugs will eventually damp down to 0. This seems worth doing
even if it introduces bugs.
The previous commit was super useful. The links are not actually being
lost when I exit pensieve. Instead, they're somehow not being set in
some code path that I haven't tracked down yet.
The important thing is, I've been missing things because I wasn't
running it from a terminal. prints (that the links are empty) were
disappearing that would have helped diagnose it. Lesson learned: always
send error prints to the log as well. At least there we have a hope of
spotting them.
Once we start emitting prints to the log, also include the function
name. On errors so far we've not bothered because the default LOVE error
handler shows the stack trace. However the logs don't record the stack,
and we might go looking at them long after the app crashes. The print
doesn't need function names, but the log does so we'll just
lowest-common-denominator both.
I'm disabling the logs for the bug of 3a9f1ed91e, losing the cursor.
Now focusing on the bug of losing links between notes sometimes. I
suspect it happens because I quit soon after creating a link. We'll see.
I don't recally any other bugs bothering me recently.
file.lua:283: bad argument #1 to 'pairs' (table expected, got nil)
Traceback
[love "callbacks.lua"]:228: in function 'handler'
[C]: in function 'pairs'
file.lua:283: in function 'empty'
file.lua:157: in function 'save_links'
run.lua:1358: in function 'fn'
commands.lua:1486: in function 'process_all_links'
run.lua:1357: in function 'stop_editing'
commands.lua:1112: in function 'link'
commands.lua:477: in function 'run_command'
commands.lua:557: in function 'run_command_with_args'
commands.lua:226: in function 'keychord_press_on_command_palette'
run.lua:775: in function 'keychord_press'
main.lua:207: in function 'keychord_press'
keychord.lua:11: in function <keychord.lua:5>
app.lua:31: in function <app.lua:22>
[C]: in function 'xpcall'
I'm not able to reproduce it. How can decoding the json metadata ever
yield nil?
file:write can write multiple args one after another; no need to
concatenate them first.
I'm starting to pay attention to memory usage after the experience of
turning off the JIT.
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.
Kartik K. Agaram