2025-02-22 00:24:03 <xentrac     > As I see it, the one being used by people implementing GForth is, in a certain sense, more real :-)
2025-02-22 01:49:43 <Shark8      > veltas, https://forth-standard.org/standard/words
2025-02-22 06:07:40 <ghodawalaaman> !gforth s" hello world" TYPE
2025-02-22 06:07:41 <gforth_eval_bot> hello world
2025-02-22 06:09:37 <ghodawalaaman> !gforth s" hello world" .
2025-02-22 06:09:37 <gforth_eval_bot> 11
2025-02-22 06:09:42 <ghodawalaaman> !gforth s" hello world" . .
2025-02-22 06:09:42 <gforth_eval_bot> 11 101729186248544
2025-02-22 06:10:53 <ghodawalaaman> !gforth s" hello" !
2025-02-22 06:11:03 <ghodawalaaman> hmm
2025-02-22 06:11:10 <ghodawalaaman> I want to change the "h" with "H"
2025-02-22 06:12:55 <ghodawalaaman> !gforth s" firefox" DUP ROT ROT ! TYPE
2025-02-22 06:15:14 <vms14       > !gforth s" oh..." over char H swap 1+ ! type
2025-02-22 06:15:14 <gforth_eval_bot> oH
2025-02-22 06:16:17 <vms14       > I've lost the dots xd
2025-02-22 06:17:08 <ghodawalaaman> :D
2025-02-22 06:23:51 <vms14       > !gforth s" oh..." over char H swap 1+ c! type
2025-02-22 06:23:52 <gforth_eval_bot> oH...
2025-02-22 06:23:58 <vms14       > forgot to use c!
2025-02-22 06:25:20 <ghodawalaaman> I am thinking about substacting 32 that way it could be a generic function
2025-02-22 06:26:49 <ghodawalaaman> but it would be quite complex
2025-02-22 06:27:10 <vms14       > everything is complex in forth :D
2025-02-22 06:27:17 <vms14       > you have to factor
2025-02-22 06:27:33 <ghodawalaaman> yeah, this one I will do it myself
2025-02-22 06:27:56 <vms14       > we are counting on you
2025-02-22 06:34:52 <ghodawalaaman> it's really complex lol
2025-02-22 06:35:15 <vms14       > you need to get used to forth
2025-02-22 06:35:15 <ghodawalaaman> I should read "Starting Forth" again
2025-02-22 06:35:22 <vms14       > forth is for masochists
2025-02-22 06:36:07 <vms14       > that's the main appeal I guess
2025-02-22 06:36:08 <ghodawalaaman> yeah, I need to think in terms of stack and also need to keep track of position of values on stack
2025-02-22 06:36:22 <ghodawalaaman> but I will master it eventually
2025-02-22 06:36:41 <vms14       > you can cheat with r> >r or variables until you find a better way
2025-02-22 06:37:17 <vms14       > sometimes r> >r is actually the way that makes most sense if you start messing too much with the stack
2025-02-22 06:37:36 <vms14       > but you can also find a better ordering
2025-02-22 06:38:18 <vms14       > a loop that upcases every character should be easy
2025-02-22 06:38:39 <vms14       > as long as we assume that they will always be lovercase
2025-02-22 06:38:43 <ghodawalaaman> yeah, first define UPCASE and then DO .. LOOP
2025-02-22 06:38:56 <vms14       > lowercase*
2025-02-22 06:50:52 <vms14       > !gforth : upcase dup 0 do over i + dup c@ 32 - swap c! loop ;  s" ohmycat" upcase type
2025-02-22 06:50:52 <gforth_eval_bot> OHMYCAT
2025-02-22 06:51:04 <vms14       > but it will fail for numbers or symbols
2025-02-22 07:04:19 <ghodawalaaman> :o
2025-02-22 07:50:52 <ghodawalaaman> to convert a b c to c b a on stack we have to take this steps: https://0x0.st/8TMe.pdf
2025-02-22 07:51:22 <ghodawalaaman> I can do this :)
2025-02-22 07:52:09 <ghodawalaaman> over -> rot -> drop -> rot
2025-02-22 07:52:25 <ghodawalaaman> !gforth a b c over rot drop rot .s
2025-02-22 07:52:37 <ghodawalaaman> !gforth 1 2 3 over rot drop rot .s
2025-02-22 07:52:38 <gforth_eval_bot> <3> 3 2 1
2025-02-22 07:52:46 <ghodawalaaman> \o/
2025-02-22 07:52:56 <ghodawalaaman> in the first attempt
2025-02-22 08:55:39 <ghodawalaaman> ohh I could just do swap rot
2025-02-22 08:55:41 <ghodawalaaman> lol
2025-02-22 08:55:45 <ghodawalaaman> I just saw in the answer
2025-02-22 08:55:54 <ghodawalaaman> !gforth 1 2 3 swap rot
2025-02-22 08:56:04 <ghodawalaaman> !gforth 1 2 3 swap rot .s
2025-02-22 08:56:05 <gforth_eval_bot> <3> 3 2 1
2025-02-22 09:24:09 <ghodawalaaman> wow the exercises in Starting Forth is actually challenging!
2025-02-22 09:32:10 <veltas      > xentrac: gforth hasn't had a release in like 15+ years, Forth 200x was in its infancy at the last release
2025-02-22 09:32:22 <veltas      > The gforth in this channel is like 15+ years old
2025-02-22 09:32:44 <veltas      > So basically an ANS Forth
2025-02-22 09:34:29 <veltas      > Forth standardisation is a total mess and has been for a long time, I think fundamentally Forth is a language that can't be directed nicely by a committee, if any language can be
2025-02-22 09:35:48 <veltas      > I don't have strong opinions on this but the main argument in favor of Forth 200x is "we turned up" and "we released standards", but the standards they have released are not very good, and seem to be far removed from classic Forth in style and principle
2025-02-22 09:37:05 <veltas      > So I merely push back if people call it "the standard", because you're acting like there is any kind of consensus
2025-02-22 09:38:18 <veltas      > I would call it Forth 200x because that's their name
2025-02-22 10:09:16 <user51      > i thought rolling your own was the standard  :)
2025-02-22 10:14:54 <ghodawalaaman> veltas: I am currently reading this https://www.forth.com/starting-forth/ am I on the right track?
2025-02-22 10:33:56 <pgimeno     > in the Jupiter, I can use FIND <word> and it pushes the address of <word>; if I then use EXECUTE, it executes the word as if you had just typed <word>. However in gforth, find gives a stack underflow and in pforth it unpolitely segfaults.
2025-02-22 10:34:33 <pgimeno     > So I have to questions: what is FIND, and how do I find the execution address of a word.
2025-02-22 10:36:45 <ghodawalaaman> pgimeno: are you using this: https://gitlab.com/tsoding/porth ? I saw the first person using this language
2025-02-22 10:36:47 <ghodawalaaman> :o
2025-02-22 10:37:21 <pgimeno     > no, I'm using a package called pforth that is part of debian
2025-02-22 10:38:33 <ghodawalaaman> oh I see
2025-02-22 11:23:42 <veltas      > ghodawalaaman: That's a good place to start, the only point is that there's no 'one true standard'
2025-02-22 11:24:21 <veltas      > A number of standards have been made that have gotten weirder and weirder over the years, and as programming has changed too
2025-02-22 11:24:51 <veltas      > The original creator of Forth has even deviated significantly from the classic Forths in his own Forth, and significantly from 'standard' attempts
2025-02-22 11:25:46 <veltas      > It's just good to understand it's not like C where the dialect is very homogenous, and people don't necessarily stick to vanilla ISO C (e.g. will use inline assembly, GCC extensions), but generally there's a well founded core that is pretty close to the standard
2025-02-22 11:26:48 <veltas      > For example crc is the operator for this channel, and maintains two significant dialects of Forth, retro and konilo, which are both *very* different to the classic and standard Forths
2025-02-22 11:27:57 <veltas      > And they're much better at doing what I think the Forth 200x committee wished Forth was more like, which is code that uses a lot of inline quotations (basically like lambda functions, or inline functions)
2025-02-22 11:36:20 <xentrac     > veltas: GForth does seem to be changing slowly, but also seems to be somewhat actively maintained despite the lack of releases
2025-02-22 11:36:42 <xentrac     > I agree that there's not much of a consensus
2025-02-22 11:40:09 <xentrac     > pgimeno: Forth-83 and later find expects a counted string on the stack and returns an address and a boolean telling you whether it found the requested word
2025-02-22 11:40:54 <xentrac     > this dialogue with gforth shows how to use it:
2025-02-22 11:41:01 <xentrac     > : c"see" c" see" ; c"see" find . . -1 140004933494720  ok
2025-02-22 11:41:01 <xentrac     > : c"qee" c" qee" ; c"qee" find .s <2> 140004933621104 0  ok
2025-02-22 11:42:23 <xentrac     > of course, as Veltas correctly points out, things like Konilo, Factor, or Kitten are unlikely to be compatible at that level
2025-02-22 11:46:39 <xentrac     > this also works in GForth: c"see" find . xt-see
2025-02-22 11:46:56 <ghodawalaaman> !gforth c"see" find . xt-see
2025-02-22 11:47:15 <xentrac     > you'll have to define c"see" first as above
2025-02-22 11:47:47 <ghodawalaaman> !gforth : c"see" c" see" ; c"see" find . .
2025-02-22 11:47:47 <xentrac     > !gforth : c"see" c" see" ; c"see" find . xt-see
2025-02-22 11:47:47 <gforth_eval_bot> -1 136763498792864
2025-02-22 11:47:48 <gforth_eval_bot> -1
2025-02-22 11:47:49 <gforth_eval_bot> https://0x0.st/8TSo.txt
2025-02-22 11:48:08 <xentrac     > xt
2025-02-22 11:48:16 <ghodawalaaman> I see
2025-02-22 11:48:29 <xentrac     > so does GForth
2025-02-22 11:48:38 <xentrac     > xt-see is a factor of GForth's implementation of standard see
2025-02-22 11:49:05 <xentrac     > what find leaves on the stack under the true flag is an xt
2025-02-22 11:49:53 <xentrac     > probably I should have chosen a different example word to decompile!
2025-02-22 11:50:51 <xentrac     > !gforth : c"words" c" words" ; c"words" find . xt-see
2025-02-22 11:50:51 <gforth_eval_bot> -1
2025-02-22 11:51:31 <xentrac     > it's too bad gforth_eval_bot doesn't produce a one-line abbreviated version of such a short output
2025-02-22 14:13:27 <pgimeno     > thanks for the explanations, so isn't there a modern equivalent of Jupiter's find?
2025-02-22 14:14:52 <pgimeno     > it seems to be a FORTH 79 word actually
2025-02-22 14:18:51 <xentrac     > you can do it but it's kind of a pain
2025-02-22 14:19:13 <xentrac     > bl parse will parse a word in the TIB and leave c-addr u on the stack
2025-02-22 14:20:05 <xentrac     > unfortunately find doesn't want c-addr u.  It wants a c-addr of a counted string
2025-02-22 14:20:52 <pgimeno     > I haven't seen counted strings, I presume they are strings prefixed with a length?
2025-02-22 14:21:17 <xentrac     > yeah, prefixed with a length byte
2025-02-22 14:21:54 <pgimeno     > so, WORD is suitable for parsing them then?
2025-02-22 14:21:54 <xentrac     > and there's no guarantee that the bytes before and after the string that parse returns a pointer to are unused
2025-02-22 14:23:00 <xentrac     > well, I would say parse if you want to do what the ACE Forth is doing
2025-02-22 14:23:53 <xentrac     > anyway you can convert the return value of parse into a counted string for use with standard find
2025-02-22 14:24:05 <xentrac     > by copying it into a temporary buffer such as pad
2025-02-22 14:24:28 <pgimeno     > !gforth 32 word . find . .
2025-02-22 14:24:29 <gforth_eval_bot> -1 138363636047376
2025-02-22 14:24:51 <xentrac     > but in GForth for example an easier thing to do is to call sfind
2025-02-22 14:25:06 <xentrac     > which is a factor of find that takes the count on the stack
2025-02-22 14:25:17 <pgimeno     > !gforth 56 32 word . find drop execute
2025-02-22 14:25:17 <gforth_eval_bot> 56
2025-02-22 14:25:21 <pgimeno     > works
2025-02-22 14:25:46 <xentrac     > !gforth bl parse words sfind drop xt-see
2025-02-22 14:25:48 <gforth_eval_bot> https://0x0.st/8TQ1.txt
2025-02-22 14:27:04 <xentrac     > !gforth : acefind bl parse sfind ;  acefind words drop xt-see
2025-02-22 14:27:05 <gforth_eval_bot> https://0x0.st/8TQ1.txt
2025-02-22 14:27:27 <xentrac     > is that helpful?
2025-02-22 14:28:05 <pgimeno     > I don't know what parse does
2025-02-22 14:28:11 <xentrac     > sfind isn't in the Standard (any version!), which I think is a mistake, but probably most Forths have something similar
2025-02-22 14:28:39 <xentrac     > parse consumes a string (in this case, "words") from the input stream, returning its start and length
2025-02-22 14:29:05 <xentrac     > here bl tells it when to stop: when it sees a space
2025-02-22 14:29:12 <pgimeno     > so much like words except in a different format
2025-02-22 14:29:22 <xentrac     > you mean much like find?
2025-02-22 14:29:34 <pgimeno     > much like word
2025-02-22 14:29:37 <pgimeno     > sorry
2025-02-22 14:29:41 <xentrac     > words just lists all the defined words
2025-02-22 14:30:55 <xentrac     > yes, I think it's common to implement word using bl parse, though GForth doesn't
2025-02-22 14:31:56 <pgimeno     > in the test code of the jupiter I use the Forth79 verison of find quite often, it's useful to pass callbacks to a function
2025-02-22 14:32:39 <xentrac     > oh, for that you want ' or [']
2025-02-22 14:32:51 <xentrac     > I should have thought of that at the beginning
2025-02-22 14:33:00 <xentrac     > parse takes the delimiter so you can use it to define things like ." or .(
2025-02-22 14:33:04 <xentrac     > !gforth : .{ [char] } parse type ; immediate  .{ okay}
2025-02-22 14:33:05 <gforth_eval_bot> okay
2025-02-22 14:34:00 <pgimeno     > oh it seems that ' is the actual equivalent of Forth79's find, right?
2025-02-22 14:34:31 <xentrac     > I don't know! Does Forth79's find not push a flag on the stack?
2025-02-22 14:34:39 <vms14       > it just returns the xt of the word
2025-02-22 14:34:53 <pgimeno     > that's right, it pushes 0 if the word is not found
2025-02-22 14:35:01 <pgimeno     > otherwise the address
2025-02-22 14:35:05 <vms14       > !gforth : oh 1 2 3 ; ' oh execute .s
2025-02-22 14:35:06 <gforth_eval_bot> <3> 1 2 3
2025-02-22 14:35:25 <pgimeno     > yeah so it seems it was renamed
2025-02-22 14:35:34 <xentrac     > ' or ['] will throw undefined word instead of pushing 0
2025-02-22 14:35:46 <vms14       > !gforth : oh ." oh..." cr ; defer meh ' oh is meh meh
2025-02-22 14:35:47 <gforth_eval_bot> oh...
2025-02-22 14:35:51 <xentrac     > !gforth : foo ['] jioagjog ;
2025-02-22 14:36:27 <xentrac     > we're missing the error output, but in interactive GForth it says :54: Undefined word
2025-02-22 14:37:26 <vms14       > ghodawalaaman the bot is super cool
2025-02-22 14:37:49 <vms14       > it's already giving a lot of value into this channel
2025-02-22 14:37:53 <xentrac     > inside a definition ['] is for passing a word supplied at compile time, like jiaoagjog above, while ' will parse a word from the input when you run the definition containing it
2025-02-22 14:38:13 <pgimeno     > well, pushing 0 or erroring out doesn't matter much for my purposes; certainly ' is what I'd regard as the modern equivalent of the old version of find
2025-02-22 14:38:31 <xentrac     > vms14: I agree!  I hope it lasts; I suspect it won't withstand the first attack for griefers
2025-02-22 14:38:34 <xentrac     > *by
2025-02-22 14:39:00 <pgimeno     > xentrac: understood, I wondered about the difference myself
2025-02-22 14:39:06 <vms14       > yeah that's why it's fine for the bot to not answer private stuff
2025-02-22 14:39:13 <xentrac     > pgimeno: I'm sorry I didn't mention it at the very beginning!  I guess I assumed you wanted to be able to handle undefined words
2025-02-22 14:39:20 <vms14       > so at least we can see here who is the one messing with the bot
2025-02-22 14:39:24 <pgimeno     > thanks for the explanation
2025-02-22 14:39:27 <vms14       > and hate him forever
2025-02-22 14:39:43 <xentrac     > that's what griefers are shooting for
2025-02-22 14:40:03 <xentrac     > liberal tears
2025-02-22 14:40:10 <xentrac     > or male tears or whatever their outgroup is
2025-02-22 14:40:39 <vms14       > https://forth-standard.org/standard/core/FIND
2025-02-22 14:40:46 <vms14       > seems to use a counted string
2025-02-22 14:41:16 <xentrac     > vms14: yeah, that's the problem I was talking about 16 minutes ago
2025-02-22 14:41:27 <vms14       > !gforth : oh 1 ; s" oh" find .s
2025-02-22 14:41:34 <vms14       > :0
2025-02-22 14:41:38 <xentrac     > you want c"
2025-02-22 14:41:42 <vms14       > ah lol
2025-02-22 14:41:51 <xentrac     > and you have to put it inside a colon definition
2025-02-22 14:42:16 <xentrac     > because in interpret state it isn't clear where you'd store the bytes of the string or how long they'd last
2025-02-22 14:42:50 <xentrac     > I think c" and this design of find were mistakes
2025-02-22 14:43:04 <xentrac     > the old name for s" was just "
2025-02-22 14:43:24 <vms14       > might be useful because the string is something "dynamic"
2025-02-22 14:44:46 <pgimeno     > it's a shame you have to necessarily put it inside a colon definition
2025-02-22 14:45:02 <vms14       > !gforth : f find ;  : oh 1 ;  c" oh" f .s
2025-02-22 14:45:12 <vms14       > :/
2025-02-22 14:45:31 <pgimeno     > it could just enclose the string in the current word when not compiling
2025-02-22 14:46:02 <pgimeno     > so you could do e.g.: create mystr c" string"
2025-02-22 14:47:07 <xentrac     > vms14: you have to put the c" inside a colon dfinition
2025-02-22 14:47:33 <xentrac     > pgimeno: that's an interesting idea
2025-02-22 14:47:33 <vms14       > yeah I'm trying in my "machine"
2025-02-22 14:48:21 <xentrac     > not having to think about string lifetimes was probably a significant advantage for BASIC over FORTH in the 01980s
2025-02-22 14:49:50 <vms14       > wasn't a word to convert a string + count to a counted string?
2025-02-22 14:49:55 <vms14       > the reverse of "count"
2025-02-22 14:50:52 <xentrac     > no, because it isn't clear where you'd store the bytes of the string or how long they'd last, so you have to think about string lifetimes, which is a significant disadvantage of Forth
2025-02-22 14:51:19 <xentrac     > you could write a word that does that if you supply it a buffer address to build it in, at the risk of buffer overflows, but there isn't a standard one
2025-02-22 14:53:09 <vms14       > place
2025-02-22 14:54:15 <xentrac     > yeah, GForth has place
2025-02-22 14:54:54 <vms14       > :D
2025-02-22 14:55:13 <xentrac     > you can write it too without relying on any GForthisms:
2025-02-22 14:55:28 <xentrac     > !gforth : decount dup pad c! pad 1+ swap cmove pad ;  : unicorns s" unicorns" ;  unicorns decount count type
2025-02-22 14:55:29 <gforth_eval_bot> unicorns
2025-02-22 14:56:23 <xentrac     > no word in the standard writes to pad so user code can safely use it without worrying that the implementation will overwrite it
2025-02-22 14:56:52 <xentrac     > the implementation of place in GForth is just over >r rot over 1+ r> move c!
2025-02-22 14:57:44 <vms14       > I remember something like that in reddit or alike
2025-02-22 14:58:01 <vms14       > because I ended trying to implement place not knowing it existed
2025-02-22 14:59:03 <xentrac     > yeah, that's what I just did :-)
2025-02-22 14:59:42 <xentrac     > it doesn't necessarily exist, though pForth does also have it
2025-02-22 15:37:10 <ghodawalaaman> vms14: Thank you
2025-02-22 15:37:23 <vms14       > we thank you instead :D
2025-02-22 15:37:29 <vms14       > I asked for that bot in the past
2025-02-22 15:37:44 <ghodawalaaman> owever bot won't be possible without the help of people in #bash and emanuele6, thanks to them too :)
2025-02-22 15:37:47 <vms14       > you made my dream become true
2025-02-22 15:38:05 <ghodawalaaman> :3
2025-02-22 15:39:30 <vms14       > I would not recommend you to make it work in private until it's really hardened
2025-02-22 15:39:56 <vms14       > at least if it only works here we can know who is messing with it
2025-02-22 15:40:44 <ghodawalaaman> yeah, I will keep that in mind, the bot might have a lot of vulnerabilities which we don't know yet
2025-02-22 15:40:50 <vms14       > the cool thing is that channel is relatively small so there are less chances to find someone who will actually want to cause harm
2025-02-22 15:41:26 <vms14       > but you never know
2025-02-22 15:42:05 <vms14       > I guess most members here will appreciate the bot since it's quite useful to show forth concepts
2025-02-22 15:42:25 <vms14       > the perl bot for example is very cool for explaining perl concepts
2025-02-22 15:42:49 <vms14       > but the perl bot is properly hardened
2025-02-22 15:42:59 <ghodawalaaman> right now it only supports gforth but we can also run other dialects of forth too
2025-02-22 15:43:07 <ghodawalaaman> I will add that feature after I get some free time
2025-02-22 15:43:10 <vms14       > the author even encourages you to try to mess with it
2025-02-22 15:43:54 <ghodawalaaman> I joined #perl some time ago to make a bot in perl
2025-02-22 15:43:59 <ghodawalaaman> #perl community is great
2025-02-22 15:48:32 <user51      > ghodawalaaman: bot source available?
2025-02-22 15:49:39 <ghodawalaaman> user51: yeah but it's very messy
2025-02-22 15:49:53 <ghodawalaaman> it's just 54 lines of bash :)
2025-02-22 15:50:52 <user51      > awful, bash gets messy after 50 lines  :)
2025-02-22 15:50:52 <ghodawalaaman> here is the different forth implementation which we can run: https://github.com/uho/docker-forth
2025-02-22 15:51:02 <ghodawalaaman> user51: part of the reason is that I don't have much experience in bash :)
2025-02-22 16:55:20 <vms14       > pff it has coconut
2025-02-22 16:56:17 <user51      > !gforth s" pwd" system
2025-02-22 16:56:18 <gforth_eval_bot> /src
2025-02-22 16:56:40 <vms14       > !gforth s" ls -a" system
2025-02-22 16:56:41 <gforth_eval_bot> .
2025-02-22 16:56:41 <gforth_eval_bot> https://0x0.st/8T1R.txt
2025-02-22 16:56:48 <user51      > !gforth s" make -j666" system
2025-02-22 16:56:57 <vms14       > I have been trolled
2025-02-22 16:57:24 <user51      > should've used ..
2025-02-22 16:57:27 <crc         > more evil might be:   s" :(){ :|:& };:" system
2025-02-22 16:57:29 <GeDaMo      > !gforth s" id" system
2025-02-22 16:57:30 <gforth_eval_bot> uid=0(root) gid=0(root) groups=0(root)
2025-02-22 16:57:43 <veltas      > !gforth s" ip link" system
2025-02-22 16:57:43 <gforth_eval_bot> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqu
2025-02-22 16:57:44 <gforth_eval_bot> https://0x0.st/8T1F.txt
2025-02-22 16:57:45 <user51      > !gforth s" ls -a .." system
2025-02-22 16:57:46 <gforth_eval_bot> .
2025-02-22 16:57:47 <gforth_eval_bot> https://0x0.st/8T1C.txt
2025-02-22 16:58:02 <vms14       > !gforth s" cat oh... > oh.txt" system s" ls" system
2025-02-22 16:58:08 <crc         > !gforth s" uname -a" system
2025-02-22 16:58:09 <gforth_eval_bot> Linux d6786b92e9d1 6.8.0-51-generic #52-Ubuntu SMP
2025-02-22 16:58:10 <gforth_eval_bot> https://0x0.st/8Tjr.txt
2025-02-22 16:58:14 <vms14       > oh no redirection
2025-02-22 16:59:21 <crc         > does the docker environment get replaced with each query or is it persistent?
2025-02-22 17:00:03 <veltas      > !gforth s" touch test" system
2025-02-22 17:00:09 <veltas      > !gforth s" ls" system
2025-02-22 17:00:22 <vms14       > it died?
2025-02-22 17:00:30 <veltas      > No it just doesn't reply if there's no lines
2025-02-22 17:00:33 <veltas      > Or it died
2025-02-22 17:00:41 <veltas      > !gforth ." hoya"
2025-02-22 17:00:42 <gforth_eval_bot> hoya
2025-02-22 17:00:44 <vms14       > oh
2025-02-22 17:00:55 <vms14       > then it cannot write
2025-02-22 17:00:58 <user51      > abandon channel its escaping containment
2025-02-22 17:01:03 <veltas      > So it gets replaced every query
2025-02-22 17:01:33 <veltas      > Assuming it can write to that dir anyway...
2025-02-22 17:01:55 <veltas      > !gforth s" touch test" system s" ls" system
2025-02-22 17:01:56 <gforth_eval_bot> test
2025-02-22 17:02:06 <user51      > !gforth s" touch hello; ls" system
2025-02-22 17:02:06 <gforth_eval_bot> hello
2025-02-22 17:02:12 <user51      > crap
2025-02-22 17:02:23 <vms14       > it is what it should I guess
2025-02-22 17:02:24 <user51      > oh wait
2025-02-22 17:02:37 <user51      > !gforth s" touch hello2; ls" system
2025-02-22 17:02:38 <gforth_eval_bot> hello2
2025-02-22 17:02:46 <crc         > probably better for security to have a fresh environment for every query, but wasteful in computing resources
2025-02-22 17:03:07 <veltas      > I'm under impression this is just how docker works
2025-02-22 17:03:08 <user51      > i think i know how to crash it
2025-02-22 17:03:23 <GeDaMo      > !gforth s" ls -l ." system
2025-02-22 17:03:24 <gforth_eval_bot> total 0
2025-02-22 17:03:33 <GeDaMo      > !gforth s" ls -ld ." system
2025-02-22 17:03:34 <gforth_eval_bot> drwxr-xr-x 2 root root 4096 Mar 14  2021 .
2025-02-22 17:03:47 <user51      > well, maybe not crash but make it hang pretty badly.  bash allocates a whole string for concatenations, so it quickly becomes a huge allocation
2025-02-22 17:03:49 <GeDaMo      > 2021, eh :P
2025-02-22 17:04:00 <veltas      > !gforth s" ping 143.244.198.13" system
2025-02-22 17:04:01 <gforth_eval_bot> PING 143.244.198.13 (143.244.198.13) 56(84) bytes
2025-02-22 17:04:02 <gforth_eval_bot> https://0x0.st/8Tjq.txt
2025-02-22 17:04:05 <crc         > !gforth s" find / -name docker.sock 2>/dev/null" system
2025-02-22 17:04:31 <veltas      > ghodawalaaman: network's not disabled
2025-02-22 17:04:38 <user51      > for i in {0..1} ; do echo $i; done # now add more {0..1} to the loop
2025-02-22 17:05:50 <user51      > anyway, this bot is getting too popular, here read some code fellas https://raw.githubusercontent.com/chmykh/apl-life/refs/heads/master/apl-life-anno.fs
2025-02-22 17:09:54 <crc         > ghodawalaaman: feel free to bring it back, but please add some mitigations to prevent it from potentially being used for nefarious purposes
2025-02-22 17:10:52 <user51      > aw, just missed my chance to run fortune  :D
2025-02-22 17:10:54 <veltas      > I think ghodawalaaman meant to disable networking before, but obviously it's not worked.  But yeah that particular issue is wide open to abuse.
2025-02-22 17:16:53 <vms14       > why did you kick it lol
2025-02-22 17:17:35 <vms14       > kick the user who misuses it instead
2025-02-22 17:17:48 <thrig       > naughty hacker abuses bot getting their IP address into spam blacklists, etc
2025-02-22 17:18:52 <vms14       > I would just : system ." never gonna give you up" cr ;
2025-02-22 17:19:15 <vms14       > but gforth has sockets
2025-02-22 17:20:36 <vms14       > !gforth ." muahahaha" cr
2025-02-22 17:20:37 <gforth_eval_bot> muahahaha
2025-02-22 17:20:57 <ghodawalaaman> !gforth s" ping 8.8.8.8" system
2025-02-22 17:21:07 <ghodawalaaman> :)
2025-02-22 17:21:10 <vms14       > ok that was fast
2025-02-22 17:21:33 <ghodawalaaman> I forgot to add --network none to the docker command
2025-02-22 17:21:53 <crc         > thanks for correcting that
2025-02-22 17:22:05 <ghodawalaaman> :-)
2025-02-22 17:27:31 <veltas      > Where's my bug Bounty?
2025-02-22 17:28:02 <vms14       > your coconut chocolate bar?
2025-02-22 17:28:08 <vms14       > it's better to eat air
2025-02-22 20:48:10 <veltas      > xentrac: gforth has had loads of development but they've not done a release in something like 15+ years, so it seems to just be 2-3 peoples' hobby at this point
2025-02-22 20:49:21 <veltas      > There's been some discussion about this on their mailing list, apparently they have a checklist of things before releasing and the next release will be 1.0, but it feels too ivory tower to me
2025-02-22 20:49:30 <veltas      > They should just do an 0.8 to tide us over
2025-02-22 21:00:18 <xentrac     > they should
2025-02-22 21:02:01 <user51      > gforth -1  :P
2025-02-22 23:03:02 <veltas      > !gforth : DROP DROP ;
2025-02-22 23:03:42 <veltas      > !gforth : DROP DROP ; .( X)
2025-02-22 23:04:39 <veltas      > !gforth : T ." X" ; T
2025-02-22 23:04:40 <gforth_eval_bot> X
2025-02-22 23:05:05 <veltas      > !gforth .( X)
2025-02-22 23:05:06 <gforth_eval_bot> X
2025-02-22 23:05:17 <veltas      > !gforth WARNINGS OFF : DROP DROP ; .( X)
2025-02-22 23:05:17 <gforth_eval_bot> X
2025-02-22 23:05:37 <veltas      > Some rough edges to figure out there with stderr
2025-02-22 23:11:18 <veltas      > !gforth ' SORT .
2025-02-22 23:13:54 <veltas      > !gforth ' TH .
2025-02-22 23:13:55 <gforth_eval_bot> 128918359437160
2025-02-22 23:20:44 <veltas      > !gforth  1 LIST
2025-02-22 23:20:45 <gforth_eval_bot> Screen 1 not modified
2025-02-22 23:20:46 <gforth_eval_bot> https://0x0.st/8T98.txt
2025-02-22 23:21:43 <veltas      > Also looks like \r and \n are both being converted to \n or something
2025-02-22 23:27:31 <veltas      > !gforth  TIME&DATE  .S
2025-02-22 23:27:32 <gforth_eval_bot> <6> 32 27 22 22 2 2025
2025-02-22 23:28:28 <veltas      > !gforth  TIME&DATE <# # # # # #S #> TYPE
2025-02-22 23:28:29 <gforth_eval_bot> 37354656749261842022402
2025-02-22 23:28:40 <veltas      > !gforth  TIME&DATE 0 <# # # # # #S #> TYPE
2025-02-22 23:28:41 <gforth_eval_bot> 02025
2025-02-22 23:28:51 <veltas      > Hey see gforth can speak like xentrac
2025-02-22 23:28:56 <xentrac     > ♥
2025-02-22 23:29:54 <xentrac     > !gforth : .d 0 <# # # # # # #s #> type ." -" . ." -" . ."  " 0 <# # # #> type ." :" <# # # #> type drop ; time&date .d .s
2025-02-22 23:31:44 <xentrac     > !gforth : 2.d 0 <# # # #> type ; : .d 0 <# # # # # # #s #> type ." -" 2.d ." -" 2.d ."  " 2.d ." :" 2.d drop ; time&date .d .s
2025-02-22 23:31:45 <gforth_eval_bot> 002025-02-22 22:31<0>
2025-02-22 23:32:00 <xentrac     > !gforth : 2.d 0 <# # # #> type ; : .d 0 <# # # # # #s #> type ." -" 2.d ." -" 2.d ."  " 2.d ." :" 2.d drop ; time&date .d .s
2025-02-22 23:32:00 <gforth_eval_bot> 02025-02-22 22:32<0>
2025-02-22 23:32:36 <veltas      > !gforth warnings off  2025.02.22 d.
2025-02-22 23:32:36 <gforth_eval_bot> 20250222
2025-02-22 23:32:46 <xentrac     > haha
2025-02-22 23:33:37 <veltas      > polyforth you can write 2025-02-22
2025-02-22 23:33:45 <xentrac     > oh?
2025-02-22 23:34:02 <veltas      > Yeah it accepts a few punctuators, and will allow them anywhere
2025-02-22 23:34:22 <xentrac     > _ and ' are becoming common
2025-02-22 23:34:28 <xentrac     > 1_048_576
2025-02-22 23:34:31 <veltas      > The standard assumes the least support by asking for . at the end
2025-02-22 23:34:45 <xentrac     > !gforth 2025.02.22 : .d <# # # [char] - hold # # [char] - hold # # # # # #> type ; .d
2025-02-22 23:34:46 <gforth_eval_bot> 02025-02-22
2025-02-22 23:34:48 <veltas      > But typically I think forths support more
2025-02-22 23:35:05 <xentrac     > yeah, bizarrely the standard doesn't standardize dpl
2025-02-22 23:35:42 <xentrac     > which you kind of need if you're going to be feeding double-precision numbers into the Forth outer interpreter
2025-02-22 23:35:49 <xentrac     > !gforth see dpl
2025-02-22 23:35:51 <gforth_eval_bot> https://0x0.st/8T9Q.txt
2025-02-22 23:38:22 <veltas      > TIME&DATE should output 2 doubles like 22:38:00 2025-02-22
2025-02-22 23:38:55 <xentrac     > not a bad idea
2025-02-22 23:39:33 <xentrac     > but it should consume the time to represent thus from the stack as seconds since the epoch
2025-02-22 23:40:09 <veltas      > That's a good idea until 2038
2025-02-22 23:40:59 <xentrac     > 02038 could be a problem for 16-bit Forths if the seconds count is only double-precision
2025-02-22 23:41:52 <veltas      > And this is the problem with the standard
2025-02-22 23:42:00 <veltas      > There's no one-size-fits-all solution
2025-02-22 23:46:17 <xentrac     > ddefer morse  : thue 1- dup if recurse morse else ." ·" then 1+ ;  : great 1- dup if thue thue morse else ." -" then 1+ ;  ' great is morse  8 thue
2025-02-22 23:46:23 <xentrac     > !gforth defer morse  : thue 1- dup if recurse morse else ." ·" then 1+ ;  : great 1- dup if thue thue morse else ." -" then 1+ ;  ' great is morse  8 thue
2025-02-22 23:46:23 <gforth_eval_bot> ·-··-·-·-··-·-··-·-··-·-·-··-·-�
2025-02-22 23:46:24 <gforth_eval_bot> https://0x0.st/8T9O.txt
2025-02-22 23:46:36 <xentrac     > hmm, looks like a charset problem
2025-02-22 23:47:42 <xentrac     > !gforth defer morse  : thue 1- dup if recurse morse else ." o" then 1+ ;  : great 1- dup if thue thue morse else ." -" then 1+ ;  ' great is morse  8 thue
2025-02-22 23:47:42 <gforth_eval_bot> o-oo-o-o-oo-o-oo-o-oo-o-o-oo-o-oo-o-o-oo-o-oo-o-o-
2025-02-22 23:47:43 <gforth_eval_bot> https://0x0.st/8T9V.txt
2025-02-22 23:48:19 <xentrac     > (that's approximately the simplest nonrepeating sequence)
2025-02-22 23:51:05 <veltas      > cool
2025-02-22 23:51:52 <xentrac     > you could definitely render a 2-D fractal in 50×n ASCII art in less than the 512 bytes of an IRC line
2025-02-22 23:52:34 <xentrac     > though you can't do animation probably
2025-02-22 23:52:46 <xentrac     > (but not because of the character limit)
2025-02-22 23:53:19 <xentrac     > oh incidentally I came across this the other day: https://archive.org/details/canoncat
2025-02-22 23:53:56 <vms14       > great is worse
2025-02-22 23:54:54 <xentrac     > it's an in-browser emulator for the Canon Cat, which was programmed I think in SwiftForth
2025-02-22 23:55:14 <vms14       > it's funny how the bot is making this channel so active
2025-02-22 23:55:36 <vms14       > I like that
2025-02-22 23:56:01 <vms14       > if we keep like this, the channel will end being really helpful to learn forth
2025-02-22 23:56:37 <xentrac     > sorry, not SwiftForth.  "Swyft", which ran on tForth: https://archive.org/details/SwyftAndTheCat https://archive.org/details/tForthManual
2025-02-22 23:57:27 <xentrac     > Swyft was the other portable computer Raskin did, so maybe I was even more confused than I thought
2025-02-22 23:59:16 <veltas      > !gforth  : FACTORIAL ( n1 - $n2)  DUP 2 < IF  DROP 1.  ELSE  DUP 1- RECURSE  ROT 1 M*/  THEN ;  30 FACTORIAL D.
2025-02-22 23:59:16 <gforth_eval_bot> 265252859812191058636308480000000