| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Bugfix for the "remaining bug" mentioned in commit 3391.
|
| |
|
|
|
|
|
|
|
| |
Well, almost. I can't use them in some places in C++ where I'm just
creating a temporary reagent without passing it through transforms. Like
in some unit tests. I can't use them in memory-should-contain.
And there's one remaining bug: I can't use abbreviations in a couple of
places in 075channel.mu.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fix overzealous search-and-replace in commit 3380.
|
| | |
|
| | |
|
| |
|
|
|
| |
One more place we were missing expanding type abbreviations: inside
container definitions.
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It might be too much, particularly if students start peeking inside .mu
files early. But worth a shot for not just to iron out the kinks in the
abbreviation system.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Commit 3370 fixed the memory leak but it still had print:character
printing characters rather than numbers like it used to before 3365. Go
back to the old, unambiguous trace.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix CI.
Figuring out this memory leak was an epic story. I was able to quickly
track down that it was caused by commit 3365, in particular the
overloading of to-text to support characters. But beyond that I was
stumped. Why were layer 3's trace_stream::curr_stream objects being
leaked in layer 81 by a change in layer 59?!
Triaging through the layers, I found the following:
layer 81 - leaks 2 blocks (in clear-line-erases-printed-characters)
layer 83 - leaks 4 additional blocks (in clear-line-erases-printed-characters-2)
I also figured out that the leaks were happening because of the call to
'trace' on a character inside print:character (that's the 'print'
function called with a character argument)
trace 90, [print-character], c
So I tried to create a simple scenario:
scenario trace-on-character-leaks [
1:character <- copy 111/o
trace 90, [print-character], 1:character
]
But that triggered no leaks. Which made sense because there were plenty
of calls to that 'trace' instruction in print:character. The leak only
happened when print:character was called from clear-line. Oh, it happens
only when tracing 0/nul characters. Tracing a Mu string with a nul
character creates an empty C++ string, which is weird. But why should it
leak memory?!
Anyway, I tried a new scenario at layer 62 (when 'trace' starts
auto-converting characters to text)
scenario stashing-nul-character-leaks [
1:character <- copy 0/nul
trace 90, [dbg], 1:character
]
But still, no leak! I played around with running layers until 70, 80.
But then it didn't leak even at layer 82 where I'd seen it leak before.
What had I done?
Turns out it was only leaking if I used names for variables and not
numeric addresses. Eventually I was able to get layer 59 to leak:
scenario stashing-nul-character-leaks [
c:character <- copy 0/nul
x:text <- to-text c
trace 90, [dbg], x
]
At that point I finally went to look at layer 3 (I'd been thinking about
it before, but hadn't bothered to *actually go look*!) And the leak was
obvious.
In the end, all the information I needed was right there in the leak
report. The reason this was hard to find was that I wasn't ready to
believe there could be a bug in layer 3 after all these months. I had to
go through the five stages of grief before I was ready for that
realization.
Final mystery: why was the memory leak not triggered by numeric
variables? Because the transform to auto-convert ingredients to text
only operated on named variables. Manually performing the transform did
leak:
scenario stashing-text-containing-nul-character-leaks [
1:text <- new character:type, 1/capacity
put-index *1:text, 0, 0/nul
trace 90, [dbg], 1:text
]
|
| |
|
|
| |
Fix some tests and make them less fragile.
|
| |
|
|
| |
Decouple layer 61 test from layer 62 dependency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Solution to a minor puzzle that came up during today's lesson with Ella:
some sandboxes were showing the address of text results, while others
were showing their contents. It took a while to realize that the
distinction lay in whether the sandbox was saving the results in a text
variable:
new [abc]
=> <some address>
x:text <- new [abc]
=> abc
It took *much* longer to realize why I couldn't make the first case work
like the second. Eventually I realized why: recipes were reclaiming
their results if they weren't 'escaping' -- that is, being saved in a
variable in the caller so they could be used later.
Any solution to this would be a hack, so I'm going to just leave it
alone. Type abbreviations should help minimize the extra typing needed
to get sandboxes to show text contents.
|
| |
|
|
|
|
| |
Small bugfix in error messages for scenarios: we're trying to use
read_mu_string() on an array of characters rather than an address to an
array of characters. So we need to pretend we have a refcount.
|
| |
|
|
|
| |
The implementation is quite hacky. Let's see how future needs develop
before we try to clean it up.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This commit completes the final step: fixing the final failing tests (in
chessboard.mu) by teaching `restart` about the block signal.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix failing scenarios in channel layer. We do so by introducing a kludgy
new instruction to explicitly signal when a routine is stuck ('blocked')
and waiting on another.
All this locking and blocking may well be a crap design. We'll see if we
find ourselves using these primitives again. Ideally we don't need them
for anything else now that we're done building channels.
Still some failing scenarios left in chessboard.mu. Let's see how that
goes.
|
| |
|
|
|
| |
Reorder `wait-for-routine-to-block` to be close to related routines
`switch` and `restart`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously our channels were based on an unconventional
`wait-for-location` primitive that waits for a specific address to
change its contents. This only works as long as a channel has a single
reader and a single writer routine. To support multiple readers and
writers we switch to a more conventional compare-and-set primitive.
There's still a couple of failing scenarios, though -- the ones using
`wait-for-routine-to-block`, because the new approach never blocks on an
empty or full channel, just yields CPU for a time before polling. Hmm,
how to fix this?
|
| |
|
|
| |
Three separate CI fixes(!)
|
| |
|
|
| |
Fix a warning on some compilers.
|
| |
|
|
|
|
|
|
| |
Expand type abbreviations when checking for colliding/redefined
variants.
This may need a separate transform if we ever find the need to use type
abbreviations before defining them.
|
| |
|
|
|
|
|
|
|
| |
Done using 'text' type abbreviation everywhere.
There's still a problem. If we define a function with a type
abbreviation and then redefine it without, I think we end up creating
separate variants. That seems wrong. Let's isolate a scenario for that
next.
|
| |
|
|
| |
Process type abbreviations in *shape-shifting* function headers.
|
| | |
|
| | |
|
| |
|
|
|
| |
Reorganize layers a bit so I can add a couple of scenarios testing
static dispatch *before* I add `stash` into the mix.
|