| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This wouldn't have failed silently; I have that fig leaf. If someone had
tried to copy an exclusive container containing an exclusive container
containing an address Mu would have crashed on them.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Caleb Couch for finding this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some rare situations the editor would join a line with the next when
it should simply wrap to the next screen row. Thanks Caleb and Ella
Couch for finally running into a situation that was easy to reproduce.
The scenario diffs are misleading on this commit. I had to:
a) delete the obsolete 'editor-wraps-cursor-after-inserting-characters'
because it was written back when a line just large enough to fit in a
single line would not wrap:
| | <-- screen boundary
abcde
These days it will wrap after making room for the wrap indicator:
| | <-- screen boundary
abcd↩
e
b) rename editor-wraps-cursor-after-inserting-characters-2 to
editor-wraps-cursor-after-inserting-characters-in-middle-of-line
c) create a new scenario demonstrating the bug:
editor-wraps-cursor-after-inserting-characters-at-end-of-line
|
| |
|
|
|
|
| |
By disabling lookups on the product of 'create-array', I'd messed it up
so we were treating the product as a raw address and ignoring
default-space. Just remove that exception.
|
| |
|
|
|
|
|
| |
Drastically streamlined floating-point overflow/underflow detection.
For some reason I can't find a way to actually handle SIGFPE traps; they
have to segfault the program.
|
| |
|
|
|
|
|
|
| |
I'd included handling for SIGFPE on faith but I'm not actually able to
see it triggering. Drop it until we can at least test it manually.
In general, floating-point is horrendous: https://hal.archives-ouvertes.fr/hal-00576641v1/document.
Neither types nor tests will help deal with it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves on commit 3026; it turns out you need to manually handle
the traps generated by -ftrapv.
https://gist.github.com/mastbaum/1004768
Signal handling is based on https://spin.atomicobject.com/2013/01/13/exceptions-stack-traces-c.
Various combinations of platform+compiler seem to work very differently:
gcc everywhere seems to have extremely threadbare ftrapv support
Clang + OSX generates SIGILL.
Clang + Linux is advertised to generate SIGABRT, so I handle that out
of an excess of caution. However, in my experience it seems to kill
the program (sometimes segfaulting) even without any signal handlers
installed.
In the process, I realized that all my current builds are using Clang,
so I added one little test on CI to use g++ in commit 3029.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Stop depending on the LLVM apt repo in CI:
http://lists.llvm.org/pipermail/llvm-dev/2016-May/100303.html
(Thanks Travis CI support.)
|
| | |
|
| |
|
|
|
|
|
| |
How did I not know about -ftrapv for so long?! Found while reading
Memarian et al, "Into the depths of C: Elaborating the de facto
standards".
http://www.cl.cam.ac.uk/~pes20/cerberus/pldi16.pdf
|
| |
|
|
|
| |
When I floor the down-arrow too much, don't scroll unnecessarily off the
bottom of the screen. But *do* scroll if there's errors to show.
|
| | |
|
| | |
|
| |
|
|
| |
Clean up 3020.
|
| | |
|
| |
|
|
|
|
|
|
| |
Extremely ugly change.
Also ended up fixing some places where I was mixing up sources and
sinks. But I'm not going to bother updating edit/ and sandbox/ apps.
Just too many scenarios to clean up.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
There's still a problem: if I ever want to use any of the special
scenario variables like 'screen', 'console', etc., then I can't use
'local-scope' in my scenario.
|
| |
|
|
|
| |
Tests are clearer if memory locations look different from other literal
values.
|
| | |
|
| |
|
|
| |
Clean up old tests after https://news.ycombinator.com/item?id=11779013
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
insert_container is getting pretty gnarly. It's spread across two layers
(containers and shape-shifting containers), and since it has to deal
with extending existing containers it's coiled in on itself,
constantly reading and writing the Type table.
Maybe I should uncoil the case of extending a container and make it
separate from defining a new container.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Drop those tests now that we've confirmed over the last few commits that
they work. The new test introduced in the bugfix of commit 3003 takes
over their duties.
|
| |
|
|
|
|
| |
Thanks Caleb Couch for finding this hole, and for noticing that it made
a bug in binary-search harder to find. For now we'll just rely on the
host's support for printing floating-point.
|
| |
|
|
|
|
| |
Bugfix: overriding a primitive recipe with a generic variant that takes
an address of something shouldn't mask the primitive when you call it
with literal 0.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|