2021-06-23 10:32:20 <rick_carlino1> crc is there a word that will start a REPL listener at an arbitrary point, then resume execution after a certain word is called? I am thinking of things like `debugger` in JS or `b
2021-06-23 10:32:43 <rick_carlino1> Trying to set an interactive breakpoint in an arbitrary word location to inspect a problem.
2021-06-23 10:35:36 <rick_carlino1> Adding `listener` to a word is simple enough but I can't find a way to exit the listener. I can't find a word that is similar to `bye`, but only exits the listener, not the app.
2021-06-23 10:41:22 <eli_oat     > rick_calino1 in normy forth would this be something like ---marker---?
2021-06-23 10:43:50 <eli_oat     > whoops, rick_carlino1 -- I forgot the r there
2021-06-23 10:44:19 <eli_oat     > lol, I cannot type to save my life today
2021-06-23 10:45:23 <eli_oat     > I've got this file, https://txt.eli.li/pb/go.fs that lets me bop in and out of vim while editing a forth file
2021-06-23 10:46:37 <rick_carlino1> Oh that's neat.
2021-06-23 10:47:56 <eli_oat     > full disclosure, I stole it from this video: https://www.youtube.com/watch\?v\=mvrE2ZGe-rs
2021-06-23 11:00:17 <JanetBq[m]  > it seems every forther has encountered that video at some time
2021-06-23 11:00:40 <JanetBq[m]  > i knew exactly which one it was just by seeing the "ecr" word
2021-06-23 11:00:45 <eli_oat     > hahaha
2021-06-23 11:00:57 <eli_oat     > yeah, I feel like I've found every single forth video on youtube
2021-06-23 11:00:59 <rick_carlino1> I think I did watch that one back in the day.
2021-06-23 11:01:09 <eli_oat     > recently saw one on retro
2021-06-23 11:01:14 <rick_carlino1> There really aren't enough. Some dayTM I hope I can contribute some back.
2021-06-23 11:01:19 <rick_carlino1> Oh realyl?!?
2021-06-23 11:01:34 <eli_oat     > yeah, it isn't much, just a quick walkthrough of the retro iOS app on an iPad
2021-06-23 11:02:39 <eli_oat     > https://www.youtube.com/watch?v=9wbmlya74_o
2021-06-23 11:05:59 <crc         > someone made a video on retro for ios?
2021-06-23 11:06:46 <eli_oat     > yeah -- this is the URL, https://www.youtube.com/watch?v=9wbmlya74_o
2021-06-23 11:07:01 <eli_oat     > it is more of a "I am really excited about forth on iPad!" than anything else
2021-06-23 11:07:43 <crc         > I'll watch it tonight
2021-06-23 11:07:53 <crc         > rick_carlino1: perhaps something like this? http://forth.works/share/7a7fea850aea0663b2bfc6b842153963
2021-06-23 11:11:08 <rick_carlino1> That works thanks crc !
2021-06-23 14:48:32 <crc         > eli_oat: http://forth.works/share/d8d62303cc229696b168855f1cf89822 is a quick attempt at implementing ecr in retro
2021-06-23 14:50:08 <eli_oat     > this is rad!
2021-06-23 14:50:19 <eli_oat     > after sharing that I started to noodle on how I'd do it in retro
2021-06-23 14:50:26 <eli_oat     > but have been in meetings all day, so haven't poked at it yet
2021-06-23 14:50:31 <eli_oat     > excited to take this for a spin!
2021-06-23 14:54:32 <nihilazo    > I should mess with retro more. I want to build an assembler for uxn in retro
2021-06-23 14:54:35 <nihilazo    > might be interesting
2021-06-23 14:54:59 <nihilazo    > especially because such a project would inherit retro's literateness and be able to use it as a macro system if I design it well
2021-06-23 15:05:23 <eli_oat     > for context, this is uxn -- https://wiki.xxiivv.com/site/uxn.html
2021-06-23 15:06:56 <nihilazo    > the main thing making it a bit more difficult than another thing to build an assembler for is things that require vectors to addresses, so it would probably have to be two pass
2021-06-23 15:20:45 <crc         > if it helps, https://git.sr.ht/~crc_/retroforth-impexus has jmf's two pass assembler for x86
2021-06-23 15:20:58 <crc         > I need to take a closer look at uxn
2021-06-23 15:23:36 <kensanata   > I wrote a little program in it before the syntax got changed; then I was unwilling to commit the time again to figure out the changes.
2021-06-23 15:27:58 <nihilazo    > it's pretty stable now
2021-06-23 15:28:08 <nihilazo    > I've been working on kalama for a few months with no changes going on
2021-06-23 15:28:26 <nihilazo    > there's a pretty decent library of software, including ports of most f the 100r stuff, so I doubt there's much willingness for more changes any more
2021-06-23 15:28:31 <nihilazo    > crc: thanks, I'll have a look
2021-06-23 15:30:08 <kensanata   > nihilazo: Good news! I just saw the Orca port posts today and I thought that's *amazing*.
2021-06-23 15:30:17 <nihilazo    > yeah the orca port is nuts
2021-06-23 15:30:21 <nihilazo    > so cool
2021-06-23 15:31:06 <nihilazo    > if you want to try uxn now is like, the best time
2021-06-23 15:31:24 <nihilazo    > it's stable, but we're still early enough that we're figuring out cool tricks and ways to do stuff
2021-06-23 15:33:07 <kensanata   > And webuxn is also mindblowing, of course.
2021-06-23 15:48:40 <eli_oat     > shoot! I just found webuxn. This is wild!
2021-06-23 16:09:54 <crc         > can you send me a link to webuxn?
2021-06-23 16:11:03 <eli_oat     > https://aduros.com/webuxn/?rom=roms/musictracker.rom
2021-06-23 16:11:12 <eli_oat     > https://aduros.com/webuxn/
2021-06-23 16:11:18 <eli_oat     > one sec., I can find the repo, too, I bet
2021-06-23 16:11:38 <eli_oat     > https://github.com/aduros/webuxn
2021-06-23 16:12:42 <crc         > thanks! I'll take a look at this after I get home tonight :)
2021-06-23 16:50:01 <rick_carlino1> Heh, I figured the folks in this channel would be interested in Uxn. I very much was thinking "How can I port Retro to this?" when I saw it.
2021-06-23 16:50:45 <eli_oat     > yeah! Whenever I play with uxn (haven't done anything of consequence) I find myself wishing I had a forth rather than its assembly language to write in
2021-06-23 16:51:15 <eli_oat     > gotta go make dinner, but got fantasies of playing with these things tonight!
2021-06-23 16:51:18 <eli_oat     > peace!
2021-06-23 17:03:34 <crc         > running retro on uxn would likely be difficult due to memory constraints. But I might be able to implement a similar model on it.
2021-06-23 17:09:24 <rick_carlino1> I figured it would be. In that regard, is the RetroForth outter interpreter model not well suited to low memory systems, or is it just that Nga was built with desktop in mind?
2021-06-23 17:10:17 <rick_carlino1> What I mean to say is, does Retro use more memory as a result of the token / sigil based parsing or is it just due to the VM architecture?
2021-06-23 17:11:25 <rick_carlino1> I would love to see something similar to Retro but with low memory targets in mind. Something that supports the use of sigils, has a stricter RPN adherence than traditional Forths
2021-06-23 17:14:50 <rick_carlino1> Yeah I guess if I had to remove as many things as possible in the name of memory conservation to make something that was "retro-like"
2021-06-23 17:15:34 <rick_carlino1> I would find the token based parsing and the use of sigils to be the two big things that I like about Retro.
2021-06-23 17:20:54 <crc         > It mostly comes down to my memory model. Only addressing in 32-bit units leads to a lot of internal waste
2021-06-23 17:21:44 <crc         > 'Hello  could be 6 bytes if byte addressed, but is is 24 on nga
2021-06-23 17:22:19 <crc         > Given that my system has hundreds of words, the amount of unused space in strings is considerable
2021-06-23 17:23:25 <rick_carlino1> Ah OK, that makes sense.
2021-06-23 17:23:42 <rick_carlino1> So it's not really the Retro style as much as the underlying architecture. That's good to know at least.
2021-06-23 17:25:24 <crc         > This is something I might change in the future. Since the kernel can now be bigger than 1k cells, I have space to implement words that would allow for byte packing of strings. It'd be somewhat slow
2021-06-23 17:26:43 <crc         > Doing so will be a gradual change. I'd need to introduce some new words for fetching and storing into strings, and update some parts (like the buffer: words) to accommodate this
2021-06-23 17:27:13 <rick_carlino1> Ah that's interesting. Makes sense.
2021-06-23 17:30:55 <rick_carlino1> In the case of Uxn, it has a flexible word size (8 or 16 bit depending on if the LONG flag is set to 1 on the instruction).
2021-06-23 17:31:40 <rick_carlino1> Newb question: Have any forths address variable cell size in ways other than creating words like `d+`? Is it even a problem?
2021-06-23 17:31:53 <rick_carlino1> *addressed the issue of variable cell size
2021-06-23 17:32:42 <rick_carlino1> I have seen some forths do that, where they just add `d` or something like that infront of every existing word and I always found it unsightly, but Im not sure of an alternative.
2021-06-23 17:34:27 <crc         > yeah. There's a lot to consider on how to best approach this, which is most of why I haven't started on it yet
2021-06-23 17:35:04 <rick_carlino1> Has there ever been a Forth system to handle it similarly to the way ANS Forths handle BASE information?
2021-06-23 17:35:29 <crc         > I'll probably add s:fetch/char and s:store/char in the near future, as an initial transition step towards byte addressable strings
2021-06-23 17:35:47 <crc         > Not that I've seen, though that's not necessarily a bad way to do it.
2021-06-23 17:36:28 <rick_carlino1> I imagine you would lose some performance though if your `+` operator needed to check a CELL_SIZE flag every time though. Hmmm
2021-06-23 17:36:57 <crc         > Yes
2021-06-23 17:36:59 <rick_carlino1> but that would be great, if you could do something like `LONG #2 #2 + SHORT` instead of `#2 #2 l:+`
2021-06-23 17:38:14 <crc         > I have considered designing a new VM to support this kind of thing
2021-06-23 17:39:49 <rick_carlino1> If I had to chose between a fast forth and a memory efficient one, I would be pretty OK using a slower one.
2021-06-23 17:40:09 <crc         > a reasonable assumption would be to use the native cell size on the stack, so arithmetic would always be 32 or 64 bit, then have words to check for sizing when doing store/fetch
2021-06-23 17:40:13 <rick_carlino1> Would be interested in seeing what that would look like, I imagine that would be in a v13 release right?
2021-06-23 17:40:18 <crc         > Yes
2021-06-23 17:40:24 <rick_carlino1> Oh that is a good idea
2021-06-23 17:40:53 <crc         > 
ACTION has begun some preliminary notes towards a retro13...

