| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Fix CI; unfortunately it runs C++98.
|
| |
|
|
| |
handle newlines
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been saying for a while[1][2][3] that adding extra abstractions makes
things harder for newcomers, and adding new notations doubly so. And then
I notice this DSL in my own backyard. Makes me feel like a hypocrite.
[1] https://news.ycombinator.com/item?id=13565743#13570092
[2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning
[3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2
The implementation of the DSL was also highly hacky:
a) It was happening in the tangle/ tool, but was utterly unrelated to tangling
layers.
b) There were several persnickety constraints on the different kinds of
lines and the specific order they were expected in. I kept finding bugs
where the translator would silently do the wrong thing. Or the error messages
sucked, and readers may be stuck looking at the generated code to figure
out what happened. Fixing error messages would require a lot more code,
which is one of my arguments against DSLs in the first place: they may
be easy to implement, but they're hard to design to go with the grain of
the underlying platform. They require lots of iteration. Is that effort
worth prioritizing in this project?
On the other hand, the DSL did make at least some readers' life easier,
the ones who weren't immediately put off by having to learn a strange syntax.
There were fewer quotes to parse, fewer backslash escapes.
Anyway, since there are also people who dislike having to put up with strange
syntaxes, we'll call that consideration a wash and tear this DSL out.
---
This commit was sheer drudgery. Hopefully it won't need to be redone with
a new DSL because I grow sick of backslashes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bring back support for incrementally printing the trace to the screen (stderr).
I previously thought I didn't need this as long as I'm always incrementally
saving to the 'last_run' trace file. But I quickly ran into a use for it:
when I want to see a complete trace including switching into the sandbox's
trace and back out again.
So there are now two separate commandline flags:
--trace to save the trace to file
--dump to print the trace to screen
The former won't handle sandbox traces. But the latter will.
I'm deemphasizing --dump in the help message since it should be rarely
used.
One other situation where I've used stderr in the past is for just raw
convenience. But trying to always use the trace was a foolish consistency.
Conclusion:
a) For simple debugging, feel free to just use cout/cerr. Delete them
before committing.
b) If the prints get too complex, switch to the trace and browse_trace
tool.
c) If using nested sandboxes, emit to stderr, redirect to file, and browse_trace.
I've gone back and forth on these questions in the past; now I'm trying
to be a little more rigorous about capturing reasoning.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've extracted it into a separate binary, independent of my Mu prototype.
I also cleaned up my tracing layer to be a little nicer. Major improvements:
- Realized that incremental tracing really ought to be the default.
And to minimize printing traces to screen.
- Finally figured out how to combine layers and call stack frames in a
single dimension of depth. The answer: optimize for the experience of
`browse_trace`. Instructions occupy a range of depths based on their call
stack frame, and minor details of an instruction lie one level deeper
in each case.
Other than that, I spent some time adjusting levels everywhere to make
`browse_trace` useful.
|
| |
|
|
|
|
| |
Clean up the debugging flow, and go over help messages for inconsistencies.
They predate the new Readme, which takes some time to describe the x86
instruction set.
|
| | |
|
| |
|
|
|
| |
New '--dump' commandline arg to incrementally print trace lines to stderr
as they're emitted.
|
| | |
|
| |
|
|
|
| |
We want to always print numbers in hex. This should make that a little
more comprehensive.
|
| |
|
|
|
| |
Side effect: better error messages when the tangler does something
unexpected.
|
| |
|
|
|
| |
It would be confusing to use negative numbers in raw hex. But we'll rely
on programmer taste there.
|
| | |
|
| |
|
|
|
|
| |
The current approach to warnings is workable. We'll just never print
warnings to the screen in tests. In tests you can do whatever you want.
This is simpler than messing with levels of warnings.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Draft attempt at cleaning up warnings, but this isn't quite right.
We still emit warnings for every level-1 scenario, and hiding for each
of them seems painful.
Even if we do that, level-2 scenarios would want to hide level-3 and
over warnings, but *not* level-1 warnings. So we need a cardinal number
rather than booleans.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This ports commit 4421 to the subx/ program.
|
| |
|
|
|
| |
Never mind, let's drop unused/vestigial altogether. Use absence of names
to signal unused arguments.
|
| |
|
|
| |
Port commit 4235 to subx.
|
| |
|
|
| |
Fix CI.
|
| | |
|
| | |
|
| |
|