| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Support reloading the recipe side of the edit/ app when it includes type
abbreviations.
Thanks Ella Couch for reporting this problem.
|
| | |
|
| | |
|
| |
|
|
| |
Avoid spurious mutability errors due to index variables.
|
| | |
|
| | |
|
| |
|
|
|
| |
Wrap $read-from-socket in a channel and fix the socket example
so that browser's display the response properly.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Undo commit 3340. Let's standardize names of non-core files to only have
dashes. That's also consistent with the edit/ and sandbox/ apps. Mu
programmers will tend to pervasively use dashes, just like Lisp
programmers.
Scripts will continue to use underscores..
|
| |
|
|
|
|
|
| |
$write-to-socket, $read-from-socket, and $accept now pass around
references to socket pointers.
$read-from-socket handles EOF explicitly.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| | |
|