2023-11-21 02:32:11 <zelgomer    > i'm stupid :(
2023-11-21 02:33:37 <zelgomer    > i can't explain what i'm experiencing right now
2023-11-21 02:33:42 <zelgomer    > it's like some kind of logical dyslexia
2023-11-21 02:34:01 <zelgomer    > if TOS is 0, then 0<> should produce true, which is not 0
2023-11-21 02:34:44 <zelgomer    > no wait
2023-11-21 02:35:06 <zelgomer    > 0 0= .  -> t
2023-11-21 02:35:24 <zelgomer    > why is this confusing me so much? i need to call it a night
2023-11-21 03:17:02 <kws         > i'm finding it a lot more difficult to understand how I would implement forth in C than in assembler
2023-11-21 03:17:06 <kws         > it has to be indirect threaded code, because I can't generate machine instructions for direct threaded or subroutine threaded code wihout RWX
2023-11-21 03:17:49 <kws         > and i dont think it can be token threaded because I certainly want more than e.g. 256 words if i represented a token with a char
2023-11-21 03:19:19 <kws         > is there some sort of resource I could reference to build an intuition about how to implement ITC in C ?
2023-11-21 03:33:01 <zelgomer    > kws, i have the same problem. i "get" forth in assembler, but when i try to write it in c, it becomes confusing.
2023-11-21 03:35:39 <zelgomer    > having said that, my attempts in the past have simply allocated arrays of function pointers. IP is just a void (**ip)(void), and you execute a word with a "while (*ip) (*ip++)();"
2023-11-21 03:36:59 <kws         > hmm, well im glad im not alone. interesting, i see
2023-11-21 07:04:06 <PoppaVic    > hmm.. 74 in forth? Been a long time since I'e seen that.
2023-11-21 07:05:33 <PoppaVic    > only see 2 I seem to recall.
2023-11-21 07:43:12 <KipIngram   > HEY!
2023-11-21 07:43:16 <KipIngram   > Oh, he's gone.
2023-11-21 07:43:30 <KipIngram   > I know that guy pretty well.
2023-11-21 07:44:16 <KipIngram   > I hate I missed him.  He runs a channel called #c-banned that I've hung out on at times.  It's been pretty dead there lately though - that's the first I've seen of him for months.
2023-11-21 12:41:31 <olle        > 
ACTION https://www.youtube.com/watch?v=eA_XHgyhpRU&list=PLJ6S12Wv_o1L0MHOYKzvTTLC4VYc4eBVS  A Brief Introduction to Forth 

