2021-08-29 14:44:42 <tabemann    > this channel is so dead these days :(
2021-08-29 14:46:30 <f-a         > it is summer
2021-08-29 14:48:00 <imode       > wait until september or october.
2021-08-29 14:48:49 <tabemann    > september is three days from now
2021-08-29 14:50:46 <tabemann    > I figured it was because of the whole freenode matter
2021-08-29 14:53:11 <f-a         > that might be too
2021-08-29 14:53:16 <f-a         > are there still people on freenode?
2021-08-29 14:53:21 <f-a         > freenode/#forth, I mean
2021-08-29 14:53:34 <remexre     > I'm mostly just lurking here (rather than posting) because I'm not doing Forthy projects for a few months
2021-08-29 14:54:53 <remexre     > (though I suppose the projects I am working on have two stacks... no RPN though)
2021-08-29 14:59:34 <nihilazo    > yeah I'm not really doing any forthy stuff so I'm not here much
2021-08-29 15:03:34 <imode       > I'm going to start doing forthy stuff but I can't start it yet.
2021-08-29 15:33:24 <tabemann    > 
ACTION has been working on forthy stuff all summer

2021-08-29 15:38:10 <f-a         > like?
2021-08-29 15:49:32 <tabemann    > zeptoforth
2021-08-29 15:49:57 <tabemann    > a forth that includes an RTOS
2021-08-29 15:50:23 <tabemann    > for Cortex-M4 and Cortex-M7 MCU's
2021-08-29 19:07:47 <crc         > tabemann: I've been busy at work, but am working on some Forth stuff (a new vm for a future retro [and other things...], proper UTF8 support, adding an FFI)
2021-08-29 19:11:19 <tabemann    > if I ever use Forth on the PC again (as opposed to Haskell, or Python plus shell for scripting), I'll have to try out Retro
2021-08-29 22:26:06 <imode       > crc: how are you planning on implementing that FFI?
2021-08-29 22:27:26 <crc         > it's not a general ffi; you have to write wrapper functions that have particular calling signatures and handle translation between retro state and the external code you use
2021-08-29 22:28:13 <imode       > ahhhh.
2021-08-29 22:28:47 <imode       > so if I wanted to call out to say SDL, I'd have to write wrapper functions and then link them in?
2021-08-29 22:28:50 <crc         > forthworks.com:8000/file?udc=1&ln=on&ci=tip&name=vm%2Fnga-c%2Fretro.c see line 294 for the start
2021-08-29 22:28:51 <crc         > yes
2021-08-29 22:29:03 <imode       > that's how I've approached it, good to know I'm not crazy.
2021-08-29 22:29:15 <imode       > are the wrapper functions written in C?
2021-08-29 22:29:43 <imode       > ah.
2021-08-29 22:29:45 <imode       > yup.
2021-08-29 22:29:54 <crc         > c, so anything that's compatible with c abi and can generate a shared library on your host
2021-08-29 22:31:06 <crc         > I spent a lot of time looking into writing something that could directly map functions in, but there's no way to do that in a clean, non-fragile manner that I could find
2021-08-29 22:31:14 <imode       > neat. I've always used that "buffer" approach (where you can load something with "sane" call sigs that calls out to other stuff), but also at some point added the ability for it to be stateful by handing each handle/handle-group its own memory.
2021-08-29 22:31:40 <imode       > so instead of just writing an SDL wrapper, you can have a piece of code that manages an SDL window without having to map that to the interpreter state.
2021-08-29 22:31:43 <imode       > kind of like a black box.
2021-08-29 22:31:54 <imode       > that you just poke every now and again.