2024-05-05 00:22:04 <zelgomer    > just got meta does> working finally
2024-05-05 00:22:22 <zelgomer    > this is so confusing to me
2024-05-05 00:22:47 <zelgomer    > i mean, i understand it, it's just difficult for me to articulate to myself becuase i lack good terminology for things
2024-05-05 00:23:17 <zelgomer    > like my "dodoes" code fragment is unnamed, for example. maybe that's not a good idea.
2024-05-05 01:21:56 <lf94        > where are there more active forth dudes
2024-05-05 01:22:00 <lf94        > or is this it
2024-05-05 01:22:05 <lf94        > is this peak forth community
2024-05-05 01:22:15 <Zarutian_iPad> whatcha mean more active?
2024-05-05 01:26:57 <dbucklin    > Check out the newsgroup if you haven't already. comp.lang.forth. There's some good stuff in there, but also some *interesting* stuff.
2024-05-05 01:28:14 <lf94        > I havent :o people still use those?
2024-05-05 01:28:18 <lf94        > I thought it was legacy
2024-05-05 01:28:35 <vms14       > :0
2024-05-05 01:28:49 <dbucklin    > LEgacy as hell, haha. Let me find the website that was recommended to me.
2024-05-05 01:29:01 <lf94        > Like so legacy the whole system doest exist anymore, it's read-only
2024-05-05 01:29:20 <dbucklin    > Check out https://www.novabbs.com/devel/thread.php?group=comp.lang.forth
2024-05-05 01:29:29 <dbucklin    > I take no responsibility for what you find there lol
2024-05-05 01:30:46 <lf94        > Wow, people _are_ still postnig
2024-05-05 01:30:48 <lf94        > Awesome!
2024-05-05 01:30:52 <dbucklin    > Oh, sorry, that's not my meaning of legacy.
2024-05-05 01:31:11 <dbucklin    > To me, "legacy" just means "it's what we have now and it's not the newest thing"
2024-05-05 01:31:36 <dbucklin    > To me, legacy != dead.
2024-05-05 01:32:47 <dbucklin    > The history or netnews is really interesting. Sad to see where's it's at today, but times be a-changin'!
2024-05-05 03:29:47 <lf94        > Are there any other forth communities you guys are aware of?
2024-05-05 03:32:34 <Al2O3       > usenet news?
2024-05-05 04:18:00 <lf94        > I fixed the issue on gameboy :)
2024-05-05 04:18:05 <lf94        > FUCK endianness
2024-05-05 04:18:18 <lf94        > It's beautiful. Runs the exact same on gforth and gbforth.
2024-05-05 04:18:36 <lf94        > extremely minimal difference. basically just for printing and ram/rom selection.
2024-05-05 04:20:18 <Zarutian_iPad> yeah, stop with the byte addressing crap, address whole cells only and then use ibstructions to seperate out the bytes
2024-05-05 04:20:19 <lf94        > the code is actually so beautiful
2024-05-05 04:20:29 <lf94        > No, the issue WAS the whole cells.
2024-05-05 04:20:41 <lf94        > Going byte addressing completely fixed it, as expected.
2024-05-05 04:21:02 <lf94        > the issue is you cant get your head around the endianness of anything. it's like a sifting floor.
2024-05-05 04:21:23 <lf94        > the way gbforth operates on its 16-bit numbers is completely different to gforth's 64-bit numbers
2024-05-05 04:21:39 <lf94        > going at the byte level completely fixed it, it's awesome
2024-05-05 04:21:48 <lf94        > I feel like I unlocked some secret knowledge
2024-05-05 04:22:36 <lf94        > like, this is honest to god real portable code
2024-05-05 04:32:06 <Al2O3       > or just stop being concerned about 8 bits, and go with 32 or 64 only, and waste a bunch of memory foot print...   Honestly, today, its hard to argue that angle.
2024-05-05 04:32:34 <Al2O3       > I just bought a memory card, 128 gig, for something like 37 dollars.
2024-05-05 04:33:01 <Al2O3       > :)   btw, this was a forth joke, if you didn't get it.
2024-05-05 04:33:13 <zelgomer    > how about i write to it using 16gb chars then?
2024-05-05 04:37:20 <zelgomer    > so i've been entertaining an idea in my head lately. i'm tempted to experiment with using the linux kernel but with a forth init. good idea or unholy abomination?
2024-05-05 04:38:04 <lf94        > what about the experiment is appealing? :)
2024-05-05 04:38:13 <lf94        > I'd like to hear more
2024-05-05 04:42:31 <zelgomer    > that's about the extent of it. just stupid ideas to try new things. i think having a forth userland might be fun, but leveraging the drivers already available with linux
2024-05-05 05:00:17 <Al2O3       > no such things stupid ideas.   Just ideas that have not been researched enough maybe.
2024-05-05 05:13:07 <coyote      > that'd be pretty neat
2024-05-05 06:08:22 <lf94        > zelgomer: I'd really love to see a uefi forth :)
2024-05-05 06:08:32 <lf94        > I learned uefi even has network and disk capabilities.
2024-05-05 06:33:46 <Al2O3       > I blame the lack of iodized salt in the diet :)   https://nypost.com/2024/05/03/lifestyle/iq-scores-decline-in-the-us-where-does-your-state-rank/
2024-05-05 06:33:56 <Al2O3       > and the forth dimension revivial.
2024-05-05 06:34:07 <Al2O3       > that was a terrible album.
2024-05-05 07:25:04 <lf94        > https://www.youtube.com/watch?v=QGpZl23vXbw
2024-05-05 17:25:57 <lf94        > Is there a general forth editor that saves to text?
2024-05-05 17:25:59 <lf94        > and reads from text
2024-05-05 17:26:10 <lf94        > But keeps the 60x20 blocks?
2024-05-05 17:26:26 <lf94        > 64x16 *
2024-05-05 17:38:52 <KipIngram   > lf94: I wrote a couple of simple little C programs that converted my blocks.dat file to and from text format.  It just inserted line feeds to go to text.  Going the other way was a little more than just removing them, it would add/remove spaces to make all the lines 64 long.
2024-05-05 17:40:00 <KipIngram   > Then I set up vim to show me the 64 width in a visual way, so I'd notice if I typed a line that was too long.  That worked fine.
2024-05-05 17:41:08 <KipIngram   > It also inserted separations between the blocks, and a line that called out the block number.
2024-05-05 17:42:24 <KipIngram   > I may still have those lying around somewhere - I'll check in a little while when I'm a little more awake.
2024-05-05 17:42:49 <KipIngram   > I was up till quite late last night upgrading my os, so I only woke up a few minutes ago.
2024-05-05 17:52:01 <lf94        > I use kakoune, but I feel a forth editor actually has some real nice benefits.
2024-05-05 17:52:20 <lf94        > 64x16 screens lets you navigate really fast between code. and if you can move chunks of text, that's nice too
2024-05-05 17:52:28 <lf94        > (block selection)
2024-05-05 17:55:47 <KipIngram   > I think so too.
2024-05-05 17:57:55 <KipIngram   > I've gradually moved to variable length lines, but it does complicate the editor code.  And it's not like source takes up much of modern massive disks.
2024-05-05 18:00:26 <KipIngram   > I factored my EXPECT word to include a word I call EDIT.  EDIT can do all the line editing on a buffer that already has some content in it, and takes a parameter for where the cursor should start out initially.  And if it gets a keystroke that isn't for "line" editing, it returns with that key on the stack, to be tested by the wrapping code.
2024-05-05 18:00:40 <KipIngram   > So it does a lot of the work of an editor and make it easier to write an editor around it.
2024-05-05 18:01:26 <KipIngram   > But EDIT winds up being one of the largest words in my system in terms of code space.
2024-05-05 18:03:23 <KipIngram   > Another thing that makes that stuff more complicated is trying to support utf8 chars.  You lose the "one char, one byte" correspondence.
2024-05-05 18:04:06 <KipIngram   > But once I got interested in stealing features from APL, utf8 became more or less a necessity.
2024-05-05 18:24:12 <Al2O3       > KipIngram couldn't you have used sed/awk for that same process?
2024-05-05 18:26:40 <KipIngram   > Almost certainly, if I'd dug into it.  I use sed fairly often for "basic things," but I'm no power user, and I've rarely used awk.  I can at least write a sed  substitution line on the fly, but awk I pretty much just copy stuff others have done off the web when I need it for something.
2024-05-05 18:27:17 <KipIngram   > I'm sure if I took the time to learn it better I'd be happy with the new ability.
2024-05-05 18:27:33 <KipIngram   > I love little "basic tools" like that.
2024-05-05 18:38:29 <MrMobius    > I've begrudgingly used awk for various Linux things. Sometimes I consider making a general usage python script to replace all that when awk is being an asshole
2024-05-05 18:50:18 <zelgomer    > i've actually grown to really appreciate awk
2024-05-05 20:38:56 <dbucklin    > I remember seeing the O'Reilly sed & awk pocket guide and thinking that the tarsiers on the cover were named sed & awk :D
2024-05-05 20:39:26 <KipIngram   > :-)
2024-05-05 21:07:33 <luiz_       > hi
2024-05-05 21:07:48 <luiz_       > just saw lf94 video, made me think about forth again
2024-05-05 21:08:31 <luiz_       > i'm very tired of having to beg gcc not to screw my logic
2024-05-05 21:09:41 <luiz_       > I read Starting Forth a long time ago
2024-05-05 21:10:27 <luiz_       > I have a few questions...
2024-05-05 21:11:35 <luiz_       > Is there a good, but not too good, compiler (.fs > .s)?
2024-05-05 21:12:34 <luiz_       > Does Forth hold up on modern systems? Like, how good is the interaction with Linux (syscalls, fd, etc)?
2024-05-05 21:13:13 <luiz_       > Is there an ANSI C of Forth (i.e. the lowest common denominator)?
2024-05-05 21:14:01 <luiz_       > How do you go about managing memory in practice? Like receiving a TCP packet
2024-05-05 21:31:38 <zelgomer    > i'm sure there are several ansi c forths out there. in fact, what i've been working on for the past few months is to develop a new (to me) practice: for each project, i plan to track a very small (<1K LOC) single-file .c file that implements a very basic forth VM, and then using that, i write cross-compilers in forth and then write the end product in the new cross-compiling forth dialect
2024-05-05 21:33:41 <zelgomer    > the idea being that i'm completely decoupled from the compiler, but there is still this host VM umbilical so that the only dependency required to build the project is a standard host c compiler (and preferably make, sh, and awk, but you could get by without those if you had to)
2024-05-05 21:37:42 <vms14       > lulz_ there's gforth and retroforth
2024-05-05 21:38:09 <vms14       > not sure about how much ansi are
2024-05-05 21:38:54 <vms14       > https://rosettacode.org/wiki/Draw_a_pixel#Forth
2024-05-05 21:39:32 <vms14       > it's quite cool to make c bindings by just using stack notation
2024-05-05 21:40:46 <vms14       > ansi c there's pforth i guess
2024-05-05 21:40:54 <vms14       > or ficl?
2024-05-05 21:41:17 <vms14       > https://github.com/philburk/pforth
2024-05-05 21:42:07 <vms14       > Ficl syntax is based on ANS Forth and the code is ANSI C
2024-05-05 21:42:20 <vms14       > both
2024-05-05 22:03:02 <zelgomer    > luiz_: about interaction with linux, i've been having a fine time with it. you just write code words to bind to your system calls and take parameters or push results to/from the stack.
2024-05-05 22:04:01 <zelgomer    > managing memory is free-form. you either don't (statically allocate buffers), or you come up with your own dynamic memory system, or you link with libc and use malloc (which you're sort of forced to do if you intend to call c libraries)
2024-05-05 22:05:02 <crc         > luiz_: I'm not aware of any that generate a .s; my RetroForth (not a standard model) has a `retro-compiler` that generates executables; x4 can do similar. I believe some of the commercial systems can as well.
2024-05-05 22:05:03 <luiz_       > zelgomer, do you know of any network library i could take a look at?
2024-05-05 22:08:04 <zelgomer    > no, sorry. i'm actually quite ignorant of other forths and forth libraries floating out there. for me, the appeal of forth is doing it all myself.
2024-05-05 22:08:31 <crc         > luiz_: gforth's socket library is at https://github.com/forthy42/gforth/blob/master/unix/socket.fs
2024-05-05 22:13:19 <crc         > https://github.com/mark4th/x4/blob/master/src/ext/sockets.f is the sockets.f from x4 (uses linux syscalls instead of a C FFI)
2024-05-05 22:16:12 <luiz_       > oh, yes
2024-05-05 22:19:57 <crc         > the possible interactions with a modern host will depend on the forth
2024-05-05 22:20:22 <crc         > Ones written in assembly (like x4) are likely to have easier integration with the host syscalls than ones written in C
2024-05-05 22:20:36 <crc         > Some, like gforth, have FFI words for using system libraries
2024-05-05 22:22:20 <luiz_       > ok, as a final question: what good learning resources are out there (besides leo brodie, of course)?
2024-05-05 22:26:43 <zelgomer    > luiz_: in my opinion, nothing helped me to grok forth and how it works like bradrodriguez's moving forth series
2024-05-05 22:26:57 <zelgomer    > you can also download his camelforth source for several platforms
2024-05-05 22:27:10 <zelgomer    > and his chromium meta forth
2024-05-05 22:27:35 <zelgomer    > brad rodriguez. he has two names like most of us :)
2024-05-05 22:27:43 <zelgomer    > www.bradrodriguez.com
2024-05-05 22:28:45 <crc         > this one I can't really help with much (my work with forth has diverged from the traditional systems over the years)
2024-05-05 22:29:47 <luiz_       > crc, do you have a website?
2024-05-05 22:30:04 <crc         > There's brodie's Starting Forth & Thinking Forth books, Elizabeth Rather & Stephen Pelc (Forth, Inc & MPE) have both written books (I've not read these)
2024-05-05 22:30:47 <crc         > http://retroforth.org for my larger, older forth, and http://konilo.org for my smaller, newer one
2024-05-05 22:32:38 <luiz_       > cool, i'll check those out
2024-05-05 22:32:39 <luiz_       > thanks guys
2024-05-05 22:33:06 <crc         > quite old at this point, but https://archive.org/details/MitchDerickLindaBakerForthEncyclopediaTheCompleteForthProgrammersManualMountainViewPress1982/page/n11/mode/2up is pretty detailed on fig-forth
2024-05-05 23:03:07 <dbucklin    > luiz_: Recently recommended here was Loeliger's book, Threaded Interpretive Languages. https://dn790007.ca.archive.org/0/items/R.G.LoeligerThreadedInterpretiveLanguagesTheirDesignAndImplementationByteBooks1981/R.%20G.%20Loeliger-Threaded%20Interpretive%20Languages_%20Their%20Design%20and%20Implementation-Byte%20Books%20%281981%29.pdf
2024-05-05 23:03:20 <dbucklin    > sorry for the link gore
2024-05-05 23:04:10 <luiz_       > oh, thanks
2024-05-05 23:04:36 <luiz_       > better this than an URL shortner that requires javascript :D
2024-05-05 23:04:47 <dbucklin    > haha, that would be gross