| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Thanks Peter van Hardenberg for causing me to run into this crash (the
first time I tried to demo sandboxes in a long time).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Fix CI after commit 4987. And track stack depths more correctly inside
sandboxes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 rat's nest that all my trace management globals had
gradually turned into.
a) Get rid of 'Start_tracing'. Horryibly named, I don't know how I
missed that until now.
b) Never use START_TRACING_UNTIL_END_OF_SCOPE in main(). It's
confusing to combine it with atexit(delete Trace_stream), because the
atexit() never has to run. Instead we'll just manually initialize
Trace_stream and let atexit() clean up.
c) If we run tests we only want a trace for the test run itself. So
delete the Trace_stream that was initialized at the top of main --
once it's clear we had no load-time errors.
d) Clean up horribly "Load Recipes" waypoints, combine them with the better
name, "Mu Prelude".
Putting these together, we have the following manual tests:
- CFLAGS=-g mu x.mu
Should not create last_run.
- CFLAGS=-g mu --trace x.mu
Should create last_run.
Should write it out exactly once.
- CFLAGS=-g mu --trace x.mu # when x.mu has an error
Should create last_run.
Should write it out exactly once.
- CFLAGS=-g mu --trace test copy_literal # C test
Should create last_run.
Should write it out exactly once.
- CFLAGS=-g mu --trace test recipe_with_header # Mu test
Should create last_run.
Should write it out exactly once.
I don't know how to automate these scenarios yet. We need a way to run
our build toolchain atop our stack.
|
| |
|
|
| |
This has taken me almost 6 weeks :(
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been working on this slowly over several weeks, but it's too hard
to support 0 as the null value for addresses. I constantly have to add
exceptions for scalar value corresponding to an address type (now
occupying 2 locations). The final straw is the test for 'reload':
x:num <- reload text
'reload' returns an address. But there's no way to know that for
arbitrary instructions.
New plan: let's put this off for a bit and first create support for
literals. Then use 'null' instead of '0' for addresses everywhere. Then
it'll be easy to just change what 'null' means.
|
| |
|
|
|
| |
I no longer remember why we were disabling memory reclamation inside
sandboxes. Everything seems to be working. Just take it out.
|
| | |
|
| | |
|
| |
|
|
| |
Time to make my ad hoc commented out code fragments a first-class feature.
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Lakshman Swaminathan for reporting this issue.
|
| | |
|
| |
|
|
|
|
|
| |
Properly support reloading lessons containing scenarios in edit/ and
sandbox/ apps.
I was so sure I tested this for commit 3724, but apparently not.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Support reloading the recipe side of the edit/ app when it includes type
abbreviations.
Thanks Ella Couch for reporting this problem.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Solution to a minor puzzle that came up during today's lesson with Ella:
some sandboxes were showing the address of text results, while others
were showing their contents. It took a while to realize that the
distinction lay in whether the sandbox was saving the results in a text
variable:
new [abc]
=> <some address>
x:text <- new [abc]
=> abc
It took *much* longer to realize why I couldn't make the first case work
like the second. Eventually I realized why: recipes were reclaiming
their results if they weren't 'escaping' -- that is, being saved in a
variable in the caller so they could be used later.
Any solution to this would be a hack, so I'm going to just leave it
alone. Type abbreviations should help minimize the extra typing needed
to get sandboxes to show text contents.
|
| |
|
|
|
|
|
|
|
| |
Deconstruct the tracing layer which had been an exception to our
includes-types-prototypes-globals-functions organization thus far.
To do this we predefine a few primitive globals before the types that
use them, and we pull some method definitions out of struct definitions
at the cost of having to manually write a couple of prototypes.
|
| |
|