| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Show more thorough information about instructions in the trace, but keep
the original form in error messages.
|
| |
|
|
|
|
|
|
|
| |
Several times now I've wasted time tracking down a failing test only to
eventually remember that order of definition matters in tests even
though it doesn't elsewhere -- I've been having tests implicitly start
running the first function defined in them. Now I stop doing that if a
test defines a function called 'main', and just start the test at main
instead.
|
| |
|
|
|
|
|
|
| |
As outlined at the end of 2797. This worked out surprisingly well. Now
the snapshotting code touches fewer layers, and it's much better
behaved, with less need for special-case logic, particularly inside
run_interactive(). 30% slower, but should hopefully not cause any more
bugs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I started to make channels generic in 2784, I introduced an
infinite loop when running until just layer 72. This happens because
transform_all() can create new recipes while specializing, and these
were getting added to Recently_added_recipes and then deleted. I didn't
notice until now because layer 91 was clearing Recently_added_recipes
soon after.
Solution: make calls to transform_all after calls to load_permanently
also clear Recently_added_recipes like load_permanently does.
No transforms yet create new types. If they do we'll need to start
handling the other Recently_added_* variables as well.
I should rethink this whole approach of tracking changes to global state
while running tests, and undoing such changes. Ideally I wouldn't need
to manually track changes for each global. I should just encapsulate all
global state in an object, copy it for each test and delete the copy
when I'm done.
|
| | |
|
| |
|
|
| |
This should eradicate the issue of 2771.
|
| | |
|
| |
|
|
|
| |
Get rid of a local variable that was only serving to render unreadable
the code for reclaiming allocated memory.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'm dropping all mention of 'recipe' terminology from the Readme. That
way I hope to avoid further bike-shedding discussions while I very
slowly decide on the right terminology with my students.
I could be smarter in my error messages and use 'recipe' when code uses
it and 'function' otherwise. But what about other words like ingredient?
It would all add complexity that I'm not yet sure is worthwhile. But I
do want separate experiences for veteran programmers reading about Mu on
github and for people learning programming using Mu.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is the easy one. The remaining ones are like phantoms popping up
and dying at random. One thing I know is that they all have to do with
tangling. Always implicated is the line in the tangle layer where
instructions are loaded and inserted into After_fragments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stack of plans for cleaning up replace_type_ingredients() and a couple
of other things, from main problem to subproblems:
include type names in the type_tree rather than in the separate properties vector
make type_tree and string_tree real cons cells, with separate leaf nodes
redo the vocabulary for dumping various objects:
do we really need to_string and debug_string?
can we have a version with *all* information?
can we have to_string not call debug_string?
This commit nibbles at the edges of the final task, switching from
member method syntax to global function like almost everything else. I'm
mostly using methods just for STL in this project.
|
| | |
|
| |
|
|
| |
More tweaks to the trace after all my debugging.
|
| |
|
|
| |
Somehow this never transferred over from the Arc version until now.
|
| |
|
|
|
|
|
|
| |
I'd feared that the refcount errors in the previous commit meant there
was a bug in my ref-counting, so I temporarily used new variables rather
than reusing existing ones. But it turns out the one remaining place
memory corruption can happen is when recipes don't use default-scope and
so end up sharing memory. Don't I have a warning for this?
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also start auto-abandoning addresses when their refcount returns to 0.
I'm mixing this auto-abandon support with my earlier/hackier support for
automatically abandoning default-space created by 'local-scope'. We need
to flesh out the story for automatically reclaiming memory using
C++-style destructors.
But that's a value-add. Memory corruption is far more important to avoid
than memory *leaks*.
|
| |
|
|
| |
Separate core mu tests from those loaded from the commandline.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
One new issue: the traces for all tests are perturbed by the .mu files we
choose to load.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Still some spurious warnings.
This was an insane experience building out generics. Time to reflect.
Where did I go wrong? How did I end up writing no tests? Let's take some
time and go over the last 50 commits with a fine-tooth comb.
Generics seems to be the feature that has moved mu from a VM project to
a compiler project.
|
| |
|
|
| |
Ooh, I think I see a solution.
|
| |
|
|
|
|
|
|
| |
Now we're back to trying to rerunning idempotent transforms on
specialized recipes. Still doesn't work, but at least we don't see
different results depending on whether the trace is enabled inside the
test or right at the start. That got fixed by the more disciplined
insertion into maps, looks like.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm still seeing all sorts of failures in turning on layer 11 of edit/,
so I'm backing away and nailing down every culprit I run into. First up:
stop accidentally inserting empty objects into maps during lookups.
Commands run:
$ sed -i 's/\(Recipe_ordinal\|Recipe\|Type_ordinal\|Type\|Memory\)\[\([^]]*\)\] = \(.*\);/put(\1, \2, \3);/' 0[1-9]*
$ vi 075scenario_console.cc # manually fix up Memory[Memory[CONSOLE]]
$ sed -i 's/\(Memory\)\[\([^]]*\)\]/get_or_insert(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe_ordinal\|Type_ordinal\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe\|Type\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
Now mu dies pretty quickly because of all the places I try to lookup a
missing value.
|
| |
|
|
|
| |
Deduce operation id from name during transform rather than load, so that
earlier transforms have a chance to modify the name.
|
| | |
|
| |
|
|
|
|
|
|
| |
I checked these commands:
$ mu x.mu
$ grep "===" .traces/interactive
$ grep "===\|---" .traces/interactive
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I've been growing lax on white-box testing when it's one of the three
big thrusts of this whole effort. Perhaps it was because I got too
obsessed with keeping traces stable and didn't notice that stable
doesn't mean "not changing". Or perhaps it's because I still don't have
a zoomable trace browser that can parse traces from disk. Or perhaps
$trace-browser is too clunky and discourages me from using it.
Regardless, I need to make the trace useable again before I work much
more on the next few rewriting transforms.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were several places where we push a call on to a routine without
incrementing call-stack depth, which was used to compute the depth at
which to trace an instruction. So sometimes you ended up one depth lower
than you started a call with. Do this enough times and instructions that
should be traced at level 100 end up at level 0 and pop up as errors.
Solution: since call-stack depth is only used for tracing, include it in
the trace stream and make sure we reset it along with the trace stream.
Then catch all places where we forget to increment call-stack depth and
make sure we catch such places in the future.
When I first ran into this with Caleb I thought there must be some way
that we're writing some output into the warnings result. I didn't
recognize that the spurious output as part of the trace, just at the
wrong level.
|
| |
|
|
|
|
|
| |
At the lowest level I'm reluctantly starting to see the need for errors
that stop the program in its tracks. Only way to avoid memory corruption
and security issues. But beyond that core I still want to be as lenient
as possible at higher levels of abstraction.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Always show recipe name where error occurred. But don't show internal
'interactive' name for sandboxes, that's just confusing.
What started out as warnings are now ossifying into errors that halt all
execution. Is this how things went with C and Unix as well?
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Front-loads it a bit more than I'd like, but the payoff is that other
recipes will now be able to describe the type checks right next to their
operation.
I'm also introducing a new use of /raw with literals to indicate unsafe
typecasts.
|
| | |
|
| |
|
|
|
| |
That way we only have to check each static instruction once, rather than
every time it runs.
|