2021-06-23 17:42:28 <rick_carlino1> I have been keeping a note about the "RetroForth of my dreams" in a personal trello board. One moment while I find it.
2021-06-23 17:47:20 <rick_carlino1> crc https://gist.github.com/RickCarlino/647f837be41721e8e998726e7a33be9b
2021-06-23 17:47:57 <rick_carlino1> #5 is somewhat hard to type out an explanation for, but it would help the Javascript implementation's performance.
2021-06-23 17:48:17 <rick_carlino1> I also have an embedded scripting language use case that would benefit from such a setup, though it's a bit complicated to explain.
2021-06-23 17:49:37 <rick_carlino1> also #6 is not a strongly held opinion. I want to make that clear.
2021-06-23 17:51:15 <crc         > #6 is something I've considered. It would allow a reduction in words since that's what an array is in retro.
2021-06-23 17:53:13 <crc         > #3 is relevant as I (slowly) work on the native branch; I'll need some degree of interrupt handling to support some physical hardware
2021-06-23 17:53:34 <rick_carlino1> When I was noodling over the idea of a Retro-esque Forth system, I figured I could use char arrays and not implement strings at all
2021-06-23 17:54:13 <rick_carlino1> I haven't worked with systems that use counted strings much (I heard pascal uses them?) but I always think "Gee, those must be nice to work with".
2021-06-23 17:54:36 <rick_carlino1> (compared to null terminated strings)
2021-06-23 17:56:00 <crc         > NULLs are trivial, and have some advantages (easier to chop a string as you can
2021-06-23 17:56:13 <crc         > just advance the starting pointer
2021-06-23 17:57:03 <crc         > At various points I've done implementations both ways, and a hybrid with both a count and a null terminator
2021-06-23 17:57:17 <rick_carlino1> I think that's what ESPForth does.
2021-06-23 17:57:30 <rick_carlino1> They handle null strings via `z"` iirc
2021-06-23 17:57:52 <crc         > hybrid was advantageous on x86 assembly as it made FFI stuff easier
2021-06-23 17:58:48 <rick_carlino1> That's the one point that makes me not hold the preference very strongly- C interop is nice.
2021-06-23 18:00:44 <crc         > C interoperability isn't really directly possible now though, as the memory models are different. It's not that much trouble to implement functions to translate length prefixed strings to null and
2021-06-23 18:09:52 <crc         > 
ACTION is now considering taking some time to start fleshing out ideas for a new vm & changes to retro to support this

2021-06-23 18:11:35 <rick_carlino1> I'd be very curious to hear about your progress!
2021-06-23 18:28:19 <crc         > I'll keep you updated :)