2024-05-04 01:00:08 <lf94        > I still don't get postpone's text description to be honest
2024-05-04 01:04:27 <lf94        > Could someone explain "compilation semantics" to me
2024-05-04 01:05:24 <lf94        > Compilation:
2024-05-04 01:05:26 <lf94        > ( "<spaces>name" -- )
2024-05-04 01:05:30 <lf94        > Is this _after_ the word "postpone" ?
2024-05-04 01:06:28 <hello-operator> Yes it is, that's used to indicate it parses a word
2024-05-04 01:06:35 <hello-operator> Like "postpone if"
2024-05-04 01:07:17 <lf94        > What happens in the case of
2024-05-04 01:07:29 <lf94        > postpone [then] parse-name ?
2024-05-04 01:07:52 <lf94        > parse-name takes a name to go find also
2024-05-04 01:08:02 <lf94        > or should it be after also?
2024-05-04 01:21:56 <lf94        > anyone have examples of using "parse" ?
2024-05-04 01:22:01 <lf94        > I think this is actually what Im after :)
2024-05-04 01:53:44 <lf94        > Nice, I fixed it :)
2024-05-04 01:53:50 <lf94        > God damn I love Forth!
2024-05-04 02:09:38 <thrig       > May the FORTH be with you, always. https://thrig.me/tmp/forth-atari.png (NSFW, etc)
2024-05-04 03:25:31 <zelgomer    > lf94: postpone is a parsing word. "postpone [then] parse-name" will execute postpone, which parses [then] and does something with it, then control returns to the outer interpreter loop and parse-name is parsed and executed (or compiled, whatever, depending on state and immediacy)
2024-05-04 03:25:46 <lf94        > yea I figured it out
2024-05-04 03:25:49 <lf94        > i understand everything now
2024-05-04 03:27:06 <zelgomer    > EVERYTHING??
2024-05-04 03:28:31 <lf94        > everything.
2024-05-04 03:36:40 <KipIngram   > lf94: What I THINK postpone does is a) it's immediate, so it executes while the definition it's in is being compiled, and b) it causes execution to skip the word following it in the executing definition, and instead it compiles that word to the definition being COMPILED.
2024-05-04 03:37:23 <KipIngram   > So POSTPONE + would cause + to be compiled to the definition being compiled, and not executed "now."  It doesn't execute until later - when the word being compiled is executed.  + is "postponed" until then.
2024-05-04 03:38:16 <KipIngram   > I haven't used it a lot, so I'm not sure what it would do if you interpreted it (used it outside of a definition).  If you wanted it to behave the same way it would have to be STATE smart.
2024-05-04 03:38:18 <lf94        > yep
2024-05-04 03:38:29 <lf94        > the last sentence you wrote describes it well
2024-05-04 03:39:13 <KipIngram   > There would be no point in using it in interpretive mode, since you don't have a definition being compiled then.
2024-05-04 03:39:18 <zelgomer    > the key is that postpone is aware when the word it parses is immediate and does the right thing
2024-05-04 03:40:06 <KipIngram   > This is what COMPILE used to do.  And if the word you were trying to postpone was itself immediate, there was [COMPILE] for that, I believe.
2024-05-04 03:40:43 <zelgomer    > which means it's not what conpile used to do
2024-05-04 03:41:07 <zelgomer    > "postpone if" compiles if into the word currently being defined, "postpone +" arranges for + to be compiled when the word currently being defined executes
2024-05-04 03:41:16 <KipIngram   > But COMPILE wasn't immediate.
2024-05-04 03:42:13 <KipIngram   > With COMPILE +, both COMPILE and + would get compiled, but then when the word executed it would use the return stack to pull it out of the running definition and put it in the definition under construction.
2024-05-04 03:42:43 <KipIngram   > You would up not executing + "now" because COMPILE skipped the return address over it.
2024-05-04 03:42:56 <KipIngram   > wound
2024-05-04 03:44:10 <KipIngram   > But that worked cleanly because all compiled words took up the same amount of space in the definition, so COMPILE knew how far forward to nudge the return address.
2024-05-04 03:44:29 <KipIngram   > As that doc you had earlier pointed out, that doesn't work as nicely with code threaded systems.
2024-05-04 03:46:01 <KipIngram   > The thing getting copied to the new definition might be a one byte opcode, or a four byte call.  And if it's a call it might be relative, so you couldn't just copy it - you'd have to adjust the relative offset based on where you put it.
2024-05-04 03:46:04 <KipIngram   > Lot of smarts.
2024-05-04 04:03:14 <zelgomer    > ah, forth. the language of terseness.
2024-05-04 05:21:29 <Al2O3       > Forth, the language for the sky in us all.
2024-05-04 05:21:55 <Al2O3       > and maybe some precise, exact, specific, and of course direct threaded interpreted language.
2024-05-04 05:22:49 <Al2O3       > for when we can look up, and forth, into the heavens and then look back from the moon or mars at the Earth, we know how to march Forth.
2024-05-04 05:29:36 <KipIngram   > :-)
2024-05-04 05:29:47 <KipIngram   > Indirect threading isn't that bad.  It has some nice aspects.
2024-05-04 05:29:52 <KipIngram   > And it's the most traditional.
2024-05-04 05:30:21 <KipIngram   > You can isolate your code better with indirect threading, too.
2024-05-04 05:30:33 <KipIngram   > Put all the machien code in one tight little bundle.
2024-05-04 05:33:59 <KipIngram   > Man, I'm trying to stream content from my raspberry pi up in the media room to my notebook, and it's driving me nuts.  I've tried half a dozen different players, I've tried samba and nfs and sftp.  But no matter what I do I get like 0.1 second video freezes (but not audio) every 11-12 seconds or so.
2024-05-04 05:34:03 <KipIngram   > Just enough to notice.
2024-05-04 05:34:18 <KipIngram   > If i play a local file, it's fine.  If I stream it to my work Macintosh, it's fine.
2024-05-04 05:34:58 <KipIngram   > I can even set up an sftp: share from localhost - then if I play file X straight of the disk, it's great - if I play it over the share it gives me those freezes.
2024-05-04 05:35:15 <KipIngram   > I need to just top and see what happens after I upgrade my os in a couple of days.
2024-05-04 05:35:18 <KipIngram   > It might just go away.
2024-05-04 05:35:58 <KipIngram   > Oh, and at least with mpv it reports a full 500+ seconds of buffered data at the time this happens.  So it's NOT data starved.
2024-05-04 16:26:18 <lf94        > I've learned a very, very important fact after this project
2024-05-04 16:26:41 <lf94        > If you want _truly_ portable code, you must operate at the 8-bit level. This is the only way to be memory layout independent...
2024-05-04 16:27:10 <lf94        > I was operating at that level, until I was told most 8-bit forths operate on 16-bit cells (which was sweet!)
2024-05-04 16:27:25 <lf94        > So I moved my code to work with 16-bit cells. But this turned out to be a mess.
2024-05-04 16:28:09 <lf94        > I'm not re-reworking my code to go back to 8-bit ops, but I've implemented a small : reverse-nibbles ... ;
2024-05-04 16:48:04 <KipIngram   > Yeah, once you go beyond eight bits endian stuff comes in.  But you're going to face that sooner or later anyway - even if you have an eight-bit basic system, as soon as you need to deal with a 16-bit quantity, whether you do so "natively" or not, then you have to know what a proper 16 bit quantity is "representing," and that can be different in different systems.
2024-05-04 16:51:19 <lf94        > Nope, I'm making this more painful myself. Now I'm encountering issues with overflow detection. There is no way to detect overflow for $FFFF + $FFFF UNLESS I check a carry bit provided by the CPU. I need a CPU independent check.
2024-05-04 16:51:36 <lf94        > The only way to get this check is to reduce everything back to 8-bits to free up that other byte to check for carry.
2024-05-04 16:53:58 <lf94        > KipIngram: what do you mean? I've implemented 32-bit operations on this 8-bit cpu :)
2024-05-04 16:54:21 <lf94        > Everything was 100% ok until I moved to 16-bit cells
2024-05-04 16:54:27 <lf94        > Kickin my ass rigt now
2024-05-04 17:12:44 <zelgomer    > if you want truly portable code, you've come to the wrong place. i don't understand why you keep bringing this up.
2024-05-04 17:17:22 <lf94        > I don't understand why you say I'm in the wrong place. If anything it feels like I'm really in the right place!
2024-05-04 17:17:52 <lf94        > This is not to do with forth. It's to do with my approach.
2024-05-04 17:18:13 <lf94        > My original approach was actually the most correct: working with bytes and nothing more
2024-05-04 17:23:20 <dave0       > lf94: there is M+ that you can use to detect overflow when adding two cells
2024-05-04 17:23:50 <lf94        > the issue with that is, it won't work on a 32-bit system and an 8-bit system at the same time
2024-05-04 17:24:33 <dave0       > M+ works with cells
2024-05-04 17:24:45 <dave0       > all sizes of cells
2024-05-04 17:24:45 <lf94        > but on x86_64 isnt a cell 64-bits
2024-05-04 17:24:58 <lf94        > It won't work for what I'm doing
2024-05-04 17:25:04 <lf94        > that's nice to know though
2024-05-04 17:25:32 <zelgomer    > dave0: he's trying to implement sha256, so he wants to work with chunks of known width
2024-05-04 17:25:53 <dave0       > oh i see
2024-05-04 17:26:11 <lf94        > It's been a really good exercise
2024-05-04 17:30:28 <lf94        > zelgomer: you haven't explained yet why this is the wrong place :)
2024-05-04 17:31:46 <lf94        > Having Forth that runs on an i7, ~30 years older than the Game Boy CPU, and also the Game Boy CPU... I don't know what truly portable then is.
2024-05-04 17:32:59 <zelgomer    > i have explained it several times, and so have others. you are never going to write code that works in my forth and in kip's forth. forth is a diy macro assembler, there is no such thing as portability here
2024-05-04 17:33:25 <lf94        > I'm not sure how that's true when I've shown the contrary
2024-05-04 17:33:37 <lf94        > You telling me my eyes are fooling me?
2024-05-04 17:34:01 <zelgomer    > if "portability" to you means writing your own forth to run on multiple platforms, then you control the primitives and cell size or endianness should not be an issue to you
2024-05-04 17:34:31 <zelgomer    > lf94: you have not produced code that will work in my forth
2024-05-04 17:34:47 <lf94        > If you and kip's forth implement the usual forth semantics, there is no reason why it couldnt
2024-05-04 17:35:09 <lf94        > I havent tried :)
2024-05-04 17:35:15 <zelgomer    > we /don't/, that's the point!
2024-05-04 17:35:22 <lf94        > then you have written forth-likes
2024-05-04 17:35:34 <lf94        > it's like forth, but it aint
2024-05-04 17:35:40 <dave0       > for fun i did a forth for amd64 with 256 bit cells :-)
2024-05-04 17:35:47 <lf94        > dave0: beauty
2024-05-04 17:36:01 <lf94        > dave0: im very new to forth. im about a month in
2024-05-04 17:36:13 <lf94        > before this, I had always read about it, but seemed way too esoteric, and not useful
2024-05-04 17:36:22 <dave0       > oh i took years before i got anything working
2024-05-04 17:36:22 <zelgomer    > seriously? you're going to declare yourself now the arbiter of what is and isn't forth?
2024-05-04 17:36:25 <lf94        > having a second or third look, my mind is completely transformed.
2024-05-04 17:36:58 <lf94        > zelgomer: no, by definition of what ive read by prolific forth creators and users, I think it's pretty clear
2024-05-04 17:37:09 <lf94        > zelgomer: you're telling me you have higher authority than them?
2024-05-04 17:37:15 <lf94        > not a very good look.
2024-05-04 17:37:39 <zelgomer    > i'm not claiming any authority, that's what you are doing
2024-05-04 17:37:45 <lf94        > that's fine though, you're a high confidence kind of person
2024-05-04 17:38:08 <dave0       > lf94: the general idea i got from forth was you tailor your forth to the job at hand
2024-05-04 17:38:10 <lf94        > very opinionated vs what others generally say and think
2024-05-04 17:38:21 <lf94        > dave0: yep
2024-05-04 17:38:33 <lf94        > you create your own little dsls
2024-05-04 17:39:14 <zelgomer    > ... which means every forth dsl will have its own nuances and be a little different
2024-05-04 17:39:16 <dave0       > are you trying to do sha256 on a gameboy?
2024-05-04 17:39:29 <lf94        > "trying" -> I already did :)
2024-05-04 17:39:34 <dave0       > oh
2024-05-04 17:39:50 <lf94        > https://www.youtube.com/watch?v=1cg2rssdJvE
2024-05-04 17:39:54 <lf94        > Works on gforth and gbforth
2024-05-04 17:39:59 <dave0       > then the job is done?
2024-05-04 17:40:13 <lf94        > Not quite, because the hash is incorrect on Game Boy, because of memory layout :).
2024-05-04 17:40:41 <lf94        > because I foolishing went from handling everything as 8-bits to gbforth's 16-bit cell size...
2024-05-04 17:44:26 <lf94        > zelgomer: you create your own dsls _using forth_. the underlying forths will all have common ground. that common ground is all you need for portability.
2024-05-04 17:44:38 <lf94        > [if] [then] basically makes it possible. if it doesnt exist, you can add them
2024-05-04 17:44:57 <lf94        > that's what I had to do for gbforth
2024-05-04 17:45:18 <lf94        > now it's just a flag at the top of the file to switch between gbforth and gforth
2024-05-04 18:07:21 <KipIngram   > lf94: I just mena that your cpu has an expectation of how a 32-bit value is going to appear in memory, and some other cpu might have a different expectation.  Obviously there are ways to deal with it, but you have to do that somewhere in your code.  If you're working with bytes and building the wider quantities yourself, then you have to build then little endian or big endian, and which one "works" will
2024-05-04 18:07:23 <KipIngram   > depend on the cpu you're running on.
2024-05-04 18:08:56 <KipIngram   > My approach in such a situation would be to try to encpsulate all those things in one part of my code and have that part well separated, and just "touch it" appropriately when I moved to a new platform.
2024-05-04 18:09:39 <KipIngram   > I don't think an 100% portable approach would be IMPOSSIBLE, but it's almost certain to be less performant in a significant way.
2024-05-04 18:12:15 <KipIngram   > You'll have to have SOME native code in your system - I'd just try to include a compact set of words in that that "dealt with" these platform dependent things.  And then the REST of the system would be made portable.
2024-05-04 18:12:37 <KipIngram   > Like, you could have a word that returned overflow status.
2024-05-04 18:12:50 <KipIngram   > And got it however that particular CPU offers it.
2024-05-04 18:13:29 <KipIngram   > A problem with that, though, is that if your inner interpreter involves any addition then it would overwrite the overflow info before you could get your hands on it via another word.
2024-05-04 18:13:46 <KipIngram   > It would only persist until the next addition, so if the engine does one, your info is gone.
2024-05-04 18:14:52 <KipIngram   > So if you wanted, say, a bignum package, you'd probably have to write parts of it as primitives.
2024-05-04 18:15:44 <KipIngram   > You could define a "bignum +" word that left the overflow status as a flag on the stack, but you wouldn't want that to be your normal +.
2024-05-04 18:16:36 <KipIngram   > Or you could implement a system level flags facility, but then all your primitives would have to maintain it.
2024-05-04 19:19:06 <rendar      > let's say i have a word ASSERT>0 which peeks the top of the stack, check if its an integer >0 and does nothing, doesn't push any value into the stack, but if the value is an integer == 0 it returns an error. This word makes sense, right?
2024-05-04 19:40:04 <zelgomer    > lf94> zelgomer: you create your own dsls _using forth_.
2024-05-04 19:40:20 <zelgomer    > and then i use my dsl to write programs that are compiled onto the target
2024-05-04 19:40:27 <zelgomer    > my compiler doesn't go to the target
2024-05-04 19:41:09 <zelgomer    > does that make it not forth?
2024-05-04 19:41:29 <zelgomer    > even my compiler doesn't comply with ans
2024-05-04 19:41:38 <zelgomer    > does that make it not forth?
2024-05-04 19:42:00 <rendar      > hi zelgomer
2024-05-04 19:43:16 <zelgomer    > lf94: case in point ^
2024-05-04 20:01:37 <KipIngram   > Sure, that makes sense.
2024-05-04 20:22:32 <MrMobius    > I suppose Chuck Moore's forths aren't forth either then
2024-05-04 20:24:19 <MrMobius    > about portability, I think you could do it if you stuck to a few rules you knew beforehand
2024-05-04 20:25:37 <MrMobius    > you might be tempted to load a certain byte of a 32 bit value to check the sign or something so the forth would have to provide enough primitives that there's no reason to read bytes out if larger types
2024-05-04 20:26:06 <MrMobius    > and then the programmer has to stick to the convention and not use c@ where it would cause problems
2024-05-04 20:28:10 <KipIngram   > I'm very sure portability was not on Chuck's mind even a little.
2024-05-04 20:28:22 <KipIngram   > It's entirely contrary to his philosophy.
2024-05-04 20:30:41 <KipIngram   > His thinking is very geared to solving single specific problems - the one that's in front of you right now.
2024-05-04 20:37:30 <nmz         > he ports forth to the machine, he doesn't port the machine to forth
2024-05-04 20:37:55 <nmz         > or maybe that's backwards
2024-05-04 20:39:47 <zelgomer    > i think it's fair to say chuck went well into the "port the machine to forth" path
2024-05-04 20:56:08 <KipIngram   > I know what you mean.  For each new system the Forth he writes for it will be optimized to take advantage of that machine's strengths - he doesn't try to have a Forth that he shoehorns onto everythin.
2024-05-04 20:56:19 <KipIngram   > He lets the hardware steer  him.
2024-05-04 21:30:42 <lf94        > rendar: yes
2024-05-04 21:30:51 <lf94        > Guys why'd you ignore that guy :')
2024-05-04 21:31:08 <lf94        > rendar: that makes sense to me. your error though will be a stack value no?
2024-05-04 21:31:33 <lf94        > Sorry I'm painting my house right now - I wouldve answered right away
2024-05-04 21:32:42 <zelgomer    > i might have called it 0>assert or just 0> abort" message"
2024-05-04 21:33:46 <lf94        > +1
2024-05-04 21:35:20 <lf94        > rendar: you may want assert>0 to return values in both cases depending what kind of error you want to do-
2024-05-04 21:35:26 <lf94        > we're assuming you want the program to halt
2024-05-04 21:35:34 <lf94        > (so you'd call abort as zelgomer suggested)
2024-05-04 21:36:17 <zelgomer    > my point is more that i'd put the condition first, following the rpn style
2024-05-04 22:18:17 <rendar      > no the error is not returned into the stack, it's "thrown", my own version of forth can throw errors
2024-05-04 23:19:58 <Al2O3       > Mr. Chuckies forth is forth, just maybe not ANS forth.   Forth can be whatever you want it to be, stripped down bare metal, fat as a opera singer, up to you.
2024-05-04 23:21:28 <Al2O3       > Best forth I can even imagine is a bare metal forth, well implemented, and then layers of garbage provided either by folks that use it a lot and leverage it in a general way, and call themselves toolsmiths and consultants.
2024-05-04 23:44:31 <lf94        > rendar: im not sure throwing errors is forthy
2024-05-04 23:44:35 <lf94        > rendar: how does the system work
2024-05-04 23:44:44 <zelgomer    > this guy
2024-05-04 23:44:50 <lf94        > I said "I'm not sure"
2024-05-04 23:44:56 <lf94        > this guy
2024-05-04 23:45:06 <lf94        > busy policing
2024-05-04 23:45:18 <zelgomer    > many forths have a throw/catch
2024-05-04 23:45:37 <lf94        > thank you for the useful answer