2022-03-12 12:52:28 <KipIngram   > dirtyforth - I like it.
2022-03-12 12:53:33 <KipIngram   > MrMobius: I absolutely agree - building the tool is what I love.  And getting it to the point where I can start working "on it, with it" is great - that's the bulk of my actual Forth programming experience.
2022-03-12 12:54:10 <KipIngram   > There's actually something "beautiful" about the internal workings of Forth.
2022-03-12 12:55:48 <KipIngram   > vms14: You'll need to choose among indirect, direct, and code threading.  I have specific opinions here which I'll share, but it's very much a personal decision.  I always go with indirect threading, and if I didn't do that I'd do direct threading.  I've never written a code threaded one, and I'm fairly sure I never will - somehow it just doesn't "feel like Forth" as much to me.
2022-03-12 12:56:12 <KipIngram   > There is a common belief that "code threading is faster," but I think that depends on the processor architecture and instruction timings of said processor.
2022-03-12 12:56:38 <KipIngram   > I am fairly convinced that some features of Forth are very much easier to do in indirect threading, with CREATE / DOES> being a prime example.
2022-03-12 12:57:05 <KipIngram   > I think indirect threading "exposes the full elegance" of Forth in a way that the others don't.
2022-03-12 12:57:24 <KipIngram   > And it's the most historically traditional model to boot.
2022-03-12 12:59:26 <Zarutian_HTC> KipIngram: what do you call it when the arch is actually dual stack machine?
2022-03-12 13:00:18 <KipIngram   > Once you've made that decision, there comes a subset of words that you can reasonably do either "as primitives" or "as definitions."  Another common practice is to lean toward doing as many things as possible with definitions, for portability.  But you pay a performance price for doing that.  I've wound up being "primitive heavy," for good performance, but at the same time I want the portability, so these
2022-03-12 13:00:19 <Zarutian_HTC> say for instance the canonical dual stack machine from Koopmans book or say excameras J1
2022-03-12 13:00:21 <KipIngram   > days I think in terms of a third layer, that I call the "portable instruction layer."  That's a set of macros that just spew a bit of assembly code into whatever primitive is currently being built.  I try to limit the number of those that I have in a reasonable way, and wind up with a few dozen.
2022-03-12 13:00:52 <KipIngram   > I try to choose those so that I can get primitives that are near optimal performance.  But the payoff is that the *primitive* implementations then become portable.
2022-03-12 13:01:03 <KipIngram   > So having a large number of primitives doesn't impose a "porting penalty."
2022-03-12 13:01:24 <KipIngram   > Zarutian_HTC: Yeah, that gets blurry then, doesn't it?
2022-03-12 13:01:34 <KipIngram   > I've never worked on such a platform, so I haven't given it a lot of thought.
2022-03-12 13:01:51 <KipIngram   > But yes - I see your point.  They can all kind of converge, given the right hardware.
2022-03-12 13:03:24 <Zarutian_HTC> what I like about the dual stack archs is how near parallel they are in their fetch exec decode pipelines
2022-03-12 13:03:30 <KipIngram   > vms14: It is possible to do a "real" Forth using GNU C.  It has extensions that let you write a real, legitimate inner interpreter.  I've done one.  It was rather ugly when you looked at the source, and eventually became hard to maintain, but it worked and performed well.
2022-03-12 13:03:39 <KipIngram   > These days I use nasm for the start, though.
2022-03-12 13:03:46 <KipIngram   > s/for/from/
2022-03-12 13:04:12 <MrMobius    > i never really got the argument of portable forth
2022-03-12 13:04:23 <MrMobius    > it doesnt seem  to be something that happens in practice
2022-03-12 13:04:42 <MrMobius    > unless its just fun to build in the functionality for it
2022-03-12 13:06:05 <KipIngram   > Yes, I totally get that.  However, what I have to work on today is an x86 box running Linux.  What I want to do in the future is build embedded gadgets, most likely with ARM processors.  So I'm paying some attention to making *that particular port* as simple and yet still good performance as possible.
2022-03-12 13:06:12 <Zarutian_HTC> well, I get the portability argument for when you are using source libraries when solving a thorny problem
2022-03-12 13:06:27 <KipIngram   > When I choose the "instructions" of this portability layer (the macros), I'm trying to choose them to support optimum primitives for both x86 and ARM.
2022-03-12 13:06:55 <KipIngram   > I use a few Linux syscalls - every one of those implies new code I'll have to write when I port to some bare metal platform.
2022-03-12 13:07:25 <KipIngram   > So I think I'm not trying to be "universally portable" so much as "portable in a specific way that I think will matter to me."
2022-03-12 13:07:44 <MrMobius    > because you want to run the same program from your PC on ARM?
2022-03-12 13:07:54 <Zarutian_HTC> one neat thing I have wanted to steal from Smalltalk80 / Squeak is the fallback for yet to be implemented primitives
2022-03-12 13:08:32 <KipIngram   > I'm not really writing specific programs yet - I'm still working on "the tool."  I'm really targeting something that you could think of as an actual operating system, to "run a system."
2022-03-12 13:08:42 <KipIngram   > What I write using it someday will depend on what I build.
2022-03-12 13:09:08 <KipIngram   > The general model I'm going for is the one I typically use on Linux, which is to run GNU screen and have a whole flock of windows in which I do various t hings.
2022-03-12 13:09:47 <KipIngram   > I'd say what I'm working on right now is the framework that will constitute how I produce the user interface to my potential future embedded gadgets.
2022-03-12 13:10:06 <KipIngram   > Not yet any of the "gadget applications."
2022-03-12 13:10:18 <Zarutian_HTC> basically the idea is to fallback to something like a colon definition for a 'primitive' if that primitive is not available
2022-03-12 13:11:12 <Zarutian_HTC> KipIngram: TUI, serial, or GUI too?
2022-03-12 13:11:16 <KipIngram   > Yes, I've thought about making it simple to redefine words (my header has a pointer in it to "actual implementation") - one possibility is to begin with a lot of definitions and selectively replace them with primitive implementations later.
2022-03-12 13:11:38 <KipIngram   > Console based, but I've been studying the kitty terminal emulator graphics protocol lately.
2022-03-12 13:11:52 <Zarutian_HTC> kitty terminal?
2022-03-12 13:11:56 <KipIngram   > I think modern GUIs "overuse" graphics, but on the other hand graphics are valuable.
2022-03-12 13:12:11 <KipIngram   > https://sw.kovidgoyal.net/kitty/
2022-03-12 13:12:26 <KipIngram   > It's a GPU-using terminal emulator.  Very fast.
2022-03-12 13:12:31 <Zarutian_HTC> protocols such as sixels, regis, ripscrip, ans naplps?
2022-03-12 13:12:38 <KipIngram   > Lot of thought seems to have been given to supporting server/client configurations.
2022-03-12 13:12:45 <KipIngram   > Yes, it's along those lines.
2022-03-12 13:12:48 <Zarutian_HTC> s/ans/and/
2022-03-12 13:13:01 <KipIngram   > But seems very general and at least at the moment I think it seems well thought through.
2022-03-12 13:13:08 <KipIngram   > I've only started looking at it a few days ago, though.
2022-03-12 13:13:36 <KipIngram   > I run terminator on my Linux box, but I use kitty for some hotkey "pop up" tools that I've implemented.
2022-03-12 13:14:16 <Zarutian_HTC> well, I am on the opinion if one is going to do gui and 2d gfx then one needs an object system (not class oop though)
2022-03-12 13:14:17 <KipIngram   > A text snippet library, a dedicated tool for searching the text versions of a book series I'm heavily into, and just recently a "popup" that uses vimwiki to give me a "personal note taking" system.
2022-03-12 13:15:00 <KipIngram   > I can't argue with that - I think I've not pondered it enough to actually argue, so you may well be right.
2022-03-12 13:15:23 <KipIngram   > But yeah, GUIs and object environements do seem well matched to me.
2022-03-12 13:15:59 <KipIngram   > I suppose it *might* just be because the two things were of high community interest at the same time, and so got developed together, but it may also be a natural symbiosis.
2022-03-12 13:16:34 <Zarutian_HTC> eh, I agrue that is a symbiosis
2022-03-12 13:16:50 <KipIngram   > Seems likely.
2022-03-12 13:17:09 <KipIngram   > Like I said, though, I'm an amateur on that front.
2022-03-12 13:17:59 <Zarutian_HTC> and a bit of a gfx lib I been fiddling together allows for easy composition of primitives
2022-03-12 13:18:00 <KipIngram   > I've hacked around a lot of software over the years, but I'm no computer scientist.
2022-03-12 13:18:29 <Zarutian_HTC> neither am I, just an electronics tech
2022-03-12 13:18:54 <KipIngram   > Well, it just feels like you've dug into that aspect more than I have, perhaps.
2022-03-12 13:19:35 <Zarutian_HTC> "why the hell does it take so long to do that" kind of questions I got answered by going through SICP
2022-03-12 13:19:39 <KipIngram   > I've tended to inhabit the lower layers of the software ecosystem.
2022-03-12 13:20:15 <KipIngram   > But the formal stuff is certainly interesting - I've peeked into it a little.
2022-03-12 13:20:32 <KipIngram   > I have a copy of SICP somewhere.  That thing is massive.
2022-03-12 13:21:15 <Zarutian_HTC> up to a point, yes but sometimes I get the feeling that some computer scientists are just pure mathematicians
2022-03-12 13:21:31 <KipIngram   > I got a lot more interested in LISP a year or so ago, when it came up here for a few days.  But just like Forth, more in the "implementation" aspects than in applications.
2022-03-12 13:21:49 <KipIngram   > I do think it gets to that level, yes.
2022-03-12 13:22:02 <KipIngram   > That seems like it may even be the case in physics.
2022-03-12 13:22:07 <Zarutian_HTC> well, I only ever read the online version of it and for fun watchef the taped lectures
2022-03-12 13:22:35 <Zarutian_HTC> watched*
2022-03-12 13:24:25 <Zarutian_HTC> one thing I have not gotten much time into is sound processing using 7400s series chips and delta sigma encoding
2022-03-12 13:25:09 <KipIngram   > DSP is awesome.  I used to work for a company that made seismic gear.  Our stuff was the very "ground level" sensors, but that whole functionality chain, all the way to the final images, is pretty interesting.
2022-03-12 13:26:04 <Zarutian_HTC> I am just looking into how to do dsp without the multiply-accumulate paradigm
2022-03-12 13:29:01 <Zarutian_HTC> so far I have come up with how to do delay (use shift register), summation, and pitch shifting by halfing or doubling
2022-03-12 13:31:59 <Zarutian_HTC> sure the nyquist freq for say x bits at y hertz becomes x*y hertz but it is fun problem to work on
2022-03-12 13:34:52 <Zarutian_HTC> re that gfx lib: as pixmaps/bitmaps have just four methods/verbs/selectors, one can do composition and transformations quite easily
2022-03-12 13:36:44 <Zarutian_HTC> the four are: getWidth ( -- w ), getHeight ( -- h), getPoint ( x y -- colour), and putPoint ( colour x y -- )
2022-03-12 13:37:56 <Zarutian_HTC> the translations transforms just deal with transforming the x y coordnates
2022-03-12 13:38:39 <Zarutian_HTC> rotation one can do by the three shears method
2022-03-12 13:41:26 <Zarutian_HTC> also clipping one can do by instanciating a clipper that acts like a pixmap but needs reference to two pixmaps and a bitmap or mask
2022-03-12 13:41:43 <KipIngram   > Sorry - got busy for a minute.  That all sounds fascinating.
2022-03-12 13:42:34 <KipIngram   > I've always also been interested in Chuck's work on modeling and designing semiconductors - sounds like he had some very interesting and "different" transistor models, that worked.
2022-03-12 13:43:03 <KipIngram   > Sounds like you don't necessarily have to just immediately pick up floating point and the traditional differential equation approach.
2022-03-12 13:43:19 <Zarutian_HTC> and frankly I do not know how to do this without an object system if I do not want to have issues with the usual forth dictionary
2022-03-12 13:44:17 <KipIngram   > I do spend a fair amount of time tinkering with how to introduce "atypical" thiings into Forth, and generally it seems pretty hard.  The usual pattern is that I think about some extension, and that leads me down a rabbit hole and the first thing I know it's becoming a monstrosity.
2022-03-12 13:44:34 <KipIngram   > Some of that is just me succumbing to feature creep, though.
2022-03-12 13:44:38 <KipIngram   > A good bit of it, actually.
2022-03-12 13:44:59 <KipIngram   > "Oh, now that I have this it would be easy to do that," etc.
2022-03-12 13:49:16 <KipIngram   > Yesterday it was just strings.  I think that one is within reach, and something along the lines of crc's circular buffer is almost certainly the right idea, I think.
2022-03-12 13:49:40 <KipIngram   > But even just as minor an extension of that is introducing some very "different" ideas into Forth.
2022-03-12 13:49:54 <KipIngram   > "as that"
2022-03-12 13:50:01 <KipIngram   > Christ, I'm still only half awake today.
2022-03-12 13:57:37 <Zarutian_HTC> well, string stuff if one intends to do lot of it would benefit from object system as that allows for doing them as ropes
2022-03-12 13:58:58 <Zarutian_HTC> basically you would have three kinds of string rope objects: immutable segment, slice of a string, and a concatination
2022-03-12 14:00:20 <Zarutian_HTC> plus one could do lazy strings, lazy endless ones, etc
2022-03-12 14:01:08 <Zarutian_HTC> but that is cm'ing into scheme lisp territory
2022-03-12 14:01:24 <Zarutian_HTC> and function based programming
2022-03-12 14:02:18 <Zarutian_HTC> but that is precisely why I like Forth, you can grow it into these directions as need be
2022-03-12 14:11:11 <KipIngram   > Yes - very much.  You have any links to those thoughts?  Sounds interesting, and it's exactly on my mind right now.
2022-03-12 14:16:07 <KipIngram   > I kind of see both sides - on the one hand, one of Forth's great assets is its brute simplicity.  That was probably particularly valuable in the early days, when hardware was less powerful.  But on the other hand, there are some genuinely *good ideas* out there, and some of them might qualify as things one could wire into Forth at the low level and gain a lot of benefits.
2022-03-12 14:16:54 <KipIngram   > I think a really clean regex engine, written in the lines of early regex thinking (https://swtch.com/~rsc/regexp/regexp1.html) might be an example.
2022-03-12 14:17:13 <KipIngram   > Note that this is *not* "common modern regex," as you'll see if you read that link.
2022-03-12 14:17:29 <KipIngram   > Features have been added to modern regex that are actually very expensive computationally.
2022-03-12 14:18:12 <KipIngram   > The original idea, though, was very clean and effective.
2022-03-12 14:21:03 <KipIngram   > Like if you had a simple regex engine that would "peel the next match" off of the front of a string, you could use it in WORD or you could use it in ." or you could use it to pass over a comment, or for any other purpose that you could come up with.
2022-03-12 14:22:00 <KipIngram   > By the time you've separately implemented WORD and ." and ( and so on, you've paid some of the carrying costs of such an engine anyway.
2022-03-12 14:26:13 <KipIngram   > You could probably also use it to test a parsed out word for whether or not it was a number, and then the conversion code would get to know it was working with a good string and wouldn't have to error check.
2022-03-12 14:28:28 <KipIngram   > Maybe - I have a "radix variable" way of specifying numbers that might require more power.  I can write <radix>:<digits>, so checking digits would require knowing the numeric value of <radix>.  So that's capture groups, and I don't know if that fits into the original early paradigm.
2022-03-12 17:01:44 <KipIngram   > Zarutian_HTC: I found some info on ropes - that's pretty interesting.  Seems to share some aspects of b*tree file systems.  Not exactly the same, but some common ideas.
2022-03-12 17:01:50 <KipIngram   > Very interesting.
2022-03-12 17:02:01 <KipIngram   > Thanks for putting me onto that notion.
2022-03-12 17:07:47 <KipIngram   > Maybe you can save me from going down a rabbit hole.  I'm looking at the rope stuff, and it says that in general the leaf strings in a rope are considered to be immutable.  I'm tempted to think that allowing small modifications to the leaf nodes, within some limits, might be beneficial.  Like to delete a character from a string, you could just delete that character from its leaf node, and adjust all the
2022-03-12 17:07:49 <KipIngram   > counts up the tree as appropriate.  Then there would be some room in that node, and you might put something else in later.  And so on.  It's the direction I feel tempted to investigate.  Is there some monster waiting down that road for me, that you're aware of?
2022-03-12 17:08:48 <KipIngram   > I'm not really seeing how that deletion example would be any different from just replacing the node completely - see what I mean?
2022-03-12 17:09:42 <KipIngram   > I'm also tempted to embellish the structure to allow efficient forward and reverse traversal of the string.
2022-03-12 17:13:15 <KipIngram   > I'm tempted toward an implementation using a pool of fixed-size RAM pages and organize them b-tree style, but with the additional information to make it a rope included as well.  In a case where I knew I was going to be doing significant modifications, I might start out with all the leaf nodes half full, leaving room to make edits, and then run it very much like a b-tree stored file.
2022-03-12 17:14:00 <KipIngram   > The "efficient traversal" change would mostly be adding a parent pointer to the nodes, I think.
2022-03-12 17:23:16 <joe9        > KipIngram: check out kfs
2022-03-12 17:23:59 <veltas      > KipIngram: Do you ever write words over more than one line?
2022-03-12 17:24:08 <joe9        > easier to understand. it uses hash buckets instead of the b-tree or b+-trees.
2022-03-12 17:26:22 <joe9        > and, the code is so much simpler.
2022-03-12 17:26:54 <veltas      > Yeah fuck trees
2022-03-12 17:27:31 <veltas      > I print everything out at work, don't care about wasting paper because I hate trees
2022-03-12 17:29:53 <joe9        > as an example, this is the whole buffer lookup code. http://okturing.com/src/13272/body
2022-03-12 17:30:48 <joe9        > lookup on the hash index and linked list search on the collisions. If not found, then replace the oldest entry. (lru)
2022-03-12 17:32:08 <veltas      > Nice
2022-03-12 17:33:28 <veltas      > What's hiob?
2022-03-12 17:34:30 <joe9        > static int nbuckets = Nbuckets;	/* max number of trees */
2022-03-12 17:34:30 <joe9        > static Hiob *hiob;			/* array of nbuckets */
2022-03-12 17:35:10 <joe9        > http://okturing.com/src/13273/body
2022-03-12 17:35:19 <veltas      > I do like that style of C, that's how C's meant to be written
2022-03-12 17:35:26 <veltas      > Unfortunately nobody in industry gets that anymore
2022-03-12 17:35:46 <veltas      > Well not 'nobody' just nobody who writes newer code I have to interact with lol
2022-03-12 18:20:05 <KipIngram   > veltas: I bend over backwards to never go over one line.
2022-03-12 18:20:33 <KipIngram   > It's gotten easier over time - these days most of my definitions are around 40-45 characters.
2022-03-12 18:20:41 <KipIngram   > That's "typical."
2022-03-12 18:23:07 <KipIngram   > joe9: I'll take a look at kfs - thanks.
2022-03-12 18:32:10 <nmz         > KipIngram: king of limbo
2022-03-12 18:32:37 <nmz         > or, you must be very good at limbo I should say
2022-03-12 18:40:58 <joe9        > I assume that the focus would be on the ideas behind it, not limbo.
2022-03-12 19:00:11 <KipIngram   > Definitely not a limbo rock star here.  I'm a fan of watching women do limbo, though.  :-)