05:09:10
##forth
<neauoire>
hey xentrac
05:10:52
##forth
<neauoire>
can you remind me how to browse pavnotes without cloning it?
05:11:32
##forth
<neauoire>
I'm working on a little UI in uxn for my self-hosted compiler, which is also written in itself.
05:12:01
##forth
<neauoire>
lots of self-modification going on there ^__^
05:51:33
##forth
<xentrac>
neauoire: well, in theory you could carry out the operations the Git client would carry out
05:56:45
##forth
<xentrac>
in e.g. Python zlib.decompress(open('b4629a560b5656a5b760c1ded688db88db8317', 'rb').read())
05:57:08
##forth
<xentrac>
which says tree 2fe2dbf439e9a0ac5492d6fb88031a12990995e6 among other things
05:59:30
##forth
<xentrac>
zlib.decompress(open('e2dbf439e9a0ac5492d6fb88031a12990995e6', 'rb').read()) gives you filenames and hashes
06:01:30
##forth
<xentrac>
if you store it in a bytestring s, for example s[s.index(b' gsais-pong.md\0'):][:40] gives you b' gsais-pong.md\x00\xd64\x90\x16F"\xd9\xd7\xd13x\xf9nTh;\xa5p\xa3\xa910064'
06:02:50
##forth
<xentrac>
and s[s.index(b' gsais-pong.md\0'):][15:35] gives you the hash, though in an inconveniently binary form
06:04:04
##forth
<xentrac>
fixable with ''.join('{:02x}'.format(b) for b in s[s.index(b' gsais-pong.md\0'):][15:35])
06:04:26
##forth
<xentrac>
which helpfully says d63490164622d9d7d13378f96e54683ba570a3a9
06:06:03
##forth
<xentrac>
and then zlib.decompress(open('3490164622d9d7d13378f96e54683ba570a3a9', 'rb').read()) gives you the actual text of the document in question
06:06:36
##forth
<xentrac>
so you *can* browse pavnotes2 without cloning it
06:07:18
##forth
<xentrac>
but it might be more practical to clone it
06:09:24
##forth
<xentrac>
the compiler dialog box looks very maccy, but I'd think the ideal UI for a compiler would usually be that you attempt to run your program and it either produces compile errors or runs
06:12:06
##forth
<xentrac>
so the compiler as such is as invisible as the BIOS or the keyboard controller except when something goes wrong
06:19:19
##forth
<xentrac>
your tastes may differ, of course
06:21:59
##forth
<xentrac>
there may be advantages to not requiring the deployment environment to have the compiler, for example, or you might want to guarantee rapid startup
14:12:49
##forth
<veltas>
In a lot of 8-bit code if you have some machine code in RAM and there's a small number of 8-bit globals it relies on, then you just use immediate values and overwrite the immediates within the instruction, instead of using separate globals
14:13:34
##forth
<veltas>
I'm sure that's used in demos, but it's really just a useful way of managing many kinds of globals in 8-bit, probably seems hacky now
14:14:16
##forth
<veltas>
In x86 I've seen reports that this is a lot slower, so I wouldn't do it on a modern CPU
14:14:52
##forth
<veltas>
I think I remember hearing that gforth until not even that long ago was doing this for certain kinds of globals, and obviously had never profiled it
14:20:43
##forth
<xentrac>
veltas: yeah, that's what the pong code is doing. it only needs to run
14:21:30
##forth
<xentrac>
uh,
14:24:05
##forth
<xentrac>
it only needs to run about 160 instructions per screen frame, if I'm counting right
14:24:44
##forth
<xentrac>
the rest of the time it's busywaiting on the VBI
14:25:05
##forth
<xentrac>
so it is okay if it is a lot slower
14:27:00
##forth
<xentrac>
it's a common technique also on neauoire's uxn virtual stack machine, where they *do* use it for speed, because uxn is invariably interpreted and so it doesn't invalidate any caches or anything
14:27:49
##forth
<xentrac>
120 of those instructions are erasing and redrawing the paddles
14:29:33
##forth
<xentrac>
the instruction that updates the ball position is lea si, [bx+si+0x2]
14:30:58
##forth
<xentrac>
bx is the vertical movement, the 2 is the horizontal movement, and the immediate 2 gets modified when the ball bounces left or right
14:31:51
##forth
<xentrac>
so you get two additions in a single instruction
14:49:39
##forth
<veltas>
Interesting stuff
15:38:18
##forth
<xentrac>
I was sort of disappointed to find that the winning entry seemed to be almost entirely micro-optimization tricks rather than conceptual insights, but maybe I'll look through one of the larger entrants to see what kind of conceptual overcomplications he avoided
15:39:29
##forth
<xentrac>
like, using the same code with a different color argument to draw the paddles and to erase them might be a thing that other entrants didn't think of
15:39:58
##forth
<xentrac>
or using XOR to draw and erase the ball so the draw and erase code is the same
15:40:47
##forth
<xentrac>
the rules for some reason prohibited clearing the screen every frame
16:15:46
##forth
<neauoire>
for things like flipping the orientation of a ball going back and forth across a field
16:16:17
##forth
<neauoire>
it's pretty nifty to change the instruction on collision instead of checking for direction every frame
16:16:40
##forth
<neauoire>
in a DVD screensaver thingy
16:17:46
##forth
<neauoire>
*instead of loading the direction register on every frame