2021-06-19 06:11:26 <NieDzejkob  > or make the barrier push ONLY too
2021-06-19 10:53:52 <cbridge     > <mark4> KipIngram, after laying down the barrier the coder should add what ever vocs he needs in there, root should automatically be in there if your vocs are like mine, without root in contex
2021-06-19 10:54:01 <cbridge     > <mark4> so "ONLY" is implied for me
2021-06-19 10:57:44 <cbridge     > <KipIngram> Yeah, I do want the system to be capable of "cutting itself off" from recovery if I so choose.
2021-06-19 10:58:07 <cbridge     > <KipIngram> That's a good thing to have for "canned applications."
2021-06-19 11:03:22 <cbridge     > <KipIngram> That is, I want to be able to make a set of "application words" available and then disconnect from everything else.
2021-06-19 11:11:15 <cbridge     > <mark4> you can do only previous :)
2021-06-19 11:16:22 <crc         > not if the application words are all that's left visible :)
2021-06-19 11:36:22 <cbridge     > <KipIngram> Right.
2021-06-19 11:36:33 <cbridge     > <KipIngram> For a canned application like that you'd leave only the app words.
2021-06-19 11:36:47 <cbridge     > <KipIngram> That would then be an app you could use in a kiosk or something like that - a public app.
2021-06-19 11:37:12 <cbridge     > <KipIngram> Of course it would be silly to do that to yourself during development.
2021-06-19 11:37:28 <cbridge     > <KipIngram> You'd always compile "only Forth" into the app vocabulary until you were done.
2021-06-19 11:43:21 <cbridge     > <mark4> yea i can do forth definitions ' only alias only only previous
2021-06-19 11:43:35 <cbridge     > <mark4> and remove all vocs from context but still have a definition for "only" in my root voc :)
2021-06-19 11:44:36 <cbridge     > <mark4> x4 also allows you to seal by removing only the root voc, that way unless thes a backdoor the user is restricted to only the vocs you have set up for them
2021-06-19 11:45:13 <cbridge     > <mark4> might be good for a multi user dungeon where players get one set of vocs, admins get another set and devs get yet anotger
2021-06-19 12:07:21 <crc         > I don't have vocabularies, but do have ways of sealing off the dictionary.
2021-06-19 12:12:07 <cbridge     > <veltas> I guess the way to do this in standard forth would be to just write another interpreter that only accepts a defined set of words
2021-06-19 12:13:24 <cbridge     > <KipIngram> Well, I don't really regard that as the "purpose" of the vocabulary mechanism - it's really just a "perk."
2021-06-19 12:27:22 <cbridge     > <mark4> ok so why does access #forth list only show bogen85 and kip not anyone else lol
2021-06-19 12:27:31 <cbridge     > <mark4> and who is this mysterious *!*@freenode-3oj.lut.9f6ob8.IP
2021-06-19 12:27:31 <cbridge     > <mark4> :)
2021-06-19 12:39:08 <cbridge     > <mark4> a bunch of opers here had their access removed, i guess teething problems wth chanserv
2021-06-19 12:39:13 <cbridge     > <mark4> so im adding you all back in
2021-06-19 12:39:55 <cbridge     > -!- ChanServ changed mode/#forth -> +o  cmtptr
2021-06-19 12:41:52 <cbridge     > -!- mark4 changed topic to "Dedicated to the only programming language you will ever need and probably never use :)"
2021-06-19 12:42:25 <cbridge     > <mark4> if someone can remember the old /topic go ahead and set it :)
2021-06-19 12:47:08 <cbridge     > -!- veltas changed topic to "Forth Programming | do drop >in | If you have two (or more) stacks and speak RPN then you're welcome here! | http://forth.chat for more information and related cha
2021-06-19 12:47:25 <cbridge     > <veltas> That's just the one in liberachat, change it if you want
2021-06-19 12:49:46 <cbridge     > <mark4> that one is good :)
2021-06-19 12:50:07 <cbridge     > <mark4> it is at least similar to the one we had here before, maybe identical
2021-06-19 12:50:43 <cbridge     > <mark4> who hosts and pays for forth.chat ?
2021-06-19 12:51:36 <cbridge     > <mark4> yea seems like mostly a anti fn political statement lol
2021-06-19 12:52:22 <cbridge     > <mark4> but thats ok too
2021-06-19 13:06:03 <crc         > mark4, that'd be me
2021-06-19 13:07:30 <cbridge     > <mark4> aha :)
2021-06-19 13:07:49 <cbridge     > <mark4> i only looked at the one page there
2021-06-19 13:08:04 <cbridge     > <veltas> Apparently it's ordered by activity
2021-06-19 13:08:34 <crc         > Activity / number of users
2021-06-19 13:10:34 <imode       > "anti fn political statement" lmao.
2021-06-19 13:12:33 <crc         > I'm not sure how many are in the freenode channel since clog is down, but I'm pretty sure there are more on this side, based on the pre-"let's scrap the existing users/channels" point when I was l
2021-06-19 13:13:26 <cbridge     > <mark4> 23 here not including chanserv
2021-06-19 13:13:33 <cbridge     > <mark4> but its not a competition :)
2021-06-19 13:13:37 <veltas      > Why are only some of the liberachat messages coming through
2021-06-19 13:14:09 <imode       > because I explicitly requested that crc exclude me from the bridge. 'cuz I don't want to be present on that pile of cancer.
2021-06-19 13:14:14 <crc         > veltas: a couple of people have requested to be excluded from the bridging
2021-06-19 13:14:21 <veltas      > That breaks it a bit
2021-06-19 13:14:50 <crc         > A little, yes
2021-06-19 13:14:57 <veltas      > That's a bit like asking to not be on a public log
2021-06-19 13:15:29 <imode       > I'm not really complaining. if you want to converse with those individuals, move to libera. *shrug*
2021-06-19 13:15:32 <cbridge     > <mark4> i dont think you need to do that, they can /ignore the bridge
2021-06-19 13:15:43 <imode       > no, my messages would still be relayed.
2021-06-19 13:15:56 <imode       > which I don't want to. public logging is one thing. transmitting that log to another network is another thing.
2021-06-19 13:16:02 <cbridge     > <mark4> and i consider this to be a public forum where there is no expectation of privacy
2021-06-19 13:16:14 <imode       > nah, it's not privacy, it's my messages being consumed by a hostile network.
2021-06-19 13:16:25 <cbridge     > <mark4> all i have to do is go look at the logs for the other channel assuming clog is functioning
2021-06-19 13:16:39 <imode       > great, that's you. I'd rather fleenode not have my messages.
2021-06-19 13:17:00 <cbridge     > <mark4> so why would free(a); where a is zero work just fine but a subsequent free(b) fails with invalid pointer ?
2021-06-19 13:17:00 <cbridge     > <mark4> b is also 0
2021-06-19 13:17:02 <imode       > same with the other users that excluded it. it's not exactly a hard thing. just don't participate.
2021-06-19 13:17:47 <veltas      > I'm not finding this very constructive, especially since you seem to want to just use this 'feature' of the bridge to exclude people and argue without response
2021-06-19 13:17:53 <cbridge     > <iv4nshm4k0v> mark4: +1, but I gather people should be allowed to be inconsistent.
2021-06-19 13:18:36 <imode       > https://stackoverflow.com/questions/2354658/freeing-a-null-pointer
2021-06-19 13:19:14 <imode       > veltas: just because you don't agree with it doesn't mean it's within my rights on this network.
2021-06-19 13:19:15 <crc         > mark4: how is it failing?
2021-06-19 13:19:31 <imode       > s/it's/it's not
2021-06-19 13:19:44 <cbridge     > <mark4> it is giving me a free(): invalid pointer error
2021-06-19 13:19:59 <cbridge     > <mark4> #c says that is indicitive of corruption elsewhere
2021-06-19 13:19:59 <veltas      > imode: I didn't say it's not within your rights (!?)
2021-06-19 13:20:01 <imode       > if it's out of range or you've freed it in the past, you'll get that.
2021-06-19 13:20:07 <cbridge     > <mark4> which i beleive could be correct
2021-06-19 13:20:39 <remexre     > mark4: can you run the program with asan/ubsan?
2021-06-19 13:20:55 <imode       > valgrind would also do it.
2021-06-19 13:21:01 <crc         > If noth a and b are zero, it shouldn't have any action
2021-06-19 13:21:39 <cbridge     > <mark4> probably not right now, part of what im doing here is tidying up some glaringly obvious alloc/free issues lol
2021-06-19 13:22:03 <cbridge     > <mark4> not well organized but i know the solution and was working my way towards it when this happened
2021-06-19 13:22:26 <cbridge     > <mark4> early stages of the cleanup.  issue might disappear once ive unzigged all the zigs and unzagged all the zags
2021-06-19 13:22:49 <cbridge     > <mark4> for now ill put guards around the frees
2021-06-19 13:23:11 <imode       > valgrind should tell you where the originating faults are.
2021-06-19 13:24:48 <remexre     > mark4: guards doing what? most malloc implementations I've seen don't let you see whether an address is live or not
2021-06-19 13:25:07 <cbridge     > <mark4> if(a) { free(a); } etc
2021-06-19 13:25:28 <remexre     > oh; free is defined to be a no-op on null pointers though
2021-06-19 13:25:36 <cbridge     > <mark4> a double free is not the issue here
2021-06-19 13:25:44 <cbridge     > <mark4> yup
2021-06-19 13:25:47 <remexre     > so if this is your system's libc's free, that really really ought not to make a difference
2021-06-19 13:27:22 <cbridge     > <mark4> one of the quirks of the language im not enamoured of :)
2021-06-19 13:27:48 <cbridge     > <mark4> right now i just have a series of if(a) { free(a); a = NULL; }
2021-06-19 13:28:42 <veltas      > Because parts of the conversation are masked by the bridge, it's much easier to read this from mark4's perspective if I sit in freenode (or /ignore imode and anyone else who's ignored by the bridge)
2021-06-19 13:28:48 <remexre     > yeah idk, asan or valgrind should be able to find the problem in like 5sec
2021-06-19 13:29:31 <imode       > veltas: the community is where the majority of the people are, not a loose fragment of a community. if you find it easier to be over there.. go over there.
2021-06-19 13:29:33 <remexre     > asan should just be adding --sanitize=address to CFLAGS & LDFLAGS, valgrind should just be a wrapper around the program (so valgrind ./mything args)
2021-06-19 13:29:51 <remexre     > (both will be more helpful w/ debuginfo compiled in, ofc)
2021-06-19 13:30:15 <veltas      > imode: I'm on both networks
2021-06-19 13:30:26 <cbridge     > <mark4> yes but even if i fix THIS problem now i basically have no order or logic to where and when i do the allocations and frees
2021-06-19 13:30:35 <imode       > veltas: cool, then that's your choice. not being picked up on the bridge is my choice.
2021-06-19 13:30:37 <cbridge     > <mark4> first impose order, then track down what ever issues might exist
2021-06-19 13:30:47 <cbridge     > <mark4> and imposing the order might be the solution anyway
2021-06-19 13:30:52 <veltas      > imode: And no the community is never "where the majority of the people are", it's where the community is. And the community is in more than one place, sorry to tell you.
2021-06-19 13:31:10 <veltas      > If that was true then probably comp.lang.forth or some godforsaken place would be 'the community'
2021-06-19 13:31:14 <imode       > loooool.
2021-06-19 13:31:29 <imode       > yeah, if that was the case then freenode would still be the hub. and 69 people wouldn't be here.
2021-06-19 13:31:30 <cbridge     > <mark4> the community is diverse and divided.  thats ok too
2021-06-19 13:32:00 <cbridge     > <crab> howdy
2021-06-19 13:32:32 <imode       > a community is people, people moved. accept that and just move on.
2021-06-19 13:32:33 <cbridge     > <veltas> imode has made it very clear that according to them it's *not* okay if you want to use freenode
2021-06-19 13:32:52 <cbridge     > <mark4> i thank them for their opinion :)
2021-06-19 13:32:53 <imode       > yeah, that's the words I used.
2021-06-19 13:33:10 <cbridge     > <mark4> they are free to chose not to be here on this server
2021-06-19 13:33:10 <veltas      > There is more than one way to communicate
2021-06-19 13:33:21 <imode       > I'm sure you wake up and choose the best way.
2021-06-19 13:33:33 <imode       > I'm glad I irritate you that much. :)
2021-06-19 13:33:58 <veltas      > imode: I'm just calling you out for your unconstructiveness
2021-06-19 13:34:10 <imode       > says the one being unconstructive.
2021-06-19 13:34:17 <imode       > that word isn't a catch-all for "people I disagree with".
2021-06-19 13:34:40 <imode       > it's not a magic adjective that makes people agree with you.
2021-06-19 13:34:51 <cbridge     > <crab> this conversation again :(
2021-06-19 13:34:59 <cbridge     > <mark4> well inode is entitled to his opinion and was always free to express it in freenode #forth, i cannot impose that primary law for my channel on the other servers
2021-06-19 13:34:59 <cbridge     > <mark4> but
2021-06-19 13:35:10 <cbridge     > <mark4> i think arguing it is also counter productive :/
2021-06-19 13:35:38 <cbridge     > <veltas> I think it's fine if you state your position and don't waste a ton of effort on it
2021-06-19 13:35:46 <cbridge     > <veltas> I don't have much else to say about it
2021-06-19 13:35:46 <cbridge     > <mark4> crab i think as long as liberia is waging its war against freenode this conversation annot die
2021-06-19 13:36:06 <cbridge     > <mark4> im constantly bombarded with "why are you still on this server.  this channel has moved to liberia" messages
2021-06-19 13:36:08 <imode       > "I don't have much else to say about it" other than you continuing this conversation lmaoooo.
2021-06-19 13:36:22 <crc         > mark4: I see those here too :)
2021-06-19 13:36:56 <cbridge     > <mark4> the ONLY way this will stop is when WE stop listening to the trolls doing it
2021-06-19 13:36:58 <imode       > the ones who are concerned about people telling them which network to use typically are the ones who initiate conversations about which network to use.
2021-06-19 13:37:18 <cbridge     > <mark4> the easiest way to get a troll out of an irc channel for example is to just totally ignore him as if he were not there or to silence him.
2021-06-19 13:37:19 <imode       > which was me. about a week and a half ago.
2021-06-19 13:39:28 <remexre     > so, in forth-related convo
2021-06-19 13:40:15 <remexre     > anyone know of anywork doing a touchscreen forth env that's "better" than just an on-screen kbd
2021-06-19 13:40:36 <remexre     > (e.g. lets one type in terms of words, w/ suggested words populated from the wordlist or something)
2021-06-19 13:40:53 <imode       > I saw something _like_ a touchscreen forth env.
2021-06-19 13:41:06 <imode       > let me see if I can find a video of it, it might've just been kb/mouse driven.
2021-06-19 13:41:19 <imode       > think it was called "brief" or something.
2021-06-19 13:41:45 <imode       > yeah it was kb/mouse driven, lame.
2021-06-19 13:47:32 <crc         > I explored this a bit in retro on ios; I had a keyboard that provided access to defined words, presented as a sorted list (namespace, then sorted alphabetically). It wasn't really any better than
2021-06-19 13:48:29 <crc         > Might have been more useful if i had less words to select from though.
2021-06-19 13:48:37 <remexre     > hm, unfortunate; do you think it might've been better if it had some "smarts" about the list order?
2021-06-19 13:48:44 <imode       > maybe it could be sorted by some sort of stack effect? there was this structural editor for haskell named lambdu or lamdu or something that came up with valid extensions to an expression.
2021-06-19 13:49:04 <remexre     > imode: yeah, that's exactly the sorta thing I'm thinking of (in general for touchscreen editors)
2021-06-19 13:49:35 <imode       > because the number of unique stack effects is limited across the dictionary, and assuming they could be "typed" or at least quantified, you could narrow it by the thing you want.
2021-06-19 13:50:23 <crc         > If I track the stack effects during editing, that could work.
2021-06-19 13:50:44 <imode       > you could annotate the elements of each effect as well, make them user-exposable for fast lookups.
2021-06-19 13:50:55 <imode       > it wouldn't be "typing" but you could search by annotation.
2021-06-19 13:51:15 <crc         > But as is, with ~450 words in the core dictionary on iOS, it wasn't usable with a standard text editor
2021-06-19 13:51:37 <crc         > I should do some analysis on the stack effects...
2021-06-19 13:53:09 <imode       > if you have some user defined types you could mine from you could do stuff like ( list int -- any )
2021-06-19 13:53:48 <crc         > 133 of 535 words have unique diagrams for the data stack
2021-06-19 13:54:31 <crc         > Mine use a terse form, more like (li-a) in that case
2021-06-19 13:55:44 <imode       > neat, do you have the opportunity to define new types?
2021-06-19 13:57:30 <crc         > Types are a convention; this is still just forth
2021-06-19 13:58:03 <imode       > true, but I was wondering if you could just annotate them with, well, anything.
2021-06-19 13:58:20 <crc         > Technically yes
2021-06-19 13:58:32 <imode       > neat.
2021-06-19 13:59:18 <crc         > I have some general conventions, which are being refined to ensure consistency.
2021-06-19 14:00:24 <crc         > A lot of my current work is in cleaning things up that have accumulated over the years.
2021-06-19 14:01:03 <imode       > how old is retro as a project?
2021-06-19 14:01:10 <crc         > Stuff like a more structured editor are things I want to attempt in the future once the rest is done
2021-06-19 14:01:32 <crc         > Hmm, 22 or 23 years
2021-06-19 14:02:13 <imode       > nice.
2021-06-19 14:02:23 <imode       > forth don't die.
2021-06-19 14:02:37 <crc         > It was started by Tom Novelli; I took over in 2000 and have been evolving and rewriting it continuously since then
2021-06-19 14:03:06 <crc         > Indeed :)
2021-06-19 14:08:32 <cbridge     > <KipIngram> Guys, this is a fantastic lecture on the Antikythera mechanism:
2021-06-19 14:08:35 <cbridge     > <KipIngram> https://www.youtube.com/watch?v=xWVA6TeUKYU
2021-06-19 14:08:41 <cbridge     > <KipIngram> Very detailed and scholarly.
2021-06-19 14:08:53 <cbridge     > <KipIngram> Blows my mind that the ancient Greeks could pull something like that off.
2021-06-19 14:11:30 <crc         > Hmm, FreeBSD 13 doesn't seem to have `as`
2021-06-19 14:15:46 <cbridge     > <iv4nshm4k0v> 
ACTION thinks of http://scp-wiki.net/scp-227 instantly

