4 ms·

Hey kragen, Someone just told me to have a look at the thread and I'm very happy I did! It's been really good for me to read back you two's exchange. I'm not h

Hey kragen, Someone just told me to have a look at the thread and I'm very happy I did! It's been really good for me to read back you two's exchange. I'm not here to defend uxn or anything like that, I was only wondering, could you do the same test with uxn11(instead of uxnemu)? I don't personally use uxnemu, I find it's too demanding for my laptop, I would love to have the data for uxn11 in comparison to uxnemu from your system if you can run X11 programs. Let me know :) Cheers!

kragen 2y ago
oh hi! delighted to hear from you! i hope it's clear i'm not here to attack uxn either let's see about uxn11... initial signs are good, 175711 instructions to start up and shutdown rather than hundreds of millions. but after using it to go through the whole left editing session, it's 175645 instructions; that suggests the real work is being done in a child process yeah, strace confirms there's a child process being spawned off. i'll have to see if i can disable that to get more accurate measurements with valgrind, later today i'm interested to hear your thoughts about how left and other uxn apps might be made usable under the constraints of the zorzpad display hardware: two 400×240 screens, each 35×58mm, with only black and white (no greyscale). left itself seems like it might be relatively easy to run usably on one of them?
- entaloneralie 2y ago
  Of course, I've really enjoyed your exploration of uxn, and all your comments are accurate. Uxn11 has a special device to spawn linux processes(like playing a mp3 on disk with aplay), it can be disabled in devices/console, I wonder why it would be acting up, left doesn't do any request to the console's special ports I think, I'll have to double-check. Left is pretty heavy, it does A LOT, it's definitely not a simple text editor, not only does it do a lot of work locating symbols and navigation strings, the front-end uses a proportional font and does a lot of positioning for it. I don't think left would be a good candidate for zorzpad, I can imagine a simpler IDE that uses fixed width font, and doesn't try to make any sense of the tal code, syntax highlight, and doesn't support utf-8 glyphs - But Left is not it. I've ported the classic macintosh notepad application, which I now use daily for taking notes, it has proportional font support, but is monochrome and has a small window, doesn't do anything fancy. Expanding this into a proper text editor with scrolling might be more realistic than trying to fit left to a monochrome screen. https://git.sr.ht/~rabbits/uxn-utils/tree/main/item/gui/notepad https://git.sr.ht/~rabbits/uxn-utils/tree/main/item/gui/note... But really, I think it'd be better to write a whole new text editor specifically for zorzpad, left has a very specific goal in mind, and I can imagine one like it designed specifically for the zorzpad. Writing text editors, or block editors, is an art that shouldn't be forgotten, anyone who's got an opportunity to write one, should do it. I've read as much of your works as I could find, you've been a big influence on the work I do nowadays, it's an honor to read a message from you. Thank you.
  - kragen 2y ago
    aw, thanks, i'm really flattered—i admire your work a lot, and i'm glad to hear i've contributed somewhat to it. you're very welcome as for proportional fonts, a few years back i wrote a microbenchmark for proportional font layout with word wrap to see how cheap i could get it. it's http://canonical.org/~kragen/sw/dev3/propfont.c http://canonical.org/~kragen/sw/dev3/propfont.c (maybe make sure you redirect stdout to a file if you run it), and it uses the n×6 font i designed for http://canonical.org/~kragen/bible-columns http://canonical.org/~kragen/bible-columns, derived from janne kujala's 4×6 font. the notes in the comments say that on my old laptop it ran at 70 megabytes per second, which is probably about 60 instructions per byte. if you redrew 32 lines of text with 32 characters each (about what you could fit on the zorzpad's two screens) it would be about 60000 instructions, about a microsecond at the apollo3's theoretical 60 dmips; that might be a reasonable thing to do after each keystroke. and there are some notes in there about how you could optimize it more running the same benchmark on my current laptop i get numbers from 64 to 68 megabytes per second, but for comparability with the editors, i should say that cachegrind measures 1,482,006,535 instructions for running 100000 iterations of rendering 126 bytes, which works out to about 118 instructions per byte and 120 000 instructions for the screen-redrawing example (of course that computation takes about 2 microseconds, while actually updating the screen will take 50000 microseconds according to the datasheet, 16700 microseconds according to some other people's experimental results, so the computation may not be the tall pole in the tent here) propfont.c might get a lot faster if its pixels were bits instead of bytes, especially on something like the thumb-2 apollo3, which has bitfield update instructions. then again, it would get slower with a larger pixel font size
    - entaloneralie 2y ago
      I'm currently away from reliable network and I can't manage to load the bible-columns image, I will try once we return to Canada. I've added proportional fonts to Left because, after writing loads of THINK Pascal, I felt like I needed it, and I still enjoy this a lot more than fixed-width, but it annoys a lot of people, even even I like to write space-padded files from time to time so Left has to support both. If I was golfing an editor(one that I would actually have to use each day), I think I would make a block editor, fixed-width, and by its block-paginated design would do away with gap buffers altogether by needed to move very little data around. An early version of Left tried something different where it would only display one @symbol at a time. In Uxn, "scope" or objects are defined with @label, and methods by &method, making it so it's well usable if you have a list of objects, and methods a-la Smalltalk's System Navigator. During editing, you never insert into the text file, but in a gap buffer made of only the object or method being edited. I always found that design pretty neat, the main downsize is when you want to add non-source files, then you have to contend with editing to a single large buffer. The font encoding for Left is https://wiki.xxiivv.com/site/ufx_format.html https://wiki.xxiivv.com/site/ufx_format.html, which allows me to calculate the sprite address glyph width sort-of quickly, the issue is that varvara has no blitter, everything is drawn as tiles so it creates a bit of overdraw for each glyph. If you have a blitter, then I think there would be pretty smart encodings for drawing proportional fonts that would make them more efficient.

kragen 2y ago

oh hi! delighted to hear from you! i hope it's clear i'm not here to attack uxn either let's see about uxn11... initial signs are good, 175711 instructions to start up and shutdown rather than hundreds of millions. but after using it to go through the whole left editing session, it's 175645 instructions; that suggests the real work is being done in a child process yeah, strace confirms there's a child process being spawned off. i'll have to see if i can disable that to get more accurate measurements with valgrind, later today i'm interested to hear your thoughts about how left and other uxn apps might be made usable under the constraints of the zorzpad display hardware: two 400×240 screens, each 35×58mm, with only black and white (no greyscale). left itself seems like it might be relatively easy to run usably on one of them?

entaloneralie 2y ago
Of course, I've really enjoyed your exploration of uxn, and all your comments are accurate. Uxn11 has a special device to spawn linux processes(like playing a mp3 on disk with aplay), it can be disabled in devices/console, I wonder why it would be acting up, left doesn't do any request to the console's special ports I think, I'll have to double-check. Left is pretty heavy, it does A LOT, it's definitely not a simple text editor, not only does it do a lot of work locating symbols and navigation strings, the front-end uses a proportional font and does a lot of positioning for it. I don't think left would be a good candidate for zorzpad, I can imagine a simpler IDE that uses fixed width font, and doesn't try to make any sense of the tal code, syntax highlight, and doesn't support utf-8 glyphs - But Left is not it. I've ported the classic macintosh notepad application, which I now use daily for taking notes, it has proportional font support, but is monochrome and has a small window, doesn't do anything fancy. Expanding this into a proper text editor with scrolling might be more realistic than trying to fit left to a monochrome screen. https://git.sr.ht/~rabbits/uxn-utils/tree/main/item/gui/notepad https://git.sr.ht/~rabbits/uxn-utils/tree/main/item/gui/note... But really, I think it'd be better to write a whole new text editor specifically for zorzpad, left has a very specific goal in mind, and I can imagine one like it designed specifically for the zorzpad. Writing text editors, or block editors, is an art that shouldn't be forgotten, anyone who's got an opportunity to write one, should do it. I've read as much of your works as I could find, you've been a big influence on the work I do nowadays, it's an honor to read a message from you. Thank you.
- kragen 2y ago
  aw, thanks, i'm really flattered—i admire your work a lot, and i'm glad to hear i've contributed somewhat to it. you're very welcome as for proportional fonts, a few years back i wrote a microbenchmark for proportional font layout with word wrap to see how cheap i could get it. it's http://canonical.org/~kragen/sw/dev3/propfont.c http://canonical.org/~kragen/sw/dev3/propfont.c (maybe make sure you redirect stdout to a file if you run it), and it uses the n×6 font i designed for http://canonical.org/~kragen/bible-columns http://canonical.org/~kragen/bible-columns, derived from janne kujala's 4×6 font. the notes in the comments say that on my old laptop it ran at 70 megabytes per second, which is probably about 60 instructions per byte. if you redrew 32 lines of text with 32 characters each (about what you could fit on the zorzpad's two screens) it would be about 60000 instructions, about a microsecond at the apollo3's theoretical 60 dmips; that might be a reasonable thing to do after each keystroke. and there are some notes in there about how you could optimize it more running the same benchmark on my current laptop i get numbers from 64 to 68 megabytes per second, but for comparability with the editors, i should say that cachegrind measures 1,482,006,535 instructions for running 100000 iterations of rendering 126 bytes, which works out to about 118 instructions per byte and 120 000 instructions for the screen-redrawing example (of course that computation takes about 2 microseconds, while actually updating the screen will take 50000 microseconds according to the datasheet, 16700 microseconds according to some other people's experimental results, so the computation may not be the tall pole in the tent here) propfont.c might get a lot faster if its pixels were bits instead of bytes, especially on something like the thumb-2 apollo3, which has bitfield update instructions. then again, it would get slower with a larger pixel font size
  - entaloneralie 2y ago
    I'm currently away from reliable network and I can't manage to load the bible-columns image, I will try once we return to Canada. I've added proportional fonts to Left because, after writing loads of THINK Pascal, I felt like I needed it, and I still enjoy this a lot more than fixed-width, but it annoys a lot of people, even even I like to write space-padded files from time to time so Left has to support both. If I was golfing an editor(one that I would actually have to use each day), I think I would make a block editor, fixed-width, and by its block-paginated design would do away with gap buffers altogether by needed to move very little data around. An early version of Left tried something different where it would only display one @symbol at a time. In Uxn, "scope" or objects are defined with @label, and methods by &method, making it so it's well usable if you have a list of objects, and methods a-la Smalltalk's System Navigator. During editing, you never insert into the text file, but in a gap buffer made of only the object or method being edited. I always found that design pretty neat, the main downsize is when you want to add non-source files, then you have to contend with editing to a single large buffer. The font encoding for Left is https://wiki.xxiivv.com/site/ufx_format.html https://wiki.xxiivv.com/site/ufx_format.html, which allows me to calculate the sprite address glyph width sort-of quickly, the issue is that varvara has no blitter, everything is drawn as tiles so it creates a bit of overdraw for each glyph. If you have a blitter, then I think there would be pretty smart encodings for drawing proportional fonts that would make them more efficient.