10:47:02
##forth
<veltas>
CREATE SCAN-CHAR 0 C, : SCAN ( addr1 u1 -- addr2 u2 ? ) SCAN-CHAR C! SCAN-CHAR 1 SEARCH ;
10:47:24
##forth
<veltas>
Another way to do this, if SEARCH is going to be defined anyway
10:48:25
##forth
<veltas>
( addr1 u1 c -- addr2 u2 ? ) that should be
10:50:31
##forth
<veltas>
Or if you can take address of return stack : SCAN ( addr1 u1 c -- addr2 u2 ? ) >R RP@ 1 SEARCH RDROP ;
11:08:37
##forth
<veltas>
And also assuming you're a little endian kind of person
12:19:15
##forth
<xentrac>
olle: I think of declarative ↔ imperative as being opposite directions along an axis, not positions on it
15:21:30
##forth
<veltas>
You know I've noticed a pattern in my embedded coding that goes from doing everything in a very imperative way, until I understand the problem really well and it gets a highly declarative refactor
15:21:45
##forth
<veltas>
Or moderately declarative anyway
15:22:31
##forth
<veltas>
Because eventually I'm conscious of the 'parameters' in their simplest form, and would rather just keep the imperative part as short as possible, as that's where most of the bugs lie
15:22:40
##forth
<veltas>
Provided the declarative part is correct and easy to maintain
15:23:54
##forth
<veltas>
The better I understand a problem the more declarative I like the code to be, for C that mostly looks like me using a lot of tables that fully or 90% specify the problem, and not having too much actual executable code handle it all.
15:24:15
##forth
<veltas>
In Forth I guess that involves a lot of tables or arrays, and using DOES> words more
15:36:08
##forth
<swampman`>
Hello, is this the place to ask if I can't get to compile gforth, or is there a better channel for that?
15:40:44
##forth
<swampman`>
Thanks, I'll ask them there then.
15:44:14
##forth
<crc>
I've never had much luck getting gforth to compile from source :(
15:46:07
##forth
<swampman`>
Well, maybe I got another question though. Suppose I want to use pforth for my program, is there an equivalent to open-dir/close-dir like the one in gforth, but in pforth instead? Whenever I try to use those in pforth, it says the word is undefined, but in gforth it's available. So my questions would be: 1) Is it really a gforth-only feature or can I use it in pforth (or other implmentations for that matter) too? 2) What would be the
15:46:08
##forth
<swampman`>
alternative if those are actually only available in gforth?
15:46:16
##forth
<swampman`>
Sorry for the textwall, btw.
15:49:13
##forth
<swampman`>
My guess would be that open-dir and close-dir are part of the standard, however, pforth hasn't gotten around to implement it, unlike gforth.
15:49:13
##forth
<crc>
open-dir isn't a standard word, and looks to be a wrapper over opendir(3) from libc
15:49:55
##forth
<swampman`>
Ah, okay.
15:51:20
##forth
<swampman`>
So, is there any other way to iterate through a directory in Forth without using open-dir, or rather using only standard words?
15:54:08
##forth
<crc>
not that I'm aware of; the file access words in ANS don't include anything for directories
15:54:58
##forth
<swampman`>
Hmm.
16:30:30
##forth
<cleobuline>
forthBot: LOAD ini.fth
16:30:30
##forth
<forthBot>
File ini.fth with MOON loaded
16:30:36
##forth
<cleobuline>
forthBot: MOON
16:30:36
##forth
<forthBot>
Phase de la lune pour Fri August 22 2025
16:30:36
##forth
<forthBot>
🌘 Croissant descendant La lune s'efface, une nuit calme a venir ! Illumination 0%
16:40:08
##forth
<veltas>
swampman`: You can ask for help with gforth here
16:40:30
##forth
<veltas>
I'm the unofficial gforth IRC support desk because I'm always answering questions on here about it
16:41:02
##forth
<veltas>
The main advice I give, which sounds like it will apply to you, is it helps to install e.g. gforth 0.7.3 either from your package manager or by building from source first, and install that
16:41:13
##forth
<veltas>
Because later gforth source needs gforth installed in order to build
16:42:31
##forth
<veltas>
The easiest way to open a directory in pforth is probably to add the relevant POSIX directory functions yourself, pForth is written in C so it should be easy to add other C functions
16:44:25
##forth
<veltas>
e.g. opendir()
16:46:18
##forth
<swampman`>
The gist of my problem is that it seems like I need some kind of gforth already installed just to compile gforth. I'm on Alpine Linux, which doesn't have gforth in its repositories. It complains about there being no gforth in the path while configuring. I already tried it with "alias gforth=pforth", which expected to fail, as it did. Then I attempted running all kinds of flags, like described on Stackoverflow by a guy with a similar
16:46:19
##forth
<swampman`>
issue. I suppose there has to be a way to compile gforth without gforth, otherwise source-based distros and BSD ports could get it, but I haven't figured it out yet.
16:46:44
##forth
<swampman`>
*could -> couldn't
16:47:04
##forth
<veltas>
Build gforth 0.7.3 from source
16:47:13
##forth
<veltas>
And install
16:47:32
##forth
<veltas>
And then you should be able to build a new snapshot / master
16:48:14
##forth
<veltas>
pForth's design philosophy is to rely only on standard ANSI C, and ANSI C has no function for enumerating directories, just for creating/renaming/deleting files.
16:52:17
##forth
<veltas>
crc: Thanks for running through claude
16:52:30
##forth
<crc>
veltas: no problem
16:52:32
##forth
<veltas>
Interesting, so it got the result after being given the error
16:54:00
##forth
<crc>
I've found claude to be particularly helpful for non-forth stuff, and better for the few forth things I've tried than chatgpt or gemini
16:57:54
##forth
<crc>
I've been doing a large python project at work, and it's been *very* useful there
17:00:15
##forth
<veltas>
I've asked ChatGPT to "really think about it" so I'll see what it gets
17:01:08
##forth
<veltas>
Clearly a very powerful tool
17:01:13
##forth
<cleobuline>
try grok
17:01:38
##forth
<veltas>
I really hate Python but it's the sort of thing I can imagine LLMs shine at
17:02:26
##forth
<remcycles>
pforth is fun. I last ran it in 2010, but also tried to get it running during a board bring up project last year. I couldn't get it integrated into my team's CMake build system because CMake is terrible, so I gave up on that side project.
17:02:46
##forth
<cleobuline>
forthBot: S" Un gros python multicolore dans une forêt enchantée "S IMAGE
17:03:13
##forth
<veltas>
remcycles: Sounds like the issue is CMake
17:03:48
##forth
<remcycles>
100% CMake. If it was done in plain Makefiles I would have had it running.
17:04:12
##forth
<vdupras>
I really hate sawing a 2x4 with a dull blade, but that's something a 800 pounds gorilla must be pretty good at.
17:05:44
##forth
<veltas>
ChatGPT's answer is full of issues, and yet the code is also much closer to what I wrote than copilot or claude
17:07:44
##forth
<veltas>
Ah ChatGPT is trying to use the return stack inside a do loop, rookie mistake
17:08:27
##forth
<veltas>
I don't know why the standard doesn't mandate that J and J' access the first and second return stack items outside the loop frame, but it doesn't
17:09:40
##forth
<veltas>
It has the OVER I + C@ R@ which is almost verbatim what I wrote, but with R@ instead of OVER
17:10:02
##forth
<veltas>
And uses OVER which makes no sense as depth is 1 there
17:10:11
##forth
<veltas>
It's so close
17:12:14
##forth
<veltas>
Okay after pointing out the return-stack / do-loop issue and the incorrect use of OVER, it's come up with pretty good code that's basically what I wrote
17:14:43
##forth
<veltas>
But it starts with ROT SWAP ROT and documents this as \ addr u ch -> addr ch u
17:15:18
##forth
<veltas>
I might prompt "is there an easier way to do the first line that does addr u ch -> addr ch u"
17:17:31
##forth
<veltas>
Wow that's really confused it, it's now suggesting >R SWAP R>
17:17:47
##forth
<veltas>
It's like it doesn't understand the stack notation order
17:18:12
##forth
<remcycles>
Because it doesn't understand anything.
17:18:13
##forth
<remcycles>
Rant: LLMs are the antithesis of Forth's ideals. Bloated resource hogs that attempt to solve a problem in the most roundabout way possible using an implementation that no one understands or can extend easily.
17:18:35
##forth
<veltas>
You're definitely right about that, 100%
17:19:24
##forth
<veltas>
It's also true about a whole load of stuff that's in my life and I can't really easily change right now, but still valid, and I am interested in what we can do to reverse the tide of useless bloat ruining everything and wasting our energy resources
17:20:27
##forth
<remcycles>
Not to criticize your attempts to use it, of course. I'm just overwhelmed by the endless AI hype cycle and ready for the next AI winter (if any).
17:20:46
##forth
<remcycles>
AI is not only an insult to life itself, but Forth too.
17:21:37
##forth
<veltas>
Hayao Miyazaki
17:22:41
##forth
<remcycles>
That's been my favorite quote this year, but it's actually quite old now. Before this current GPT wave.
17:25:29
##forth
<veltas>
ChatGPT is finally at exactly the code I had after pointing out a number of strange stack issues
17:26:46
##forth
<remcycles>
Definitely agree that reducing bloat is a good goal. There's a lot of bloat even in the field of embedded systems. Too bad efficiency isn't a more widely shared value.
17:27:26
##forth
<crc>
I use an LLM for some work things, to save me considerable typing. My personal stuff is all 100% handcrafted code.
17:31:19
##forth
<remcycles>
We had a survey at work about how we use or could use AI. I quoted Miyazaki in my response. I'm boycotting AI and hope I'm never asked to use it at work.
17:33:33
##forth
<crc>
for me, a factor is ongoing severe rsi issues. I'll use tools to help mitigate that, even if they aren't ideal
17:34:57
##forth
<remcycles>
That's understandable.
17:35:01
##forth
<crc>
I generally discourage use of LLM tools unless there's an actual use case
17:35:17
##forth
<crc>
and then try to keep the use to the minimum required
17:35:52
##forth
* crc is looking at possibly setting up something in-house for this in the future
19:03:02
##forth
<forthBot>
Environment for cleobuline inactive, freeing...
19:19:43
##forth
<swampman>
veltas: I did manage to compile gforth the way you said (as in I downloaded the 0.7.3 version and compiled that instead). Do you know what to do when gforth complains about not being able to "open image file gforth in path .:"?
19:20:00
##forth
<swampman>
*gforth.fi
19:20:12
##forth
<swampman>
That's the name of the image or whatever.
19:25:25
##forth
<swampman>
It seems like gforth seems to work if I execute it from the compilation directory. Maybe some files are missing when I did the make clean install.
19:25:30
##forth
<swampman>
I don't know.
19:29:37
##forth
<swampman>
This is the full error.
20:29:47
##forth
<swampman>
Nevermind, it works now.
20:37:34
##forth
<crc>
cleobuline: my bots were written by hand, using a non-traditional set of tools written entirely in retroforth, running in a chroot over openbsd