| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks chriscool and achikin for reporting this bug.
|
| |\
| |
| | |
move enumerate, tangle dependencies to mu.cc
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
More tweaks to the trace after all my debugging.
|
| | |
|
| |
|
|
|
| |
Very cool that these passed without trouble after the previous change.
This is on the right track.
|
| |
|
|
|
|
|
|
| |
The old approach of ad hoc boosts and penalties based on various
features was repeatedly running into exceptions and bugs. New
organization: multiple tiered scores interleaved with tie-breaks. The
moment one tier yields one or more candidates, we stop scanning further
tiers. Just break ties and return.
|
| | |
|
| |
|
|
| |
More tweaking of traces as I debug recipe specialization.
|
| | |
|
| | |
|
| |
|
|
|
| |
Turns out we don't need to threshold non-shape-shifting and
shape-shifting variants at different levels to keep all tests passing.
|
| |
|
|
|
|
|
|
|
|
| |
Thanks Caleb Couch for finding this. These tests were breaking only when
some other code somewhere has already triggered the specialization of
'append' for numbers.
How to test this? Perhaps the right fix is to warn when character
variants are used with literals. Or only when there's also a generic
variant that could conceivably be specialized for numbers.
|
| |
|
|
|
|
| |
Just this conversion isn't in itself a violation of the type system --
as long as there's no way to convert back. Except there is with 'merge'.
Next step is to type-check 'merge'.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Ran into a crash here while loading Caleb's deck-of-war program. Not
bothering debugging it..
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Reorganize further to make edit/008-sandbox-test more self-contained.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you restore 2 sandboxes, the first render was setting
response-starting-row-on-screen on both, without ever rendering a
response. If the lower sandbox contained a print and rendered the screen
instead of the response, the original response-starting-row-on-screen
was never reset. If the process of running the sandboxes caused the
lower sandbox's title bar to move below the now-stale
response-starting-row-on-screen[1], editing the lower sandbox no longer
works.
[1] (Either because the upper sandbox prints to screen as well (causing
the first F4 to move the lower sandbox down by several lines), or
because a fresh sandbox is created with several lines before the first
F4 is hit.)
Current solution: never set response-starting-row-on-screen during
reload (or otherwise when there's no response).
This is hard to test right now because 'restore' is not a tested
interface, and I can't come up with another situation where the
response-starting-row-on-screen goes stale. So I'm now trying to keep
all changes to response-starting-row-on-screen close together. Another
idea is to add a check that the click row lies below the
response-starting row *and* above the start of the next sandbox. (But
what if there's no next sandbox?)
(This bug is really a regression, introduced last Sep in 2163.)
|
| |
|
|
| |
Moving back to wrapped line was overflowing the right margin.
|
| |
|
|
|
| |
My transform pipeline ignores empty recipes, but when I specialized
shape-shifting ones I forgot that check.
|
| |
|
|
|
| |
I was finding it hard to wrap around the directionality of calls with
'lhs' and 'rhs'. Seems to work better with 'to' and 'from'. Let's see.
|
| |
|
|
|
| |
This uncovered a bug where I've been forgetting the directionality of
arguments to types_coercible().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we stash a value, mu does several levels of work for us:
a) First it inserts instructions above the stash to convert the value to
text using to-text-line.
b) to-text-line calls to-text. Both are shape-shifting, so multiple
levels of specialization happen.
To give a good error message, we track the 'stack' of current
specializations at the time of the error, and also check if the
offending instruction at the top-most level looks like it was inserted
while rewriting stash instructions.
Manual example (since booleans can't be stashed at the moment):
x:boolean <- copy 1/true
stash x
|
| |
|
|
| |
Drop yet another source of perturbance in traces.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I spent the longest time trying to understand what bug 2268 fixed. But
it's being tested now.
|
| | |
|
| |
|
|
| |
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?
|
| |
|
|
|
|
|
|
|
|
| |
When I first forked it from the edit/ app, I wasn't sure how to deal
with changing the recipe side when the only way the program accesses it
is with the untestable 'restore' hack. Now we introduce a little hook
into event-loop and pass in any updated recipe side directly.
In the process I've cleaned up several minor stylistic inconsistencies
between edit/ and sandbox/ apps.
|