| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clean up the rat's nest that all my trace management globals had
gradually turned into.
a) Get rid of 'Start_tracing'. Horryibly named, I don't know how I
missed that until now.
b) Never use START_TRACING_UNTIL_END_OF_SCOPE in main(). It's
confusing to combine it with atexit(delete Trace_stream), because the
atexit() never has to run. Instead we'll just manually initialize
Trace_stream and let atexit() clean up.
c) If we run tests we only want a trace for the test run itself. So
delete the Trace_stream that was initialized at the top of main --
once it's clear we had no load-time errors.
d) Clean up horribly "Load Recipes" waypoints, combine them with the better
name, "Mu Prelude".
Putting these together, we have the following manual tests:
- CFLAGS=-g mu x.mu
Should not create last_run.
- CFLAGS=-g mu --trace x.mu
Should create last_run.
Should write it out exactly once.
- CFLAGS=-g mu --trace x.mu # when x.mu has an error
Should create last_run.
Should write it out exactly once.
- CFLAGS=-g mu --trace test copy_literal # C test
Should create last_run.
Should write it out exactly once.
- CFLAGS=-g mu --trace test recipe_with_header # Mu test
Should create last_run.
Should write it out exactly once.
I don't know how to automate these scenarios yet. We need a way to run
our build toolchain atop our stack.
|
|
|
|
| |
This has taken me almost 6 weeks :(
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been working on this slowly over several weeks, but it's too hard
to support 0 as the null value for addresses. I constantly have to add
exceptions for scalar value corresponding to an address type (now
occupying 2 locations). The final straw is the test for 'reload':
x:num <- reload text
'reload' returns an address. But there's no way to know that for
arbitrary instructions.
New plan: let's put this off for a bit and first create support for
literals. Then use 'null' instead of '0' for addresses everywhere. Then
it'll be easy to just change what 'null' means.
|
|
|
|
|
| |
I no longer remember why we were disabling memory reclamation inside
sandboxes. Everything seems to be working. Just take it out.
|
| |
|
| |
|
|
|
|
| |
Time to make my ad hoc commented out code fragments a first-class feature.
|
| |
|
| |
|
|
|
|
| |
Thanks Lakshman Swaminathan for reporting this issue.
|
| |
|
|
|
|
|
|
|
| |
Properly support reloading lessons containing scenarios in edit/ and
sandbox/ apps.
I was so sure I tested this for commit 3724, but apparently not.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Support reloading the recipe side of the edit/ app when it includes type
abbreviations.
Thanks Ella Couch for reporting this problem.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Deconstruct the tracing layer which had been an exception to our
includes-types-prototypes-globals-functions organization thus far.
To do this we predefine a few primitive globals before the types that
use them, and we pull some method definitions out of struct definitions
at the cost of having to manually write a couple of prototypes.
|
|
|