2022-04-25 06:55:13 <crc[dev]    > KipIngram: which ebook reader do you use?
2022-04-25 07:37:57 <KipIngram   > It's an "economy model."  Kobo Clara HD.
2022-04-25 07:38:19 <KipIngram   > I like it's size.
2022-04-25 08:04:43 <crc[dev]    > I've used a number over the years (sony prs-505, pocketbook 360, kindle 4, kindle 5, kindle paperwhite, kindle voyage); the pocketbook 360 was my favorite (open-source firmware & reading application; was pocketable). This finally died though, and I've given away the others over the years.
2022-04-25 08:48:39 <KipIngram   > I'd love to have an open source one.  I used to use a Barnes and Noble Nook, and I had it rooted.  I haven't bothered to root the Kobo.  I do insist, though, on managing my own ebook library, so I use the Calibre application on Linux and it has a plugin that strips the DRM off of the books.
2022-04-25 08:49:35 <KipIngram   > I like this one because it's a nice size and it's got an entirely "non-cluttered" interface.  I don't have any interest in doing a hundred different things with it - I just "read books."
2022-04-25 08:50:18 <KipIngram   > My Nook had no backlight, but this one does and I quite like it; I usually keep it around 50-70 percent.
2022-04-25 08:56:16 <KipIngram   > I have several of those "sleep covers" for it.  They're cheap and I kind of "collect" them.  I change it every few weeks; keeps things "fresh."
2022-04-25 08:57:35 <KipIngram   > And sometimes I don't use one.  That really maximizes how "lean and sleek" it seems.
2022-04-25 10:23:46 <crab_       > howdy forthers
2022-04-25 10:25:15 <lispmacs[work]> howdy
2022-04-25 10:26:49 <crab_       > I'm making a vm to build a forth on top of(similar to how @crc has done their retroforth) and I wanted to get opinions on how to handle I/O
2022-04-25 10:27:54 <crab_       > I think retroforth added three instructions to the vm and left the actual I/O devices to be modules implemented later
2022-04-25 10:29:16 <crab_       > but I was curious if anyone had taken or concieved other approaches
2022-04-25 10:29:58 <crab_       > maybe memory mapped IO?
2022-04-25 10:30:48 <eris[m]     > uxn does mmap'd IO
2022-04-25 10:31:00 <eris[m]     > really it depends on how you want to design it
2022-04-25 10:33:49 <crab_       > let me look at uxn, I've not heard of it
2022-04-25 10:39:57 <crab_       > uxn seems interesting
2022-04-25 10:54:02 <crab_       > my other thought was to try and expose syscall
2022-04-25 11:29:04 <crc[dev]    > crab_: I've experimented with several models in my systems. three instructions (nga), a single instruction (ngaro, ilo), and memory mapped (maunga, napia). I've also done some stuff where each device gets dedicated instructions, but disliked this approach.
2022-04-25 11:30:53 <crc[dev]    > The napia implementation has memory mapped devices, as well as an io trigger instruction, and interrupts that the devices can trigger
2022-04-25 11:35:20 <KipIngram   > crab_ I use syscalls in my system, but on this latest effort I haven't exposed any generic syscall interface.  I did do that on my last one, though.
2022-04-25 11:36:21 <KipIngram   > One tip you might find useful (and better for performance) is to implement EMIT as a count=1 TYPE, instead of building TYPE on EMIT.
2022-04-25 11:36:34 <KipIngram   > That way TYPE can send out the entire string in a single syscall.
2022-04-25 11:36:53 <KipIngram   > You'd otherwise need to write a loop and EMIT the characters one at a time - that would be slow.
2022-04-25 11:37:40 <KipIngram   > On the other hand, for input I do it the traditional way - KEY is the fundamental thing, and EXPECT calls it.
2022-04-25 11:38:38 <KipIngram   > In Linux the standard read setup doesn't give you control back until user hits enter, so you can't do in "Forthy" handling of things.  I put my stdin in raw mode and handle all of the details from Forth in EXPECT.
2022-04-25 11:39:26 <KipIngram   > (you use iocotl syscall to do that)
2022-04-25 11:40:10 <KipIngram   > I've been scratching my head over I/O for a while, though - somehow someway I want to be able to do "piping tricks" like Linux does, but I haven't even really gotten a clear picture of what that "means" in Forth.
2022-04-25 11:43:32 <KipIngram   > Up until now I've made KEY blocking, but I'm about to change that.  It's what I'm currently looking at.
2022-04-25 12:35:32 <crc[dev]    > I've only toyed with a non-blocking KEY equivalent a little. It's something I want to experiment with more in the future, but it's not something I actually need
2022-04-25 12:59:15 <KipIngram   > I want to be able to deploy background workers that get to run while the foreground is waiting for me to hit a key.
2022-04-25 13:03:15 <KipIngram   > Cooperatively at first.
2022-04-25 13:03:33 <KipIngram   > But the very first step will just be to have KEY sleep in between polls until something is available.
2022-04-25 22:00:22 <KipIngram   > Added a sleep word tonight.
2022-04-25 22:00:35 <KipIngram   > I'll need that for the keyboard stuff.
2022-04-25 22:01:54 <KipIngram   > I thought about two separate one-parameter words, for < 1 second and > 1 second, but I wound up deciding on a single two-argument word.  That's how the syscall is set up anyway.
2022-04-25 22:02:39 <KipIngram   > : sleep  ( ns sec --) ... ;
2022-04-25 22:03:14 <KipIngram   > I had to admire their gumtion, letting you specify the fractional part in nanoseconds.  :-)
2022-04-25 22:03:40 <KipIngram   > gumption