2023-11-21 12:50:26 <olle        > Hm way too brief
2023-11-21 14:06:33 <veltas      > I like that they're using SwiftForth though
2023-11-21 14:09:09 <veltas      > olle: Watch this one https://www.youtube.com/watch?v=mvrE2ZGe-rs
2023-11-21 14:09:21 <veltas      > Good little video from ages ago
2023-11-21 14:10:14 <veltas      > By Samuel Falvo II apparently
2023-11-21 14:13:43 <olle        > I did see that one some time ago
2023-11-21 14:13:48 <olle        > Worth another watch
2023-11-21 14:20:32 <veltas      > Oh you don't need to watch it again :)
2023-11-21 14:20:34 <veltas      > Although I did
2023-11-21 14:20:47 <veltas      > I've seen it a couple times, some good stuff to absorb in there
2023-11-21 14:20:51 <veltas      > Although quite opinionated
2023-11-21 14:20:55 <veltas      > KipIngram I think you'd like it
2023-11-21 15:44:30 <olle        > http://www.figuk.plus.com/webforth/En/TutorlT.htm#L17 - spot the html bug
2023-11-21 15:46:26 <veltas      > I don't know how mistakes like that get left
2023-11-21 15:46:55 <veltas      > Also there's more than one mistake in that HTML
2023-11-21 15:47:31 <olle        > Yea?
2023-11-21 15:48:04 <olle        > Oh he left the email for bug reports, hehe
2023-11-21 16:46:55 <KipIngram   > I believe I've seen that - the word "slurp" seems familiar to me.
2023-11-21 17:04:14 <GeDaMo      > I think slurp is from WIl Baden
2023-11-21 17:06:33 <GeDaMo      > Well, I can't see it http://www.wilbaden.com/neil_bawd/
2023-11-21 17:28:45 <KipIngram   > I've definitely seen it used in a video a lot like that one, where a guy was just "ad lib coding" and narrating his thought process.
2023-11-21 18:20:40 <user51      > : wtf 1 . latestxt dup >body 1 th dup @ 1+ over ! drop ;
2023-11-21 18:21:31 <user51      > Does this word seem hacky and probably non-portable? It prints 1 then increments it, so subsequent calls would print 2 3 4 .. and so on
2023-11-21 18:24:29 <Zarutian_iPad> which forth is this written in?
2023-11-21 18:25:10 <user51      > gforth
2023-11-21 18:26:25 <Zarutian_iPad> a question for you rest: would you say forth is a pointfree programming or is in the tacit programming paradigm?
2023-11-21 18:27:27 <Zarutian_iPad> I am not familiar enough with gforth to answer.
2023-11-21 18:36:48 <KipIngram   > user51: Yeah, that strikes me as kind of edgy.  Self modifying code?  It would have to make assumptions about definition structure, so I wouldn't count on it being portable.
2023-11-21 18:37:14 <thrig       > create/does might be more typical for a closure-thingy
2023-11-21 18:37:42 <KipIngram   > I'd just increment and print a stack item.
2023-11-21 18:38:41 <KipIngram   > user51: I'd say that almost anything that modifies an already existing definition would be considered "dangerous and probably non-portable."
2023-11-21 18:39:00 <PoppaVic    > "Bad Juju"
2023-11-21 18:39:54 <GeDaMo      > I wrote a create/does thing that made counters
2023-11-21 18:41:12 <GeDaMo      > : counter:  create 0 , does> dup @ tuck 1+ swap ! ;
2023-11-21 18:41:19 <GeDaMo      > Something like that
2023-11-21 18:42:38 <KipIngram   > You're not compiling the (lit) runtime that needs to precede the literal value.
2023-11-21 18:43:03 <KipIngram   > Oh, never mind.
2023-11-21 18:43:12 <KipIngram   > Yeah, that looks like it would work.
2023-11-21 18:43:30 <user51      > KipIngram: Good to hear.  I read a few bits of the standard and my conclusion was that we can assume a dictionary, but can't assume a specific structure.
2023-11-21 18:43:36 <KipIngram   > Sorry - not enough coffee yet this morning.
2023-11-21 18:43:51 <user51      > Sounds like the morning hasn't started yet :)
2023-11-21 18:44:02 <user51      > I just wrote this too http://0x0.st/HwPq.txt
2023-11-21 18:44:08 <KipIngram   > user51: which is sad, since it's 11:45am here.
2023-11-21 18:45:01 <user51      > KipIngram: Well, just accept self-modifying code and change the time
2023-11-21 18:45:16 <KipIngram   > :-)
2023-11-21 18:45:52 <KipIngram   > I like your fib - nice use of tuck.
2023-11-21 18:46:49 <Zarutian_iPad> KipIngram: clock time is an illusion, morning doubly so.
2023-11-21 20:18:18 <user51      > GeDaMo: Any ideas how to reset that counter? I thought of (1) recreating it, which leaks memory (2) looping until it overflows, which might be a good way to relax
2023-11-21 20:20:44 <GeDaMo      > Which? yours or mine?
2023-11-21 20:21:10 <GeDaMo      > With mine, you can tick the name then do >body to get the address of the value
2023-11-21 20:21:21 <PoppaVic    > 
ACTION chuckles

2023-11-21 20:22:13 <user51      > GeDaMo: Nice, that works
2023-11-21 20:23:11 <PoppaVic    > find the code to var and const.. they are baseline. However, your word then becomes a ONE-OF.. You can't layer them. Unless you create a creator-word and a reset-word, but then you are definitely creating "internal variables"
2023-11-21 20:24:18 <PoppaVic    > You might be best-off with a creator-word that allocates a unit of RAM for counting and then the reset-word frees it.
2023-11-21 20:38:14 <KipIngram   > Yeah, that would be the standard way of resetting it.  The tick operation gets you the address of the data (or something that leads you to it).
2023-11-21 20:38:31 <KipIngram   > Same method lets you change the value of a constant, etc.
2023-11-21 20:44:30 <thrig       > or a closure returns a list of things to call, one of them being a reset
2023-11-21 20:50:04 <KipIngram   > I still struggle a little with the closure idea.  I get it more than I used to, but still not completely.
2023-11-21 20:50:20 <KipIngram   > I have the impression that the idea is straightforward, but is just something I think of in a different way.
2023-11-21 20:50:45 <KipIngram   > The idea of calling one thing to launch a process and then call something else later to get the result seems simple enough to me.
2023-11-21 20:51:50 <KipIngram   > In some of his processors Chuck separated @ into two pieces - first piece intiates the RAM read and the second actually acquires the data.  It's really the same idea, if you think about it.
2023-11-21 20:52:14 <KipIngram   > Normally he put them one right after the other - that single cycle of delay was enough.  But one wouldn't HAVE to do that.
2023-11-21 20:52:33 <PoppaVic    > useful breakout
2023-11-21 20:52:50 <KipIngram   > So I really just look at it as a way of staying busy while waiting for something to happen.
2023-11-21 20:54:32 <KipIngram   > Might be smart to do that with BLOCK too.
2023-11-21 21:08:44 <PoppaVic    > hmm, yeah - unless you go straight to byte-streaming