00:00:00 --- log: started forth/19.04.21
00:10:28 --- join: dys (~dys@tmo-101-89.customers.d1-online.com) joined #forth
01:08:47 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth
01:09:09 <dave0> hi
01:11:55 <rdrop-exit> Hi dave0
01:12:20 <dave0> hi rdrop-exit 
02:02:55 --- quit: ashirase (Ping timeout: 245 seconds)
02:06:58 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
03:05:16 <WilhelmVonWeiner> hallo all
03:07:51 <rdrop-exit> Hi Wilhelm Von W
03:08:17 <WilhelmVonWeiner> what are you lot up to this fine easter sundat
03:09:01 <rdrop-exit> Surfing while I wait for dinner guests
03:09:45 <rdrop-exit> Yourself?
03:10:26 <WilhelmVonWeiner> looking for any obvious changes I can make in the trees code I kanged off siraben
03:11:14 <rdrop-exit> Cool
03:12:14 <WilhelmVonWeiner> made some simple changes to avoid a lot of abstraction - cases, mutual recursion (forward declarations), enums, BEGIN-STRUCTURE
03:12:29 <siraben> WilhelmVonWeiner I like how you removed those
03:14:20 <WilhelmVonWeiner> i conjectured to myself "if you're not adding a new tree, you're inserting - so just make it recurse"
03:14:26 <WilhelmVonWeiner> appeared to work
03:14:42 <siraben> I should try AVL trees next
03:14:48 <siraben> The rotates are a little hard to do
03:14:56 <siraben> Not hard but tedious*
03:15:19 <WilhelmVonWeiner> no idea what an AVL tree is - will look into it
03:17:22 <siraben> Basically a binary tree but as you insert you make sure it stays balanced
03:17:43 <siraben> Which means you still get O(log n) search, delete, insert
03:18:04 <siraben> It's quite a minor modification, you only need one extra field in each node
03:22:13 --- quit: jedb (Ping timeout: 246 seconds)
03:23:30 <WilhelmVonWeiner> sounds like it could be fun
03:23:38 <rdrop-exit> There are so many data structures to chose from, each with its own set of tradeoffs
03:24:05 <WilhelmVonWeiner> my time is dedicated to learning SIP and working through SICP at the moment so "fun" is limited
03:24:27 <siraben> What's SIP?
03:24:37 <siraben> SICP is really great stuff
03:26:08 <rdrop-exit> I read SICP a long time ago, still have it somewhere. I wasn't all that impressed by it, especially given its reputation.
03:26:12 <siraben> I've been watching MIT's algorithms lectures series; 6.006, 6.046. I enjoy it immensely
03:26:34 <siraben> SICP's best selling point is the interpreter and compiler stuff I guess
03:26:56 <siraben> The algorithms are pretty straightforward (linked lists essentially)
03:27:53 <rdrop-exit> I think prior Forth exposure took away much of its thunder for me.
03:46:09 <WilhelmVonWeiner> SIP is the session inititation protocol.
04:09:18 <siraben> Has anyone read Thinking Forth in full? Is it worthwhile?
04:13:23 <rdrop-exit> Very worthwhile, just ignore the preface in the reprint about OOP
04:14:56 --- join: jedb (~jedb@103.254.153.113) joined #forth
05:25:12 <WilhelmVonWeiner> I need a physical copy of that before I dive into reading it properly
05:32:05 <rdrop-exit> FIG did a physical reprint with a different cover and an extra preface.
05:32:43 <WilhelmVonWeiner> I shall pick one up soon
05:32:57 <WilhelmVonWeiner> just, I've frozen my book purchases - it's embarassing how much I need to read
05:33:04 <rdrop-exit> http://thinking-forth.sourceforge.net
05:34:25 <rdrop-exit> Apparently there's a rewrite project and the original at the above site.
05:35:01 <WilhelmVonWeiner> the pdf is on my computer but reading in this stupid office chair sucks goaty balls
05:36:03 <rdrop-exit> I have two versions of the physical book on my bookshelf
05:37:43 <rdrop-exit> It's a good book to help grok the Forth mindset
05:47:48 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
06:14:58 <rdrop-exit> "Generality usually involves complexity. Don't generalize your solution any more than will be required; instead, keep it changeable."
06:28:51 <siraben> Is it applicable outside of Forth as well?
06:29:38 <rdrop-exit> Yes, absolutely in my opinion.
06:34:51 <rdrop-exit> "Anticipate things-that-may-change by organizing information, not by adding complexity. Add complexity only as necessary to make the current iteration work."
06:40:47 <john_cephalopoda> Hmm, Wirth released an article called "A plea for lean software" a long time ago.
06:40:57 <john_cephalopoda> https://cr.yp.to/bib/1995/wirth.pdf
06:40:59 <john_cephalopoda> Woth reading.
06:41:03 <john_cephalopoda> Worth*
06:42:24 <rdrop-exit> I've read it, good stuff.
06:42:25 <`presiden> Wirth
06:43:38 <rdrop-exit> Although I disagree with Wirth's perspective on many things, lean software is not one.
06:46:15 <rdrop-exit> The first version of Project Oberon was very impressive given the short time and few resources involved.
06:48:48 <rdrop-exit> Wirth's article was published much later than Thinking Forth.
06:49:10 <rdrop-exit> Let's see
06:49:29 <rdrop-exit> 1995 vs 1984
06:50:01 <john_cephalopoda> Yeah, but is there a graphial OS written in Forth?
06:52:03 <rdrop-exit> What's the relevance?
06:55:48 <john_cephalopoda> rdrop-exit: Well, Forth is perfect for writing lean software, but it is fragmented and not commonly used to write general software.
06:58:58 <rdrop-exit> Personally I'm not that interested in "general software".
06:59:31 <rdrop-exit> But I have found the Forth mindset useful even in projects that had nothing to do with Forth.
07:07:26 <rdrop-exit> All you really need for "general software" is a C interface.
07:08:19 <john_cephalopoda> Forth can access files, which makes it useful for nearly all UNIX things.
07:10:36 <rdrop-exit> C interface is what you want if leveraging UNIX is your priority.
07:11:04 <john_cephalopoda> You can write OS in Forth and you could write an emulator of the OS in C or similar, with SDL for graphics.
07:11:11 <WilhelmVonWeiner> SDL?
07:11:26 <siraben> john_cephalopoda:  I'm working on a Forth-based OS
07:11:31 <WilhelmVonWeiner> If you're writing a Forth OS you'd write your own graphics stack surely
07:11:46 <WilhelmVonWeiner> might be a PITA but will be satisfying after n years
07:11:54 <siraben> Albeit need to read up on OS design and so on so it's a little stalled right now
07:12:03 <siraben> WilhelmVonWeiner:  most of my graphics routines are in assembly
07:12:13 <WilhelmVonWeiner> I wish I knew any assembler for anything
07:12:40 <WilhelmVonWeiner> should've learned some in university :^)))))
07:12:40 <siraben> https://github.com/siraben/zkeme80/blob/master/src/display.scm
07:12:54 <john_cephalopoda> I am doing OS stuff right now. Text mode is trivial.
07:13:13 --- quit: X-Scale (Ping timeout: 246 seconds)
07:13:23 <rdrop-exit> Writing a full-blown OS in Forth kinda defeats the purpose.
07:13:26 <siraben> WilhelmVonWeiner:  never too late to learn!
07:13:40 <WilhelmVonWeiner> no, of course not - just have a lot of stuff to learn is all
07:13:45 <john_cephalopoda> rdrop-exit: It would probably still be smaller and more efficient than an OS written in C.
07:14:06 <siraben> I like Z80 assembly, although it's terribly minimal in places
07:14:31 <WilhelmVonWeiner> rdrop-exit: forthify the definition of OS - Forth is your OS, a base plate for your applications
07:14:35 <siraben> john_cephalopoda:  Hm. I would agree with smaller, but probably not more efficient
07:14:39 <WilhelmVonWeiner> TCP/IP? It's an application
07:15:14 <WilhelmVonWeiner> just load yer blocks 
07:15:36 <WilhelmVonWeiner> the way poppavic says "yer" always made me chuckle so now I use it a lot
07:17:26 <rdrop-exit> Yes, Forth is your "OS" on bare-metal, you don't write an OS in Forth.
07:17:38 <john_cephalopoda> You just do "CONNECTION1 BUFFER 33 TCP-SEND", which will use CONNECTION1 to send 33 byte of BUFFER via TCP.
07:18:04 <john_cephalopoda> rdrop-exit: It would be more like a unikernel.
07:19:02 <WilhelmVonWeiner> Not sure how I'd implement it tbh
07:19:04 <rdrop-exit> I'd avoid the OS and just use a Rump Kernel.
07:20:25 <WilhelmVonWeiner> rump kernel(s)?
07:20:52 <rdrop-exit> Allows you to use existing device drivers on bare metal.
07:21:19 <rdrop-exit> https://en.wikipedia.org/wiki/Rump_kernel
07:21:25 <WilhelmVonWeiner> I meant, I assume you'd use a couple for your various drivers
07:23:11 <rdrop-exit> With a rump kernel you can reuse the device drivers from NetBSD with your bare-metal app, without using the rest of NetBSD.
07:23:28 <john_cephalopoda> rdrop-exit: But where's the fun in it? ;p
07:25:01 <rdrop-exit> I want the banana (device drivers) not the gorilla (OS)
07:26:02 <john_cephalopoda> If I wanted things to work and to make sense, I'd just use Linux.
07:26:31 --- join: X-Scale (~ARM@83.223.226.32) joined #forth
07:26:57 <rdrop-exit> For a commercial project on big iron I'd go with a BSD.
07:27:34 <john_cephalopoda> Haven't got much experience with BSD. Tried to put it onto my RasPi but it didn't really work out.
07:27:34 <`presiden> I always wanna learn about how graphical os draws graphic to the screen.
07:28:39 <WilhelmVonWeiner> I would use OpenBSD for anything real big, even if people call it slow
07:28:43 <john_cephalopoda> `presiden: It's not too hard. 2D graphics are easy.
07:28:46 <`presiden> learn as in to understand the low level details
07:28:59 <john_cephalopoda> When you want 3D acceleration, graphics get messy.
07:29:07 <WilhelmVonWeiner> well, I'd actually use AWS Lambda or Elastic
07:29:50 <rdrop-exit> Graphics hardware does most of what used to be done in software.
07:30:05 <john_cephalopoda> I don't trust Amazon. I think it is best to run services on your own hardware. That way you can control what happens to your data.
07:31:24 <WilhelmVonWeiner> I don't trust them, I trust their pricing, uptime and speed
07:32:49 <john_cephalopoda> The trend to host more and more of our stuff on the servers of a few big corporations can't be good.
07:34:08 <rdrop-exit> It's good if you're offering a Software-as-a-Service application and want access to their customers.
07:34:29 <WilhelmVonWeiner> PaaS is great for businesses honestly
07:34:46 <WilhelmVonWeiner> erases entire departments of people when used properlu
07:36:17 <rdrop-exit> That's the direction "general software" is going in.
07:38:45 --- quit: gravicappa (Ping timeout: 245 seconds)
07:39:05 <john_cephalopoda> Well, if you got sensitive information and AWS does something bad, then all of your departments are erased.
07:39:06 --- join: gravicappa (~gravicapp@h109-187-221-4.dyn.bashtel.ru) joined #forth
07:41:00 <rdrop-exit> If the alternative is orders of magnitude more expensive than you take the risk.
07:43:54 <rdrop-exit> Cheap and convenient wins.
07:43:56 <john_cephalopoda> I can use a raspi to serve my website.
07:44:35 <john_cephalopoda> The site is a few kb, so it even works with little bandwidth.
07:44:45 <rdrop-exit> url?
07:45:03 <john_cephalopoda> https://thecutecuttlefish.org/
07:45:54 <john_cephalopoda> It has no JS because that's simply not needed. No weird google tracker stuff because that's also useless. Analytics generally don't help much.
07:46:03 <rdrop-exit> Würzburg, cool.
07:46:07 <john_cephalopoda> Yup
07:48:50 <rdrop-exit> I haven't been to Germany in years, used to go to Munich for Oktoberfest every year.
07:49:04 <john_cephalopoda> Heh. I've never been at the Oktoberfest before.
07:49:17 <rdrop-exit> Good times
07:49:23 <john_cephalopoda> Not really my scene.
07:49:45 <`presiden> nice cuttlefish
07:51:43 <john_cephalopoda> Heh, thanks :D
07:54:04 <`presiden> I love cuttlefish
07:54:05 <`presiden> as food
07:54:23 <rdrop-exit> I had a reseller in Munich, used to schedule my visits to coincide.
08:01:57 <john_cephalopoda> `presiden: I like the tentacles but cuttlefish ones are just too short. Squids are better in that regard.
08:15:24 <rdrop-exit> Goodnight all :)
08:15:35 --- quit: rdrop-exit (Quit: Lost terminal)
08:17:07 <pointfree> https://github.com/saitoha/libsixel#improved-compression
08:48:03 --- join: DabsR (~Mutter@50.234.173.34) joined #forth
08:51:47 --- quit: DabsR (Client Quit)
08:59:26 --- join: DabsR (~Mutter@50.234.173.34) joined #forth
09:02:32 --- quit: DabsR (Client Quit)
09:12:47 --- quit: dave0 (Quit: dave's not here)
11:12:19 <tabemann> back
11:12:23 <tabemann> hey guys
11:14:12 <tabemann> I got sixels working properly, with faster rendering than my old dithering sixel code
11:15:38 <john_cephalopoda> Nice. Any demo?
11:16:29 <tabemann> https://github.com/tabemann/hashforth/blob/master/examples/sixel_example.fs
11:17:37 <tabemann> that uses a 2 x 2 x 2 palette, draws a 512 x 512 square which it divides up by 2 levels of red ( 0, 1 ) and 2 levels of green ( 0, 1 )
11:17:55 <tabemann> and then animates with one frame drawn with 0 blue and another frame drawn with 1 blue
11:18:19 <tabemann> it is slow, but it's faster than my old sixel rendering code
11:18:45 <tabemann> (it is slow mostly because hashforth is slow)
11:18:49 --- quit: gravicappa (Ping timeout: 255 seconds)
11:19:17 <tabemann> but it is faster because it doesn't try to do complex dithering stuff
11:20:30 <tabemann> also, one can update parts of frames without updating the entire framebuffer, because it doesn't try to convert pixels into sixel data for every frame, but rather converts it when the user writes into the buffer
11:24:27 <tabemann> you should be able to run this after downloading sixel.fs and sixel_example.fs on ANS Forth as long as you define : NOT INVERT ;
11:26:22 <tabemann> sixel.fs is at:
11:27:03 <tabemann> https://github.com/tabemann/hashforth/blob/master/src/hashforth/sixel.fs
11:44:00 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
11:47:59 <tabemann> back
11:48:16 <tabemann> oh, btw, if you've downloaded the code, download it again
11:51:00 <john_cephalopoda> How exactly do I compile attoforth?
11:51:35 <john_cephalopoda> I get "Token type of image does not match configuration!"
11:57:25 <tabemann> don't use attoforth
11:57:35 <WilhelmVonWeiner> just set up a lovely new computer
11:57:49 <WilhelmVonWeiner> called a "zbox nano"... it's basically silent
11:58:33 <tabemann> attoforth is my old overdesigned ITC forth
11:58:52 <tabemann> hashforth is my newer forth that I've put most of my work into
11:59:02 <tabemann> as of late
11:59:54 <WilhelmVonWeiner> #forth innit
11:59:58 <tabemann> execute
12:00:37 <tabemann> make CFLAGS="-DCELL_64 -DTOkeN_16_32"
12:00:43 <tabemann> whoopd
12:00:47 <tabemann> make CFLAGS="-DCELL_64 -DTOkEN_16_32"
12:01:35 <john_cephalopoda> [john@hilbert hashforth]$ ./hashforth images/cell_64_token_16_32.image
12:01:37 <john_cephalopoda> Token type of image does not match configuration!
12:02:41 <tabemann> odd
12:02:50 <tabemann> what is the exact command you used to build it
12:06:24 <tabemann> just using "make" won't build the right executable, because I set bad defaults for it
12:06:40 <tabemann> well, defaults different from the image that comes packaged with hashforth
12:17:52 <tabemann> okay, updated Makefile to set it to match the provided image
12:18:19 <john_cephalopoda> I like it.
12:18:35 <john_cephalopoda> Nice-looking sixel stuff.
12:22:44 <tabemann> if you're using mlterm there's another .fs file that does the same but in 64 colors
12:23:39 <tabemann> examples/sixel_example_more_color.fs
12:23:50 --- quit: Zarutian_2 (Read error: Connection reset by peer)
12:23:59 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
12:24:08 <tabemann> hey Zarutian
12:26:57 <john_cephalopoda> tabemann: Yup, tried that one out, too.
12:28:02 <tabemann> as you see, the sixel rendering is slow, but not horrendously slow - it'd probably be faster if I wasn't re-rendering the whole frame each time
12:29:02 <tabemann> it'd probably work better with some sort of sprite graphics
12:29:19 <john_cephalopoda> I did some sixel rendering before.
12:29:57 <john_cephalopoda> I used a frame buffer and then just read it out and shoved it onto the screen in sixel format.
12:30:07 <john_cephalopoda> Worked ok. Was just b/w though.
12:30:10 <tabemann> that's what I'm doing
12:30:33 <tabemann> except what I'm doing supports a palette
12:31:31 <john_cephalopoda> Heh, that would be perfect for making gameboy-style games in forth.
12:31:47 <tabemann> previously I tried doing truecolor dithered down to a palette, and it was horrifically slow
12:32:03 <tabemann> especially since I was doing my conversion for the whole frame at a time
12:32:38 <john_cephalopoda> Yeah.
12:33:18 <john_cephalopoda> Have you got a scaling factor for sixels? One pixel is sometimes a little small if you want to display pixel-art stuff.
12:33:39 <john_cephalopoda> Hrm, wish I had my sixel stuff on the computer...
12:34:09 <tabemann> no, I don't have a scaling factor for this
12:34:53 <Zarutian> regarding framebuffers and such. One trick I came across is to have the main 'framebuffer' to be pointers to pixels. That is one 'pixel' in the frame buffer points to the __rrggbb colour cell of that pixel.
12:35:56 <john_cephalopoda> Is it worth it?
12:36:19 <john_cephalopoda> That is one level of indirection, when you could just allocate a big area and use it.
12:37:00 <tabemann> how I did my framebuffer for sixel.fs was to write out the bits for the pixels at pixel-write time, and then just write() out all the bits to standard output at draw time
12:37:03 <john_cephalopoda> Might be useful when you got multiple clients that can draw to the screen though...
12:37:13 <Zarutian> yeah, I was puzzled at first why
12:38:03 <john_cephalopoda> 12 applications, each with its own framebuffer, then one screen-sized framebuffer with pointers to the application framebuffers... Sounds pretty solid.
12:38:35 <john_cephalopoda> You could even mirror the application output or display it side-by-side... Or even more crazy stuff.
12:38:40 <Zarutian> john_cephalopoda: yebb, pretty easy to do the windowing cliping.
12:39:01 <john_cephalopoda> Woah, that's pretty neat!
12:39:35 <Zarutian> john_cephalopoda: and as bonus, it also allows for simple paletting for the screen framebuffer.
12:40:40 <john_cephalopoda> Oooh, now I feel like continuing with my Forth OS.
12:41:07 <Zarutian> that is, stuff like titlebars, window framing and such.
12:43:31 <john_cephalopoda> I'll have to find out how to do the compiling loop. It seems a bit complex.
12:44:38 <tabemann> what I'm thinking of doing for hashforth is have tokens written out to user space, and then when ; is reached, convert the code into SRT-NCI code
12:45:19 <tabemann> so the main part of compilation is really simple, and the part that converts the code into native code is self-contained
12:45:51 <john_cephalopoda> Hah, compiling into native code is pretty simple.
12:46:18 <john_cephalopoda> You just have to write the right instructions into memory.
12:46:28 <john_cephalopoda> https://github.com/jmf/impexus/blob/master/arch/x86/asm_x86.fth
12:48:30 <tabemann> when you're doing native code inlining and you're specifying instructions which you are modifying later after the fact?
12:49:46 <john_cephalopoda> Hmm, how do you mean?
12:50:50 <tabemann> when you are inlining words as native code, or when you are specifying a word such as BRANCH or 0BRANCH which you modify after the fact to specify a destination
12:55:13 <john_cephalopoda> When you are inlining words as native code.
13:00:15 <tabemann> TBH, inlining itself is not that complex
13:00:46 <tabemann> modifying instructions is a little more complex
13:07:41 <tabemann> from second thought, it doesn't seem that complex - what does seem a bit complex is making an implementation that combined both TTC and TTC-to-SRT/NCI conversion
13:08:00 <tabemann> *combines
13:41:50 --- quit: mtsd (Quit: leaving)
14:38:37 --- quit: dddddd (Ping timeout: 255 seconds)
14:47:50 --- quit: `presiden (Quit: WeeChat 2.4-dev)
14:52:10 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
14:58:07 <john_cephalopoda> https://bpaste.net/show/0875dbe7beee
14:58:30 <john_cephalopoda> Egg timer :þ
15:09:37 <tabemann> back
15:11:44 <tabemann> is it me, or is do/?do loop/+loop far less efficient than begin while repeat for counted loops?
15:12:18 <tabemann> like I tried measuring the difference with hashforth and it was much slower
16:11:07 --- quit: john_cephalopoda (Ping timeout: 258 seconds)
16:13:33 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth
16:13:51 <dave0> hi
16:24:20 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:26:49 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth
16:33:53 <siraben> tabemann: those loops usually use either the return stack or control flow stack
16:34:15 <siraben> In my Forth the register associated with the return stack is slower
16:34:40 <siraben> Whereas BEGIN WHILE REPEAT might not I guess
16:34:47 <siraben> Depends on how the person implemented it
16:43:39 --- quit: pierpal (Ping timeout: 268 seconds)
17:08:19 --- quit: tabemann (Ping timeout: 268 seconds)
17:35:38 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
18:00:54 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth
18:29:02 <crc> tabemann: I've not had either type in many years, but when I did the begin/while/repeat form was generally faster than the do/loop 
18:36:50 <tabemann> hey
18:44:29 --- quit: dave0 (Quit: dave's not here)
19:01:15 --- quit: proteusguy (Ping timeout: 245 seconds)
19:29:36 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth
19:35:43 <tabemann> hey
19:36:52 <rdrop-exit> Hi tabemann
19:38:25 * tabemann is busy writing sprite code that uses his sixel code
19:39:26 <rdrop-exit> cool
19:40:38 <tabemann> this should be able to have a higher framerate than just the drawing full-canvas gradients with the sixel code, because it's not actually generating the entire frame each frame
19:44:53 <tabemann> one thing I've found is I generally can do more with just three items on the data stack if I also make simultaneous use of the return stack
19:45:05 <tabemann> whereas I previously avoided using the return stack
19:45:52 <tabemann> like if there is a single pointer I have to use frequently throughout a word, I'll put it on the top of the return stack so I can frequently access it via R@
19:50:31 <rdrop-exit> An address or a pointer?
19:53:10 <tabemann> what's the difference? it's an address that points to a data structure
19:54:04 <rdrop-exit> A pointer is a variable that holds an address
19:54:18 <rdrop-exit> An address is just an address
19:54:23 <tabemann> well then an address
19:55:40 <tabemann> I need to go, though, coffee shop is closing - will be back later
19:55:54 <rdrop-exit> See ya
20:00:22 --- quit: tabemann (Ping timeout: 268 seconds)
20:09:33 --- join: gravicappa (~gravicapp@h109-187-221-4.dyn.bashtel.ru) joined #forth
20:17:13 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth
20:18:05 <dave0> re
20:23:31 --- join: tabemann (~tabemann@2600:1700:7990:24e0:5ca5:9a72:d11d:b497) joined #forth
21:03:21 <rdrop-exit> Hi dave0
21:03:33 <dave0> hi rdrop-exit 
21:09:24 <tabemann> hey
21:09:36 <rdrop-exit> hi tabemann
21:19:15 <rdrop-exit> I just re-read the Sixel Wikipedia page, fun stuff
21:27:40 <rdrop-exit> It seems like a delta mechanism would work if you need to speed it up, e.g. over a serial line
21:31:36 <ttmrichter> Sixels were a great concept.
21:32:29 <rdrop-exit> Looks like they used ReGIS underneath
21:33:13 <rdrop-exit> The loadable fonts are interesting too
21:56:31 --- quit: dave0 (Quit: dave's not here)
22:33:50 --- quit: pierpal (Ping timeout: 246 seconds)
22:37:16 <rdrop-exit> bbk
22:37:18 <rdrop-exit> bbl
22:45:20 --- quit: dddddd (Remote host closed the connection)
22:59:51 --- join: proteusguy (~proteusgu@mx-ll-14.207.101-217.dynamic.3bb.co.th) joined #forth
22:59:51 --- mode: ChanServ set +v proteusguy
23:59:59 --- log: ended forth/19.04.21