| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wanted to come up with some way to rewrite 'def-clause foo' to 'after
foo/more-clauses', something like:
rewrite def-clause [
(fn-name string-address) <- arg
(label-name string-address) <- strcat (fn-name string-address deref) ("/more-clauses" literal)
(body expr) <- arg
reply `(after ,label-name ,body)
]
But the quasiquote is still a nested expression that doesn't fit our
model well.
Still an open question how to do template interpolation in mu.
|
|
|
|
| |
We'll worry later about implementing them in mu.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I'm cheating a little when it comes to strings, making use of Racket
primitives. But in principle it seems like a local transform to
implement even in machine code.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I'm still figuring out the idioms, and it doesn't seem like there's an
easy way to avoid redundant allocations and arg reading.
At least for generic functions we want to optimize for each call-site,
we can create subsidiary labels to jump to.
Also, this is the first genuine use for random access to a function's
arguments.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Convert readme to markdown for github.
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
I have different prose in Readme and at the top of the tests. Let's see
how hard they are to manage over time.
|
|
|
|
|
|
|
|
|
|
|
| |
You can now call 'def' on a function name multiple times. Each time the
instructions you provide are *prepended* to any existing instructions.
One important use for this is when you define a new type and need to
support it in all your generic methods. Now you can keep all those
extensions in one place, near the definition of the type.
To redefine a function, use 'def!'.
|
| |
|
|
|
|
|
|
| |
This pollutes our traces with all 'system software'. Too much trouble to
keep it out; just lump it for now. Who knows, might even be useful. Most
of the time convert* labels are easy to grep out when debugging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Will the 'lightweight tools' really be all that useable if we encourage
people to layer them one atop another and track precisely what inputs
each can accept? Something to keep an eye on.
In the meanwhile, we have a new (but very unrealistic) example
demonstrating the tangling directives.
There's still a big constraint on ordering: before/after clauses have to
come before functions that need them.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also mirror mu.arc.t.html to the gh-pages branch.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies things a lot and eliminates the race condition.
I think it's practical too, as long as you save a single location and
don't permit sleeping on compound structures. I'm resigned to needing a
lock in the native setting.
Should I be concerned that I fixed a failing test by getting rid of hit?
If I had alternatives, how would I save the old sleep implementation?
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Still failing, but worth memorializing for posterity.
Race condition tests are still experimental, even more tied to a very
specific implementation. If I make changes to 'write' the very
'wipe-read' label will go away.
But then you just delete all tests relying on stale labels and try to
think up new race conditions.
|