| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Bugfix in top-level prototype: commandline args were broken since commit
4266 last June.
We still don't have automated tests for commandline args, but we'll add
an example program that'll increase the odds of detecting issues there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Never mind, let's drop unused/vestigial altogether. Use absence of names
to signal unused arguments.
|
| |
|
|
|
|
|
|
|
| |
We're going to lean back into the experiment of commit 4179 back in Jan.
If we delete memory it's up to us to ensure no pointers into it survive.
Since deep-copy depends on our refcounting infrastructure, it's gone as
well. So we're going to have to start watching out for pointers shared
over channels.
|
| |
|
|
|
|
|
| |
The trouble with rewriting 'unused' to '__attribute__(unused)' is that
if we happen to deliberately introduce '__attribute__(unused)' somehow,
say in the standard headers, then it gets expanded twice to '__attribute__(__attribute__(unused))'.
So we switch to a synonym.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have a plan for a way to avoid use-after-free errors without all the
overheads of maintaining refcounts. Has the nice side-effect of
requiring manual memory management. The Mu way is to leak memory by
default and build tools to help decide when and where to expend effort
plugging memory leaks. Arguably programs should be distributed with
summaries of their resource use characteristics.
Eliminating refcount maintenance reduces time to run tests by 30% for
`mu edit`:
this commit parent
mu test: 3.9s 4.5s
mu test edit: 2:38 3:48
Open questions:
- making reclamation easier; some sort of support for destructors
- reclaiming local scopes (which are allocated on the heap)
- should we support automatically reclaiming allocations inside them?
|
| |
|
|
|
| |
Stop hardcoding Max_depth everywhere; we had a default value for a
reason but then we forgot all about it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generalize commit 4089 to arbitrary closures, and not just the current
'space' or call frame. Now we should be treating spaces just like any
other data structure, and reclaiming all addresses inside them when we
need to.
The cost: all spaces must now specify what recipe generated them (so
they know how to interpret the array of locations) using the /names
property.
We can probably make this ergonomic with a little 'type inference'. But
at least things are safe now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fully isolate routines from their arguments.
I still need exceptions for containers that are *designed* to be
shared between routines. The primary such case is channels; we need some
way to share them between routines, and if we deep-copy them that
defeats their entire purpose.
A milder case is the use of fake file-systems in tests, though that's a
hint that there'll be more of these as the OS gets more fleshed out. The
pattern seems to be that we need to not deep-copy containers that
contain lock fields, and so their operations internally do their own
locking.
We may have to stop hard-coding the list of exceptions and allow people
to define new ones. Perhaps don't deep-copy any container with metadata
of 'shared', and then ensure that get-location is only ever called on
shared containers.
This still isn't absolutely ironclad. People can now store something
into a channel and then pass it into a routine to share arbitrary data.
But perhaps the goal isn't to be ironclad, just to avoid easy mistakes.
I'd still want an automated check for this, though. Some way to
highlight it as an unsafe pattern.
This completes step 1 in the plan of commit 3992 for making
continuations safe.
|
| | |
|
|
|
Plan:
1. Fix a hole where addresses are shared between routines when passed in
as arguments to `start-running`.
2. Switch to a new approach to refcount management: instead of updating
refcounts when writing products of instructions by default, increment
refcounts inside instructions by default and decrement refcounts in
caller. More details in future when I actually implement this.
3. Now we shouldn't need a distinction between `new-default-space` and
`local-scope`, and all functions can simply decrement refcounts of
their default-space, consistently handling any refcounts in the space.
At this point if all goes well, continuations should be safe!
This commit is just preparation for step 1.
|