The editor now uses the vertical scrollbar for handling mouse wheel
scrolling, thus keeping the scrollbar in sync.
Scrollbar index can now cover the full range (not sure why I had that
-1), and the potential divide by zero is avoided properly.
Thumb-tab now positioned properly when the range is 0.
This gets all the basic cursor motion from my old editor working.
arrow keys: left/right/up/down char/line
home/end: beginning/end of line
page up/down
and ctrl versions where left/right are prev/next work, up/down skip over
indents, home/end are beginning/end of screen, and page up/down are
beginning/end of text.
The word boundaries are currently vary simple, just transitions from
alnum_ (as it was in my old editor and in Borland's editors), but the
basic logic is working.
Currently, home always moves the cursor to the very first column, but
I'm considering making it move the cursor to the first non-space
character of the line if it's not already there, otherwise to the first
column (ie, the cursor will toggle between the two positions if it's in
one of them).
If the src type is not a class, there is no inheritance chain to walk.
Fixes a segfault when returning self after a syntax error in the
following:
+(EditStatus *)withRect:(Rect)rect
{
return [[[self alloc] initWithRect:rect]:
}
-setCursorMode:(CursorMode)mode
{
cursorMode = mode;
return self;
}
Support for finding the first address associated with a source line was
added to the engine, returning 0 if not found.
A temporary breakpoint is set and the progs allowed to run free.
However, better handling of temporary breakpoitns is needed as currently
a "permanent" breakpoint will be cleared without clearing the temporary
breakpoing if the permanent breakpoing is hit while execut-to-cursor is
running.
Basic arrow key motion, and it's currently limited to not scrolling
horizontally (need to figure out how to handle max scroll), but this
also fixes the cursor handling on focus switching :)
For now, just bsearch (normal and fuzzy), qsort, and prefixsum (not in
C's stdlib that I know of, but I think having native implementations of
float and int prefix sums will be useful.
Fuzzy bsearch is useful for finding an entry in a prefix sum array
(value is >= ele[0], < ele[1]), and the reentrant version is good when
data needs to be passed to the compare function. Adapted from the code
used in pr_resolve.
While qfcc will always align double values to 8 bytes (really, two
global words) regardless of the underlying hardware, gcc does not:
doubles are only 4-byte aligned on 32-bit hardware.
This fixes the invalid debug target handle when running on i686.
A bit of a mess for optimized vs unoptimized, but the tests acknowledge
the differences in precision while checking that the code produces the
right results allowing for that precision.
It seems that i686 code generation is all over the place reguarding sse2
vs fp, with the resulting differences in carried precision. I'm not sure
I'm happy with the situation, but at least it's being tested to a
certain extent. Not sure if this broke basic (no sse) i686 tests.
GCC does a fairly nice job of producing code for vector types when the
hardware doesn't support SIMD, but it seems to break certain math
optimization rules due to excess precision (?). Still, it works well
enough for the core engine, but may not be well suited to the tools.
However, so far, only qfvis uses vector types (and it's not tested yet),
and tools should probably be used on suitable machines anyway (not
forces, of course).
I don't know that the cache line size is 64 bytes on 32 bit systems, but
it should be ok to assume that 64-byte alignment behaves well on systems
with smaller cache lines so long as they are powers of two. This does
mean there is some waste on 32-bit systems, but it should be fairly
minimal (32 bytes per memblock, which manages page sized regions).
The Blend macro supports any non-integral type supporting * and +
(float, double, vec4f_t, etc), so it is essentially a scalar VectorBlend
or QuatBlend.
