2022-07-30 02:37:37 <veltas      > KipIngram: I wouldn't have the extra >IN==4096 check, no point
2022-07-30 02:38:09 <veltas      > I don't sanity check my programs unless I have to
2022-07-30 07:06:22 <nature      > Hello, did anybody recently tried compiling gforth from source?
2022-07-30 08:48:13 <thrig       > yes, but I already told you how that went
2022-07-30 08:52:56 <nature      > thrig: Really? I am sorry I must've missed it, I only got that you tried it a while ago and that's it, I asked you more but never saw an answer :(
2022-07-30 08:52:58 <dave0       > i managed to compile gforth 0.7.3 on NetBSD 9.0
2022-07-30 08:53:12 <dave0       > i don't remember if it needed any libraries
2022-07-30 08:53:38 <thrig       > nature: review the openbsd logs where you talked about gforth
2022-07-30 08:54:31 <nature      > Also I currendly managed to build something, but it seems that it fails when running the tests (empty output), but the executable that is already built seems to execute without any issue
2022-07-30 08:55:46 <nature      > thrig: Yeah, just checked and you simply mentionned gcc eating all your memory, but I still don't know if this is recent or not, sorry if I am missing something
2022-07-30 08:56:52 <nature      > dave0: Are the tests the last step of the build?
2022-07-30 08:57:42 <dave0       > i didn't run any tests
2022-07-30 08:58:07 <dave0       > i just did unpacked it, and did    ./configure --disable-shared
2022-07-30 08:58:14 <dave0       > oh i probably needed gmake
2022-07-30 08:58:29 <dave0       > nature: i use NetBSD ... it should be very straightforward on linux
2022-07-30 08:59:11 <dave0       > nature: if you can run    gforth   just make a couple words and see if it works
2022-07-30 08:59:24 <nature      > running gmake didn't run any tests during the build? For me it ran targets like "checkone" etc...
2022-07-30 09:00:03 <nature      > Also doing this on OpenBSD so not so straightforward either :D
2022-07-30 09:01:02 <dave0       > i don't remember, i did it last year or so
2022-07-30 09:03:55 <nature      > okok, thanks already.  And yeah I am able to make a couple of words.  I am just wondering if there are missing things since the build ended with an error, yet I still end up with something that looks like a working executable
2022-07-30 09:18:12 <KipIngram   > veltas: There is a point in the >IN check if I decide to arrange to have it automatically increment to block N+1 and continue unless the content of block N actually "ends."  If I decide I want that it would be possible to arrange for a single word to straddle the block boundary.  My reasoning is that that's a "step" toward file system support - it would allow me to group a set of blocks into one unified batch
2022-07-30 09:18:14 <KipIngram   > of source - then later when I implement a file system it would become possible for those blocks to be non-sequential.
2022-07-30 09:19:06 <KipIngram   > With that an editor could just present the content of multiple blocks as one smooth text body.
2022-07-30 09:19:56 <KipIngram   > I'm not doing that now - currently I just force return a null if I hit the end of the block.  That bit would need to be modified if I wanted it to increment to the next block and reset >IN to 0.
2022-07-30 09:22:37 <KipIngram   > But you're right - so long as I end text in a block with a null character there's no need for that check - it would never actually run.
2022-07-30 09:23:00 <KipIngram   > And in traditional systems to chain blocks together one would have -->
2022-07-30 09:43:10 <thrig       > gforth master branch canna even clear ./configure
2022-07-30 09:47:57 <thrig       > god damn it. gmake re-ran ./configure which puts the errors back in
2022-07-30 09:49:28 <KipIngram   > Ugh - make processes can really be hella frustrating.
2022-07-30 09:49:53 <thrig       > none of my Makefile (nor autotools) is this crazy
2022-07-30 09:50:19 <KipIngram   > I'm sure I'm even more that way than you.  When I first met make it was back in the super simple days, and it made a lot of sense.
2022-07-30 09:50:28 <KipIngram   > But they've just continually complicated it over the years.
2022-07-30 09:52:25 <thrig       > about the most complicated I go is https://github.com/thrig/scripts/raw/master/doc/ans/Makefile
2022-07-30 09:53:50 <KipIngram   > That's not so bad.  I'm apt to just use the very very basic functionality - "if source newer than object, compile."
2022-07-30 09:53:52 <thrig       > hmm, blows up on ./preforth, somehow. let's try with gcc instead of clang?
2022-07-30 09:54:04 <KipIngram   > Fingers crossed.
2022-07-30 09:55:02 <nature      > thrig: let me know if you're interested in me sharing how I did it so far.  But I don't build directly from source, I do it directly with the port system
2022-07-30 10:10:46 <thrig       > gcc - "configure: error: C compiler cannot create executables"
2022-07-30 10:12:29 <KipIngram   > Hmmm.  Does clang have a built-in link step that gcc doesn't have?
2022-07-30 10:13:59 <thrig       > it might be confused about linking on openbsd
2022-07-30 10:19:05 <thrig       > configure: WARNING: No emacs found, won't build gforth.elc   yeah not installing that thing
2022-07-30 10:22:05 <thrig       > "No Gforth found in path, build from git will fail" ... nice bootstrap requirement ya got there
2022-07-30 10:23:36 <nature      > I think I managed to build it, I just end up with those last lines at the end of the build: https://ttm.sh/wMN.txt
2022-07-30 10:24:09 <nature      > If anybody knows what this "performance problems" means...
2022-07-30 10:25:49 <thrig       > yeah this is a train wreck