Refactor diff internals to allow multiple diffs
to be done in the same process. This allows a
merge3 to be implemented off the guts of
diff.
Tests are added, files with no end of line
terminator are currently broken.
The loaders can generate export tables in executables and build
dynamically loadable modules and there is a library to load those
floating around. This documents the format of dynamically loadable
modules.
The dot and inner products are not the same, and neither are cross and
outer ones.
Trimmed function signatures—similar to those in draw(2)—were added to
aid in comprehension.
Timing is not as good as it needs to be,
but servicable in more forgiving scenarios.
Clock drift between two paired systems sits
around 8 - 32 cycles when tested locally.
adventuresin9 wrote:
I finally found the time to get the kernel working for the Mediatek
mt7688. Just the uart works now, so I still need to do the ethernet
and hopefully wifi and other stuff. But it boots all the way to the
bootargs ask, and then running !rc lets you run rc in paqfs.
https://github.com/adventuresin9/9front-mt7688
I had a heck of a time getting it to work at first, till I tracked
down an issue in strlen, that comes from the strchr code. Lots of
stuff broke, and this bug also meant error messages wouldn't print
properly.
running this on the mt7688;
int n1, n2, n3, n4, n5, n6;
char *a1, *a2, *a3, *a4, *a5, *a6;
a1 = "\0";
a2 = "A";
a3 = "AA";
a4 = "AAA";
a5 = "AAAA";
a6 = "AAAAA";
n1 = strlen(a1);
n2 = strlen(a2);
n3 = strlen(a3);
n4 = strlen(a4);
n5 = strlen(a5);
n6 = strlen(a6);
iprint("STRLEN %d %d %d %d %d %d\n", n1, n2, n3, n4, n5, n6);
would get ;
STRLEN 0 1 1 2 1 6
and now it gets;
STRLEN 0 1 2 3 4 5
9front has several tests scattered throughout the source,
as well as more tests in an external 'regress' repository.
Many of these tests are broken, because there is no easy
way to build and track all of them.
This pulls in several tests from different sources, deletes
the broken tests, tests with missing data, and adds a single
command that can be run from the root of the src directory
to test our system.
The hope is that as we develop new code, we add more tests,
and eventually start running the tests on every commit.
Please enter the commit message for your changes. Lines starting
run the keyboardtap as a thread instead of a proc
so that we can read input window variable.
This gets rid of the wintap channel.
do focus handling by tracking the last window and
only send context switch when we start typing into
a different window.
have fromtap, totap channels created by open and
use the variable also as the in-use flag.
handle use nbsendp() when sending to the tap
program, as it might be blocked or misbehaving.
if the totap channel is full, we bypass the tap
and send to input again.
handle keyup on focus loss in the window thread instead
(just like the artificial mouseup) it is unrelated to
keyboardtap.
The calc functions get their buffers passed by value.
This is convenient as the code usually modifies the
buffers during iteration.
However, making ANOTHER copy (odst) and returning it
at the end is a bit silly. We already made a copy
when passing the arguments, and the caller of the
calc function can just reuse the copy it already has.
So changing the return type from Buffer to void.
When using non signed integer variables, the registerizer
would produce multiple converting load instructions on each
use, which gives the peephole optimizer a hard time as it
assumes that converting move instructions are there to
actually change the data type (hence it cannot eleminate
them).
To avoid this, when we replace a variable reference with
a register, we check that the move instruction is in fact
the same as used in the initial load (which is based
on variable type only), and replace the instruction with
a full register move (AMOV).
The peephole optimizer then is able to eleminate these
instruction giving way better code.
* exit if we get eof on kbdtap
* do not nuke the line if we restore a kanji selection without okurigana
* guard against unfortunate scheduling, the dictthread needs to get
through all it can before the keythread processes more. In typical use,
the processing was fast enough to never notice this condition but writing
out a large set of input can trigger it.
we were not handling multi null delimted messages
with one read. This makes us a bit more uniform to
other handling on the system as well ... something about clever
code.
The GAOMON S620 tablet is recognized as a HID device,
but is restricted in the X-axis to the width of a mobile
phone.
I sniffed usb traffic for generic windows 10 hid driver
and there didnt seem anything out of the ordinary.
It turns out that this is some kind of phone feature
and i suspect they have some heuristic for how windows
reads the device and config descriptors to decide if
this is windows or android.
Checking the DIGImend project git repository, they suggest
this is some kind of UCLOGIC compatible tablet, which
once a series of string properties have been read will
switch itself to some different mode.
The report descriptor is supposed to be generated from
the string properties, but the report format didnt really
match theirs.
So i ignore the string properties and just looked at the
report data.
The format after reading the magic string properties
seems to be:
08 - report id
bb - buttons: 0x80 = inrange, 0x04 = eraser, 0x02, barrel, 0x01 = touch
xx xx - x-axis: [0x0000-0x80000)
yy yy - y-axis: [0x0000-0x50000)
pp pp - pressure: [0x0000-0xffff]
?? ?? - unknown
So i hand rolled a hid report descriptor for this and
call it a day :)
