00:00:00 --- log: started forth/19.04.16 00:00:40 --- quit: Keshl (Ping timeout: 255 seconds) 00:07:56 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 00:10:40 hi guys - how goes it? 00:16:34 --- join: chunkypuffs (~chunkypuf@2a01:4f9:2b:16d5::1) joined #forth 00:33:35 --- quit: Keshl (Ping timeout: 252 seconds) 00:48:06 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 00:50:10 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 01:04:49 --- quit: pointfree (Ping timeout: 240 seconds) 01:05:52 --- join: mstevens_ (sid285816@gateway/web/irccloud.com/x-nacwkdaexodlvrsw) joined #forth 01:06:23 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-wiozeucxptzpwsqb) joined #forth 01:06:28 --- quit: mstevens (Ping timeout: 250 seconds) 01:06:28 --- nick: mstevens_ -> mstevens 01:28:32 --- quit: KipIngram (Read error: Connection reset by peer) 02:03:47 --- quit: ashirase (Ping timeout: 252 seconds) 02:07:26 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:14:59 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth 02:14:59 --- mode: ChanServ set +v KipIngram 02:28:45 --- join: Blue_flame (~u0_a111@2409:4042:2207:d199:d1d8:a2e3:9f06:75a4) joined #forth 02:35:29 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:17:12 --- quit: Blue_flame (Quit: Blue_flame) 04:42:32 --- quit: pierpal (Quit: Poof) 04:42:50 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 04:53:12 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-lpifihwcgdqrynpe) joined #forth 05:27:17 Hey the_cuckoo 05:54:00 --- quit: john_cephalopoda (Ping timeout: 268 seconds) 05:56:37 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 06:14:14 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-ykfqcgihmjcrtzuv) joined #forth 06:14:14 --- join: alexshpilkin (alexshpilk@gateway/shell/matrix.org/x-dehivhycwowupgon) joined #forth 06:14:14 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-axbuccrvnlpvnwpa) joined #forth 06:30:37 --- join: probablymoony (moony@hellomouse/dev/moony) joined #forth 06:31:28 --- quit: moony (Ping timeout: 252 seconds) 06:44:09 --- quit: nerfur (Ping timeout: 245 seconds) 06:49:33 --- join: nerfur (~nerfur@broadband-95-84-184-13.ip.moscow.rt.ru) joined #forth 07:06:06 --- quit: bb010g (Read error: Connection reset by peer) 07:06:26 --- quit: alexshpilkin (Write error: Connection reset by peer) 07:06:27 --- quit: jimt[m] (Read error: Connection reset by peer) 07:06:29 --- quit: siraben (Read error: Connection reset by peer) 07:08:32 --- quit: pierpal (Quit: Poof) 07:08:50 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 07:29:49 --- join: X-Scale (~ARM@83.223.226.53) joined #forth 07:31:30 hello all 07:31:50 I was thinking about unix pipes and Forth 07:31:55 --- quit: proteusguy (Ping timeout: 246 seconds) 07:32:08 --- quit: tabemann (Ping timeout: 250 seconds) 07:32:11 the concept is hard to apply to Forth 07:32:31 unless you can buffer *all* the output 07:36:06 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-jgcaiotpfunarrjv) joined #forth 07:40:28 WilhelmVonWeiner: You'd have to filter code, because data is code in forth http://www.0xff.in/bin/AndreasWagner-parse-time-execution.pdf#page=6 07:44:04 ...at least that's how I like it. 07:46:07 Forth words + the parameter stack assumes fixed arities, unixy pipes do not. 07:59:30 --- quit: ovf () 08:00:53 --- join: ovf (sid19068@gateway/web/irccloud.com/x-atyyesnlxgcglstk) joined #forth 08:03:54 The parse time execution thing ( non-literal word headers ) would perform better if I were to serialize the execution semantics... perhaps by capturing return stack contents. 08:13:43 WilhelmVonWeiner, what's hard about it? 08:15:01 --- quit: jhei () 08:15:19 --- join: jhei (sid81469@gateway/web/irccloud.com/x-vyguyyznvvrwcrmh) joined #forth 08:15:23 --- join: alexshpilkin (alexshpilk@gateway/shell/matrix.org/x-diigrrqboabuzqwx) joined #forth 08:15:23 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-pvaqtxxkxfeoptwr) joined #forth 08:15:23 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-gxvddwivowyblvze) joined #forth 08:51:52 I like this: https://mastodon.social/@SpindleyQ/101672717992252183 ...a lightweight generator/iterator. 08:52:41 Using : yield rswap ; 09:09:31 pointfree: nice! didn't know there was a person on mastodon who did forth 09:13:02 siraben: There happen to be a lot of forthers on mastodon if you find them https://mastodon.social/@mogwai_poet/100856339466627067 09:13:20 also, the #forth hashtag on mastodon 09:13:45 I'm https://x0r.be/@pointfree 09:25:51 * pointfree might just switch from a linux webhost to a forth unikernel https://nanovms.com/dev/tutorials/running-forth-unikernels 09:26:18 https://en.wikipedia.org/wiki/Unikernel <-- embedded and cloud software come full circle. 10:05:50 --- quit: pierpal (Ping timeout: 245 seconds) 10:06:57 Huh, the img files spat out by gforth can be booted? Neat! 10:10:26 pointfree: If there was a really good and secure Forth OS, I'd maybe use it on my server. But right now I don't really know of something, especially nothing that can do networking and has a set of proper applications. 10:11:34 And, how godawful would networking, a pipe, grepping, browsing, sed, etc, etc be? 10:23:24 john_cephalopod and pointfree: I am still trying to figgure out how to do object-capabilities on Forth. 10:24:00 * PoppaVic facepalms... 10:28:21 PoppaVic: depends. One might use the SIK/SOK KeyKOS convention to do stdin&out and use the UNIX philosophy of one program for one thing and let the command system parse something like a shell pipeline command and set that up. 10:29:46 ..and you thus obviate the advantages to forth and "parsing". 10:31:21 Create a POL for a protocol and defer KEY and EMIT to talk to it. 10:34:12 PoppaVic: well, what I have in mind is that a Forth would be the command system (think of it as a shell in UNIX term) 10:36:15 well, a Forth "shell" is no more than a forth-app, so - go wild. 10:51:51 pointfree: Can You please elaborate what do You mean by Unikernel? What is new about it?! 10:53:09 afair unikernel is an OS abstraction (like linux kernel) which may be used per process (as in each process has its own kernel) 10:53:50 and you just link into it whatever your process needs (networking? sure, it grows by 200KB - stuff like that) 10:56:26 I find a rump kernel more interesting, it gives a way to leverage device drivers in an OS-less manner. 10:56:36 https://en.wikipedia.org/wiki/Rump_kernel 10:56:56 --- quit: gravicappa (Ping timeout: 252 seconds) 10:56:59 I want the banana not the gorilla 10:58:06 What kind of application of Forth would it be if libs are not written in Forth?! 10:58:36 what makes you think this matters? We've had gforth for ages, and cforths before. 10:59:08 Mostly, the resistance to LIBS is predicated on shitty register-use, time spent saving and restoring, and CM's comments 11:01:02 the nanovms/ops documentation leaves me with plenty of questions. There's no mention of architecture, library calls, etc. It does say that "Nanos is capable of executing any valid ELF binary", but that's too vague to be useful. (I can't evaluate it further w/o spinning up a Linux VM, which I'm not inclined to do currently) 11:02:55 I never bothered to decide if ELF was stupid or not. I know a ton of folks write perfectly fine code, only to fight ELF - and that osX maco is worse. 11:03:00 machO 11:03:36 I'm more interested in access to existing device drivers than accessing libraries, a rump kernel is ideal for this. 11:04:28 rdrop-exit: same here 11:04:30 well, even DD's are an issue - I mean, wtf? You want closed-source DRIVERS for yer fucking devices? 11:04:53 Who said anything about closed-source? 11:05:14 rdrop-exit: plenty of drivers continue to be "blobs" 11:07:21 Sure, but the point is that the major disincentive to writing a bare-metal Forth for a PC or larger machine is drivers 11:07:57 At least with a rump kernel you can get access to drivers 11:08:21 You can always pick and choose which you want to reuse. 11:09:13 And you can focus your efforts on those few you really want to write from scratch. 11:11:03 If I were to write a bare-metal Forth for a "large" machine, my main concern would be drivers, don't care about libraries. 11:12:32 /win 3 11:13:46 I should try building a rump kernel variation of retro/native 11:14:01 Cool 11:23:03 I assume the main reason that Forth Inc. stopped doing bare-metal Forths for PCs was the driver situation. 11:28:07 that's a large part of why I stopped supporting retro on bare metal for many years 11:49:54 It's almost 3am, time to hit the sack. :) 11:50:03 --- quit: rdrop-exit (Quit: Lost terminal) 12:23:01 PoppaVic: Networking doesn't have to be awful. In fact there's probably no way it can get more awful than BSD/Winsocks 12:23:37 PoppaVic: For grepping, sed etc you could just use a regular shell. Just write the shell in forth. 12:27:19 As for drivers, as soon as you have established a "syscall" API, you can just put any driver behind it. You can run it on top of an OS or just on hardware with some random drivers inbetween. 12:27:43 For graphics on host OS, SDL could be used. 12:28:10 john_cephalopoda: I am not "writing a regular shell in forth" - not then or now. Don't be silly. 12:38:32 I am sure that with a bit of thinking one could find some new abstractions that make Forth work in all the required ways. 12:40:16 Give an output, or input, you can torture forth to "anything" - question is: why the hell would I bother? I got paid? I expect to get paid? you should pay me? 12:41:06 How about you get "happy" and write a nice Forth Shell for linux? That would port to osX fairly easy - and to BSD. Go wild. 12:44:56 PoppaVic: On Linux I use Bash. There is no need for a new shell. The only reason why one would want one is that one is trying to write an OS in plain Forth. 14:10:58 PoppaVic: Sam Falvo does not like ELF. He wrote two articles about why he does not like it, in case you want the details: 14:10:58 https://kestrelcomputer.github.io/kestrel/2018/01/29/on-elf https://kestrelcomputer.github.io/kestrel/2018/02/01/on-elf-2 14:48:16 TIL there are new #Mecrisp and #mecrisp-stellaris channels on freenode http://mecrisp.sourceforge.net/ 14:51:43 Most of the mecrisp and amforth discussion happened in the German `#forth-ev` channel which is inaccessible outside Germany. https://wiki.forth-ev.de/doku.php/infos:forthchatirc 15:05:20 --- quit: cheater (Ping timeout: 252 seconds) 15:05:57 --- quit: unused0 (Quit: Leaving) 15:06:11 --- join: unused0 (~cac@172.242.245.233) joined #forth 15:07:46 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 15:37:15 pointfree: re those elf posts: ASLR is pointless and irritating when it gets in your way. 15:38:55 --- quit: cheater (Ping timeout: 255 seconds) 15:41:38 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 15:56:48 Zarutian: Yes, a both pointless and irritating hotfix of sorts. 15:56:48 There are some good arguments for using a single address space and decoupling addressing from protection, capability-security. That sort of approach could be a good fit for forthy-style raw memory access + capability security. 15:56:48 http://wiki.c2.com/?SingleAddressSpaceOperatingSystem 15:56:48 I read a really nice paper on such a scheme years ago. Now I can't find the pdf. 16:02:33 it isnt like doing some sort of MMU or MBU is hard. 16:03:45 a bit about Memory Banking Unit: one design I saw even worked for untrusted binary executable programs. 16:05:13 the trick was that the control registers for which banks were selected in which bank-slots were in one of those banks 16:06:07 if an interrupt (or vector pull) happened then that bank got switched back in and ISR in it run. 16:07:15 one 'bank' in each bank-slot caused an vectored-interrupt when access to it was attempted 16:08:48 this scheme was targetting the Western Digital 68c816 chip which does not have a 'mode' bit for kernel/user mode 16:10:01 no huge hardware walked page tables or such. 16:17:27 --- quit: john_cephalopoda (Ping timeout: 268 seconds) 16:18:50 oh and few other banks contain the i/o registers. One i/o device that is handy for preemtive multitasking is a count down timer that interrupts when it reaches zero. 16:24:56 pointfree: hmm... in part two of the elf blog posts you linked to there is no mention of the dynamic loading way that inspired Mach-o file format. 16:27:50 in that case the executable binary is to most apearances an statically linked one. But at the start of the .TEXT part there is code that does syscalls to load dynamically linked libraries 16:30:27 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:31:54 pretty much loading an position independent code into memory, call to the start of it with jump table base address where pointers to the library routines are expected to be. 16:55:44 --- join: DabsR (~Mutter@190.62.250.41) joined #forth 17:00:42 --- quit: DabsR (Remote host closed the connection) 17:31:34 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 17:33:21 --- quit: dddddd (Remote host closed the connection) 17:36:49 --- quit: nighty (Ping timeout: 240 seconds) 17:39:31 --- join: nighty (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 17:57:12 --- quit: nighty (Quit: Disappeared in a puff of smoke) 17:58:37 --- join: nighty (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 18:38:16 wake up, #forth ! 18:38:51 sleep down, #forth ! 18:39:11 hey 18:39:48 I want to draw images with sixels but I'm afraid hashforth will be too slow to do so efficiently 18:40:50 when I tried to draw sixels with attoforth, which I suspect is significantly faster than hashforth, it was painfully slow - mind you I was using a dithering algorithm 18:51:59 tabemann: I tried converting the framebuffer to sixels upon displaying them but found it to be too slow. Now I convert to sixels on write, keep my framebuffer in sixel format, and then just TYPE it. 18:51:59 Bundle everything into one frame unless you want animation. 18:51:59 The rle compression also helps when TYPEing the image over a slow uart link. 18:54:11 I'm thinking that approach would work with a limited number of sixels 18:54:25 *colors 18:54:34 like 16 colors 18:55:14 but when doing something like 100 * 100 * 100 colors with mlterm, that's not feasible 18:55:43 True. 18:56:22 I thought mlterm supports 256 sixel color registers (?) 19:04:04 okay, mlterm used to support 256 color registers 19:04:10 now it supports 1024 color registers 19:05:00 still not near truecolor 19:50:00 --- join: gravicappa (~gravicapp@h109-187-43-215.dyn.bashtel.ru) joined #forth 20:06:57 --- quit: tabemann (Ping timeout: 268 seconds) 20:29:05 --- join: tabemann (~tabemann@2600:1700:7990:24e0:7d60:d448:1ce0:b090) joined #forth 21:25:44 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 23:59:59 --- log: ended forth/19.04.16