| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Thanks Ella Couch for finding this bug. It's helped me find errors in
mu's code itself.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I might change my mind on this, but it's worth a try after watching Ella
run up against it today. I got her to build the recipe 'odd?', but then
it failed to run because she couldn't convert a numeric remainder to a
number without a conditional (which I haven't taught her yet).
For now I don't change the value in the boolean, so booleans can store
arbitrary bit patterns like in C. We just say that 0 is false and
anything else is true. I *think* that doesn't break the type system..
|
| | |
|
| |
|
|
|
| |
Only Hide_errors when strictly necessary. In other places let test
failures directly show the unexpected error.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I really have only one warning left: when somebody redefines a function.
I think I'm going to just turn that into an error as well and drop the
notion of warnings altogether. Anytime we find something wrong we stop
running the program. This is a place where hygiene is justified.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Very cool that I thought I didn't support type ingredients in arbitrary
positions in container definitions, but I really did. I just didn't have
a test for it, and now I do.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically I need to make these tests work:
- Test 1: specializing while saving shape-shifting recipe literal
recipe f a:address:shared:_elem -> b:address:shared:_elem [
local-scope
load-ingredients
reply a
]
recipe main [
local-scope
{x: (recipe (address shared number) -> (address shared number))} <- copy f
y:address:shared:number <- new number:type
*y <- copy 34
z:address:shared:number <- call x, y
$print *z, 10/newline
]
- Test 2: passing recipe literal to higher-order recipe
recipe g x:address:shared:number, {h: (recipe (address shared number) -> (address shared number))} -> y:address:shared:number [
local-scope
load-ingredients
y <- call f, x
]
recipe main [
local-scope
x:address:shared:number <- new number:type
*x <- copy 34
y:address:shared:number <- g x, f
$print *y, 10/newline
]
|
| | |
|
| |
|
|
|
|
| |
I noticed while teaching Ella that when mu encountered a missing recipe
it failed to find *any* recipes after that point, leading to a lot of
spurious errors. Now fixed.
|
| |
|
|
|
|
|
|
|
|
| |
To find this I spent some time trying to diagnose when it happened but
there was no seeming pattern. I'd ended up with a small single-file .cc
and single-file .mu that reproduced one memory leak. Eventually I tried
deleting all type_tree and string_tree from it, and lo the leaks
vanished. I retried on all of edit (just loading), and the leaks
remained gone. At that point I switched tack and started looking at all
the core methods of these classes.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
That same line that caused me so much grief in 2681!
I just ran edit/ through valgrind for the first time, and found more
memory leaks breeding while I wasn't looking. That's next.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Ok, we don't need that check after all, because the
type_ingredient_names.empty() check earlier in the layer prevents it
from ever triggering.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All my attempts at staging this change failed with this humongous commit
that took all day and involved debugging three monstrous bugs. Two of
the bugs had to do with forgetting to check the type name in the
implementation of shape-shifting recipes. Bug #2 in particular would
cause core tests in layer 59 to fail -- only when I loaded up edit/! It
got me to just hack directly on mu.cc until I figured out the cause
(snapshot saved in mu.cc.modified). The problem turned out to be that I
accidentally saved a type ingredient in the Type table during
specialization. Now I know that that can be very bad.
I've checked the traces for any stray type numbers (rather than names).
I also found what might be a bug from last November (labeled TODO), but
we'll verify after this commit.
|
| |
|
|
| |
Delete all the [] that has crept in since 2377 in November.
|
| | |
|
| |
|
|
|
|
|
| |
Start using type names from the type tree rather than the property tree
in most places. Hopefully the only occurrences of
'properties.at(0).second' left are ones where we're managing it. Next we
can stop writing to it.
|
| |
|
|
| |
Include type names in the type tree. Though we aren't using them yet.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
But I realize that this won't actually streamline
replace_type_ingredients(), which needs that 'if (curr->left)
curr = curr->left' dance for an unrelated reason. So there's no
justification for entering into this big refactoring.
|
| | |
|
| | |
|
| |
|
|
| |
It's only for transient debugging.
|
| |
|
|
|
|
| |
to_string(): relatively stable fields only; for trace()
debug_string(): all fields; for debugging
inspect(): for a form that can be parsed back later
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Move code around to put all string-conversion functions in a single
section with a reasonable order, from recipe to instruction to reagent
to reagent members.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Cleanup.
|