| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Clean up rest of long-standing bit of ugliness.
I'm growing more confident now that I can use layers to cleanly add any
functionality I want. All I need is hook functions. No need to ever put
'{' on their own line, or add arguments to calls.
|
| |
|
|
| |
Clean up one long-standing bit of ugliness.
|
| |
|
|
|
|
| |
Turns out chessboard.mu started deadlocking in commit 3258 even though
all its tests continue to pass. Not fixed yet; first make deadlock
easier to diagnose.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Prefer preincrement operators wherever possible. Old versions of
compilers used to be better at optimizing them. Even if we don't care
about performance it's useful to make unary operators look like unary
operators wherever possible, and to distinguish the 'statement form'
which doesn't care about the value of the expression from the
postincrement which usually increments as a side-effect in some larger
computation (and so is worth avoiding except for some common idioms, or
perhaps even there).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the process of debugging the last couple of commits (though I no
longer remember exactly how) I noticed that 'wait-for-routine' only
waits until the target routine stops running for any reason, including
when it blocks on something. That's not the synchronization primitive we
want in production code, even if it's necessary for some scenarios like
'buffer-lines-blocks-until-newline'. So we rename the old 'wait-for-routine'
primitive to 'wait-for-routine-to-block', and create a new version of
'wait-for-routine' that say callers of 'start-writing' can safely use,
because it waits until a target routine actually completes (either
successfully or not).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another hole in refcount management, which I noticed while doing commit
3202, and thinking about which led to the insight of commit 3212.
Now the summary of commit 3197 is modified to this:
Update refcounts of products after every instruction, EXCEPT:
a) when instruction is a non-primitive and the callee starts with
'local-scope' (because it's already not decremented in 'return')
OR:
b) when instruction is primitive 'next-ingredient' or
'next-ingredient-without-typechecking', and its result is saved to a
variable in the default space (because it's already incremented at
the time of the call)
|
| |
|
|
|
|
|
|
|
|
|
| |
When updating refcounts for a typed segment of memory being copied over
with another, we were only ever using the new copy's data to determine
any tags for exclusive containers. Looks like the right way to do
refcounts is to increment and decrement separately.
Hopefully this is a complete fix for the intermittent but
non-deterministic errors we've been encountering while running the edit/
app.
|
| |
|
|
| |
Fix CI.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you pass an ingredient to a recipe using 'start-running' it mostly
behaves identically to performing a regular function call. However, if
the calling function completed before the new routine had a chance to
run, the ingredients passed in ran the risk of being reclaimed.
In response, let's always increment refcounts at the time of a function
call rather than when the ingredients are read inside the callee.
Now the summary of commit 3197 is modified to this:
Update refcounts of products after every instruction, EXCEPT:
a) when instruction is a non-primitive and the callee starts with
'local-scope' (because it's already not decremented in 'return')
OR:
b) when instruction is primitive 'next-ingredient' or
'next-ingredient-without-typechecking'
|
| | |
|
| | |
|
| |
|