2021-06-19 14:20:39 <cbridge     > <crab> I've thought some about touchscreen interfaces, but not for forth specifically
2021-06-19 14:20:45 <cbridge     > <crab> I shall have to ruminate on that
2021-06-19 14:21:48 <remexre     > yeah, the main language I've thought about them for is a typed and total lisp, where analyzing both the syntax and semantics is way easier, so filtering suggested tokens is pretty simple
2021-06-19 14:23:52 <cbridge     > <crab> I was thinking how I should approach input with gba as well
2021-06-19 14:24:26 <cbridge     > <crab> I will need some sort of virtual keyboard but i'd like to limit its use as much as possible
2021-06-19 14:26:56 <imode       > remexre: what's interesting is that, via "structural typing" (stack effects) you could build your intended syntax.
2021-06-19 14:27:12 <imode       > in a concatenative lang.
2021-06-19 14:28:48 <remexre     > oh, on the syntax side I meant that once words start being able to play with the input buffer, trying to parse programs with holes gets really really hard
2021-06-19 14:29:57 <imode       > ugh, true.
2021-06-19 14:29:59 <crc         > remexre: in my case, that's not an issue
2021-06-19 14:30:05 <imode       > oh?
2021-06-19 14:30:37 <crc         > retro operates on individual input tokens, there are no words that parse ahead
2021-06-19 14:30:44 <imode       > oh that's nice.
2021-06-19 14:31:02 <imode       > as in, you can't parse ahead of the word you're executing?
2021-06-19 14:31:12 <crc         > correct
2021-06-19 14:31:39 <imode       > what's an immediate word look like in retro? do they just not exist?
2021-06-19 14:32:14 <crc         > I still have immediate words, but mainly to inline machine code when necessary
2021-06-19 14:32:40 <imode       > ah fair.
2021-06-19 14:34:22 <imode       > my solution to that for my concatenative lang was... nothing. don't parse anything. you wanna go through stdin, fine, but there's no lookahead.
2021-06-19 14:34:43 <imode       > it does have nested lists and most of the nicities of postcript and joy though. so a forth, eh.
2021-06-19 15:53:09 <neuro`      > Do you try to base it on a particular standard for your Forths?
2021-06-19 15:53:30 <neuro`      > KipIngram how about you?
2021-06-19 15:53:51 <crc         > I do not follow any of the standards in mine
2021-06-19 15:55:15 <neuro`      > Yes, I could tell that for retro pretty much, although perhaps some inspirations?
2021-06-19 15:56:29 <crc         > I only look at the standards documents when trying to find info for others; my path diverged from traditional Forth long ago
2021-06-19 15:56:49 <neuro`      > I really like the literate programming and functional style with use of nonames
2021-06-19 15:57:27 <crc         > From what I've seen of Kip's code, it doesn't appear to be ANS based
2021-06-19 16:00:43 <crc         > mark4's systems are non-standard, though more traditional than most of the ones I watch. He's anti ANS, but not necessarily some of the older standards.
2021-06-19 16:02:20 <crc         > ciforth (lina, wina) follow a FIG model IIRC; gforth is ANS+extensions; jonesforth is non standard; (there are definitely more non-standard implementations than standard ones)
2021-06-19 16:04:02 <neuro`      > I wonder the degree of portability across these Forths considering the "core" word definitions. But I suppose it varies greatly.
2021-06-19 16:04:13 <neuro`      > Portability of the user applications that is
2021-06-19 16:05:02 <crc         > http://forthworks.com/forth/family-tree.txt has a sort of family tree, showing at least influences from the standards
2021-06-19 16:05:18 <neuro`      > Great
2021-06-19 16:08:10 <crc         > I should probably expand/update that a bit to add in the Forth200x stuff
2021-06-19 16:17:57 <imode       > ooo
2021-06-19 16:29:56 <crc         > I've thought about setting up something to gather and link to information on forth systems
2021-06-19 16:36:32 <veltas      > neuro_: As far as I'm concerned, at least since ANS forth, every standard attempt has introduced words that are either totally out of the spirit of forth, or have a dumb name for something most people already
2021-06-19 16:37:06 <veltas      > And this isn't a knee jerk reaction, it's the unfortunate realisation I had very slowly while trying to be open minded
2021-06-19 16:37:32 <veltas      > I think fig Forth is straight up better than standard forth, although it lacks some of the comfort features you expect on a modern system
2021-06-19 16:38:08 <veltas      > Unlike most other languages, when I see a non-standard forth I go ahead and try it. Sometimes the deviations improve it, sometimes not, but every time the design and unique features I tend to find interesting
2021-06-19 16:41:29 <veltas      > There are still benefits to trying to conform to a standard, of course. You're going to get more immediate familiarity. And although as crc said most forths aren't standard, the *most* comptibility you can ge
2021-06-19 16:52:00 <crc         > I wish there were metrics on that
2021-06-19 17:00:00 <veltas      > Well even without metrics it's quite contrived to worry about compatibility in forth, it's really not the point of forth
2021-06-19 17:00:13 <veltas      > But sometimes it is a concern, for a certain class of forths
2021-06-19 17:00:55 <imode       > fun fact: death road to canada uses forth.
2021-06-19 17:03:09 <veltas      > Oh yeah?
2021-06-19 17:03:19 <imode       > yeah, I was kinda shocked.
2021-06-19 17:03:34 <imode       > it's used as the scripting language for the game.
2021-06-19 17:03:42 <imode       > I think with a very thin shim to SDL.
2021-06-19 17:32:07 <brainfunnel > veltas: if I wanted to model a forth I want to write after any particular standard, would you say I should shoot for ANS? or something which preceded it?
2021-06-19 17:33:42 <neuro`      > Actually that's the reason I had in mind when asking. I'm currently writing one for Z80 slowly, but checking existing implementations, there's quite a bit of variety. I kind of want to be able to
2021-06-19 17:34:35 <neuro`      > As for the inner interpreter, I pretty much copied what's in Threaded Interpreted Languages for now, it seems quite thightly packed. I'll try to improve it if I can at some point.
2021-06-19 17:38:47 <veltas      > brainfunnel: Shoot for something like ANS or fig Forth. I.e. change stuff if you can make it easier for yourself
2021-06-19 17:39:10 <veltas      > If you find yourself implementing ENVIRONMENT? you've gone the wrong way
2021-06-19 18:58:37 <KipIngram   > neuro`: I'm sorry - what exactly is the question?
2021-06-19 18:58:48 <KipIngram   > How about me what?
2021-06-19 18:59:06 <KipIngram   > Immediate words?
2021-06-19 18:59:12 <KipIngram   > I do have support for immediate words.
2021-06-19 18:59:51 <KipIngram   > However, one thing that requires immediate words in most Forth implementations is the compiling of jumps, because an offset is required after the word itself, to tell it how far to jump.
2021-06-19 19:00:03 <KipIngram   > So you have an immediate word that compiles the jump word and then compiles the offset.
2021-06-19 19:00:13 <KipIngram   > And you have to have such an immediate word for every jump word you've got.
2021-06-19 19:00:41 <KipIngram   > Well, because of my conditional recursion words, I have a LOT of words that need offsets.  Dozens.
2021-06-19 19:01:12 <crc         > Kip: the question was in reference to:
2021-06-19 19:01:14 <crc         > 15:53 <neuro`> Do you try to base it on a particular standard for your Forths?
2021-06-19 19:01:22 <KipIngram   > I didn't want to have to implement dozens of "wrapper" words, so I arranged another way.  I have a bit in my word headers - if that bit is set, then the compiler compiles the offset back to the beginnin
2021-06-19 19:01:29 <KipIngram   > So I don't need immediate words for that.
2021-06-19 19:01:31 <KipIngram   > I see.
2021-06-19 19:01:48 <KipIngram   > Um, my Forths are usually more like FIG Forth than any later "standardized" Forth.
2021-06-19 19:02:15 <KipIngram   > They'd probaby be more like Forth-79 than any other standard.
2021-06-19 19:02:25 <moon        > I've been using a lot of TAQOZ FORTH recently, and it's a tad annoying that it doesn't look like any standard forth (at least to me)
2021-06-19 19:02:27 <KipIngram   > I don't care for a lot of the standardization stuff that came later.
2021-06-19 19:02:49 <KipIngram   > Well, one of the strengths of Forth is that you can write it any way you like.
2021-06-19 19:03:05 <KipIngram   > Standards are fine, but insisting on a standard is antithetical to the philosophy of  Forth.
2021-06-19 19:03:35 <KipIngram   > If you listen to Chuck he'd say the Forth should be tailored to the application.
2021-06-19 19:03:47 <moon        > yea TAQOZ has a design reason for it, it's more performant the way it's built
2021-06-19 19:03:53 <KipIngram   > I think I dislike the later standards because they went so overboard trying to hide the internals.
2021-06-19 19:04:02 <KipIngram   > Access to the internals is what Forth is all about for me.
2021-06-19 19:04:17 <moon        > which is to avoid push/pop when possible as memory access on it's target platform isn't the fastest.
2021-06-19 19:04:43 <moon        > (So lots of transformative words like 1+, which are written in assembly and never push/pop)
2021-06-19 19:05:01 <KipIngram   > Those are nice words.
2021-06-19 19:05:31 <KipIngram   > They're generally very efficient on almost any Forth, since the TOS is usually cached in a register.
2021-06-19 19:06:02 <moon        > TAQOZ caches the TOS, TOS-1, TOS-2, and  TOS-3
2021-06-19 19:06:18 <moon        > so the general trick is to try and stay in that space
2021-06-19 19:06:37 <KipIngram   > So DROP has to move them all and then refill the last from RAM?
2021-06-19 19:06:54 <KipIngram   > Caching too much leads to a lot of register-register motion.
2021-06-19 19:07:10 <KipIngram   > The GFORTH guys have done some fairly careful studies of that.
2021-06-19 19:07:10 <moon        > https://hellomouse.net/~moony/TAQOZ/kernel/stack.p2a | (goto label DROP)
2021-06-19 19:07:11 <moon        > yes
2021-06-19 19:07:21 <moon        > not my design, i would've personally used a smaller cache
2021-06-19 19:07:42 <KipIngram   > Yeah, I've thought about it and shied away from it.
2021-06-19 19:07:53 <moon        > but the TOS-{0,3} choice was made on an earlier version of the Propeller 2
2021-06-19 19:07:55 <KipIngram   > Caching one item seems to be quite positive, and I always do.
2021-06-19 19:07:58 <moon        > and Propeller
2021-06-19 19:07:59 <KipIngram   > But never tried more.
2021-06-19 19:08:03 <moon        > which didn't have the core-local LUTRAM
2021-06-19 19:08:15 <moon        > and as such had a nasty penalty for stack interaction
2021-06-19 19:08:20 <KipIngram   > Yeah.
2021-06-19 19:08:31 <moon        > but on P2, it's in LUTRAM, which has 2 cycle access times (same speed as a MOV)
2021-06-19 19:08:42 <moon        > so a single space of cache would've been fine, if not none at all
2021-06-19 19:12:51 <NieDzejkob  > hold on, when does caching more than TOS itself ever help?
2021-06-19 19:13:30 <moon        > NieDzejkob: When accessing RAM costs 16+ cycles compared to just doing a MOV
2021-06-19 19:14:01 <NieDzejkob  > but won't you need to access it either way?
2021-06-19 19:14:30 <NieDzejkob  > like, you'd need something like ( a b -- c d )
2021-06-19 19:15:00 <KipIngram   > NieDzejkob: SWAP
2021-06-19 19:15:33 <KipIngram   > ROT and -ROT, if you have three cached.
2021-06-19 19:15:45 <KipIngram   > But your point isn't entirely invalid.
2021-06-19 19:15:49 <NieDzejkob  > hmm okay I guess those really do happen often
2021-06-19 19:16:00 <KipIngram   > That was my point too - DROP ultimately requires a RAM read no matter how many you have cached.
2021-06-19 19:16:07 <KipIngram   > And DUP a RAM write.
2021-06-19 19:16:13 <moon        > on the propeller 2, there's a lot less reason for the 4 cache spots, but on propeller it was good to have from what I heard
2021-06-19 19:21:31 <moon        > speaking of, i need to recompile TAQOZ FORTH
2021-06-19 19:21:51 <moon        > it by default ships with a large chunk of RAM set aside for a VGA buffer (which is nice for some uses) but what I'm doing doesn't need it
2021-06-19 19:21:58 <moon        > and i want that RAM back >:(
2021-06-19 19:22:33 <moon        > smth like 176k
2021-06-19 19:25:14 <KipIngram   > :-)  I used to really enjoy graphics when the buffer was in RAM and could be directly accessed.
2021-06-19 19:25:24 <KipIngram   > The technology in that area has just run away from me, though.
2021-06-19 19:26:10 <imode       > graphics needs to be accessible again.
2021-06-19 19:26:23 <moon        > KipIngram: It's a nice 360p VGA buffer, but the system only has 512K of RAM total and I want that space back :P
2021-06-19 19:29:03 <moon        > it's nice though, the propeller 2 feels like an old retro system with TAQOZ installed
2021-06-19 19:29:40 <moon        > I have it's serial tied to IRC right now for kicks, but I want to write a proper bot on it later
2021-06-19 19:31:05 <moon        > maybe convince it's video to work at a nicer resolution (480p) and write a game
2021-06-19 19:31:59 <moon        > I'd probably change it to use a scanline renderer for that though, to save on ram
2021-06-19 19:36:32 <NieDzejkob  > I've been looking for something that describes the interface of the traditional block editor based on one-letter Forth words. Any pointers?
2021-06-19 19:43:50 <KipIngram   > moon: Yeah, that's a pretty good chunk of your RAM - I don't blame you.  The notion of an in RAM video buffer just touched the sentimentalist in me.  :-)
2021-06-19 19:44:23 <KipIngram   > My first PC was an IBM PC-AT, and I got a Hercules monochrome graphics card with it.  Had a lot of fun running graphics into that buffer.  :-)
2021-06-19 19:44:43 <moon        > Propeller 2 is the "bit bang everything" microcontroller, so it's solution to graphics is similarly old-school
2021-06-19 19:44:50 <moon        > it's fun to tinker with
2021-06-19 19:45:27 <imode       > I should get one. do they have decent breakout boards?
2021-06-19 19:45:48 <moon        > imode: The board I have is great, but the whole thing is $150 total which is :(
2021-06-19 19:45:55 <imode       > meh, that's acceptable.
2021-06-19 19:46:05 <imode       > I have an old DE2 lying around that I could hook up to it for some accelerator fun.
2021-06-19 19:46:09 <moon        > there's a breakout solution that doesn't expose all the pins, but fits right onto a breadboard
2021-06-19 19:49:04 <NieDzejkob  > huh, wasn't propeller the fpga board?
2021-06-19 19:49:37 <NieDzejkob  > re: my previous message on block editors, I've found something in the polyforth manual: http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf
2021-06-19 19:51:57 <moon        > NieDzejkob> huh, wasn't propeller the fpga board? | Propeller 1 had a Verilog release a few years back, but they're not FPGA boards
2021-06-19 19:54:36 <NieDzejkob  > ah, I was thinking of the papilio board
2021-06-19 20:05:18 <dave0       > maw
2021-06-19 20:23:38 <imode       > moon: ohhhhh I remember waiting for the verilog to drop!
2021-06-19 20:47:05 <KipIngram   > maw dave0
2021-06-19 20:47:16 <dave0       > maw KipIngram
2021-06-19 20:47:23 <dave0       > i'm just about to go for a walk
2021-06-19 20:47:43 <dave0       > it rained yesterday and lady friend "borrowed" my raincoat so i couldn't walk :-/
2021-06-19 20:53:38 <dave0       > ok time for a walk! bbl
2021-06-19 21:04:03 <KipIngram   > I got my walk done earlier.
2021-06-19 21:05:00 <KipIngram   > 94 degrees.  34 for you C peeps.
2021-06-19 22:07:43 <siraben     > KipIngram: heard the current heatwave is record-breaking
2021-06-19 23:59:43 <dave0       > re maw