| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the one major refinement on the C programming model I'm planning
to introduce in mu. Instead of Rust's menagerie of pointer types and
static checking, I want to introduce just one new type, and use it to
perform ref-counting at runtime.
So far all we're doing is updating new's interface. The actual
ref-counting implementation is next.
One implication: I might sometimes need duplicate implementations for a
recipe with allocated vs vanilla addresses of the same type. So far it
seems I can get away with just always passing in allocated addresses;
the situations when you want to pass an unallocated address to a recipe
should be few and far between.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- notes
bug in edit/ triggers in immutable but not master branch
bug triggered by changes to layer 059: we're finding an unspecialized call to 'length' in 'append_6'
hard to debug because trace isn't complete
just bring out the big hammer: use a new log file
length_2 from recipes.mu is not being deleted (bug #1)
so reload doesn't switch length to length_2 when variant_already_exists (bug #2)
so we end up saving in Recipe for a primitive ordinal
so no valid specialization is found for 'length' (bug #3)
why doesn't it trigger in a non-interactive scenario?
argh, wasn't checking for an empty line at end. ok, confidence restored.
|
| |
|
|
|
|
|
| |
A long-standing question resolved: why specializations sometimes skipped
some names. Turns out cleanup is incomplete if Recipe_ordinal and Recipe
aren't exactly lined up with each other, and the early exit in
new_variant was breaking that constraint.
|
| |
|
|
|
|
|
|
| |
Not entirely happy with this. Maybe we'll find a better name. But at
least it's an improvement.
One part I *am* happy with is renaming string-replace to replace,
string-append to append, etc. Overdue, now that we have static dispatch.
|
| |
|
|
|
| |
Requires carefully deleting specializations so that they can be
reintroduced each time.
|
| |
|
|
|
|
|
|
|
| |
This is happening because of our recent generic changes, which trigger
some post-processing transforms on all recipes even if we processed them
before. We could clear 'interactive' inside 'reload' to avoid this, but
random 'run' blocks in scenarios can still pick up errors from sandboxes
earlier in a scenario. The right place to clear the 'interactive' recipe
is right after we use it, in run_code_end().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And it caught a bug: I mean to always update type names and types in
sync.
The last month or so I've been getting reluctantly but inexorably
converted to the need and value of a type system. First I thought I just
need a minimal but rigorous type system to avoid memory corruption and
security issues. Now I think I also want it to be expressive enough to
be able to express what data different phases in a compiler read and
write, and to be able to designate specific fields as 'fully computed'
so that we can statically check that phases wait until their data is
available.
The phase-ordering problem in a compiler is perhaps the canary in the
coal-mine for a more general problem: even small changes can
dramatically explode the state space if they violate assumptions
previously held about the domain. My understanding of when type pointers
are null and not null is immeasurably more nuanced today than it was a
week ago, but I didn't need the nuance until I introduced generic
functions. That initial draft of a hundred lines bumped me up to a much
larger state space. How to make it more obvious when something happens
that is akin to discovering a new continent, or finding oneself
teleported to Jupiter?
Assumptions can be implicit or explicit. Perhaps a delete of an
assertion should be estimated at 1000 LoC of complexity?
|
| | |
|
| | |
|
| |
|
|
| |
Now we can collect all traces, just modulating the depth.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|