00:00:00 --- log: started forth/18.12.25
00:15:11 <proteusguy> :-)
00:20:22 <ttmrichter> I can picture creative use of stack manipulations to spell out MERRYXMAS when unravelled.
00:52:15 <siraben> added a GIF demostration to my Forth-based OS
00:52:17 <siraben> https://github.com/siraben/zkeme80
01:51:20 --- quit: gravicappa (Ping timeout: 246 seconds)
02:02:55 --- quit: ashirase (Ping timeout: 245 seconds)
02:03:54 <WilhelmVonWeiner> john_cephalopoda: thousands of units of data
02:17:33 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
03:40:27 --- quit: pierpal (Quit: Poof)
03:40:48 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
03:43:09 --- quit: pierpal (Read error: Connection reset by peer)
03:46:34 --- quit: proteusguy (Remote host closed the connection)
03:48:42 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
03:52:47 --- quit: pierpal (Ping timeout: 246 seconds)
04:01:38 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
04:08:36 --- quit: pierpal (Ping timeout: 244 seconds)
04:16:36 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
04:45:06 --- quit: DKordic (Quit: ERC Version 5.3 (IRC client for Emacs))
05:01:34 --- quit: pierpal (Ping timeout: 268 seconds)
05:10:01 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
05:22:38 --- join: the_cuckoo (~charlie@d51A50AE9.access.telenet.be) joined #forth
05:26:00 <the_cuckoo> in case anyone is interested, i've knocked up a forth-like intepreter in bash - https://gitlab.com/lilo_booter/bts - small demo of use here: https://asciinema.org/a/bgQkXAW21nR2cs5to9sfKYP2T - this serves as a prototype for another implementation for me (so i probably won't take it much further)
05:26:48 <the_cuckoo> thought it was kinda funny though :) 
05:45:34 <john_cephalopoda> FUCK YEAH!
05:45:39 <john_cephalopoda> Um, right.
05:45:51 <john_cephalopoda> I just got a multiboot header working.
05:47:30 --- join: dddddd_ (~dddddd@unaffiliated/dddddd) joined #forth
05:48:45 --- quit: pierpal (Read error: Connection reset by peer)
05:53:35 --- nick: dddddd_ -> dddddd
05:56:42 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
05:58:03 --- quit: pierpal (Read error: Connection reset by peer)
06:00:58 <jn__> john_cephalopoda: nice!
06:08:16 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
06:18:39 --- quit: pierpal (Ping timeout: 268 seconds)
06:29:43 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
06:47:29 --- join: Kumool (~Khwerz@adsl-64-237-235-60.prtc.net) joined #forth
07:15:02 --- join: proteusguy (~proteus-g@cm-58-10-209-107.revip7.asianet.co.th) joined #forth
07:15:03 --- mode: ChanServ set +v proteusguy
08:09:01 --- quit: dys (Ping timeout: 250 seconds)
08:31:29 --- quit: dave0 (Quit: dave's not here)
08:51:55 <FatalNIX> proteusguy: what do you mean christmas?
08:51:58 <FatalNIX> what christmas
08:52:07 <FatalNIX> I've been working since saturday
08:58:13 <pointfree> I'm going to need some of these *analog* memory chips http://www.kowatec.com/prod/ap/doc/apr6016-v13.pdf
09:01:33 --- quit: pierpal (Ping timeout: 244 seconds)
09:02:49 <pointfree> afaik Zarutian likes funky memory chips ^
09:03:46 <Zarutian> pointfree: naah, just those that act like sram but are still non-volatile
09:06:32 <jn__> battery-backed SRAM? ;)
09:06:38 <pointfree> I wish these analog memory chips were non-volatile. The use of floating gate pFET's (flash memory) makes me think they may have limited write endurance.
09:06:41 <pointfree> jn__: mram
09:07:02 <Zarutian> jn__: nope tritium+solar_cell power backed SRAM
09:07:10 * PoppaVic facepalms...
09:07:28 <jn__> ah, MRAM is interesting
09:07:44 <pointfree> flywheel-backed SRAM
09:08:17 <PoppaVic> yer surrounded and bombarded with RF from every direction: make it pay ;-P
09:08:55 <PoppaVic> I should have said EMF, but whatever ;-)
09:17:15 <john_cephalopoda> I once used FRAM.
09:21:13 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
09:21:24 <PoppaVic> F-ram looks quite useful
09:29:55 --- quit: pierpal (Read error: Connection reset by peer)
09:30:11 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
09:48:39 <pointfree> *not non-volatile
09:53:35 --- quit: pierpal (Quit: Poof)
09:53:56 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
10:08:37 <tabemann> hey guys
10:17:32 <pointfree> Apparently at least mlterm supports 256 color registers. I piped img2sixel of a colorful animated gif to a hexdump tool.
10:18:31 <tabemann> I also hear that xterm when compiled with a certain option supports 256 color registers.
10:18:43 <tabemann> whereas I coded my sixel.fs to dither to 16 colors
10:18:57 <tabemann> because that's what stock xterm supports
10:20:27 <tabemann> unfortunately sixel.fs is too slow, even after a number of optimizations - soeeding it up may require a rewrite of attoforth to be native-code compiling
10:22:02 <PoppaVic> might as well just write yer own xwindow emulator
10:23:17 <pointfree> http://excamera.com/sphinx/termdriver/index.html
10:24:54 <PoppaVic> pointfree: amusingly, that just takes you back 20 years ;-)
10:25:59 <PoppaVic> actually, vga is prolly more like.. 30? I forget.
10:26:06 <pointfree> In some ways that's a good thing.
10:26:36 <PoppaVic> very few, by now.
10:28:45 <tabemann> it's been a while since I've had a monitor that matched VGA pixel dimensions
10:29:13 <PoppaVic> heh.. been awhile since I had a tube-monitor at all.
10:29:22 <tabemann> same here
10:30:17 <PoppaVic> Volume-wise, I swear it always ended up more massive than the nearby tower.
10:30:18 <tabemann> I'd've rather'd this've supported something like DVI or HDMI
10:30:43 <tabemann> those tube-monitors were heavy as fuck
10:31:11 <PoppaVic> HDMI sorta' bugs me.. Like on the pi.. How the hell come there is no shield-or-chip-or-board to "Just add another hdmi display"?
10:31:14 <pointfree> vga is simple and easy to implement. It also works well.
10:31:31 <pointfree> Hdmi is super complicated.
10:32:14 <PoppaVic> Yes, I figure it's way overkill for TV or display.
10:32:47 <john_cephalopoda> Also HDMI is pretty proprietary.
10:33:12 <tabemann> how does DVI compare?
10:33:17 <pointfree> vga can be trivially bitbanged like a uart can be.
10:33:29 <PoppaVic> pointfree: my own need would be for a small 7" display to cover an access-panel, interfacing to a pi and drives for music, input, or output to an HDMI display, so.. I get frustrated ;-)
10:47:15 <Zarutian> I have looked into HDMI. It isnt that complex, just pain in the arse to implement.
10:47:48 <tabemann> the main thing is it has (albeit optional) DRM baked in
10:48:16 <tabemann> the only thing is if you don't include the DRM things that expect the DRM won't talk to you
10:48:30 <Zarutian> so HDMI comes out of DVI, meaning there are three colour channels that need very accurite pixel clocks to transfer.
10:48:45 <Zarutian> then it is also twisted pair diffrential signalling
10:49:38 <Zarutian> tabemann: did you see that CCC talk about that device that adds an overlay to a 'DRM'ed HDMI signal?
10:49:52 <tabemann> no I didn't
10:52:48 <Zarutian> tabemann: completely open source and legimate. Besides I think you can get scrubbers that pretend to be a compliant monitor but just decrypts the HDMI signal and forwards it out.
10:54:37 <Zarutian> so, I havent seen any HDMI framebuffer devices, but then again I havent been looking.
11:08:55 * tabemann is happy that now with search paths he can run attoforth from anywhere on the system rather than just from the installation directory
12:19:43 --- join: DKordic (~user@178-221-182-126.dynamic.isp.telekom.rs) joined #forth
12:20:04 <tabemann> hey
12:23:31 <WilhelmVonWeiner> hey tabemann what's up
12:23:59 <DKordic> Greetings tabemann.  
13:18:55 <tabemann> back
13:19:16 <tabemann> next thing up - make attoforth detect whether it's connected to a terminal or not
13:23:03 <PoppaVic> isatty()
13:23:45 <tabemann> yeah, just gotta make an API for that, and write code so that it doesn't do any special terminal handling if isatty() doesn't indicate that it is a terminal
13:24:22 <PoppaVic> I remember when I learned about that stupid func... I headslapped, facepalmed, moaned - and got the code working in moments.
13:25:20 <PoppaVic> (I knew it had to be something stupid, but I had one hell of a time running down docs.. and old unix-teacher coughed it up)
13:25:25 <PoppaVic> and/an
13:33:00 --- join: X-Scale (~ARM@91.192.137.78.rev.vodafone.pt) joined #forth
13:39:34 <tabemann> hey
15:32:48 <the_cuckoo> ok - if this is the syntax, which commands should i add? :)
15:33:27 <PoppaVic> huh?
15:33:35 <the_cuckoo> bts.def 'dup' 0 pick
15:33:36 <the_cuckoo> bts.def 'swap' 1 roll
15:33:49 <the_cuckoo> sorry - not used to chat client :)
15:34:10 <PoppaVic> I have no idea what you think you are doing.
15:34:45 <the_cuckoo> well, i'm looking for words to add to my grammar :)
15:35:01 <PoppaVic> You mean a vocabulary?
15:35:17 <PoppaVic> You only ADD what you need 
15:35:26 <the_cuckoo> i have a few, figured i was missing some - was looking for suggestions :)
15:35:55 <PoppaVic> well, there is always "kitchen-sink" - that one seems popular.
15:35:58 <the_cuckoo> no worries - will add the ones i remember :)
15:36:07 <the_cuckoo> heh
15:36:20 <the_cuckoo> they have utility :)
15:36:42 <PoppaVic> Not usually in a cellphone, laptop, or pocket-knife.
15:40:25 <the_cuckoo> well, the kitchen sink can exist outside the phone, laptop or knife - i don't think it's so bad that the phone or laptop would control the sink... i'd probably wonder about the need for the knife
15:41:19 <PoppaVic> if the "kitchen-sink" is in the voc, it's akin to folding it into the knife, or cell, etc.
15:46:19 <the_cuckoo> hmm - well, oddly... i think of push as the kitchen-sink :) - ymmv
16:08:53 <tabemann> hey guys again
16:10:20 <tabemann> I feel like I've made a dirty hack
16:11:05 <tabemann> I was having some problems were attoforth was exiting before the IO manager completed writing their outputs
16:11:15 <tabemann> *the tasks'
16:11:55 <tabemann> so, it turned out that the simplest solution was to write a task that loops until only 1 task is left (itself) and no writes are pending
16:12:05 <tabemann> once no tasks are running, attoforth exits
16:12:59 <tabemann> note that this task also does the same thing in an atexit handler, so if you execute BYE, which triggers all tasks' atexit handlers before killing them, it still has the same effect
16:13:40 <tabemann> the part that I don't like is that it is essentially a spinwait with a sleep added, where it checks every 100 ms
16:16:54 <PoppaVic> you don't have an event-loop? Post <delete-me> events
16:20:16 <PoppaVic> I should have said loop/queue - since the outer-loop is always waiting anyway. (humans are slow as hell)
16:20:48 <PoppaVic> Odd how our eyes - and ears - are so much "faster".
16:21:03 <tabemann> there's an event loop in the IO manager, but for implementation reasons it is pretty slow
16:21:15 <tabemann> because it goes through a poll() loop
16:21:43 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
16:21:48 <PoppaVic> ugh, not what I'd meant
16:22:32 <tabemann> you are asking whether I have a central event loop where I can listen for system events and such
16:22:53 <PoppaVic> yeah, somewhere there is always one - usually it's the KEY? thing
16:23:17 <tabemann> KEY? uses a blocking read to wait for user input
16:23:43 <PoppaVic> well, that's not a KEY? then..
16:23:45 <tabemann> not a real blocking read - it doesn't block the other tasks - but one implemented with the IO manager and poll()
16:23:46 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:23:50 <PoppaVic> ah
16:23:52 <tabemann> wait wait wait
16:23:59 <tabemann> it's nonblocking
16:24:04 <tabemann> I got confused
16:24:06 <tabemann> KEY is blocking
16:24:33 <PoppaVic> OK, so - while it's not-blocking, let it peek at a little ring-buff or something for events to service - like killing tasks.
16:26:05 <tabemann> the thing is that even if I integrated it into the terminal handler, the terminal handler is not necessarily running
16:26:31 <tabemann> e.g. when executing scripts while KEY?, KEY, or ACCEPT are not in use
16:27:05 <PoppaVic> All I can tell you is: when you are running, with tasks, you need something like the event-queue to speak to a master thread.
16:30:47 <PoppaVic> I've also pondered the idea of event-conditionals for tasks/threads/coprocesses - just not gone anywhere with it
17:59:58 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
18:00:54 <dave0> re
18:26:00 <tabemann> back
18:26:51 <tabemann> the problem with the event loop approach is I'd need events from the IO manager, and an event for every IO write that completes, regardless of whether it is blocking or not, would significantly hurt erformance
18:26:59 <dave0> hi tabemann 
18:27:37 <tabemann> so I'd be back to polling being the best strategy (100 ms is far enough apart to have little impact but close enough together to not have much noticeable impact for the user)
18:27:40 <tabemann> hey dave0 
22:12:50 --- quit: Kumool (Quit: WeeChat 2.3)
22:17:05 --- quit: pierpal (Quit: Poof)
22:17:23 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
23:59:59 --- log: ended forth/18.12.25