| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Still can't print non-integer numbers, so this is a bit hacky.
The big consequence is that you can't print literal characters anymore
because of our rules about how we pick which variant to statically
dispatch to. You have to save to a character variable first.
Maybe I can add an annotation to literals..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
| |
No more bugs; phew.
|
| |
|
|
|
| |
Now I complain before running if a call somewhere doesn't line up with
its ingredients, or if no specialization can be made to match it.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
2473 was the final bugfix holding this back.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
|
|
|
| |
I notice that it isn't working perfectly; after maximize/unmaximize the
editor stops wrapping text, like it still thinks the editor is
maximized.
We don't even use this feature anymore, do we? Just delete it rather
than bother debugging.
|
| |
|
|
| |
Great that it just worked after the previous commit.
|
| |
|
|
|
|
| |
Fix the drawback in the previous commit: if an ingredient is just a
literal 0 we'll skip its type-checking and hope to map type ingredients
elsewhere.
|
| |
|
|
|
|
|
|
|
| |
I was failing to specialize calls containing literals. And then I had to
deal with whether literals should map to numbers or characters. (Answer:
both.)
One of the issues that still remains: shape-shifting recipes can't be
called with literals for addresses, even if it's 0.
|
| | |
|
| |
|
|
| |
Thanks Caleb Couch. This one's been on my list for 2 weeks.
|
| |
|
|
|
|
| |
If a name repeats between ingredients, we raise an error.
If a name repeats across ingredients and products, every call should
share the same name across the corresponding ingredients and products.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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?
|
| |
|
|
|
| |
Fix that stray issue with a better phase ordering.
Another thing I'm not testing.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
One nice consequence of all my deduction of reply ingredients is that I
can insert the same fragment into recipes with different headers, and
everything works as long as reply instructions are implicitly deduced.
One thing I had to fix to make this work was to move reply-deduction out
of rewrite rules and turn it into a first-class transform, so that it
happens after tangling.
I'm glad to see the back of that hack inside <scroll-down>.
|
| | |
|
| |
|
|
|
| |
Still seeing repeated null refinements. Maybe my approach to fixing
those errors is fundamentally broken.
|
| | |
|
| |
|
|
|
| |
Introducing a new 'newlayer' tag like 'todo', to record places where a
nascent new layer might be starting to bud off.
|
| |
|
|
| |
Now we can collect all traces, just modulating the depth.
|
| |
|
|
|
|
|
|
| |
We still can't check ingredient types, and even this is still a run-time
check. We'll need to start tracking recipe signatures at some point.
I've had to introduce a hack called /skiptypecheck. Time to get generics
working.
|
| |
|
|
| |
Already I'm finding type errors in the programming environment.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
How the heck was this working until now?
There must be redundant moves. And was I clobbering test data?
|
| |
|
|
| |
Thanks Jack and Caleb Couch for the idea.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|