2023-12-11 04:22:23 <slacko_user13052> I'm looking for some help using jsforth with the 2nd edition of starting forth. I'm using an older version from forthfreak.net - and everything has gone rather well until I got to chaper 3. I can't manage to find any documentation on jsforths block filesystem stuff.
2023-12-11 04:24:59 <GeDaMo      > slacko_user13052: which particular jsforth are you using?
2023-12-11 04:26:04 <slacko_user13052> the one from forthfreak.net - its on archive.org
2023-12-11 04:26:49 <slacko_user13052> I'm using an offline version I saved, but I can go dig up a link if needed
2023-12-11 04:29:32 <slacko_user13052> [04:22] [slacko_user13052(+iw)] [3:libera/##forth(+nt)]
2023-12-11 04:34:38 <GeDaMo      > It seems to store the blocks in cookies?
2023-12-11 04:35:56 <slacko_user13052> and ram
2023-12-11 04:36:36 <slacko_user13052> look at blocks 4-7 they contain the editing words I am having trouble with
2023-12-11 04:37:23 <GeDaMo      > I'm looking at the JS code
2023-12-11 04:37:36 <slacko_user13052> ah, gotcha
2023-12-11 04:37:43 <GeDaMo      > What's the problem you are having?
2023-12-11 04:38:45 <slacko_user13052> I know little about forth (hence the book), and the block edit comands don't apear to be documented
2023-12-11 04:39:29 <slacko_user13052> I figured out how to use some of them to clear blocks, but I can't figure out how to add new stuff to them
2023-12-11 04:43:05 <GeDaMo      > Looks like 1 block gives you the address of block 1 in memory then update should write any changes
2023-12-11 04:47:44 <slacko_user13052> how do I write anything to the in memory block to start with?
2023-12-11 04:48:30 <GeDaMo      > You write to the address you get from block
2023-12-11 04:50:29 <slacko_user13052> sure, but I am a complete novice here, what word does that? do I just push strings into memory with s( and then do a memcpy or something?
2023-12-11 04:52:18 <GeDaMo      > ! or c! write to memory
2023-12-11 04:54:08 <slacko_user13052> ok, I'll take a stab at that. Thanks for your help.
2023-12-11 04:55:53 <slacko_user13052> fwiw I was trying to use the retro line editor in block 7, if you figure out what that suff does, I'm pretty curious about it
2023-12-11 05:44:59 <GeDaMo      > slacko_user13052: I can see the Forth source for the editor in the JS source
2023-12-11 05:45:08 <GeDaMo      > "ramdrive block 3 - modified retro editor"
2023-12-11 07:40:59 <slacko_user13052> @GeDaMo yes thats the thing I was trying to use. I think the ia word is the one that provides the functionality I was loking for, but I don;t know how to use it
2023-12-11 07:45:47 <slacko_user13052> Thanks to your help, and some poking around I've been able to write to blocks using cmove, line, s(, and some other stuff. so I will probaby be able to continue working with the book and this forth implementation - albiet after I write some substitut code
2023-12-11 08:09:27 <slacko_user13052> @GeDaMo I will resend two previous replies that you may not have recieved
2023-12-11 08:10:02 <slacko_user13052> @GeDaMo yes thats the thing I was trying to use. I think the ia word is the one that provides the functionality I was looking for, but I don't know how to use it
2023-12-11 08:10:23 <slacko_user13052> Thanks to your help, and some poking around I've been able to write to blocks using cmove, line, s(, and some other stuff. so I will probaby be able to continue working with the book and this forth implementation - albiet after I write some substitut code
2023-12-11 08:11:08 <GeDaMo      > Yeah, sorry, I'm having some connection problems
2023-12-11 08:11:23 <GeDaMo      > Glad you're making progress :)
2023-12-11 08:13:45 <slacko_user13052> no worries, it happens to everyone who can't be bothered to do the whole remote irssi thing (IE me)
2023-12-11 08:17:13 <slacko_user13052> It feels a bit wierd to be trying to write substitute code using stuff I 'shouldn't know yet' based on the book - but every language and learning experience gets messy sooner or later
2023-12-11 12:35:27 <KipIngram   > slacko_user13052: Don't know if it got mentioned above but move and cmove are useful there too.  Block copies, whereas !, c!, etc. are small item stores.
2023-12-11 12:35:47 <KipIngram   > For an editor I think cmove likely makes the most sense.
2023-12-11 12:36:03 <olle        > Need a new weekly word for /r/forth :d
2023-12-11 12:36:12 <olle        > What about freeing memory?
2023-12-11 12:36:21 <olle        > Never see that mentioned in the books, only how to allocate hahaha
2023-12-11 12:36:38 <KipIngram   > Other than FORGET or marker stuff there's not anything in standard Forth.
2023-12-11 12:37:08 <olle        > Eh?
2023-12-11 12:37:23 <olle        > So just allot and forget :)
2023-12-11 12:37:33 <KipIngram   > slacko_user13052: In my case I wrote my EXPECT word so that a sub-word of it can edit an existing string buffer; I just run that direction on the right part of my block buffer, depending on what line i'm wanting to edit.
2023-12-11 12:37:47 <KipIngram   > Yes, and of course : and variable and so on implicitly allocate.
2023-12-11 12:37:55 <KipIngram   > , does too.
2023-12-11 12:38:23 <KipIngram   > marker is just a different way of implementing forget, that gives you somewhat more capabilities to clean things up.
2023-12-11 12:38:54 <KipIngram   > FORGET has to "figure everything out," where as MARKER creates an item you can later forget to, and stores some helpful information for that process.
2023-12-11 12:39:03 <GeDaMo      > Freeing memory just involves moving the dictionary pointer back which is what forget and marker do
2023-12-11 12:39:31 <GeDaMo      > they erase everything allocated after a specified point
2023-12-11 12:39:35 <zelgomer    > surely you also have to update last
2023-12-11 12:40:16 <GeDaMo      > "Restore all dictionary allocation and search order pointers to the state they had just prior to the definition of name." https://forth-standard.org/standard/core/MARKER
2023-12-11 12:41:04 <KipIngram   > GeDaMo; there are a lot of things that can bite you when you do that if you're not careful, though.
2023-12-11 12:41:13 <KipIngram   > If you've done things like create new vocabularies and so on.
2023-12-11 12:41:30 <KipIngram   > Markers store the info needed to reverse those things.
2023-12-11 12:41:40 <GeDaMo      > Yeah
2023-12-11 12:42:11 <KipIngram   > I "like" FORGET better, but I do see why it can't always do the job well implemented the old fashioned way.
2023-12-11 12:46:47 <zelgomer    > here's a situation i encounter every once in a while. say you have  : foo ( x )  bar baz quux ;  where bar, baz, and quux also need to see x (either to test its value or to write it somwhere). would you normally write it that way and put it on bar, baz, and quux to do ( x -- x ), or would you write those subordinate words to consume it and put dups in foo?
2023-12-11 12:47:27 <zelgomer    > i guess the former is more of pipeline thinking, the latter more parameter passing thinking
2023-12-11 12:53:06 <user51      > olle: I suggest QUIT.
2023-12-11 13:03:04 <olle        > user51: hmmmm
2023-12-11 13:03:07 <olle        > quit is not bye
2023-12-11 13:03:36 <zelgomer    > correct
2023-12-11 13:04:52 <thrig       > q .q ZZ exit control-x control-s
2023-12-11 13:05:42 <thrig       > or was it -c to get out of emacs?
2023-12-11 13:16:24 <olle        > Forget:  This word is obsolescent and is included as a concession to existing implementations.
2023-12-11 13:58:52 <user51      > zelgomer: Maybe using HERE or a variable could help.
2023-12-11 14:01:23 <zelgomer    > if you think here can help me, then i think you misunderstood my question
2023-12-11 14:14:14 <KipIngram   > zelgomer: That would depend a lot on the situation for me, I think.  If the words involved were going to be 'often used in many situations' where they might not be used in tandem with the other words, I'd have them consume their argument, and I'd use dups as needed.
2023-12-11 14:14:57 <KipIngram   > On the other hand, if these words were kind of a one-off situation and arose mostly through factoring, and were unlikely to be used elsewhere, I'd leave x on the stack for the others to have a crack at.
2023-12-11 14:15:14 <KipIngram   > In a single situation - the one above - it's clearly better for the first called words to leave x there.
2023-12-11 14:15:24 <KipIngram   > But there might be broader considerations.
2023-12-11 14:15:49 <KipIngram   > So I've done it both ways, and it "just depends."
2023-12-11 14:16:02 <KipIngram   > How's that for a thrillingly useful answer?  :-|
2023-12-11 14:16:59 <KipIngram   > In my case if I were leaving x in place then a lot of those words would probably get defined with .: instead of : and would very shortly get wiped from the dictionary.
2023-12-11 14:17:11 <KipIngram   > So that they COULDN'T be called from anywhere else.
2023-12-11 14:17:32 <KipIngram   > But a generally useful word should consume its inputs, in my opinion.
2023-12-11 14:23:58 <zelgomer    > what is .:?
2023-12-11 14:24:40 <KipIngram   > That's a word I made up.  It is identical to : except it sets a bit in the new header.
2023-12-11 14:25:05 <KipIngram   > I have another word .wipe that will scan the current vocabulary and "unlink" all words with that bit set from the dictionary.
2023-12-11 14:25:17 <KipIngram   > The definition remains, of course - it's just no longer FINDable.
2023-12-11 14:25:30 <zelgomer    > this is why i've decided to start adopting more conventional words. why would you think that you can communicate with me using words that only you know?
2023-12-11 14:25:38 <KipIngram   > It's just my way to keep from getting a bunch of chaff in my namespaces.
2023-12-11 14:26:10 <KipIngram   > Well, usually in my code the definition of an unusual word is right there a line or two or three above.
2023-12-11 14:26:44 <KipIngram   > But of course you make a point - words should be named as effectively as possible.
2023-12-11 14:27:00 <KipIngram   > They should at least ALLUDE A LITTLE to what they do.
2023-12-11 14:27:23 <zelgomer    > i think .: is fine, my point is more that it's difficult for forthers to talk to each other unless you limit the conversation to words that are commonly well defined
2023-12-11 14:27:27 <KipIngram   > but the name alone can't necessarily convey the full details (total stack effect, etc.)
2023-12-11 14:27:47 <KipIngram   > Yeah, but my first interest in creating my system is to support my own work.
2023-12-11 14:28:14 <zelgomer    > that's fine, but you used a word that only you understand to answer a question posed by me :)
2023-12-11 14:28:14 <KipIngram   > The person I'm most interested in communicating with is future Kip.
2023-12-11 14:28:36 <zelgomer    > not when you're posting to this channel
2023-12-11 14:29:08 <KipIngram   > Well, I have explained what my unusual words do here a number of times.  But anyway, sorry about that.
2023-12-11 14:29:38 <KipIngram   > Stick around long enough and  you'll probably roll your eyes when you see one of those descriptions for the half-dozenth time.
2023-12-11 14:30:25 <KipIngram   > But it's at least a touch intuitive - in Linux any file that leads off with a . is hidden.  That was what motivated the name .: