00:00:00 --- log: started forth/20.07.19 00:02:46 --- quit: elioat (Remote host closed the connection) 00:03:51 --- quit: deesix (Ping timeout: 256 seconds) 00:12:19 --- join: crab1 joined #forth 00:12:33 greetings, #forth 00:17:37 --- quit: yunfan (Quit: WeeChat 1.9.1) 00:44:00 --- join: xek_ joined #forth 00:45:56 --- join: jsoft joined #forth 01:51:53 --- quit: xek_ (Ping timeout: 265 seconds) 02:18:06 --- quit: Croran (Quit: No Ping reply in 180 seconds.) 02:19:21 --- join: Croran joined #forth 02:29:06 --- join: xek_ joined #forth 02:48:36 --- quit: xek_ (Ping timeout: 256 seconds) 03:54:21 GREETINGS crab1 04:54:24 --- join: jedb_ joined #forth 04:55:11 --- quit: jedb (Ping timeout: 264 seconds) 05:05:16 How are my fellow forthers? 05:05:47 doing great... building new forths. ;-) what else would a forther be doing? 05:06:34 what sorts of forths are we building today? 05:07:53 ActorForth - strong type system which I then build a forth-like language on top of it. intended to build crypto-contracts with it. 05:10:51 I've still not made a forth to completion. 05:11:16 this one isn't complete yet - but it's getting closer. 05:11:20 I always end up angry at whatever architecture I'm building it on and quit 05:13:04 crab1, haha that's understandable. but having something working is of value no matter what. 05:14:33 it undoubtedly is, and it's something I fail to value enough 05:15:09 because here I sit, usually writing forth on paper and never executing anything whatsoever :) 05:18:49 keeping focus and just getting what you need done is difficult since you've always got new ideas on something else you could do with it. just expect to re-write the thing a few times, at least big chunks of it. 05:19:21 I always have example code for useful things that I want to run in my forth. Then I build just enough forth to execute that. 05:27:56 I've not honed in tightly enough on what I want 05:28:37 well there you have it. ;-) 05:28:59 crab1, what environment(s) are you targeting? 05:32:57 either AArch64 or Amd64 05:33:17 --- quit: catern (*.net *.split) 05:33:17 --- quit: APic (*.net *.split) 05:33:40 I want to use on one of my laptops, I have an arm and an intel lappy 05:33:44 oh cool. you writing in asm64 or C/C++ or something completely different? baremetal or under an OS? 05:35:34 Probably has to be under an OS since the world is telling me that getting things to boot on my ARM laptop is a PITA 05:37:10 I lean toward asm, another option is ziglang.org 05:37:44 zig is pretty nice to write in, but I still lean toward asm 05:39:20 Hell what I want at the end of the day is almost just a forth style macro assembler 05:40:05 --- join: APic joined #forth 05:40:34 never heard of ziglang before. interesting. 05:41:48 zig is almost like 'C but everything works how you expect it to' 05:42:17 and it has decent error messages and good options for writings tests and such 05:45:36 looks pretty cool like a better classic 'C', a platform independent assembly language. 05:46:49 --- join: catern joined #forth 05:47:30 I at least get less annoyed with Zig than I do C 05:49:01 my canonical implementation of ActorForth is using python. It will eventually be self hosted. Haven't decided what underlying target platform that will assume. Eventually I want to make an FGPA that interprets its primitives natively. 05:52:04 mm FPGAs are nice 05:52:49 ideal if you need a stack based processor... 05:56:44 What asm64 I've written I've done with nasm. Much prefer it to the gnu asm syntax. 06:00:16 there is also yasm 06:05:06 am i the one person on earth who doesn't mind at&t syntax 06:05:24 cmtptr, perhaps the "last" ;-) 06:06:09 Personally, I find all of the standard asm syntaxes unwieldly 06:06:18 crab1, I'd heard of yasm but never tried it. 06:06:22 maybr it's just gnu stockholm syndrome 06:06:59 crab1, agreed which is why I prefer writing my own asm in forth but the x86 CPU is a monster. Not something nice like 6809 or 68k. 06:08:58 but ATT is really no worse than Intel or any others in my book 07:43:49 --- join: elioat joined #forth 08:23:41 --- quit: crab1 (Ping timeout: 246 seconds) 08:33:42 --- quit: Zarutian_HTC (Ping timeout: 256 seconds) 09:37:52 --- nick: jedb_ -> jedb 09:53:49 --- join: crab1 joined #forth 10:23:32 --- join: Zarutian_HTC joined #forth 10:59:28 --- quit: gravicappa (Ping timeout: 258 seconds) 11:00:07 --- join: gravicappa joined #forth 11:19:56 --- join: xek_ joined #forth 11:52:49 --- quit: crab1 (Quit: WeeChat 2.8) 12:57:02 --- quit: jsoft (Ping timeout: 246 seconds) 13:55:08 --- quit: xek_ (Ping timeout: 246 seconds) 15:45:30 --- quit: proteus-guy (Ping timeout: 256 seconds) 15:50:23 --- quit: gravicappa (Ping timeout: 264 seconds) 16:28:44 --- quit: MrMobius (Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!) 16:34:16 --- join: MrMobius joined #forth 17:22:24 --- join: dave0 joined #forth 18:16:35 --- join: boru` joined #forth 18:16:38 --- quit: boru (Disconnected by services) 18:16:40 --- nick: boru` -> boru 19:40:15 --- join: jsoft joined #forth 19:54:46 --- join: crab1 joined #forth 19:55:11 How do modern day forth systems tend to handle concurrency? 20:37:32 --- quit: dave0 (Quit: dave's not here) 20:49:48 I just implement coroutines, and set things up to be one process / cpu core 21:03:40 crab1, old forths mostly did cooperative multi-tasking because there was generally only one core. But forth lends itself incredibly well to multi-core development and coroutines, like remexre describes, are particularly apt. ActorForth will ultimately have an actor concurrency model with extremely low overhead per independent actor thanks to the natural low call overhead for forth words. 21:05:11 er yeah, I didn't write the second half of my response 21:06:15 e.g. sharing a socket between multiple processes for network-connected processes, which iirc is how some C software does it anyway, for crash-resilience 21:23:10 --- quit: jsoft (Ping timeout: 256 seconds) 21:33:57 crab1: it depends on the programmer 21:34:17 most embedded forth systems that include some kind of cooperative multitasker 21:34:41 but if you have a timer interrupt you could use the interrupt handler to implement preemptive multitasking 21:35:19 the problem is that you now have to deal with a "hostile" multitasker 21:35:39 you have to use mutexes etc. to protect critical sections 21:35:57 or stop the timer/mask the interrupt inside critical sections 21:36:50 the question is do you want to complicate your system that much? 21:37:05 or is cooperative multitasking good enough 21:37:40 because truly time critical is rare enough that you probably can afford to dedicate a timer interrupt to it 21:38:01 ofcourse this depends on your hardware 21:38:37 or you could implement a callout system to multiplex a single hardware timer and interrupt 21:39:38 e.g. keep a binary heap sorted by deadline for oneshot timers 21:58:03 --- join: jsoft joined #forth 22:08:39 so there are many options 22:15:25 --- join: gravicappa joined #forth 22:16:36 crab1: other forth systems running on top of operating system just expose the native thread api in some way 22:16:58 iirc gforth supports pthreads 22:17:06 of for a implosion design. 22:17:10 https://gforth.org/manual/Pthreads.html 22:17:30 just ignore that line 23:59:59 --- log: ended forth/20.07.19