00:00:00 --- log: started forth/18.10.27
01:32:11 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
02:11:59 --- quit: pierpal (Read error: Connection reset by peer)
02:15:25 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
02:23:51 --- quit: pierpal (Read error: Connection reset by peer)
02:24:01 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
02:27:12 --- quit: pierpal (Read error: Connection reset by peer)
02:30:45 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
02:38:20 --- quit: pierpal (Read error: Connection reset by peer)
02:41:06 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
03:29:30 <WilhelmVonWeiner> KipIngram: I can't decipher your syntax. what the hell is a .<=; supposed to do, emit the value if <= and exit? is a hardcoded?
03:32:13 <KipIngram> No.  I've talked about that a few times here before.  I have numerous words that look like other words with a . prefixed to the start.
03:32:19 <WilhelmVonWeiner> I don't use stack comments and I've lost the code I used but it's probably something like ( N L H -- F) (the code doing `L N <= N H <= AND`)
03:32:43 <KipIngram> When the . is used in that way it has nothing to do with output - instead it indicates that the deepest stack parameter that would normally be consumed by the word is retained.
03:33:12 <KipIngram> So < expects two parameters a b and leavs a flag.
03:33:32 <WilhelmVonWeiner> ...sounds convoluted
03:33:36 <KipIngram> <; expects and consumes the same two parameters, but doesn't leave a flag - instead it conditionally returns.
03:33:55 <KipIngram> .<; expects the two parameters but leaves one of them on the stack - leaves a.
03:34:17 <KipIngram> So .< would leave the flag and only consume one of the arguments.
03:34:35 <KipIngram> It's good when you need to make multiple comparisons with the same data - eliminates a lot of DUP calls from the code.
03:34:56 <KipIngram> I've found it shortens and tightens my code quite a bit.
03:35:01 <WilhelmVonWeiner> And this is a primitive?
03:35:06 <KipIngram> Yes.
03:35:18 <KipIngram> My Forth is fairly primitive heavy.
03:35:27 <WilhelmVonWeiner> it kind of makes sense, but you must have a huge number of primitives
03:35:30 <KipIngram> But I find them easy to remember because they fall into "families."
03:35:36 <WilhelmVonWeiner> I would just do OVER SWAP lol
03:36:17 <KipIngram> Sure - if I'd been gunning for the fewest primitives possible I'd have done it very differently.
03:36:33 <KipIngram> I just wanted to wind up with very very efficient code, that's all.
03:36:36 <WilhelmVonWeiner> so it's functionall equivalent to `: .<; OVER SWAP < IF RDROP THEN ;`?
03:36:53 <KipIngram> Let me look at that for a minute.
03:36:57 <WilhelmVonWeiner> I guess it does seem reasonable if you're going for a lot of primitives
03:37:11 <KipIngram> Yes, I think so.
03:37:39 <KipIngram> Well, I wasn't "going for a lot of primitives" so much as "tolerating a lot of primitives, as long as they're well-organized."
03:38:22 <KipIngram> I want to be able to write short, good performance code.
03:38:34 <KipIngram> I just found that the . prefix helped me do that in quite a few places.
03:39:41 <KipIngram> For example if I need to compare a value to several different values for equality, it removes all the DUPs.  And also .= is a shorter, faster primitive than = is, since it doesn't have to adjust the stack pointer.
03:40:10 <KipIngram> .= just replaces b (the TOS) with a flag.
03:40:29 <KipIngram> And the conditional returns have HUGELY shortened a lot of my definitions.
03:40:52 <KipIngram> I tend to have reltively few IF ... THENs, and NO IF ... ELSE ... THEN
03:42:01 <WilhelmVonWeiner> I still prefer quotations/anonymous functions so `if` can be postfix
03:42:27 <WilhelmVonWeiner> `[ function-here ] if`
03:43:03 <KipIngram> I think that's an interesting idea.  I haven't really played with it.
03:43:21 <KipIngram> But I see why you might like it - it sort of brings a "consistency" to the language.
03:43:45 <WilhelmVonWeiner> I think reading ahead in the input stream is a little weird.
03:44:16 <WilhelmVonWeiner> I mean it kind of makes sense as the input is in a buffer and all, but it's not very forth-like
03:44:23 <KipIngram> Well, nothing actually DOES that (reads ahead).
03:44:38 <KipIngram> But it's sort of logically there.
03:45:28 <KipIngram> I assume your anonymous function gets compiled at comppile time, and at execution time its xt gets pushed to the stack?
03:46:32 * WilhelmVonWeiner shrugs
03:47:20 <WilhelmVonWeiner> it's crc's language retro if you want to know, ask him or check the source
03:47:30 <KipIngram> I just think of IF as compiling a conditional forward jump, with THEN defining the target.
03:47:32 <WilhelmVonWeiner> Never really thought about it, long as it works i'm good
03:47:40 <KipIngram> That's something I can wrap my brain around just fine.
03:48:07 <WilhelmVonWeiner> postfix `if` just executes an XT on top of the stack if true, else it drops it
03:48:33 <KipIngram> I think that seems less run-time efficient.
03:48:47 <KipIngram> You have to push an xt to the stack, then decide to execute or drop it.
03:49:05 <KipIngram> With the conventional approach you just either jump or not.
03:49:18 <KipIngram> Less stack activity - faster code.
03:50:16 <WilhelmVonWeiner> I don't know what the assembler for a conditional forward jump would look like.
03:51:06 <WilhelmVonWeiner> I mean don't you have to know where the THEN continues from?
03:51:07 <KipIngram> In mine it's just and rcx, rcx; jz <target>
03:51:49 <WilhelmVonWeiner> how do you know that without compiling everything between IF and THEN
03:51:56 <KipIngram> Yes, at compile time IF compiles the call to (if), the runtime, and leaves space for a jump distance.
03:52:07 <KipIngram> It leaves the address of that distance slot on the stack, along with a flag.
03:52:32 <KipIngram> THEN confirms that flag, grabs that address, firgures out how far it is from that address to HERE, and sticks the distance in the right place.
03:52:52 <KipIngram> THEN doesn't actually compile anything new - it just fixes up the jump IF compiled.
03:54:51 <KipIngram> For IF ... ELSE ... THEN it's similar - IF compiles the jump and a target slot; ELSE sets that target slot but also compiles an unconditional jump and a new target slot, and THEN fixes up that second target slot.
03:55:06 <KipIngram> A lot of the control structures in traditional FORTH get made that way.
03:55:27 <KipIngram> BEGIN AGAIN - BEGIN just notes an address on the stack, for the start of the loop.  AGAIN compiles a jump back to that address.
03:56:39 <WilhelmVonWeiner> from your description I don't think a compiled word containing a quotation ( [] ) would be slower than traditional if, you're just pushing the address of an xt to the top of the stack
03:56:40 <KipIngram> I spoke wrong above - I don't actually use and rcx, rcx; jz <target> in my code.  I do, but not across the span of IF ... THEN.
03:57:04 <KipIngram> My (if) primitive checks toe top of stack, and if it's FALSE it adds the contents of the following instruction cell to the IP.
03:57:10 <KipIngram> Otherwise it just steps IP over that cell.
03:57:57 <KipIngram> I think it would be a LITTLE slower.  Not so much so to rule it out if you like it - I think it's a totally acceptable approach.  But you at least have to move that xt to the stack, and then remove it from the stack.
03:58:02 <KipIngram> That's extra work.
03:59:01 <KipIngram> Both approaches are the same up through calculating the flag.
03:59:29 <KipIngram> Then the traditional approach calls the next instruction cell, which either increments IP or adds to IP, and the decision is all done.
04:00:54 <KipIngram> The postfix approach has to 1) move the xt to the stack, then it executes the if primmitive which either drops the stack or executes it.  Now that I'm looking at it in detail I suspect that would be similar in complexity to my (if).  So maybe it's only pushing the xt to the stack that is extra - that's a very  modest cost.
04:01:11 <KipIngram> I think if you find the code easier to understand and write this way, then it's totally ok.
04:04:57 <KipIngram> My (if) runtime primitive looks like this:  and rcx, rcx;  jz <label>;  add r13, 8;  next;  <label>  add r13, [r13];  next
04:05:28 <KipIngram> Actually that's how it would look if my instruction cells were 64 bit - they're 32 bits, so the stuff after label is a hair heavier.
04:05:45 <KipIngram> I have to move that added value into a register using movsx and then add it.
04:06:30 <WilhelmVonWeiner> retro is run on a C binary emulating the Nga stack architecture
04:07:26 <KipIngram> Oh, I left out the code to drop the flag from the stack.
04:08:33 <KipIngram> So in my parlance what I just described above would be .(if) (the dot thing again, meaning "don't consume the deepest argument" which in this case is the only argument).  I don't think I actually have .(if) implemented.
04:09:14 <KipIngram> Like i said, I've gravitated toward conditional returns instead of IF ... THEN type stuff.
04:09:40 <KipIngram> It encourages factoring - I take the stuff from inside IF ... THEN and factor it into a word, then do a conditional return at the start of that word.
04:09:55 <WilhelmVonWeiner> I just go with whatever makes the code immediately simpler and easier to read
04:10:01 <KipIngram> It's occurred to me it would be faster to factor it into a word and then have a conditional skip next word primitive.
04:10:21 <KipIngram> Right, me too really, and I imagine what's simpler to read varies from person to person.
04:10:34 <KipIngram> Like I have a friend who hates my cryptic symbolic names.
04:10:45 <KipIngram> He likes long "wordy" names - they're easier for him to read.
04:11:00 <WilhelmVonWeiner> Well yeah
04:11:04 <KipIngram> I like having my code shorter, and the symbolic stuff works for me just fine.
04:11:08 <KipIngram> So I've run with it.
04:11:27 <KipIngram> I usually have a "method to the madness" - the symbols "tell me things" and I have no problem knowing what the names mean.
04:11:56 <KipIngram> I've really never done any team programming, so I've evolved a style that's about writing code for myself.
04:12:04 <WilhelmVonWeiner> ` Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." `
04:12:15 <KipIngram> ;-)  Yup.
04:12:56 <KipIngram> But was that because he found himself having trouble remember what creat was, or because people lampooned the short cryptic names?
04:13:07 <KipIngram> I imagine it was the latter.
04:14:03 <KipIngram> So I've applied that "dot prefix" convention to conventional . as well.
04:14:13 <KipIngram> That gave me .. which is just . but doesn't drop the argument.
04:14:21 <KipIngram> Handy for debugging.
04:14:29 <KipIngram> Just stick .. in anywhere to peek at the stack.
04:15:17 <KipIngram> The choice of . for that prefix character was totally arbitrary.  My friend would have called .< for example DUP<
04:15:39 <KipIngram> That seemed like the "obvious name" to him.
04:16:18 <KipIngram> .. would have been DUP.
04:16:38 <KipIngram> But to me I may as well just type DUP . if I'm going to do that - it loses most of the value.
04:16:53 <KipIngram> If it's for debugging you don't care about performance anyway.
04:17:41 <KipIngram> I didn't have .. in mind when I developed that . prefix idea.  I just stuck that in later when I realized it brought slight convenience for troubleshooting.
04:24:25 <KipIngram> I think one of the best things about Forth is that we can all explore these different things, all of which are quite effective ways to solve these problems, and we each evolve our own set of ideas that work well for us.
04:25:04 <KipIngram> I think that's EXACTLY what Moore likes seeing us do with the language.  None of these things we've discussed really diverge from the "essence" of Forth in any serious way.
04:25:44 <KipIngram> I *really* like "minimal primitive" Forths - I think that's a great area to explore.
04:26:18 <KipIngram> It's just not my goal in this particular case - I wanted to be able to select whichever conditional I happened to need in a situation, and know that it was "primitive fast."  So I made all of them primitives.
04:26:44 <WilhelmVonWeiner> I remember reading him write "the idea of Forth is you write a 100, 200 word vocabulary of verbs to solve your problem, and then a 4-word definition which you execute at the end of it" 
04:26:51 <WilhelmVonWeiner> paraphrased obviously
04:27:30 <KipIngram> Right - I remember that one.  That's the "develop a problem lexicon" aspect of the method.
04:27:33 <KipIngram> I'm all for that.
04:28:46 <KipIngram> I think that rides on top of all of these different implementation variations.
04:30:33 <KipIngram> So I have a question for you, tabemann, if you're still around.
04:30:43 <KipIngram> You mentioned closure again this earlier.
04:30:50 <KipIngram> I went and looked closure up on Wikipedia.
04:31:24 <KipIngram> Now, I'm paraphrasing, but I think I read that a closure is a function along with a "snapshot" of the variable environment that existed at the time the closure is created.
04:31:32 <KipIngram> Ok, so in Forth we define words - that's the function part.
04:31:57 <KipIngram> But no snapshot of the system variable state is made - when the function runs it runs against the THEN value of the system variables, not the compile time value of the variables.
04:32:03 <KipIngram> It seems like that's not quite a closure to me.
04:32:06 <KipIngram> Care to comment?
04:32:26 <KipIngram> "Closures are typically implemented with a special data structure that contains a pointer to the function code, plus a representation of the function's lexical environment (i.e., the set of available variables) at the time when the closure was created."
04:32:36 <KipIngram> "When the closure is entered at a later time, possibly with a different lexical environment, the function is executed with its non-local variables referring to the ones captured by the closure, not the current environment."
04:32:51 <KipIngram> Forth doesn't have that last part - when you run a word it runs in the context of the CURRENT environment.
04:33:32 <KipIngram> So if I'm understanding that right, I question whether this idea is present in Forth at all.
04:36:49 <KipIngram> I decided to poke into that beccause every time one of you guys say something about a closure my eyes glaze over and I lose the thread of the conversation, and I HATE not following Forth conversations.
04:38:21 <KipIngram> But anyway, when you make a Forth definition, you are defining a function, but you are not "freezing in" any external variable values, unless you go to a fair bit of trouble to do so (you can use [ to hop out to interpret mode, fetch a variable, use ] to go back into compile mode, and say LITERAL.  That puts the COMPILE TIME value of that variable on the stack at that point when the definition runs.
04:38:34 <KipIngram> But that's an elaborate process that's not done very often.
04:38:54 <KipIngram> The normal way is just to say <variable> @ and that's going to get you the RUN TIME value.
04:39:18 <KipIngram> Wikipedia also says this: "A language implementation cannot easily support full closures if its run-time memory model allocates all automatic variables on a linear stack."
04:39:23 <KipIngram> Well, that's exactly what Forth does.
04:39:39 <KipIngram> The dictionary is effectively a stack-like structure, that you pop with FORGET or its cousins.
04:43:11 <KipIngram> So I'm sort of questioning the applicability of the term to Forth.
04:49:24 <KipIngram> I think you could use Forth to define language features that brought closure-like behavior; you could define a class of variables that produced a value at compile time.  The resulting words would be immediate and would "can" the behavior I outlined above, using LITERAL.
04:49:35 <KipIngram> Then something like this:
04:49:57 <KipIngram> : <word> DUP * ALPHA * ;
04:50:33 <KipIngram> which is basically alpha*x^2, where ALPHA is one of these things I just described, would use ALPHA's value at the time <word> was defined.
04:50:44 <KipIngram> The then-current value would get canned in the word as a literal.
04:55:23 <siraben> KipIngram:  Closures capture the environment in which they were defined.
04:55:53 <siraben> When a non-local variable is encountered in a closure, it gets looked up FIRST in the ORIGINAL environment, but if it's not found it gets looked up in the CURRENT environment.
04:56:25 <siraben> So if x = 3 when I made my closure, a lookup of the value of x in the closure body will resolve to 3, even if in the CURRENT environment x = 5
04:56:34 <siraben> So bindings are essentially shadowed.
04:57:43 <siraben> One motivation for it is to encapsulate state.
04:58:35 <siraben> Let's say if you want to keep track of the count of many different items.  Each counter "object" (which is really a closure) performs actions to its own counter and not that of others.
05:00:10 <siraben> I'd imagine that creating a closure would just be a matter of allocating a variable at compile time (defining it), then subsequent references in the closure body would point towards this local variable, then when ; is encountered or some appropriate closure-ending word, the variable is made HIDDEN.
05:04:50 <siraben> Forth is pretty sane in its scoping and definition shadowing rules.
05:06:04 <siraben> Here's an example of how I used it in a different language (Scheme):
05:06:31 <siraben> To make a gravity simulator, I have to keep track of many bodies at the same time
05:06:51 <siraben> Each with their own position, velocity, mass etc.
05:07:22 <siraben> So hence I created a closure to represent them, with "methods" that get or set the values of the object.
05:08:00 <siraben> I'm not too sure what the benefits would be in Forth, perhaps someone could demonstrate where closures would be a beneficial abstraction.
05:12:54 <KipIngram> Ok, yes - I see you could do that also (as opposed to the LITERAL based approach I described).
05:13:09 <KipIngram> But you'd have to BUILD this capability in Forth - it's not the natural native ation.
05:13:20 <KipIngram> That's ok though - one of the neat things about Forth is that you can do that kind of thing.
05:13:25 <KipIngram> Build whatever behavior you want.
05:14:47 <siraben> Yeah, personally I wouldn't use them yet because in my constrained environment defining extra words costs bytes.
05:15:03 <siraben> And it really only helps when you have multiple instances of a mutable object.
05:16:17 <siraben> I'm experimenting with a new word called MAP (taken from functional programming)
05:16:42 <siraben> The idea is that it takes an execution token and a count and applies the execution token to the n-topmost elements on the stack.
05:17:47 <siraben> : DOUBLE DUP + ; ( 1 2 3 <addr-of-double> ) 3 MAP -- ( 2 4 6 )
05:19:22 <siraben> Words which take execution tokens of other words are pretty interesting, because you can do a lot of run-time tricks, especially with anonymous words which I believe tabemann is doing.
05:19:47 <KipIngram> Yeah, that does look interesting.
05:20:11 <KipIngram> I don't have anonymous words in mine - I have words that I need only locally, and a mechanism for trimming their names when I'm done using them.
05:21:28 <KipIngram> That old old book of Chucks had some stuff in it where he had teh ability to put name/value pairs in a disk block, and he could add such a block to the system search order.
05:21:45 <KipIngram> I think that idea is interesting, but applicable to more than just disk blocks.
05:22:36 <KipIngram> I imagine when I actually implement this "trimmable naming" thing I'll do it by 1) allocating a heap block, 2) putting the names in that block as name/value items, 3) have such a block be included in my searches, 4) just deallocate the block when I don't need the names anymore.
05:23:01 <KipIngram> Using it on disk blocks gives a nice framework for a simple "file system."
05:23:22 <KipIngram> where you're essentially just giving the ability to attach names to numbers used as disk blocks.
05:23:38 <KipIngram> I suspect this was Chuck's forerunner of what later evolved into vocabularies.
05:24:07 <WilhelmVonWeiner> siraben: re MAP: I did something similar, but in my word pushed n items to the return stack then popped them off and a loop applied the xt to each
05:24:11 <KipIngram> Because that book doesn't otherwise mention vocabularies at all, and he used the name CONTEXT for the variable that holds the disk block # you use for such search extension.
05:24:26 <siraben> WilhelmVonWeiner:  Yes, that's basically how mine words.
05:24:27 <siraben> works*
05:25:09 <siraben> KipIngram:  Which book would you be referring to?
05:26:46 <KipIngram> https://colorforth.github.io/POL.htm
05:27:08 <KipIngram> It's very very early - I don't think he even describes : definitions as we now understand them.
05:27:20 <KipIngram> He had that syntax, but it just stored the definition as a text string for later execution.
05:27:47 <KipIngram> So he didn't yet have the "threading model" he later developed.
05:28:03 <KipIngram> I've found a number of things in there that are thought-provoking.
05:28:15 <siraben> Interesting, a primitive Forth.
05:28:47 <siraben> Making programming languages is truly an organic process, if one looks around at any.
05:31:11 <KipIngram> Yeah; I had no idea that it was so "unformed" at any point.
05:31:17 <KipIngram> But of course why wouldn't it have been?
05:31:30 <KipIngram> Chuck isn't exactly what you'd call a "terse and concise" writer.
05:31:44 <KipIngram> His style makes it a bit of work to extract the essence of what he's talking about.
05:31:52 <KipIngram> Parts of that I've read several times now.
05:32:04 --- quit: pierpal (Ping timeout: 252 seconds)
05:32:17 <KipIngram> Section 8, "Programs that Think" is quite interesting - nothing like that at all in the modern definition of Forth.
05:32:33 <KipIngram> Basically if he can't find a word in the dictionary, he'll drop the last character and try again, iteratively.
05:32:43 <WilhelmVonWeiner> a preliminary scan revelas classic Chuck
05:32:57 <WilhelmVonWeiner> "Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions."
05:32:57 <KipIngram> Then I guess when he finally executes some "root word," he can treat the extra characters as data in some way.
05:33:05 <WilhelmVonWeiner> I love that philosophy
05:33:07 <KipIngram> Right - definitely Chuck.
05:33:13 <KipIngram> Solve the problem in front of you.
05:33:17 <WilhelmVonWeiner> so much code is bogged down with extensibility
05:33:21 <siraben> Forth is really nice in that it's one of those languages that's highly imperative but quite "pure" at the same time.
05:33:26 <KipIngram> Yes.
05:33:37 <WilhelmVonWeiner> I don't really think of Forth as imperative
05:33:41 <siraben> Using mutable state is reserved for special circumstances.
05:33:44 <KipIngram> I totally do.
05:33:48 <WilhelmVonWeiner> it's a bunch of nested function calls passing around the local state
05:34:01 <siraben> Well then is C imperative?
05:34:03 <KipIngram> When I write Forth I'm totally in the "telling the computer what to do" mind set.
05:34:09 <siraben> Right, no fuss.
05:34:10 <WilhelmVonWeiner> Yeah, cause state in C is different
05:34:32 <siraben> 99% of the time in Forth the state is the current stack.
05:34:34 <KipIngram> But I do see where you're coming from - it's occurred to me that you can regard Forth as a functional language.
05:34:42 <KipIngram> new_state = f(old_state).
05:34:50 <KipIngram> Where state is the WHOLE state of the machine.
05:34:52 <siraben> In fact my emulator for it is in a functional manner.
05:34:53 <siraben> No mutation.
05:34:56 <siraben> Right.
05:34:57 <WilhelmVonWeiner> exactly
05:35:11 <siraben> (Haskellers, this is like the world-passing idea of the IO monad)
05:35:19 <WilhelmVonWeiner> I think it's so easily modellable as a functional language that it might as well be
05:35:24 <KipIngram> For  most words, it's new_stack = f(old_stack).
05:35:34 <KipIngram> But that doesn't quite capture everything.
05:35:37 <siraben> Take an old "world", and return a new "world" with your effects (I/O, mutation etc.) performed.
05:35:48 <WilhelmVonWeiner> just not always *pure*, because of VARIABLES and maybe the dictionary (but that can be passed around too if ya want)
05:36:12 <siraben> The purity of it makes it highly composable as well.
05:36:18 <siraben> Since composition is just concatenation.
05:36:18 <WilhelmVonWeiner> but ML isn't 100% purely functional either
05:36:22 <WilhelmVonWeiner> so not my problem
05:36:38 <siraben> WilhelmVonWeiner: I've been reading a book on Standard ML today, around halfway through.
05:36:52 <KipIngram> I'm not really a functional programmer, so to me that's just an intellectual observation - I don't really "use it that way."
05:36:56 <siraben> An interesting language, but totally different to Forth.
05:36:58 <WilhelmVonWeiner> I would love to do that but I have so much school work
05:37:17 <WilhelmVonWeiner> writing a stack machine in Haskell so I can compile it to Verilog using a tool named Clash
05:37:23 <KipIngram> What are you studying, WilhelmVonWeiner?
05:37:32 <WilhelmVonWeiner> Robotics
05:37:36 <KipIngram> Oh, NEAT.
05:37:39 <KipIngram> :-)
05:37:53 <KipIngram> I've read around in the area, and have a fair bit of motion control in my history.
05:37:59 <WilhelmVonWeiner> My initial final project was a robot powered by PunyForth on the ESP8266 but I lost all my source
05:38:02 <KipIngram> Not stuff you'd REALLY call robotics, though.
05:38:07 <KipIngram> Mostly pick and place machines.
05:38:10 <WilhelmVonWeiner> because I never back anything up and I still don't care
05:38:12 <KipIngram> Some machine vision related to that.
05:38:57 <KipIngram> I guess *technically* a PnP machine is a robot, but it's not quite what we think of when we use the word.
05:38:57 <siraben> Maybe it's just me but it seems that Forth has an adversion towards using data structures, correct me if I'm wrong.
05:39:04 <siraben> Like trees, hash tables etc. ?
05:39:14 <KipIngram> It just doesn't provide an elegant way to get at them.
05:39:15 <siraben> There's a linked list for the dictionary, obviously.
05:39:19 <siraben> Right.
05:39:27 <siraben> Then again, the language is highly malleable.
05:39:37 <KipIngram> Right.
05:39:52 <KipIngram> You could develop a structure lingo without too much trouble.
05:40:25 <KipIngram> So it "doesn't support structures" in the same way assembly doesn't.
05:40:58 <siraben> My syntactic abstractions are mostly need-driven.
05:41:13 <KipIngram> I thought a while back about how that disk-block-name/value thing could be used to make for a nice database access syntax.
05:41:27 <WilhelmVonWeiner> siraben: I recon you could write a CREATE DOES> that generates trees in a way similar to Haskell perhaps
05:41:29 <KipIngram> Your DB tables would start off with a name/value section defining the field offsets within rows, the row length, and so on.
05:41:43 <KipIngram> So when you invoked a table name, those name-value items would become searchable.
05:41:48 <KipIngram> Then you could use field names, etc.
05:41:59 <KipIngram> In the end it all just winds up giving you an address.
05:42:02 <siraben> Ah, I completely forgot about CREATE and DOES>, that is the way Forth abstracts data structures, in a sense.
05:42:08 <KipIngram> Of a specific field in a specific row.
05:42:11 <siraben> You can define VARIABLE, CONSTANT, etc.
05:42:18 <KipIngram> Yes, right.
05:42:36 <KipIngram> I've been scratching my head recently for a more "natural" way to put that kind of functionality in.
05:42:50 <KipIngram> CREATE ... DOES> is usually sort of unwieldy to implement.
05:43:00 <KipIngram> It's bending the system in a direction it doesn't really like to bend.
05:43:09 <WilhelmVonWeiner> siraben: "the pearl of forth" is what I always remember that as, from a primer document somewhere
05:43:10 <KipIngram> For one thing, I feel like you should be able to use any defining word at the start.
05:43:21 <KipIngram> For example, : ... DOES> ... ;
05:43:29 <WilhelmVonWeiner> ...why
05:43:33 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
05:43:52 <siraben> KipIngram:  I fixed it by mutating (hah!) the target address of CALL DOCOL to CALL DODOES
05:44:12 <siraben> My DOES> satisfies the desired behavior, so it must be correct!
05:44:20 <KipIngram> Well, I observed that when you define a word using CREATE ... DOES>, what's actually happening is that when you execute such a word you get the run time action of a word made with CREATE, and then DOES> is tacked on.
05:44:54 <KipIngram> You're inheriting the functionality of the root defining word, and then extending it.
05:45:04 <KipIngram> So example:
05:45:18 <KipIngram> : ALPHA  CREATE ... DOES> ...1... ;
05:45:19 <siraben> That's a powerful idea, it allows you to create "hooks" in a sense.
05:45:29 <KipIngram> : BETA  ALPHA ... DOES> ... ;
05:45:39 <KipIngram> It lets you inherit ALPHA's action and extend it for BETA.
05:45:47 <siraben> Precisely.
05:45:55 <KipIngram> Someone of you guys was complaining that ultimately CREATE DOES> isn't very useful, because it lacks that inheritance.
05:46:04 <KipIngram> So I was thinking about how that could be changed.
05:46:16 <siraben> That's when I had a mind-melting moment "Forth is amazing!"
05:46:24 <siraben> Well, seeing IF defined in Forth was also mind-melting.
05:46:55 <KipIngram> I found that GForth would let me do that above, and you DO inherit and extend the allocation portion of things.
05:47:03 <KipIngram> But you don't inherit the DOES> part.
05:47:23 <KipIngram> So ALPHA x would allocate some memory for x and give it an action.
05:47:39 <KipIngram> You'd like for BETA to allocate just like AlPHA, and then allocate some more potentially.
05:47:45 <KipIngram> And similarly extend the run-time action.
05:47:59 <KipIngram> It seems to me that brings a PROPER idea of "inheritance" to Forth.
05:48:10 <KipIngram> I haven't devised a really elegant way of implementing it, though.
05:48:22 <KipIngram> I came up with something, but it was kind of tacky in my opinion.
05:48:58 <KipIngram> So, WilhelmVonWeiner, I don't think I'd actually find myself saying : ... DOES>.
05:49:13 <KipIngram> I see it as using your own defining words as the basis for extension.
05:50:10 <KipIngram> That buddy of mine that likes the long wordy names basically just ran away when I dropped the word "inheritance" into a Forth conversation.
05:52:08 <KipIngram> Hmmm.  It just occurred to me that a smoother implementation would probably be possible if I ran BETA's DOES> code first and THEN ALPHA's.  I could just jump at the end of the new code.
05:52:16 <KipIngram> But I don't think that's really what you want it to do.
05:52:31 <KipIngram> siraben, don't you think it should run ALPHA's DOES> code first and then BETA's?
05:52:59 <siraben> KipIngram:  It runs BETA's DOES> code and then ALPHA's, right?
05:53:05 <siraben> In its current form
05:53:18 <KipIngram> No, in my original thinking I was trying to run ALPHA's first.
05:53:31 <siraben> What does it actually do then?
05:53:36 <KipIngram> But I right now thinking that doing BETA's first would make for a cleaner implementation.
05:53:54 <KipIngram> Well, a cell gets allocated at the beginning of where the DOES> code will get compiled.
05:54:21 <KipIngram> And then somewhere in the process the run-time behavior of the defining word you used (ALPHA in this case) gets put into that cell as a regular Forth "word call."
05:54:56 <KipIngram> It would be what you'd get in traditional Forth if you said this:
05:55:18 <KipIngram> .... DOES> (ALPHA) <Forth code for BETA DOES>>...;
05:55:38 <KipIngram> In the base case, CREATE ... DOES> A B C D ; you'd get
05:55:49 <KipIngram> (fetch) A B C D
05:55:55 <siraben> I see.
05:56:20 <KipIngram> But the other way around you'd want to wind up with A B C D <jump to (ALPHA)>
05:56:30 <siraben> So which DOES> code gets run first?
05:56:46 <KipIngram> I sort think it should be (ALPHA) then (BETA).
05:57:07 <KipIngram> Because when we use CREATE the fetch has to come BEORE the DOES> code, so the DOES> code has that address on the stack to work with.
05:57:23 <KipIngram> So when you say 
05:57:38 <KipIngram> : <word>  <defining word> <allocation code> DOES> <action code> ;
05:57:57 <KipIngram> you need to run the runtime action of a word defined with <defining word> first, and then you <action code>.
05:59:28 <KipIngram> In an indirect threaded system like mine, that means that if you say BETA b you have to have a way of calling (ALPHA) against the address of b.
06:00:13 <KipIngram> What it winds up meaning is that I have to compile a CFA/PFA header pair for b against more than one CFA.
06:00:44 <KipIngram> I need an (ALPHA)/PFA(b) pair.
06:01:11 <siraben> I need to do more things with DOES> , I feel that I'm not taking advantage of its full potential.
06:01:17 <KipIngram> Maybe I'm overcomplicating it.  Maybe pushing the address is just done automatically just like I've always thought of it.
06:01:39 <KipIngram> Then I just need to call (ALPHA) and it's just a : definition.
06:01:46 <KipIngram> And then run (BETA).
06:01:53 <KipIngram> That's probably better.
06:03:03 <KipIngram> Anyway, I didn't mean to get into an implementation discussion - I was just noting that allowing the use of any defining word in such a definition brings in a more complete idea of inheritance.
06:05:04 <KipIngram> So you always get b's address pushed to the stack, first.  CREATE has no extra DOES> action, so no extra cell is placed before the DOES> code at that base level.
06:05:29 <KipIngram> But ALPHA ... DOES> ... ; causes such an extra cell to be placed, and it's used to call (ALPHA).
06:06:27 <KipIngram> siraben: I think all of the things you said melt your brain arise just from the way Forth moves back and forth between "compiler" and "application" levels.
06:06:38 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
06:06:38 --- quit: ncv (Changing host)
06:06:38 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
06:07:28 <KipIngram> All languages are Turing complete.  So you could write a C compiler in C.  That means C's if then structure can be implemented using C code.
06:07:45 <KipIngram> You just don't have a system that lets you do it in "little pieces" and try it out along the way the way you do in Forth.
06:08:42 <KipIngram> All of the resources that support such "compile time intelligence" are just right there for you to tinker with.
06:09:49 <siraben> Right, the switch between compiling/interpreting is very... lispy
06:09:54 <KipIngram> :-)
06:10:16 <KipIngram> And Forth has simplified the syntax (i.e., removed it) to the point where there just really aren't any "rocket science" parts that you can't grok.
06:12:19 <KipIngram> You know, this isn't quite correct, but this DOES> stuff is awfully close to this working:
06:12:45 <KipIngram> Bear with the "meta incorrectness" of this, please.
06:13:01 <KipIngram> : :  : DOES> EXECUTE ;
06:13:18 <KipIngram> In fact, this might actually work:
06:13:29 <KipIngram> Oh, sorry.
06:13:32 <KipIngram> Here, this is better:
06:13:48 <KipIngram> : COLON  CREATE DOES> CFA EXECUTE ;
06:14:36 <KipIngram> That's not efficient - it causes you to bring every executed word through the stack rather than executing it in place.
06:14:36 <X-Scale> I wish PostScript could get more love too. It's so self contained, so close to Forth, and so powerful in terms of static text and graphics.
06:14:54 <KipIngram> Hmmm.  I'm VERY interested in better string support for Forth.
06:15:01 <KipIngram> Maybe I should pull that hood up and poke around.
06:15:31 <KipIngram> Anyway, the idea above is that you could then say
06:15:38 <KipIngram> COLON ALPHA A B C ;
06:15:43 <KipIngram> And have it work.
06:16:00 <KipIngram> Oh.
06:16:16 <KipIngram> : COLON  CREATE ] DOES> CFA EXECUTE ;
06:27:06 --- quit: Zarutian (Ping timeout: 246 seconds)
06:29:18 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
06:32:24 <siraben> KipIngram:  That seems valid.
06:39:07 <KipIngram> Where all this starts to get weird in my system is in the CFA/PFA pair region.  When I just say CREATE b I get a new word with a CFA pointer that points to dovar and a PFA pointer that points to the location of b's data.
06:39:16 <KipIngram> dovar just pushes that address to the stack and we're done.
06:40:07 <KipIngram> But ALPHA b has to create something that has a CFA pointing to some runtime code, a PFA that points to b's parameter address, and ALSO a pointer to the compiled DOES> code.
06:40:15 <KipIngram> It requires more information in the header.
06:40:45 <KipIngram> That runtime code pushes the PFA pointer and then runs the DOES> code like a : definition.
06:41:30 <KipIngram> Maybe when I say : ALPHA CREATE ... DOES> ... ; I need to create an explicit header for the does> code as well - it could be named (ALPHA).
06:42:00 <KipIngram> If I had that, then I could MANUALLY do this:
06:42:15 <KipIngram> : BETA ALPHA ... DOES> (ALPHA) <new code> ; 
06:42:18 <KipIngram> and that would work.
06:42:38 <KipIngram> I'd then have a definition (BETA) that first called (ALPHA) and then did the new stuff.
06:42:53 <KipIngram> From there it shouldn't be to hard to automate that so I didn't have to type (ALPHA) otu manually.
06:43:24 <KipIngram> I wouldn't necessarily have to have (ALPHA) appear in the dictionary by name, but I need that explicit CFA/PFA pair for it.
06:44:03 <KipIngram> In keeping with this we'd think of dovar now as (CREATE).
06:44:58 <KipIngram> That (ALPHA) CFA/PFA pair is the thing that I have to point to when I use (ALPHA) in code later.
06:46:13 <KipIngram> So DOES> needs to extend the new header by adding the extra info.
06:47:03 <KipIngram> Ah, the problem there is that if BETA b uses ALPHA to do the defining, we already have a three-item header, because all ALPHA items do.
06:47:07 <WilhelmVonWeiner> so I have a buffer 1700 bytes in size holding 1700 chars
06:47:18 <KipIngram> Efficient.  :-)  
06:47:23 <KipIngram> Ok., what then?
06:47:31 <WilhelmVonWeiner> wait not 1700 bytes in size
06:47:35 <WilhelmVonWeiner> well
06:47:42 <WilhelmVonWeiner> ymaybe. You know what I mean
06:47:55 <KipIngram> Uh, ok - I'm not sure yet, but carry on.
06:48:27 <WilhelmVonWeiner> anyway if I want to remove a char at position n, anything after n needs to be moved back a space
06:48:36 <KipIngram> Right.
06:48:47 <WilhelmVonWeiner> that's surely very inefficient
06:49:11 <KipIngram> Yeah, it's not ideal, but anything you do to alleviate that is going to swell up the storage you need.
06:49:13 <KipIngram> Keep going.
06:49:50 <WilhelmVonWeiner> that's it really, that is my problem
06:50:13 <WilhelmVonWeiner> this is a buffer of text that's being drawn to the screen 
06:50:50 <WilhelmVonWeiner> Is using an array data structure a wrong approach?
06:51:10 <KipIngram> Well, it's almost certainly the best way to get it to the screen fast.
06:51:20 <KipIngram> Because you can use an output call that slams the whole thing out.
06:51:42 <KipIngram> That's much much better than doing it char by char, which is what you'd have to do if you used a data structure that made insert and delete O(1).
06:52:33 <KipIngram> When I get around to wanting to redraw screens of information, I'm planning to do it by lines.  But each line will be stored as a tight array like that.
06:53:03 <WilhelmVonWeiner> well I'm writing an editor and move the cursor around with VT100 escape codes and that
06:53:26 <WilhelmVonWeiner> and the current cursor location is kept on TOS 
06:53:31 <KipIngram> Right - that's exactly the application that I had in mind when I thought about all that.
06:53:51 <KipIngram> I would suspect that any speed you gain with a fancy data structure for your text you'll lose again by having to output char by char.
06:54:13 <WilhelmVonWeiner> I just don't want to have to "<addr> DUP C@ SWAP 1- C!" for every element after the one removed
06:54:18 <KipIngram> I think I'd just write the insert delete moves as eficiently as I could (like with rep movs - based CMOVE) and live with it.
06:54:29 <KipIngram> Oh, don't do that.
06:54:29 <WilhelmVonWeiner> CMOVE? 
06:54:38 <KipIngram> Calculate and use CMOVE or <CMOVE.
06:54:44 <KipIngram> Moves a whole block of stuff.
06:54:47 <WilhelmVonWeiner> I guess I should look at some more words I may not know
06:54:48 <WilhelmVonWeiner> cheer
06:54:50 <KipIngram> source dest count CMOVE
06:54:50 <WilhelmVonWeiner> *cheers
06:55:10 <KipIngram> <CMOVE starts at the high address end; CMOVE starts at the low.
06:55:25 <KipIngram> For inserting you'll want <CMOVE, or else the early bytes will overwrite the later ones.
06:55:34 <KipIngram> For deletes you'll use CMOVE.
06:55:45 <KipIngram> I may have that backwards, though - check your docs.
06:55:51 <WilhelmVonWeiner> Yeah I remember that from Starting Forth now
06:56:03 <WilhelmVonWeiner> and the useful illustration
06:56:28 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
06:56:32 <KipIngram> So, siraben.  : ALPHA CREATE ... DOES> ... ; 
06:56:44 <KipIngram> The CREATE creates a standard two-cell CFA/PFA pair.
06:57:00 <KipIngram> DOES> has to add the extra info required to point to the DOES> code.
06:57:24 <KipIngram> So ALPHA b first creates a two-cell header and then extends it to 3.
06:57:35 <KipIngram> But : BETA  ALPHA ... DOES> ... ; 
06:57:50 <KipIngram> BETA b uses ALPHA to create the header - that gets 3 cells right from the jump.
06:58:30 <KipIngram> So in that case DOES> shouldn't add to that.  Intead it should grab the pointer in that three-cell bit that points to ALPHA's DOES> code, and it should put a call to that at the start of BETA's does code.
06:58:49 <KipIngram> Then MODIFY the information stored in that third cell so that it points to (BETA) instead of (ALPHA).
06:59:17 <KipIngram> So DOES> has to be able to tell how many cells were put in the last header so it knows what to do.
07:00:21 <KipIngram> So, it could check the existing CFA; if it's dovar it knows there's no third cell.  If it's anything else there is a third cell already.
07:00:23 --- quit: pierpal (Read error: Connection reset by peer)
07:00:43 <KipIngram> And in any case it modifies that CFA pointer to be dodoes instead of dovar.
07:00:50 <KipIngram> So I guess it would actually compare to dodoes.
07:00:54 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
07:02:42 <KipIngram> LATEST CFA @ (DOES) <> IF ... THEN ...
07:04:04 <KipIngram> Oh, and as an aside, DOES> is also an immediate word that compiles the (;) to the storage allocation part of the defining word.
07:06:14 <KipIngram> Ok, I think I see how to make this work now.  I tried a couple of weeks ago, but it was ugly and involved.  This is much tidier.  Basically I wasn't creating the CFA/PFA pair for (ALPHA) until I needed it in BETA's DOES> code.  And that was just terribly untidy.  If I go ahead and create it "just in case" when I define ALPHA, things will work out much more smoothly.
07:06:50 <KipIngram> Also, the extra cell in the header was pointing directly to the definition that came after DOES> - but that needs to point to (ALPHA)'s CFA PFA pair, not to the definition list.
07:07:00 <KipIngram> dodoes can step through that level of indirection.
07:07:46 --- quit: pierpal (Ping timeout: 252 seconds)
07:08:09 <KipIngram> So when we define ALPHA:  : ALPHA CREATE ... DOES> ... ;
07:09:21 <KipIngram> We get first a colon def for ALPHA.  it gets the CREATE and the storage allocation words defined into it.  DOES> will apply a (;) to that, then will create a NEW CFA/PFA pair pointing to HERE.  
07:11:20 <KipIngram> Agh - stopping.  I'm going to go write it down; I'll pastebin it later.  There's just enough going on here to make me not quite able to keep it in my head.  Sorry.
07:16:55 <siraben> KipIngram:  Do you keep a blog?
07:17:10 <KipIngram> I have one, but I haven't updated in years.  
07:17:17 <siraben> I'd be interested in reading Forth blogs, you have a lot of ideas.
07:17:25 <KipIngram> Many years ago I had a pretty extensive one, and actually showed up in search results on various things and stuff.
07:17:28 <siraben> Which is a good thing, gives me ideas too
07:17:33 <siraben> I see
07:17:39 <KipIngram> For a while I had the #1 search result on "strong AI theorem."
07:17:40 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
07:17:51 <KipIngram> But that's all gone, and what I've got now only has a few entries.
07:20:41 <rdrop-exit> Hi KipIngram. Where's your blog?
07:22:17 <KipIngram> Oh dear.  I don't know that I'm terribly proud of anything there right now, but it's http://www.kipingram.com/blog.  I left it midway through trying to structure some possible future business ideas into it.  So it's not very "coherent" right now.
07:22:24 <KipIngram> You're welcome to take a look, though.
07:22:42 <KipIngram> I enjoyed blogging; I just never seem to have that kind of time on my hands these days.
07:24:46 <rdrop-exit> Thanks, will check it out.
07:24:57 <KipIngram> It won't take you long.  :-)
07:25:26 <rdrop-exit> No worries :-)
07:25:29 <KipIngram> Well, one thing that is there that is potentially interesting is beneath the Topics link in the top bar.
07:26:09 <KipIngram> There are links there to a number of physics papers, and the beginnings of a project I scratched at a little where I had it in mind that I was going to build an equatorial mount for my 14" Dobsonian tube.
07:26:53 <rdrop-exit> Cool
07:56:49 <rdrop-exit> I'm trying to decide what technical book to add to my read/reread pile.
08:03:54 <rdrop-exit> Blaauw & Brooks' "Blaauw and Brooks' "Computer Architecture Concepts and Evolution" always makes for fascinating reading, and it's been years since I last read it.
08:04:48 <rdrop-exit> Looks like I stammered, I should never pause and think in the middle of typing a post.
08:05:52 <KipIngram> Oh, yeah - I do some weird stuff when I do that.
08:06:08 <KipIngram> My IRC client only lets me see the most recent 50-60 characters I've typed, so that makes it even worse.
08:06:13 <KipIngram> I can totally lose track of what I typed earlier.
08:09:16 <rdrop-exit> It's one of the few books that really gets into the architectural details of historical machines like the Zuse Z4, Burroughs B5000, Bull Gamma, IBM Stretch, etc...
08:14:05 <KipIngram> That's golden stuff.
08:18:23 <rdrop-exit> https://www.amazon.com/Computer-Architecture-Evolution-Gerritt-Blaauw/dp/0201105578?crid=2IFKGDJABNCOX&keywords=computer+architecture+concepts+and+evolution&qid=1540653464&sprefix=Computer+architecture+con%2Caps%2C437&sr=8-1&ref=sr_1_1
08:18:41 <rdrop-exit> https://www.amazon.com/Computer-Architecture-Evolution-Gerritt-Blaauw/dp/0201105578
08:24:02 <rdrop-exit> You may recognize the authors:
08:24:10 <rdrop-exit> https://en.wikipedia.org/wiki/Fred_Brooks
08:24:18 <rdrop-exit> https://en.wikipedia.org/wiki/Gerrit_Blaauw
08:41:00 <crc> As a side note on Retro's conditional words: the underlying instruction set for my VM has a conditional call instruction, but not a conditional jump.
08:43:31 <crc> A traditional IF/ELSE/THEN can be implemented, but compiles to the same code as the postfix conditionals and quotations.
08:45:19 <siraben> KipIngram:  Which IRC client are you using?
08:52:39 <KipIngram> Weechat Curses.
09:07:39 <KipIngram> Ok, siraben, I think I have it now.
09:07:41 <KipIngram> https://pastebin.com/B2j7Jmc7
09:08:34 <siraben> I see.
09:08:35 <KipIngram> I left out what happens when FOO runs.
09:08:41 <siraben> Moving to using a gateway has greatly improved my IRC life, no disconnects.
09:08:46 <siraben> I see the pastebin.
09:09:00 <KipIngram> dodoes just pushes the regular PFA content to the stack and then transfers to the : def specified by the extra PFA cell.
09:09:19 <KipIngram> I run weechat curses on a seedbox, that I connect to with mosh.
09:09:22 <siraben> Huh it already is accumulating a lot of views, bots, perhaps?
09:09:29 <KipIngram> GENERALLY there are no disconnects - at least none caused by me.
09:09:37 <KipIngram> Sometimes they reboot my seedbox, and sometimes Freenode is flaky.
09:09:50 <KipIngram> Wow - it's only been there for two minutes.
09:09:53 <KipIngram> I would expect, yes.
09:10:12 <KipIngram> The Machine.  ;-)
09:10:16 <siraben> I've seen bots just crawl pastebin looking for password/information dumps.
09:10:23 <KipIngram> Sure.
09:10:33 <KipIngram> That was a Person of Interest reference, in case you don't watch it.
09:11:04 <siraben> Huh.  I don't watch it, unfortunately.
09:11:08 <siraben> Worth it?
09:11:12 <KipIngram> So defining words get an extra header pair, designating the DOES> code as a : def.
09:11:23 <KipIngram> And defined words get one extra cell after the usual CFA/PFA.
09:11:42 <siraben> Yep, this looks a lot like how my DOES> works
09:11:45 <KipIngram> The inheritance is obtained by compiling (<old>), if it exists, as the first cell of (<new>).
09:12:41 <KipIngram> Then if <new> is used in <new2>, the compilation of (<new>) as the first cell of (<new2>) will also take care of calling (<old>).
09:12:50 --- quit: rdrop-exit (Quit: Lost terminal)
09:40:28 --- quit: dave0 (Quit: dave's not here)
10:22:35 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
10:44:13 --- quit: pierpal (Read error: Connection reset by peer)
10:44:25 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
10:52:45 --- quit: pierpal (Ping timeout: 246 seconds)
11:34:39 <tabemann> hey guys
11:46:27 <WilhelmVonWeiner> tabemann: what's up bossman
12:29:48 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
12:32:30 --- quit: MrMobius (Ping timeout: 246 seconds)
12:32:30 --- nick: [1]MrMobius -> MrMobius
12:33:37 <KipIngram> Hi tabemann.
14:13:26 <moony> Considering writing a FORTH for the https://lbphacker.pw/powdertoy/R216/manual.md
14:13:31 <moony> any advice? :p
14:18:30 <Zarutian> moony: hmm.. start with eForth?
14:20:21 <moony> Heh, i need a model that has both speed and space in mind. the cpu runs at only 60 IPS at best, 20 IPS at worst, (Leans toward best) so gotta avoid too much meta
14:24:19 <Zarutian> aah, then treat it like a compilation target from a host forth.
14:24:46 <Zarutian> like you are compiling to a big sequenced GAL or some such
14:25:30 <moony> so write a forth compiler for it instead. Mm. Was hoping to interpret (For a demo), so i'll work on that still. Even if it takes several seconds to do 1 1 + 🤔 
14:39:55 <WilhelmVonWeiner> lol. a powder toy CPU
14:39:59 <WilhelmVonWeiner> that's awesome
14:46:01 <moony> WilhelmVonWeiner, why don't you tell LBPHacker that? (Seriously he's on freenode, so you can. :P)
14:51:14 --- quit: Labu (Read error: Connection reset by peer)
14:59:37 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
15:10:56 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
15:11:05 --- join: leaverite (~quassel@freebsd/user/wa5qjh) joined #forth
15:16:14 --- quit: leaverite (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
15:30:52 --- quit: dne (Remote host closed the connection)
15:33:07 --- join: dne (~dne@jaune.mayonnaise.net) joined #forth
16:04:06 --- quit: pierpal (Ping timeout: 244 seconds)
16:17:42 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth
18:22:16 <siraben> moony:  Hey, I'm thinking about that too!
18:22:26 <siraben> LBPHacker is pretty active in #powder-subframe
18:22:30 <moony> siraben, i know. I posed the question because of you lol
18:22:33 <siraben> He recently made an 8K version
18:22:49 <moony> i'm aware
18:22:51 <siraben> Oh yeah you're in #powder-subframe as well
18:22:51 <moony> he made it for me lol
18:22:59 <siraben> :)
18:26:11 <siraben> His manual is pretty extensive as well.
18:30:36 <Zarutian> powdertoy is a cellular automata?
18:33:46 <siraben> Basically
18:34:04 <siraben> There's non-deterministic elements as well, but strip those away and you have a cellular automata
18:34:10 <siraben> Albeit one of the most complex in the world
18:34:29 <siraben> (also it has cellular automata elements like GOL, the star wars rule, etc.)
18:41:24 <moony> "one of"
18:41:30 <moony> the most
18:42:09 <moony> Also i dunno if it actually classifies
18:42:31 <moony> each individual cell has it's own set of internal states, for one, which i've never seen in any cellular automata
18:55:02 <Zarutian> here is a challange for ya: generate the continuance of this sequence 0x0000 0x8000 0x4000 0xC000 0x2000 0xA000 0x6000 ... until you have 0xFFFF
18:56:11 <siraben> Impossible?
18:58:31 <Zarutian> siraben: look at those numbers again, if hex is bothering ya then try converting them into binary
18:58:45 <Zarutian> and with that I am off to bed
19:02:12 <moony> Zarutian, Increment, but reverse the bit order when outputing. Neat.
19:02:30 <moony> siraben, ^
19:02:39 <siraben> Right, I took a look at the binary
19:02:57 <moony> 0x0000 == 0x0000 0x0001 == 0x8000 0x0002 == 0x4000 ...
19:04:42 * siraben uploaded an image: Screen Shot 2018-10-28 at 9.04.03 AM.png (19KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/GtcMWYNYjnJWdpDOBkWvSSUw >
19:04:45 <siraben> Those of you following along
19:05:19 <moony> wait
19:05:20 <moony> oh
19:05:22 <moony> i'm dumb
19:05:27 <moony> i just did some mental tweaking
19:05:36 <moony> time to fix my mental bit fiddling method
19:06:21 <moony> i was going to make a joke, but then i realised that it's incredibly dirty because english sucks
19:37:10 * tabemann wishes tasks would die on their own, but because of his simplification of the inner interpreter it has had the effect of making it so that if the main word of a task exits, the Forth system segfaults
19:37:52 <tabemann> making it so I had to add to the spawn wrapper code so that when the xt called by the wrapper exits, it then kills the current thread
19:38:34 <moony> tabemann, Catch the segfault, deduce it's cause from interp state (MAKE SURE TO WRAP WITH SAFETY NET), bam solved for almost all possible segfault cases
19:38:37 <moony> :p
19:38:44 <moony> libunwind can help with that, too
19:40:03 <moony> (This is assuming interp is in C or C++)
21:26:41 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
21:26:42 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
21:30:50 --- quit: jedb (Ping timeout: 245 seconds)
21:38:19 <tabemann> back
21:39:05 <tabemann> the thing is that if I catch SIGSEGV, then I will catch many failures where the system would be in an unknown state afterwards
21:39:49 <tabemann> because the heap state could become corrupted or like
21:43:11 --- quit: pierpal (Read error: Connection reset by peer)
21:45:38 --- join: jedb (~jedb@199.66.90.113) joined #forth
22:34:04 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth
22:34:17 <dave0> hi
22:34:28 <tabemann> hey
22:34:35 <dave0> hi tabemann 
22:36:15 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
22:39:41 --- quit: pierpal (Read error: Connection reset by peer)
22:43:01 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
22:51:34 --- quit: pierpal (Ping timeout: 252 seconds)
23:40:44 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
23:40:58 --- join: pierpal (~pierpal@95.234.60.245) joined #forth
23:59:59 --- log: ended forth/18.10.27