2024-11-19 09:40:17 <lilo_booter > :) - what's a saner way of doing this: defer x-equation : x-create-equation s" : x-equation-impl { F: x } " 2swap s+ s"  ; ' x-equation-impl is x-equation" s+ evaluate ; s" x" x-create-equation
2024-11-19 09:55:46 <lilo_booter > ... or s" x fsin" x-create-equation or even s" 0e" etc (actually, i'll probably change x-equation to y= as it's possibly more reflective what's going on)
2024-11-19 13:49:10 <xentrac     > zelgomer: using Forth probably will not help you amass wealth.  Attracting beautiful women is a definite possibility: either they might like Forth, or you could livecode music in Forth
2024-11-19 13:52:50 <xentrac     > lilo_booter: I'm not sure either how that code works (what's s+?) or what problem it is designed to solve
2024-11-19 13:57:46 <user51      > Maybe it should be wealth first, forth later.
2024-11-19 14:07:32 <xentrac     > Mike Perry, one of the authors of F83, did amass wealth and retire in his 30s to a fancy resort in Mexico.  But it wasn't because of Forth; it was because he founded Paradise, the company that made a single-chip EGA, which then got used in clone EGA cards from lots of companies.  And then he got bought out.
2024-11-19 14:09:05 <xentrac     > Though I guess he founded Paradise with people he knew from working on firmware for a laptop in the 01970s, in Forth.  So, although Forth won't make you rich, it might introduce you to people who will.
2024-11-19 14:09:29 <user51      > Any of you guys rich?  :P
2024-11-19 14:10:53 <xentrac     > No.  I think these days it's more likely to introduce you to people who voluntarily pass up golden opportunities to get rich ;)
2024-11-19 15:05:48 <lilo_booter > xentrac: admittedly weird - probably better way to do things - s+ is string append and the whole things it works as follows: defer x-equation <- allows me to define a word which uses x-equation before defining it - like:  : x-loop ( "equation" -- ) x-create-equation xy-width 0 do i col-to-x x-equation i y-to-row col-row-at loop ; - create-equation turns the provided string into an instance of
2024-11-19 15:05:50 <lilo_booter > x-equation - so to a simple y=x plot, s" x" x-loop is sufficient (i did mention that i was looking for a saner approach :))
2024-11-19 15:15:19 <lilo_booter > in essence, given an input s" x" x-create-equation constructs and evaluates a string which contains: ": x-equation-impl { F: x } x ; ' x-equation-impl is x-equation"
2024-11-19 15:16:48 <xentrac     > I see
2024-11-19 15:18:16 <xentrac     > you could just define the equation directly as a word that takes x (on the floating-point stack or by invoking a word called x) and use is to set a deferred word to it, or you could pass the xt of the function to plot to your plotting function
2024-11-19 15:18:35 <xentrac     > but if you prefer doing it with strings that seems okay too
2024-11-19 15:19:23 <lilo_booter > i considered the manual word definition, but it seemed somewhat verbose
2024-11-19 15:20:25 <xentrac     > like if you wanted to plot x² - x + 3 you could :noname dup dup * - 3 + ; plot or the floating-point equivalent
2024-11-19 15:20:39 <crc         > lilo_booter: is there a reason to have x-create-equation use colon definitions instead of using :noname for this?
2024-11-19 15:21:12 <lilo_booter > i guess that would just be ignorance on my part :) - sounds better
2024-11-19 15:21:49 <xentrac     > which I think might be :noname fdup fdup f* f- 3. d>f f+ ; plot
2024-11-19 15:22:40 <MrMobius    > I've been wondering lately if there would be any use to have your compiler look up words but cache a certain number of them instead of writing them to the dictionary so a later word can process them if that's useful and otherwise they get written automatically or when you hit ;
2024-11-19 15:22:41 <lilo_booter > well, i was kinda thinking that i might allow an infix specification of the equation
2024-11-19 15:23:22 <xentrac     > but plot wouldn't have to care how the word it was invoking was defined internally, unless it wanted to do something other than evaluate it at different points.  symbolically differentiate it, for example
2024-11-19 15:25:12 <MrMobius    > so instead of `FLOAT 1.23e4 FLOAT 4.56e7` you might have `1.23e4 4.56e7 FLOATS` since if for example your forth doesnt understand floats and FLOAT needs to parse the same word, you could just cache 1.23e4 and 4.56e7 and FLOATS would look back at the cache and handle those words
2024-11-19 15:25:47 <MrMobius    > handle those numbers I mean
2024-11-19 15:27:05 <MrMobius    > not that useful here since you might do `FLOATS 1.23 4.56 ENDFLOATS` to save typing but I wonder if there are more interesting things you could do with that
2024-11-19 15:31:31 <thrig       > forgetting to type endfloats might be hilarious?
2024-11-19 15:31:35 <lilo_booter > well, that relates to another thing i wanted to ask - is there a way to drop the exponent requirement from the floating point number input? don't mind doing it in the code, but if the user is required to type "x 3e f**", it feels like there are a couple of points that a newbie would struggle with there (rpn itself is one hurdle, but the e and f are, well, kinda nasty)
2024-11-19 15:32:53 <lilo_booter > hence, considering the idea of parsing the string, and if i'm doing that, infix is a hop, skip and jump away (well, kinda)
2024-11-19 15:35:26 <xentrac     > yeah
2024-11-19 15:36:14 <MrMobius    > another interesting idea might be to pass a forth word to the interpreter for it to call when it doesnt recognize something. that word could see if it's a float or something and if not, generate the standard not found error
2024-11-19 17:24:34 <lilo_booter > hmm - yeah, looking into :noname and leaving an xt on the stack - not quite the push to the higher level input i was looking for (as above though, my current use of evaluate is hardly stepping far from forth implementation details at the moment, but it feels like a step in the direction i want to head) - however, my current approach is broken as each time i redefine the x-equation-impl word, i get
2024-11-19 17:24:36 <lilo_booter > a noisy diagnostic on stdout or stderr which mangles the graphs i'm plotting, while using :noname and executing the xt has no such side effect, so i will definitely use that one
2024-11-19 17:26:29 <lilo_booter > (ie: still using using string appends and evaluate, but dropping the defer/named word
2024-11-19 17:26:41 <xentrac     > how are you allocating the memory for the string appends?
2024-11-19 17:27:36 <lilo_booter > i was hoping that s+ was doing that for me? might be building on a false premise though
2024-11-19 17:31:32 <lilo_booter > checking under valgrind, i get a clean bill of health when using it - no leaks
2024-11-19 17:31:57 <lilo_booter > and no invalid access to uninitialised memory
2024-11-19 17:32:25 <lilo_booter > so it seems like for my use at least, this type of string concatenation is ok
2024-11-19 17:34:11 <xentrac     > s+ isn't a standard word, and I wouldn't trust Valgrind to be able to tell when you're not writing in C :)
2024-11-19 17:34:19 <xentrac     > it's an extension by whatever Forth you're using
2024-11-19 17:36:58 <lilo_booter > heh - yeah - probably a valid point for valgrind - and i'm probably going to fall into a few gforth specific traps :)
2024-11-19 17:37:50 <xentrac     > oh, are you using GForth?
2024-11-19 17:38:14 <lilo_booter > yup
2024-11-19 17:38:22 <lilo_booter > bad idea?
2024-11-19 17:38:32 <xentrac     > GForth is fine, but s+ doesn't appear in https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Word-Index.html#Word-Index
2024-11-19 17:39:58 <lilo_booter > do you know if there's a standard way to concate two strings then?
2024-11-19 17:41:48 <xentrac     > well, you could use + swap move
2024-11-19 17:42:04 <lilo_booter > looks nice :)
2024-11-19 17:42:37 <xentrac     > I guess you probably want to save the resulting string length though
2024-11-19 17:42:45 <xentrac     > the bigger issue is that you need to allocate enough buffer space for that to work
2024-11-19 17:43:09 <xentrac     > which, in most cases, means you need to deallocate it later
2024-11-19 17:43:34 <zelgomer    > if you just copy one string to the end of another, you better hope that the first string wasn't a string literal in a word definition
2024-11-19 17:43:49 <lilo_booter > hmm - strings seem to be deallocated on type/evaluate from what i've seen?
2024-11-19 17:44:27 <xentrac     > not in general
2024-11-19 17:44:51 <lilo_booter > am gonna have to break for dinner - i definitely want to pick this up later - much appreciate the info
2024-11-19 17:45:23 <xentrac     > generally Forth only allocates memory at "compile time"
2024-11-19 17:45:35 <xentrac     > as you're adding stuff to the dictionary
2024-11-19 17:45:59 <zelgomer    > it's just like c, strings are just addresses. the scope and lifespan of the memory of that address depends on how it got there.
2024-11-19 17:46:01 <xentrac     > there's a heap-allocation vocabulary: https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Heap-Allocation.html#Heap-Allocation
2024-11-19 17:46:42 <xentrac     > which is basically just the C standard library facilities ported to Forth
2024-11-19 17:47:19 <xentrac     > lilo_booter: happy to help!
2024-11-19 17:47:38 <xentrac     > I'm sorry for the unpleasant surprise
2024-11-19 18:09:03 <TactfulCitrus> Hi everyone! Do you get any performance improvement by not using variables and keeping everything on the data stack? New to Forth so happy to be pointed to reading material
2024-11-19 18:09:51 <xentrac     > usually not, but sometimes
2024-11-19 18:10:54 <xentrac     > trying to keep everything on the data stack is a huge pitfall for Forth newcomers
2024-11-19 18:11:22 <xentrac     > it's easy to write code that you can't debug because it's full of over nip r> 2dup
2024-11-19 18:12:05 <xentrac     > so start out by storing values in variables in the same places you'd store them in variables if you were programming in C or JS (although I prefer value to variable myself)
2024-11-19 18:12:07 <TactfulCitrus> Thanks for the advice, I was implementing matrix multiplication and it was very hard to keep to track of
2024-11-19 18:12:47 <xentrac     > it's much easier to add a little bit of stack manipulation to code that's already working than it is to get code working when it has too much stack manipulation in it
2024-11-19 18:13:26 <xentrac     > I find value a bit less error-prone and more concise
2024-11-19 18:14:19 <TactfulCitrus> Couldn't agree more ther! How come value is less error prone?
2024-11-19 18:19:26 <xentrac     > well, it's pretty rare that I intend to pass the address of a variable to some other word so that it can store into it.  Generally I'm either storing into the variable x ! or fetching from it x @.  So the opportunity to write x when what I meant was x @ isn't helpful; it's just a chance to introduce a bug into my code.  And it makes the code more verbose, too, because I fetch from variables at
2024-11-19 18:19:32 <xentrac     > more callsites than I store into them
2024-11-19 18:19:47 <amby        > i essentially use VARIABLEs and VALUEs for globals
2024-11-19 18:20:07 <xentrac     > so with 0 value x I write x and to x rather than x @ and x !
2024-11-19 18:20:43 <xentrac     > yeah, that's a style I see pretty often, amby, but my experience is that Forth newcomers tend to tie themselves in knots with stack manipulation if they try it :-)
2024-11-19 18:20:47 <crc         > TactfulCitrus: in my systems, variables are slower than stack, but I use variables when they make the code cleaner & more readable.
2024-11-19 18:20:57 <amby        > if forth had locals, sure
2024-11-19 18:21:17 <xentrac     > if you have 10 things on the stack, accessing them is going to be pretty slow too, crc :)
2024-11-19 18:21:23 <amby        > but like. i have an instinct to avoid using globals for stuff that doesn't need to be global
2024-11-19 18:21:40 <amby        > xentrac: ive never really had to go deeper than 4 or 5
2024-11-19 18:21:43 <xentrac     > yeah, I do too.  but after long and painful experience I learned that that instinct was wrong in Forth
2024-11-19 18:22:01 <xentrac     > at least for my limited brain
2024-11-19 18:22:07 <amby        > i have considered adding locals
2024-11-19 18:22:14 <amby        > i have a reasonably good idea how you'd do it too
2024-11-19 18:22:14 <xentrac     > maybe you have an easier time with stack manipulation than I do!
2024-11-19 18:22:33 <crc         > I don't delve that deeply into the stack in most cases
2024-11-19 18:23:02 <vms14       > you want locals when you start using >r and r>
2024-11-19 18:23:09 <crc         > (most of my words only really ever touch the top 1-3 elements)
2024-11-19 18:23:25 <xentrac     > just to disambiguate, I'm not being sarcastic here.  I really do believe that some people have an easier time visualizing stack effects than I do
2024-11-19 18:23:26 <amby        > basically you put locals on the return stack
2024-11-19 18:23:45 <vms14       > I wonder if it's even more correct to use locals than to use the return stack as auxiliary data storage
2024-11-19 18:23:48 <amby        > depending on how complicated you wanna make it, you either pre-declare all locals before using any
2024-11-19 18:23:49 <amby        > a la old c
2024-11-19 18:23:53 <xentrac     > but other people have a harder time
2024-11-19 18:24:18 <amby        > or you could rig it up to be able to create new locals mid-definition
2024-11-19 18:24:26 <amby        > which would be harder to implement but potentially easier to use
2024-11-19 18:24:40 <xentrac     > and for us, it's better to use a variable or a value than to try to keep track of things 4 or 5 deep in the stack
2024-11-19 18:24:47 <amby        > i personally would implement them like VARIABLEs
2024-11-19 18:24:49 <vms14       > but it's true that locals would make you lazy and will affect your factoring
2024-11-19 18:24:56 <amby        > so that the option to take a pointer is there
2024-11-19 18:25:17 <vms14       > the maiin thing about forth is that managing stack elements can become so increasingly hard that it forces you to factor
2024-11-19 18:25:24 <amby        > small functions
2024-11-19 18:25:43 <amby        > also having locals makes structs less painful to work with
2024-11-19 18:25:51 <amby        > because you can chuck them on the return stack
2024-11-19 18:25:52 <xentrac     > I don't think that's the main thing about Forth.  Forth was invented as a tool to make easy things easy and hard things possible, not a tool to make easy things hard
2024-11-19 18:26:24 <vms14       > since I'm only a noob in forth, I find easy things to be incredibly hard
2024-11-19 18:26:26 <vms14       > xd
2024-11-19 18:26:28 <xentrac     > word-scoped variables like GForth's "locals" facility makes it harder to factor words into smaller pieces though
2024-11-19 18:26:41 <amby        > while we're at it, check out em-1 from that one tanenbaum paper
2024-11-19 18:26:50 <vms14       > but I assume it's just because I do not have the mindset of a forthwright
2024-11-19 18:26:57 <amby        > xentrac: that's the nice thing about not using locals
2024-11-19 18:27:10 <vms14       > at the end in my world only strings hash tables and lists exist
2024-11-19 18:27:15 <amby        > you can just chop out a section of a word and it still behaves as it did in context
2024-11-19 18:27:23 <xentrac     > I'm not a Forth expert but I *did* write StoneKnifeForth
2024-11-19 18:27:24 <amby        > it's function composition
2024-11-19 18:27:26 <xentrac     > amby: yes
2024-11-19 18:27:28 <vms14       > if you remove them I do not know what to do
2024-11-19 18:27:32 <xentrac     > what's em-1?
2024-11-19 18:27:54 <amby        > stack machine designed to minimise compiled code size
2024-11-19 18:28:00 <zelgomer    > xentrac: did not realize you were the author of SKF!
2024-11-19 18:28:12 <xentrac     > vms14: you may be interested in reading Adam Rosenberg's book about how to program without hash tables, lists, or structs: http://www.the-adam.com/adam/rantrave/st02.pdf
2024-11-19 18:28:26 <xentrac     > zelgomer: well it's not really a Forth
2024-11-19 18:28:30 <xentrac     > it doesn't have IMMEDIATE words
2024-11-19 18:28:39 <vms14       > at the end I made an interpreter very different from forth, and sometimes I even prefer it, the only problem is it's just a toy language
2024-11-19 18:29:30 <vms14       > xentrac ty I've saved it
2024-11-19 18:29:33 <xentrac     > vms14: I'm not sure whether the style Rosenberg advocates is actually good, but it's surely a useful toolkit in languages like Fortran 77, BASIC, and Forth which don't have those things
2024-11-19 18:31:21 <xentrac     > and it's different enough from the mainstream approaches that it requires some explanation
2024-11-19 18:31:21 <zelgomer    > xentrac: maybe so, but it is one that i came across and enjoyed reading, and no doubt gave me ideas
2024-11-19 18:31:33 <vms14       > it has lexical scope, lists, hashes, can evaluate lists as code, etc
2024-11-19 18:31:41 <vms14       > needs a better design overall, has several flaws
2024-11-19 18:31:48 <xentrac     > it sounds a lot like PostScript, although PS doesn't have lexical scope
2024-11-19 18:31:59 <vms14       > for example everything is mutable, even colon words
2024-11-19 18:32:17 <xentrac     > it looks cool!
2024-11-19 18:32:32 <vms14       > you can : oh 1 2 3 ;  'oh word .code pop drop => now it's : oh 1 2 ; xd
2024-11-19 18:32:48 <vms14       > which is dirty
2024-11-19 19:27:48 <lilo_booter > xentrac: thanks for the pointers and the info, and no problem at all :) - fwiw, the :noname migration works a charm and cleans up the diagnostic - as for append logic... gforth also offers >string-execute :) - https://gforth.org/manual/String-words.html
2024-11-19 19:28:17 <lilo_booter > for the purposes of what i'm doing, tying myself gforth isn't an issue anyway
2024-11-19 19:30:06 <veltas      > What is the concatenation needed for?
2024-11-19 19:34:07 <lilo_booter > veltas: well, it's a bit of a hack - but basically, i want the user to be able to provide me with a string which it will then plot as graph - like s" x 3e f**" x-loop - now, i can evaluate the string for each point, or i can do it once and create a word out of it - so i was trying to hack a solution which did the latter and currently have: : x-create-equation ( "equation" -- xt ) s" :noname { F: x
2024-11-19 19:34:08 <lilo_booter > } " 2swap s+ s"  ;" s+ evaluate ;
2024-11-19 19:34:42 <lilo_booter > sorry for line split - : x-create-equation ( "equation" -- xt ) s" :noname { F: x } " 2swap s+ s"  ;" s+ evaluate ;
2024-11-19 19:35:09 <lilo_booter > this is probably a horrible thing to do :)
2024-11-19 19:35:10 <veltas      > Is there a reason why the user can't do e.g. :noname .... ; themselves?
2024-11-19 19:35:41 <veltas      > Like :noname .... ; PLOT-THIS
2024-11-19 19:36:13 <veltas      > Anyway you don't need to concatenate the strings, you can call evaluate twice
2024-11-19 19:36:40 <lilo_booter > nope - except i don't necessarily want them to provide me with forth - i might want to allow the user to give me in-fix like s" x ** 3" and i'll provide a translation to forth
2024-11-19 19:37:01 <lilo_booter > ah didn't actually try that
2024-11-19 19:38:03 <veltas      > Well if you're going to parse it eventually anyway then you're not going to use evaluate in the end, and can write it to not need the concatenation yourself
2024-11-19 19:38:47 <veltas      > If you want to compile stuff yourself word-by-word you can use FIND / COMPILE, etc
2024-11-19 19:39:07 <lilo_booter > sure - was just being lazy (and may not write parser - just a hypothetical maybe at this point)
2024-11-19 19:39:43 <veltas      > It's not an unreasonable thing, to want to concatenate a string, but I just rarely find it necessary
2024-11-19 19:40:38 <lilo_booter > sure - but when i tried this just now:  : x-create-equation ( "equation" -- xt ) s" :noname { F: x } " evaluate evaluate s"  ;" s+ evaluate ; i get a failure
2024-11-19 19:41:40 <lilo_booter > and i'm not too surprised by that - we are currently evaluating the : stuff, so the second evaluate will be part of the word of the i'm defining
2024-11-19 19:44:39 <veltas      > The issue is that EVALUATE always interprets and you want to compile
2024-11-19 19:44:53 <lilo_booter > yup
2024-11-19 19:45:33 <veltas      > EVALUATE is quite useless unfortunately
2024-11-19 19:45:50 <veltas      > It always runs up against these kinds of problems
2024-11-19 19:46:26 <lilo_booter > meh - works for this case - i can use it for each point, and with the strcat to define the :noname it's fine too - i'm not suggesting it's pretty or optimal though :)
2024-11-19 19:46:46 <veltas      > That's precisely my complaint
2024-11-19 19:47:06 <veltas      > I mean this isn't JavaScript, it's Forth, so EVALUATE is 'useless' by Forth standards
2024-11-19 19:47:08 <lilo_booter > and it's why i brought up the conversation in the first place :)
2024-11-19 19:47:34 <veltas      > In JavaScript you wouldn't think twice about allocating a new string, or even be that aware that you're doing so
2024-11-19 19:48:01 <veltas      > But Forth can run on computers where you can literally see it sweating over a handful of bytes
2024-11-19 19:49:14 <lilo_booter > yeah, sure i get that - what i'm doing isn't targetted at that level of hardware though, so i'm not going to sweat that particular detail :)
2024-11-19 19:50:18 <lilo_booter > have clock cycles and memory to burn - all i want to make sure is that i don't leak and run reasonably efficiently without breaking too many established rules in the process
2024-11-19 19:54:20 <veltas      > Where is the string coming from?
2024-11-19 19:56:40 <lilo_booter > at this point, the variable part comes from user input on the stack - s" x 3e **" x-loop or s" x" x-loop or s" 1.0e" x-loop etc - as above, the eventual goal is to parse the input given and translate it (preferably to a compiled word) - i don't need to write part that up front if i temporarily stub it with evaluate
2024-11-19 19:57:12 <lilo_booter > s/write part/write that part/
2024-11-19 19:57:24 <veltas      > So the user is inputting stuff directly into the interpreter?
2024-11-19 19:57:30 <veltas      > The Forth interpreter?
2024-11-19 19:57:39 <lilo_booter > at this point, the user is me, so yes :)
2024-11-19 19:58:20 <veltas      > You're making the assumption here that you can iterate assuming that the source doesn't matter, my problem is that I don't think that's true!
2024-11-19 19:58:24 <veltas      > It does matter in Forth
2024-11-19 19:58:43 <veltas      > When I say 'iterate' I mean like 'iteratively develop'
2024-11-19 19:59:37 <lilo_booter > that's a fair point - i can post my code if you want to critique it
2024-11-19 19:59:49 <veltas      > A strong argument in my favour: strings aren't first-class citizens in Forth.  Strings are bytes in memory: there's a limited vocabulary for manipulating them, and doing compilation tricks and redirections
2024-11-19 20:00:15 <veltas      > The problem is that your code isn't the destination, so the current code may be irrelevant to solving your actual problem
2024-11-19 20:00:55 <veltas      > To be specific, it would be good to know right now what requirements you actually have for how the user will input this string
2024-11-19 20:01:58 <veltas      > And whether you want this to be 'portable' ANS Forth, whether a specific Forth will be used, what sort of computer it will run on
2024-11-19 20:02:05 <veltas      > You've already specified some of that
2024-11-19 20:02:20 <lilo_booter > yup
2024-11-19 20:04:15 <lilo_booter > i still think that if i can take an input and derive a word of the float in/float out variety, i don't need to worry too much about the detailsn up front (esp. considering i'm just having a bit of fun and am deliberately doing this just to see where the boundaries are)
2024-11-19 20:05:20 <veltas      > I mean Forth is a general purpose programming language, capable of any programming style, like most programming languages I know.  But in any language, and Forth especially, there are ways of doing things that run against the grain
2024-11-19 20:05:35 <lilo_booter > for sure
2024-11-19 20:06:05 <veltas      > For instance I think the smoothest Forth code that allows user interaction relies on the Forth interpreter as-is, if possible
2024-11-19 20:06:15 <TactfulCitrus> Just caught up on all the messages, thanks for the pointers guys!
2024-11-19 20:08:06 <veltas      > If it can't use the interpreter then using stuff like WORD or PARSE , and FIND COMPILE, etc makes sense because you're using parts of Forth itself to do the job
2024-11-19 20:09:00 <veltas      > And worst case scenario you need to start implementing everything yourself, or modifying string buffers for use in EVALUATE
2024-11-19 20:19:51 <lilo_booter > https://pastebin.com/CNBKzctz <- well, this is what i have - to my mind, your critique is valid and discussions in here have refined my approach quite a bit already - lines 258 and 272 are the main points of contention i believe - i'm quite happy to hear other criticisms too :)
2024-11-19 20:21:36 <lilo_booter > but note the "very silly" comment and the tongue in cheek name :) - this is me just having a bit of fun :D
2024-11-19 20:26:47 <vms14       > is the first forth code I see not using caps
2024-11-19 20:27:02 <lilo_booter > i prefer my code not to shout at me :)
2024-11-19 20:27:53 <vms14       > I guess you could create a vocabulary to avoid prefixing everything with t
2024-11-19 20:28:40 <lilo_booter > ah - is that possible with gforth? (i don't know it at all tbh - i use stack evaluation all the time, but not forth)
2024-11-19 20:30:06 <vms14       > https://gforth.org/manual/Vocabularies.html
2024-11-19 20:31:02 <lilo_booter > thanks - will look into that
2024-11-19 20:31:51 <vms14       > https://www.reddit.com/r/Forth/s/ZrBTWi4Nys
2024-11-19 20:32:50 <lilo_booter > does that help in anyway with tab completion? that's the main reason i was trying to limit the prefixes i use...
2024-11-19 20:33:06 <lilo_booter > (though tab completion in gforth is... well... ugh?)
2024-11-19 20:34:26 <vms14       > you can use rlwrap
2024-11-19 20:34:50 <vms14       > i tend to use it, you can add a file with word names to add autocompletion
2024-11-19 20:34:52 <lilo_booter > oh yeah - had forgotten about that one
2024-11-19 20:35:15 <lilo_booter > but i guess it won't dynamically add new words to dictionary
2024-11-19 20:35:29 <vms14       > and decide what characters break a word, and autocomplete files too, but that might be annoying
2024-11-19 20:35:41 <vms14       > yeah it won't :/
2024-11-19 20:36:01 <lilo_booter > fwiw - this was my attempt to learn rust and wasm - http://rrpn.geminidev.be/ (if you get the black monitor, type help)
2024-11-19 20:36:04 <vms14       > you would have to create your own repl to wrap it
2024-11-19 20:36:30 <lilo_booter > yeah - my preference for this kinda stuff is linenoise
2024-11-19 20:37:09 <lilo_booter > have been avoiding readline for years - find it somewhat ott for what it actually provides
2024-11-19 20:38:22 <vms14       > I like rlwrap, I use it for my toy lang, but I assume eventually I will have to make my own with curses or alike
2024-11-19 20:39:44 <lilo_booter > if you're c based, you could do worse than linenoise - header only, no dependencies, ugly as sin, but minimalist and powerful
2024-11-19 20:41:10 <lilo_booter > also friendly license (unlike readline)
2024-11-19 20:42:07 <vms14       > at the end I only need tcsetattr
2024-11-19 20:43:16 <lilo_booter > well, maybe.. :) - but i don't think it's an entirely trivial bit of functionality to add - i wouldn't have the patience to write it myself anyway
2024-11-19 20:45:29 <vms14       > I dislike to not be able to have 'key' as forth has without requiring a dependency
2024-11-19 20:46:05 <vms14       > there are ways, like using bash, but that's dirty
2024-11-19 20:47:11 <vms14       > gforth has it, in pforth key does not work without a newline
2024-11-19 20:47:56 <lilo_booter > ah - yeah - you definitely want that one
2024-11-19 20:48:41 <lilo_booter > need to break for a bit - bbl - thanks for the chats guys :)
2024-11-19 20:55:02 <vms14       > see you soon lilo_booter
2024-11-19 20:55:18 <vms14       > I liked that bootloader, it was used in slackware
2024-11-19 21:50:54 <veltas      > vms14: That's funny because most Forth code I see is lowercase
2024-11-19 21:51:12 <veltas      > I write uppercase but I feel like the exception
2024-11-19 22:01:55 <veltas      > Sorry lilo_booter, I don't get what you're trying to do honestly, if I wanted to pass "y = sin x" to a word I would be pushing  ' FSIN  without hesitation, or  "y = x^2 - 10"  :NONAME  FDUP F*  10E F- ;
2024-11-19 22:02:21 <veltas      > But I think I'm missing something
2024-11-19 22:07:53 <lilo_booter > veltas: yeah - i would too - but, i think most people would assume "2 ** 10 -" if they had an inkling of postfix or "x**2 - 10" it they didn't? either way, the idea of parsing the equation is just to add a bit of spice to the demo (and tbh, it's already gone way beyond its purpose anyway which was just an example on the wider subject of stack evaluation :))
2024-11-19 22:10:53 <lilo_booter > there's a much better demo which is part of the same thing which uses video and audio files and connects things together with filters and is all rpn based and which is a bit more relevant to the audience (and, ultimately, more impressive), but you know - itches sometimes need scratching
2024-11-19 22:13:12 <veltas      > Or  :NONAME  2DUP  100 M/  10 M*/  10.000 D- ;  if you're based
2024-11-19 22:16:15 <lilo_booter > i kinda like the { x } local thing because it removes the stack manipulations (one less thing to explain) - if i want y = 5, i don't have to involve x or the stack - s" 5e" is sufficient
2024-11-19 22:17:02 <veltas      > Do you end up calculating this function for a large number of input values?
2024-11-19 22:18:37 <lilo_booter > well, possibly :) - currently, i'm using the terminal width (with a massive zoom in at some points :)) - but my feeling is that i should be able to use, say, an sdl window and use its resolution for the iteration
2024-11-19 22:18:49 <lilo_booter > zoom out rather
2024-11-19 22:18:57 <veltas      > Nice
2024-11-19 22:19:15 <lilo_booter > theoretical of course - no idea if i'd ever get round to doing it (ditto for parsing)
2024-11-19 22:19:34 <lilo_booter > i don't any reason why it wouldn't form a base
2024-11-19 22:19:40 <veltas      > For that I might consider trying to make a DSL for specifying the function to build SIMD code
2024-11-19 22:19:53 <lilo_booter > ooh - that would be nice :)
2024-11-19 22:20:11 <veltas      > Especially if it was for a 'real' reason, but yeah for a little project would depend on motivation/interest
2024-11-19 22:20:57 <vms14       > with gforth you might end using sdl quite easily
2024-11-19 22:21:00 <lilo_booter > indeed - one thing that is missing from this is plotting lines between the calcualted points - that is probably the next thing i'll do
2024-11-19 22:21:13 <lilo_booter > vms14: indeed - i saw some examples already
2024-11-19 22:21:14 <vms14       > https://rosettacode.org/wiki/Draw_a_pixel#Forth
2024-11-19 22:21:41 <vms14       > I like the stack notation as ffi interface
2024-11-19 22:21:42 <lilo_booter > nice - and an example of c bindings too
2024-11-19 22:21:52 <lilo_booter > yup - works for me
2024-11-19 22:22:10 <vms14       > I dislike the fact it will have to generate code compile and link every time you run your program
2024-11-19 22:22:30 <vms14       > but since it uses libtool there might be a way to configure that
2024-11-19 22:22:50 <lilo_booter > yeah - need to look into at some point i think
2024-11-19 22:23:46 <lilo_booter > i will also get a terminal variant working in the rrpn wasm thing i posted above :)
2024-11-19 22:23:55 <lilo_booter > (some of it is already there i guess)
2024-11-19 22:24:17 <vms14       > if I had a forth in c that was easy to add c bindings I'd probably stick with forth instead of making my own abomination
2024-11-19 22:24:53 <veltas      > I'm currently working on a Forth that's designed to be loaded as a shared object, starting with AMD64 Linux
2024-11-19 22:25:05 <lilo_booter > that could be interesting
2024-11-19 22:25:10 <vms14       > it could even be embedded into the browser with emscripten and add bindings to js through js_em
2024-11-19 22:25:11 <veltas      > And to coexist with C and C libraries
2024-11-19 22:25:21 <vms14       > em_js* I guess
2024-11-19 22:25:54 <lilo_booter > not familiar - i thought wasm was what all the kids were doing these days?
2024-11-19 22:26:15 <veltas      > emscripten uses wasm, previously used asm.js
2024-11-19 22:26:22 <lilo_booter > ah - ok
2024-11-19 22:26:57 <vms14       > they are even embedding postgresql into the browser with emscripten xd
2024-11-19 22:27:20 <lilo_booter > heh - nuts stuff :)
2024-11-19 22:27:23 <vms14       > a lisper did even embed clisp into the browser
2024-11-19 22:27:37 <vms14       > https://lispcafe.org/clisp/lisp.html
2024-11-19 22:27:53 <lilo_booter > nice :)
2024-11-19 22:31:52 <lilo_booter > fwiw, i had nothing to do with lilo - it was just that when i first connected to irc, i needed to choose a nick and i went with the first thing i'd done that day
2024-11-19 22:32:27 <lilo_booter > good job i'd gone to the toilet after the boot up
2024-11-19 22:40:45 <xentrac     > yeah, I figured you weren't Werner :)
2024-11-19 22:40:54 <lilo_booter > :)
2024-11-19 22:41:13 <xentrac     > and obviously you aren't Rob Leven
2024-11-19 22:43:13 <lilo_booter > nope :) - my main contributions to open source are related to the kino and mlt projects (kino is dead, but mlt lives on with https://www.shotcut.org/ - i've not had time to do that kinda thing for a few years - 3 kids and a full time job dragging me down)
2024-11-19 22:43:33 <xentrac     > TactfulCitrus: happy to help!
2024-11-19 22:43:46 <xentrac     > TactfulCitrus: don't hesitate to ask more questions
2024-11-19 22:45:19 <xentrac     > lilo_booter: wow, that's great stuff!
2024-11-19 22:45:38 <xentrac     > I'm tempted to do some video editing but I'm more leaning toward Blender
2024-11-19 22:45:49 <xentrac     > *Levin
2024-11-19 22:45:54 <lilo_booter > ah - thanks - can't take any credit for shotcut though - that's all down to dan
2024-11-19 22:46:30 <lilo_booter > am thinking about releasing some stuff soon though...
2024-11-19 22:53:03 <xentrac     > while I am very much not a fan of the shitty "talking-head idiot alternating with vaguely relevant stock footage" that seems to be a lot of YouTube today (and most cable news) I think there are some kinds of information that really benefit from animation to present them
2024-11-19 22:54:07 <xentrac     > like, I spent a lot of time reading about automatic loom mechanisms and staring at mechanical diagrams without understanding how dobbies or jacquards worked
2024-11-19 22:55:33 <xentrac     > but things like https://ciechanow.ski/mechanical-watch/ seem like maybe a better format than a prerecorded video
2024-11-19 22:57:16 <lilo_booter > https://www.youtube.com/results?search_query=usagi+electric <- i'm totally addicted to this guys stuff - he's trying to ressurect (and build) vacuum tube computers and it's a total eye opener for me to see how all this tech started
2024-11-19 23:01:43 <lilo_booter > (i literally can follow the about 5% of the guys descriptions of circuits... but there are bunnies and cats at the end of his videos which make it all worthwhile)
2024-11-19 23:02:56 <vms14       > xd
2024-11-19 23:04:29 <amby        > vacuum tube computers are nuts
2024-11-19 23:04:38 <amby        > cuz they all do some arcane bullshit for memory
2024-11-19 23:05:08 <amby        > delay lines, storage tubes, magnetic hard drives
2024-11-19 23:08:34 <lilo_booter > yeah - doesn't feel like any of it should ever have worked at all
2024-11-19 23:10:39 <lilo_booter > xentrac: that watch thing is really interesting
2024-11-19 23:25:26 <xentrac     > lilo_booter: I know!
2024-11-19 23:25:35 <xentrac     > (I'm not Ciechanowski)
2024-11-19 23:37:48 <lilo_booter > :)