2023-12-15 03:29:13 <slacko_user13052> About the print-execution thing: you can consider this to be a form of cross-compiling, iirc the standard way to do this is to essentially have two separate forth 'kernels' that you can switch between
2023-12-15 03:44:02 <user51      > I worked on it a bit but my results are probably not portable.
2023-12-15 03:45:45 <user51      > What I did was look at the raw data with DUMP and check for specific contents of cells, which in gforth was noname CODE words.
2023-12-15 03:46:54 <user51      > http://0x0.st/HYP_.txt
2023-12-15 03:47:26 <user51      > Unfinished "sample".  But I think the principles are there.
2023-12-15 03:58:15 <slacko_user13052> imo, the main concern for portability is code structure and documentation
2023-12-15 03:58:55 <slacko_user13052> not having code that is literally able to run anywhere
2023-12-15 04:01:49 <slacko_user13052> anyway, I don;t know if there are any free linux forths that do cross-compilation, but if so, looking at that stuff might get you what you wan't with some hopefully minor modification
2023-12-15 04:04:05 <slacko_user13052> the method you are using should also work, but I can't guess at the relative quality of the approaches
2023-12-15 08:16:24 <KipIngram   > user51: Given the level of the system you're intervening in to implement that print/execute thing I'm not surprised it's non-portable.
2023-12-15 08:17:21 <olle        > How do Forth devs deal with long-running programs and memory?
2023-12-15 08:20:09 <crc         > I generally allocate the needed memory for my data structures & reuse this as needed.
2023-12-15 08:22:33 <olle        > crc: but then you have a known/clear/certain upper bound?
2023-12-15 08:22:35 <KipIngram   > olle: If your application requires dynamic memory management then you basically have to do that yourself.  If it doesn't, then there's really no problem with a Forth program running for a long time.
2023-12-15 08:23:35 <KipIngram   > olle: that's how I read crc's comment.  Sounded like he was talking about cases where he knows what the most he's going to need is and allocates it at the outset.
2023-12-15 08:24:13 <crc         > olle: that's correct
2023-12-15 08:25:00 <olle        > Mm
2023-12-15 08:25:26 <crc         > olle: I have strict limits on ram (65,536 cells on konilo, 524,288 cells on retroforth); I have to be careful with memory use
2023-12-15 08:28:02 <crc         > retroforth recently gained an optional malloc/free extension, but I've not used it other than for brief testing
2023-12-15 08:29:06 <olle        > Right
2023-12-15 08:29:42 <KipIngram   > olle: You could really make comments of this sort about any computer system and any application.  There is always some ultimate limit on availale ram/storage.  It's just that it's quite large in most cases and ultimately you just "assume you won't hit it" for most of the things you do.  But it is there and is a real limit.
2023-12-15 08:29:54 <KipIngram   > They just don't talk about it much in computer science classes.
2023-12-15 08:31:25 <KipIngram   > They kind of imagine this idealized theoretical environment so as to restrict the conversation to the algorithm or whatever under discussion.
2023-12-15 08:32:38 <KipIngram   > I guess, though, one of the purposes of a good operating system is to make those limitations as invisible to you as possible.
2023-12-15 08:34:15 <KipIngram   > Very different in embedded work - you have to be quite aware of the size of the box you're working in, since you're usually trying to make that box as small and cheap as possible.
2023-12-15 09:24:37 <olle        > KipIngram: I think the crucial point is if the dev knows the upper bound or not. Of memory usage.
2023-12-15 09:24:59 <olle        > Yes, embedded is different, true.
2023-12-15 10:15:46 <zelgomer    > forth's postfix notation presents me with naming difficulty. say i have a word "foo" that sets some global flag. what is the right word to remove foo? should i use unary "-foo" as in "negate foo", or "foo-" as in "foo subtract"
2023-12-15 10:25:15 <slacko_user13052> The two main concerns for this sort o thing are conistency and colision avoidance. Choos whatever convention you think you can apply the most consistently without colliding with other conventions you need.
2023-12-15 10:27:30 <slacko_user13052> Also, always consider if you are doing something often enough to justify giving it a convention or scheme.
2023-12-15 10:27:46 <crc         > zelgomer: I'd probably use `foo:on` and `foo:off` for this
2023-12-15 10:28:34 <crc         > but as slacko_user13052 says, as long as your naming is consistent, it'd be fine
2023-12-15 12:38:23 <zelgomer    > thanks
2023-12-15 12:38:42 <zelgomer    > :on :off is tempting
2023-12-15 12:39:36 <GeDaMo      > https://forth.sourceforge.net/mirror/comus/index.html#off
2023-12-15 12:43:29 <gordonjcp   > hm
2023-12-15 12:43:48 <gordonjcp   > I wonder how that would work for a thing with multiple pins on a device
2023-12-15 12:44:03 <gordonjcp   > like bit 0 is a motor, bit 1 is an LED, and so on
2023-12-15 12:44:22 <gordonjcp   > I guess you'd define "MOTOR" to leave the address and bit on the stack
2023-12-15 12:44:46 <gordonjcp   > "ON" would or it into the IO port, "OFF" would complement it then and it out
2023-12-15 12:58:33 <crc         > gordonjcp: I have a `pin:on` and `pin:off` for toggling pins in my embedded system
2023-12-15 21:55:17 <KipIngram   > Ahha... made to the out of town location and have WiFi working.  I can be content now.