| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Thanks Stephen Malina for the suggestion.
I don't yet know how to include comments in the .ctagsrc file, so I'll
include them here for now:
To use this file, symlink or append exuberant-ctags-rc to your
~/.ctagsrc.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This ports commits 3052 and 3053 from the edit/ app.
|
|
|
|
|
| |
As much as possible; if the cursor moves off screen, it still resets to
top of screen.
|
|
|
|
|
|
| |
This required the fix of 3051 to first-class recipe support, and will
next enable us to keep the cursor from moving in response to resize
events.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|