IRC Log - 2025-04-14 - ##forth

Channel: ##forth
Total messages: 175
Time range: 02:07:06 - 23:59:55
Most active: cleobuline (60), xentrac (43), mforth (26)
02:07:06 ##forth <xentrac> yeah, I feel like the Forth outer interpreter is pretty closely analogous to the Unix shell in a lot of ways
02:08:31 ##forth <xentrac> it's a unified user interface for all kinds of different domain-specific utility programs which may be written in the same interpreter or may be written in a lower-level language for efficiency
02:08:47 ##forth <xentrac> so cal seems like a perfectly reasonable thing to do
02:10:52 ##forth <xentrac> also, maybe sort of by coincidence, both of them are mostly "point-free programming", which is to say, you don't name inputs and outputs to functions, but just compose them together
07:21:26 ##forth <lisbeths> so I been trying to make a forth and I've ended up making more of a register machine https://github.com/memesmith0/calculator/blob/main/smallcalculator.c
07:21:32 ##forth <deadmarshal_> Is there a pattern matching example like functional langs in Forth? that would be interesting
07:21:53 ##forth <lisbeths> forth can be used to bootstrap a pattern matching interface
07:22:07 ##forth <lisbeths> most forth programers don't work with lots of text they are usually working with microcontrollers that control machines
07:22:23 ##forth <deadmarshal_> right
13:14:08 ##forth * anthk_ it's trying a jupiter ace emulator
13:14:35 ##forth <xentrac> lisbeths: hmm
13:15:46 ##forth <xentrac> lisbeths: I'm tempted to read 'n' and 'p' as 'car' and 'cdr'
13:16:12 ##forth <lisbeths> n is for number and p is for pointer
13:18:50 ##forth <xentrac> deadmarshal_: though Forth was inspired by Lisp I don't remember ever seeing anyone do that kind of symbolic computation in it. the closest I've seen is that vdupras wrote a sort of Lisp interpreter
13:19:53 ##forth <vdupras> xentrac: Lisp compiler!
13:20:02 ##forth <xentrac> apologies, yes!
13:20:06 ##forth <xentrac> Lisp compiler
13:20:08 ##forth <vdupras> :)
13:20:58 ##forth <xentrac> there isn't maybe an inherent reason that you need garbage collection for pattern-matching
13:23:07 ##forth <vdupras> in Dusk, the text parsing part of the work is mostly done in a scratchpad, a buffer of a fixed size that rolls over. But I do use my implementation of Lisp's cons, which are garbage collected, for AST storage. pretty handy
13:23:41 ##forth <xentrac> but I feel like you do at least need dynamic scoping for pattern matching. which is doable. recursive static scoping is maybe better
13:24:28 ##forth <xentrac> ASTs work pretty well with arena/pool allocation, FWIW
13:25:31 ##forth <xentrac> it's almost as convenient as GC and easier to implement efficiently
13:26:10 ##forth <vdupras> yes, it would too. I use arenas a lot in dusk, but my cons API is more convenient for ASTs and they happen to be GCed
13:26:56 ##forth <xentrac> I didn't realize that; I probably should dig into DuskOS more
13:27:24 ##forth <xentrac> I've often wondered how far you can get with symbolic computation using the Zork Z-Machine tree structure
13:29:05 ##forth <xentrac> where each object has a parent pointer, a next-sibling pointer, and a first-child pointer, as well as some properties, and the fundamental structural operation is to reparent an object elsewhere in the (single) tree
13:29:42 ##forth <xentrac> just on the basis that I like things that can't fail, and that reparenting operation can't fail
13:32:30 ##forth <xentrac> but the obvious ways to use it for that involve having a "free list" parent whose children you steal, and it can run out of children
13:37:58 ##forth <veltas> Got to love a 700 line program with 17 lines of code
13:38:10 ##forth <xentrac> heh
13:38:18 ##forth <veltas> I do respect GPL though
13:38:45 ##forth <xentrac> I was tempted to say "this program is just the GPL" but then I finally scrolled down to the program itself
13:39:39 ##forth <xentrac> but then it still wasn't very clear what it was expressing
13:40:16 ##forth <veltas> I agree that it's like car and cdr, that's what I thought too, and I have written very little Lisp
13:41:33 ##forth <veltas> I approve of using printable opcodes
13:42:38 ##forth <xentrac> I feel like an example session would probably make the program a lot more comprehensible
13:52:00 ##forth <xentrac> I'm tempted to mention `dc`
14:32:20 ##forth <deadmarshal_> Lisp compiler in Forth is great :D
14:33:03 ##forth <deadmarshal_> If you put all the stuff in the dictionary I think it'll get freed when program exits, so It acts like an arena
14:34:44 ##forth <deadmarshal_> One thing I don't understand about Forth is that if dictionary holds both words definitions and data, it probably means they are interspered in between each other. doesn't the memory gets fragmented?
14:38:49 ##forth <veltas> The allocation model is pretty much a stack, so you do indeed end up with wasted memory sometimes
14:39:28 ##forth <veltas> When you 'forget' a word or call a MARKER, you remove everything that was allocated since the thing you're removing
14:49:56 ##forth <deadmarshal_> right
14:52:14 ##forth <veltas> You can save memory anyway with creativity, but it's tradeoffs all the way down
14:53:32 ##forth <vdupras> it's of course possible to design a dictionary API that doesn't fundamentally leak memory, but that API will be specific to each forth
14:54:11 ##forth <xentrac> deadmarshal_: while in theory you could allocate space for your AST nodes using :noname or equivalent, it's probably better to use a separate heap for them
14:55:28 ##forth <deadmarshal_> yes heap would be easier
14:57:48 ##forth <xentrac> I don't think you understood what I said
14:59:40 ##forth <xentrac> the dictionary is a sort of a heap. an arena is another sort of a heap, or maybe the same sort. a malloc/free free list that permits reuse of deallocated memory is another sort of a heap. it's probably better to use a *separate* heap for AST nodes, i.e., a heap that isn't the dictionary
15:01:17 ##forth <xentrac> is that clearer?
15:08:44 ##forth <veltas> I don't personally consider the dictionary to be a 'heap', I would just say it's another stack
15:09:26 ##forth <veltas> And I think if you call it a 'heap' you will probably confuse people
15:13:22 ##forth <deadmarshal_> can we call it a heap that is used like a stack then? :|
15:14:32 ##forth <identity> looks like a pile to me
15:41:51 ##forth <xentrac> veltas: I think I did
16:03:35 ##forth <cleobuline> mforth: CREDIT
16:14:58 ##forth <xentrac> mforth: CRÉDIT
16:14:58 ##forth <mforth> Unknown word: CRÉDIT
16:20:11 ##forth <cleobuline> xentrac: you need to LOAD "test.fth"
16:20:54 ##forth <xentrac> mforth: LOAD "test.fth" CRÉDIT
16:21:09 ##forth <cleobuline> lol
16:24:12 ##forth <cleobuline> mforth: HELLO
16:24:12 ##forth <mforth> Hello cleobuline How are uou ?
16:24:46 ##forth <cleobuline> mforth: LOAD "test.fth" CRÉDIT
16:25:28 ##forth <cleobuline> it does not interpret words after LOAD , yet it's CREDIT
16:26:12 ##forth <xentrac> mforth: CRÉDIT
16:26:12 ##forth <mforth> Unknown word: CRÉDIT
16:26:29 ##forth <cleobuline> lol
16:26:36 ##forth <cleobuline> mforth: CREDIT
16:27:15 ##forth <xentrac> does it still have the bug where one line of input can produce many lines of output?
16:27:32 ##forth <cleobuline> this is not a bug
16:27:43 ##forth <xentrac> mforth: 1 dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup . dup .
16:27:44 ##forth <mforth> Unknown word: dup
16:27:58 ##forth <cleobuline> that DUP
16:28:05 ##forth <xentrac> hmm, I think it's a bug in the sense that it causes the bot to have undesirable behavior
16:28:16 ##forth <xentrac> mforth: 1 DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP . DUP .
16:28:16 ##forth <mforth> 1
16:28:16 ##forth <mforth> 1
16:28:16 ##forth <mforth> 1
16:28:17 ##forth <mforth> 1
16:28:17 ##forth <mforth> 1
16:28:18 ##forth <mforth> 1
16:28:18 ##forth <mforth> 1
16:28:19 ##forth <mforth> 1
16:28:38 ##forth <cleobuline> this not a bug
16:29:58 ##forth <cleobuline> if you do : test 1000000 DO I . LOOP ; it will spam , that the responsability of the user
16:31:04 ##forth <cleobuline> why trying to spam with the bot ?
16:31:58 ##forth <xentrac> I think it's important for the bot to not do that because sometimes people will do it by accident
16:32:21 ##forth <cleobuline> mforth: EXIT
16:32:21 ##forth <mforth> Bot shutting down...
16:32:37 ##forth <cleobuline> that's the remède
16:33:11 ##forth <cleobuline> the great soluce
16:34:53 ##forth <cleobuline> xentrac: type LOAD "test.fh" then type HELLO please
16:34:59 ##forth <identity> i mean, it's /your/ bot, so it's also /your/ responsibility to make sure it doesn't flood the channel, isn't it?
16:35:43 ##forth <cleobuline> i can't control the use of the bot , but anyone can type EXIT
16:36:10 ##forth <cleobuline> mforth: LOAD "test.fth"
16:36:21 ##forth <cleobuline> mforth: WORDS
16:36:32 ##forth <cleobuline> lol
16:36:34 ##forth <identity> you can't control the use of the bot, but you can put safeguards in place so obvious bad things don't happen
16:36:45 ##forth <veltas> The fact you can do it by accident easily is a reason to change it
16:36:52 ##forth <cleobuline> mforth: EXIT
16:37:12 ##forth <cleobuline> it's dead
16:37:40 ##forth <xentrac> :-(
16:37:50 ##forth * xentrac leaves flowers
16:38:20 ##forth <cleobuline> mforth: LOAD "test.fth"
16:38:29 ##forth <cleobuline> mforth: WORDS
16:38:43 ##forth <cleobuline> there is a bug some where :(
16:40:05 ##forth <cleobuline> mforth: WORDS
16:40:11 ##forth <cleobuline> it's dead
16:42:55 ##forth <cleobuline> mforth: WORDS
16:43:14 ##forth <cleobuline> it doe not want to wrk here
16:43:26 ##forth <cleobuline> mforth: 1 DUP .S
16:43:43 ##forth <cleobuline> did someone mute it ?
16:44:05 ##forth <xentrac> nope
16:44:07 ##forth <cleobuline> anyway
16:44:31 ##forth <xentrac> /mode ##forth +q shows nobody is quieted
16:46:02 ##forth <cleobuline> it works on my irc server not there
16:48:31 ##forth <veltas> It's stuck in the shadow realm
16:50:52 ##forth <cleobuline> maybe
16:53:16 ##forth <cleobuline> xentrac: you kill my bot with your experimentations :(
16:53:43 ##forth <cleobuline> you must use it en "Bon père de famille"
16:56:46 ##forth <cleobuline> now i thing it is shadowban
16:56:48 ##forth <xentrac> aw :-(
16:56:53 ##forth <xentrac> oh no!
16:57:03 ##forth <cleobuline> yes
16:59:38 ##forth <cleobuline> it's yout fault xentrac
17:00:14 ##forth <cleobuline> with your diabolics experiments
17:01:25 ##forth <cleobuline> i don't care it works on labynet.fr where is not any contraints
17:03:56 ##forth <xentrac> I hope it recovers soon
17:04:52 ##forth <cleobuline> i will work to enqueue the bot response with a irc thread so it will have best response time
17:05:51 ##forth <cleobuline> may be add the username to response too
17:08:32 ##forth <cleobuline> now there is still a risk of inter-locking if many users send request in the same time
19:04:15 ##forth <cleobuline> mforth: WORDS
19:04:33 ##forth <cleobuline> il est toujours shadowban le pauvre
19:18:03 ##forth <cleobuline> mforth: WORDS
19:18:04 ##forth <mforth> USERNAME .S . + - * / MOD DUP DROP SWAP OVER ROT >R R> R@ = < > AND OR NOT XOR & | ^ ~ << >> CR EMIT VARIABLE @ ! +! DO LOOP I WORDS LOAD CREATE ALLOT ." CLOCK BEGIN WHILE REPEAT AGAIN SQRT UNLOOP +LOOP PICK CLEAR-STACK PRINT NUM-TO-BIN PRIME? FORGET STRING " 2DROP IMAGE TEMP-IMAGE CLEAR-STRINGS DELAY EXIT MICRO MILLI
19:18:12 ##forth <cleobuline> it's back !
19:19:26 ##forth <cleobuline> labynet.fr :)
19:19:38 ##forth <cleobuline> the best web radio in the world
19:20:01 ##forth <cleobuline> with many experimentals IA bots
19:21:25 ##forth <cleobuline> mforth: MICRO 10000 DELAY MICRO SWAP - .
19:21:35 ##forth <mforth> 10000115
19:43:43 ##forth <[bot]konilo> Konilo via IRC
21:28:43 ##forth <anthk_> mforth: 2 SQRT .s
21:28:43 ##forth <mforth> Unknown word: .s
21:28:51 ##forth <anthk_> mforth: 2 SQRT .S
21:28:52 ##forth <mforth> <2> 1 1
21:29:32 ##forth <anthk_> mforth: 2drop
21:29:32 ##forth <mforth> Unknown word: 2drop
21:29:36 ##forth <anthk_> mforth: 2DROP
21:37:22 ##forth <vulpine> mforth: 1 SQRT .S
21:37:23 ##forth <mforth> <1> 1
21:38:11 ##forth <cleobuline> mforth: LOAD "test.fth"
21:39:54 ##forth <cleobuline> mforth: 1 2 3 5 7 11 13 17 23 31 * * * * * * * * PRIME-FACTORS .S
21:39:54 ##forth <mforth> Unknown word: PRIME-FACTORS
21:39:54 ##forth <mforth> <2> 1 363993630
21:41:47 ##forth <cleobuline> mforth: LOAD "test22.fth"
21:41:47 ##forth <mforth> Error: Error: LOAD: Cannot open file 'test22.fth'
21:41:54 ##forth <cleobuline> mforth: LOAD "test2.fth"
21:41:58 ##forth <cleobuline> mforth: 1 2 3 5 7 11 13 17 23 31 * * * * * * * * PRIME-FACTORS .S
21:41:58 ##forth <mforth> 2 3 5 7 11 13 17 23 31
21:42:31 ##forth <cleobuline> mforth: CLEAR-STACK
21:50:55 ##forth <cleobuline> mforth: 1234567 PRIME-FACTORS
21:50:55 ##forth <mforth> 127 9721
23:34:07 ##forth <pgimeno> anthk_: try out https://codeberg.org/pgimeno/JAForth if you aim at coding for the Juppy :)
23:53:13 ##forth <anthk_> ah, thanks, zesarux ran too slow on my netbook
23:53:56 ##forth <anthk_> well, is not interactive
23:54:45 ##forth <anthk_> uh, Pedro Gimeno, where did I see that name
23:54:48 ##forth <anthk_> ZX Spectrum maybe?
23:55:38 ##forth <anthk_> ah, indeed
23:58:14 ##forth <anthk_> on zesarux, it emulates the ACE in my netbook at glacial speeds
23:59:55 ##forth <anthk_> there are xace and so on but they fail to build with odd cmake errors. Still, everything but graphics and I/O might run nearly as is on 8-16 bit forths