2022-11-21 00:38:13 <remexre     > KipIngram: isn't pickle like, equivalent to eval()
2022-11-21 01:16:46 <KipIngram   > No, I don't think it actually evaluates anything.  It just converts a RAM object into a stream of bytes you can pass over a network.
2022-11-21 01:21:40 <KipIngram   > Dill is built on top of it and extends it to "most' types.
2022-11-21 09:22:52 <veltas      > KipIngram: As this channel is sort of the safe space for controversial opinions, I think binary formats can often be more human readable than JSON
2022-11-21 09:23:13 <veltas      > If you assume the reader has access to a good hex dumping tool
2022-11-21 09:23:22 <thrig       > that's an od opinion
2022-11-21 09:23:23 <veltas      > In Forth usually DUMP is good, if not you can write your own
2022-11-21 09:23:27 <veltas      > thrig: :)
2022-11-21 09:24:13 <veltas      > I've spent a lot of time reading binary formats and they're often as simple as they need to be to work
2022-11-21 09:24:30 <veltas      > JSON isn't that simple unfortunately, although the spec is quite small
2022-11-21 09:24:41 <veltas      > It can't represent an arbitrary string of bytes for one thing
2022-11-21 09:25:06 <veltas      > Not without weird intermediate stuff like a binary text representation
2022-11-21 09:25:30 <veltas      > And it's structured, which is often unnecessary and just complicates reading/writing logic
2022-11-21 09:26:56 <boru        > Like all things, it has its place. You wouldn't use binary formats for everything, or JSON for everything.
2022-11-21 10:32:39 <KipIngram   > veltas: I don't disagree.  Back in the day I got pretty good at just "looking at' x86 code and picking apart what it was going to do.  Sort of "mental disassembly."  So I know what you mean.
2022-11-21 10:33:36 <KipIngram   > And I agree that simple situations wouldn't need the power of json.  I think it's good for some things, but not necessarily universally optimum.
2022-11-21 10:34:30 <KipIngram   > Thing is, though, I do expect this data to have several structures that may be semi-complex.  I'm actually leaning toward dill right now, though, since it's explicitly intended to provide a way to "archive a session."
2022-11-21 10:34:42 <KipIngram   > That's precisely what I'm interested in doing.
2022-11-21 10:35:29 <olle        > https://www.mpeforth.com/resource-links/books/
2022-11-21 10:35:51 <olle        > I want "Programming Forth" as a video course... :/
2022-11-21 10:35:55 <olle        > Can someone do that for me?
2022-11-21 10:36:10 <olle        > Then I can run it in the background at work
2022-11-21 10:36:31 <KipIngram   > Looks simple - just imagination a loop-run state machine that has an "initialization state."  When I do a clean start, the state will be initialized to that.  To "re-start," I'll just dill.load_session(), which will set the state to some other non-initial one, and call the loop.
2022-11-21 10:36:38 <KipIngram   > Very clean.
2022-11-21 10:37:12 <KipIngram   > I just need to write it so the very first thing it does is enter that loop, and the state machine handles all the init stuff.
2022-11-21 10:39:08 <KipIngram   > If I give it a TUI using this urwid stuff, I guess that will have to be initialized in some way on each start, but I think the actual application stuff will have its state stored largely on disk anyway.
2022-11-21 10:40:19 <KipIngram   > I doubt dill.load_session() will re-activate an urwid interface.
2022-11-21 10:41:14 <KipIngram   > It would load all the right data controlling what gets shown on the screen, but I assume that just like curses there some "opening shots" you have to make to get it rolling.
2022-11-21 10:43:55 <KipIngram   > My mind's mostly on the appliance parts of this, though, which I will do in bash.
2022-11-21 10:44:03 <KipIngram   > No TUI there.
2022-11-21 10:44:25 <KipIngram   > I want to write that in a way such that I can manually "play controller" and run those pieces through their paces.
2022-11-21 10:44:39 <KipIngram   > I expect that to only be a few hours / a day of work.
2022-11-21 10:45:06 <KipIngram   > And it will get me as "productive" with the new stand as I currently am with the existing ones.
2022-11-21 14:04:33 <vms14       > do you follow any convention for naming a word that is similar to another, but does not push the element on the stack?
2022-11-21 14:04:57 <vms14       > like using that word + drop
2022-11-21 14:05:29 <vms14       > I usually have a * as a suffix to indicate different behavior for the same word
2022-11-21 14:05:36 <vms14       > like word and word*
2022-11-21 14:06:04 <vms14       > but I'd like to use a different way to mark a word that does not return the value
2022-11-21 14:06:13 <vms14       > like word~
2022-11-21 14:06:15 <vms14       > xD
2022-11-21 14:06:42 <vms14       > btw I didn't become a traitor at the end :D
2022-11-21 14:07:06 <vms14       > but idk if it's worse, now I'll make a not-so-forth in js
2022-11-21 15:24:06 <KipIngram   > Oh you mean you'd use it for its side effects, rather than for a return value?
2022-11-21 15:24:46 <KipIngram   > I have some words that do comparisons that use a naming convention.  For example, = will compare the top two items has stack effect ( a b -- f).
2022-11-21 15:25:07 <KipIngram   > But then I have .= which makes the same flag but has stack effect (a b -- a f).
2022-11-21 15:25:13 <KipIngram   > "Keeps the deepest argument."
2022-11-21 15:25:21 <KipIngram   > It's good for comparing a value to a series of other values.
2022-11-21 15:25:41 <KipIngram   > I just made up that naming convention - there was really no rhyme or reason to the prefix choice.
2022-11-21 15:26:03 <KipIngram   > I have a lot of conditional return words, and I have such "dot version" of all of them.
2022-11-21 15:26:55 <KipIngram   > So that's the opposite of your case - the special word *doesn't* drop something that the original word would.
2022-11-21 15:28:11 <KipIngram   > For a drop after running a word, I might lean toward <word>- or something?
2022-11-21 15:31:40 <olle        > Sigh
2022-11-21 15:31:52 <olle        > I want to get into forth hacking, but have a compiler to "finish" first :(
2022-11-21 15:34:37 <decay       > turn your compiler into a repl.
2022-11-21 15:35:21 <olle        > It's a PHP-to-C project
2022-11-21 15:35:36 <olle        > So maybe not impossible? o0
2022-11-21 15:35:58 <olle        > But now it's too cold in the room to focus on anything ><
2022-11-21 15:36:06 <KipIngram   > Oh, that sucks.
2022-11-21 15:36:26 <KipIngram   > That kind of "persistent discomfort" can just really kick you out of the flow.
2022-11-21 15:36:37 <olle        > 17,8C
2022-11-21 15:36:53 <olle        > 2 blankets
2022-11-21 15:36:58 <olle        > Couple of candles
2022-11-21 15:37:01 <KipIngram   > Yah - that's pretty chilly.
2022-11-21 15:37:06 <KipIngram   > Is your power out or something?
2022-11-21 15:37:21 <olle        > No, we're saving gas X|
2022-11-21 15:37:40 <KipIngram   > We had a 48 hours + power outage a few winters ago, and it got down to about 3 C inside our house before it was over.
2022-11-21 15:37:49 <olle        > YIKES
2022-11-21 15:37:56 <olle        > You had nothing to heat with??
2022-11-21 15:37:56 <KipIngram   > Yeah.  No fun at all.
2022-11-21 15:38:25 <KipIngram   > Nope.  We have a gas stove, so that worked (had to light it manually) so we could cook.
2022-11-21 15:38:28 <KipIngram   > But that was it.
2022-11-21 15:38:33 <KipIngram   > Oh, and we had hot water.
2022-11-21 15:38:50 <olle        > OK, then pyjamas party in the kitchen :)
2022-11-21 15:39:10 <olle        > I do have warm water bottle...
2022-11-21 15:39:11 <KipIngram   > 12 years ago or so we went on a ski trip, and the clothing we had from that trip was a godsend.
2022-11-21 15:39:20 <KipIngram   > Modern "high tech" cold weather gear reall works well.
2022-11-21 15:39:42 <olle        > I bought a new wool blanket, but it's not as good as I expected
2022-11-21 15:40:17 <KipIngram   > Oh, this is because of that pipeline explosion a few weeks ago?
2022-11-21 15:40:40 <olle        > KipIngram: Nah, price of gas has been high for months
2022-11-21 15:41:05 <olle        > But I guess it affected the price too
2022-11-21 15:41:52 <KipIngram   > That outage we had came durinG (and because of) one of the coldest snaps we've had in this area in years and years - it normally gets nowhere near that cold here.  Usually around 3 C OUTSIDE is about as cold as we get, save maybe one or two nights a winter.
2022-11-21 15:42:18 <KipIngram   > We're fairly close to the Gulf of Mexico, and I think the air is moist enough that it's hard to get it to any "extreme" temperature in either direction.
2022-11-21 15:42:37 <olle        > Where you at?
2022-11-21 15:42:56 <KipIngram   > But we had nights in the teens (F) - which would be say -10 C during that event.
2022-11-21 15:43:01 <KipIngram   > Near Houston Texas.
2022-11-21 15:43:04 <olle        > Brrr
2022-11-21 15:43:07 <KipIngram   > Pretty far south actually.
2022-11-21 15:43:14 <olle        > Oh yeah, I heard about the Texas outage
2022-11-21 15:43:43 <KipIngram   > The big shots that manage our power grid always brag about us having an "independent grid," but they really screwed the pooch that year.
2022-11-21 15:44:02 <olle        > What I heard, that independence is part of the problem?
2022-11-21 15:44:06 <olle        > Makes it more vulnerable
2022-11-21 15:44:31 <KipIngram   > Yes.  Certainly part of the problem.  It removed the possibility of us bringing power in from other regions.
2022-11-21 15:44:37 <KipIngram   > But there was poor planning too.
2022-11-21 15:44:38 <olle        > Right
2022-11-21 15:44:47 <olle        > Similar complains in Sweden too, heh
2022-11-21 15:44:55 <olle        > Between north and south
2022-11-21 15:44:56 <KipIngram   > The cold took out some of our capacity, and there was insufficient excess capacity online.
2022-11-21 15:45:16 <olle        > Gotta keep planning for more extreme weather yo
2022-11-21 15:45:33 <KipIngram   > The cold froze up most of the wind turbines in west Texas, and also caused some sort of problem I'm not as clear on for some of our natural gas resources.
2022-11-21 15:45:49 <olle        > Hm
2022-11-21 15:46:18 <KipIngram   > I swore I was going to buy a generator that summer (a whole house one), but other expenses came up and I still don't have one.
2022-11-21 15:47:22 <olle        > If I had my own house I'd try to invest a little into off-grid things
2022-11-21 15:47:37 <olle        > Wanna buy a summer house in some years, but requires some planning
2022-11-21 15:47:43 <KipIngram   > It's ironic - nicer houses all have pretty fireplaces, but they don't actually do anything other than light up and look pretty.  Decorative only.
2022-11-21 15:48:14 <KipIngram   > We've just wired "dependency" into our culture these days.
2022-11-21 15:48:21 <olle        > Yes, it's supposed to be built in a specific way to keep heat
2022-11-21 15:48:59 <olle        > We might be moving away from dependency into a more "smart-grid" system, eventually
2022-11-21 15:49:16 <olle        > Where each house is an electricy producer during warm summer days
2022-11-21 15:49:18 <KipIngram   > That would be good.
2022-11-21 15:49:35 <olle        > Still no large scale storage system invented :d
2022-11-21 15:49:43 <olle        > Except pumping water to high places
2022-11-21 15:49:51 <KipIngram   > Here we have the electric utilities lobby *against* moves toward self-sufficiency.
2022-11-21 15:49:53 <olle        > But I think the loss is great, friction etc
2022-11-21 15:50:04 <KipIngram   > They don't want us to have any option except to give them a regular stream of income.
2022-11-21 15:50:35 <olle        > Can't fight the materialistic foundation of history ;) When it gets cheap enough, people will buy it.
2022-11-21 15:51:09 <KipIngram   > One state even pushed for a fee to be placed on people that installed solar panels.  In other words, they wanted the money ANYWAY, even if someone wasn't using the electricity.
2022-11-21 15:51:21 <KipIngram   > I don't think that one flew.
2022-11-21 15:51:23 <olle        > Yeah, that's hilarious
2022-11-21 15:51:32 <KipIngram   > But I rolled my eyes at the audacity.
2022-11-21 15:53:44 <olle        > Let's try an ibuprofen for motivation booster...
2022-11-21 16:09:47 <KipIngram   > Drugs ftw...
2022-11-21 16:18:59 <olle        > Always
2022-11-21 16:19:21 <olle        > Funny enough, the villain in the latest rick/morty episode sucks everyone's motivation...
2022-11-21 16:19:37 <olle        > He's driven by - motivation \o/
2022-11-21 17:12:14 <KipIngram   > I had no idea Python had a built-in debugger, pdb.
2022-11-21 17:13:54 <KipIngram   > Doesn't' really surprise me, though.
2022-11-21 17:30:52 <vms14       > this is the most basic "core" of a not-so-forth
2022-11-21 17:31:01 <vms14       > https://termbin.com/kfokb
2022-11-21 17:31:17 <vms14       > 240 lines, still it has some drawbacks, but meh
2022-11-21 17:31:26 <vms14       > now the rest is word definitions
2022-11-21 17:31:52 <vms14       > one of the drawbacks is words are dynamic, I'll provide a way to "compile" them, but it also has a problem xD
2022-11-21 17:33:13 <vms14       > the compiling just searches words and converts them into functions, but there are times when a word has a temporary value, if the "compiler" does not find a word then it converts it into a call to interpret with this value
2022-11-21 17:33:57 <vms14       > the problem is if it finds it, it will convert it into a closure that retains this value and pushes it into the stack
2022-11-21 17:34:25 <vms14       > a colon word ends being an array of functions, this way the interpreter does not have to search words
2022-11-21 17:34:54 <vms14       > the problem is when a temporary binding or something will create a word that the compiler finds at that moment
2022-11-21 17:35:41 <vms14       > the word will have that value when the compiler was executed, ignoring the new binding xD
2022-11-21 17:36:16 <vms14       > idk how to fix this for now
2022-11-21 17:38:50 <vms14       > I think it's fine as long as the binding function does not get a "compiled" array, but still it's a problem
2022-11-21 17:46:54 <KipIngram   > Hey, If I am running bash and I use ssh to send a command to some other system, will variable expansions on the command string be done on my system or on the target system?  Will it be my system if I enclose the command string in double quotes and on the target system if I enclose it in single quotes?
2022-11-21 17:47:41 <vms14       > if you use ssh as a command in your system
2022-11-21 17:47:50 <vms14       > if you use it as a repl in the remote one
2022-11-21 17:48:12 <vms14       > but yes, supposedly like you say
2022-11-21 17:48:49 <vms14       > you could also '\'command\'' to not have any expansion on both
2022-11-21 17:49:42 <vms14       > or use a file and cat or alike
2022-11-21 17:56:26 <olle        > p
2022-11-21 17:56:28 <olle        > oops
2022-11-21 18:31:28 <KipIngram   > Actually I want the expansion to happen locally, and the expanded result to be sent over ssh.  So I want to enclose in double-quotes.
2022-11-21 18:44:52 <KipIngram   > Agh.  I'm having one of those "temptation moments," where you consider making something more general than it needs to be.
2022-11-21 18:45:03 <KipIngram   > I have these three things.  Controller, master, slave.
2022-11-21 18:45:19 <KipIngram   > Master and slave both run traffic into the storage - controller just controls.
2022-11-21 18:46:12 <KipIngram   > So, when it's time to start a test, controller will tell master to go.  Master will tell slave to go and start the master test.  Slave will start a beat behind, but only a very short beat.
2022-11-21 18:46:50 <KipIngram   > So the temptation is simple.  It would only a tiny bit more to make it so I could have a long chain of players.  Not just two boxes that ran tests, but several.
2022-11-21 18:47:24 <KipIngram   > The longer the chain was, the further behind the last guy would be compared to the first, but it still wouldn't be much, and when I harvest the data I throw out any timestamps that don't appear in everyone's logs anyway.
2022-11-21 18:47:47 <KipIngram   > It's more or less trivial to make it do that.  But it's not something I "need."
2022-11-21 18:48:45 <KipIngram   > Of course there's a master/slave pair for all 12 drives the box will hold, but the pairs are separate from one another.
2022-11-21 18:49:08 <KipIngram   > So the controller is a "central bubble" with 12 2-long chains coming off of it.
2022-11-21 18:51:14 <KipIngram   > The main difference between a master and a slave is that when we *restart* an incomplete test, the master will not need a "first go command" from the controller to begin, and he'll never need a controller go command to *continue* to the next step.  Once the job is started, the master runs the show until it's done.  But the slave always waits for go, on every job step.
2022-11-21 18:52:27 <KipIngram   > The appliances start off "available," but the master won't announce available to the controller unless the slave is announcing it to him.
2022-11-21 18:54:06 <KipIngram   > Then at any time the controller can copy a job directory structure to the master, and send him a "prep" command.
2022-11-21 18:54:20 <KipIngram   > Master forwards that info to the slave and gives him the prep command.
2022-11-21 18:55:02 <KipIngram   > They both do some initializing, except they can detect whether the job is new or in progress (if it's a restart).
2022-11-21 19:13:33 <vms14       > 0 1 1000000 range [ i + ] do.list .
2022-11-21 19:14:06 <vms14       > this creates a list with numbers from 1 to 1000000 and then iterates it and sums all the numbers
2022-11-21 19:14:23 <vms14       > in the perl implementation this code took 12 seconds, in the js one 0.5 seconds xD
2022-11-21 19:14:53 <vms14       > even in the browser is also that fast
2022-11-21 19:15:19 <vms14       > well didn't time it in the browser, but didn't take any noticeable time
2022-11-21 19:37:11 <eris[m]     > thats the power of JIT
2022-11-21 20:06:57 <decay       > don't discount compiler optimizations before you get to JS either. if you can say "well, at this point, we're creating a giant list from a range, and then we're... summing that list up", then you can just reduce that to a constant.
2022-11-21 20:07:16 <decay       > there's ways to symbolically compute that.
2022-11-21 20:54:37 <KipIngram   > Heh.  Later I will implement that on my Forth and see what it takes.
2022-11-21 20:54:55 <KipIngram   > That number is a million?
2022-11-21 20:55:03 <KipIngram   > Hard to count onscreen zeros.
2022-11-21 20:55:33 <KipIngram   > You just want to sum the numbers 1 to a million?
2022-11-21 20:56:09 <decay       > looks like it.
2022-11-21 20:57:14 <KipIngram   > Got to look up how my time measurement stuff works.
2022-11-21 20:57:34 <KipIngram   > But here's the code:
2022-11-21 20:57:37 <KipIngram   > : sum_it  swap over + swap 1- .0>me drop ;  ok
2022-11-21 20:57:39 <KipIngram   > 0 1000000 sum_it . 500000500000  ok
2022-11-21 20:57:50 <KipIngram   > No perceptible delay - I'll have to measure it.
2022-11-21 20:58:03 <decay       > I think the idea would be generating a list.
2022-11-21 20:58:08 <decay       > and then summing that list.
2022-11-21 21:00:30 <thrig       > I have a silly expt : that unrolls the items to multiply
2022-11-21 21:00:34 <KipIngram   > Oh.  Ok.
2022-11-21 21:00:41 <KipIngram   > I'll redo it after dinner.
2022-11-21 21:28:06 <vms14       > KipIngram: I'd like to say I don't like to use a dot for something that isn't printing and that use it for something else could be confusing, but I can't talk as I'm using the dot for a lot of things xD
2022-11-21 21:28:22 <vms14       > anyways now I can rethink my choices as I'm starting again
2022-11-21 21:28:42 <vms14       > my main concern for now is how to make the compiling for temporary bindings
2022-11-21 21:29:03 <vms14       > I'm not really compiling anything, but I convert a word into a bunch of subroutines
2022-11-21 21:29:26 <vms14       > this at least avoids the searching of the interpreter, since the compiling process just searches the stuff and creates a closure
2022-11-21 21:30:20 <vms14       > but for temporary bindings it's a problem, if the "compiler" does not find a word it assumes it's symbol and creates a closure that it's a call to the interpret() function with this symbol saved
2022-11-21 21:30:38 <vms14       > if it's a word it turns the contents into a subroutine in a recursive way
2022-11-21 21:31:34 <vms14       > the thing is if you wanted to set a temporary binding with a name that a word defined already has the "compiler" will take that definition instead and make a closure with the value it found, so the temporary binding goes to trash
2022-11-21 21:32:11 <vms14       > but I'm thinking in making also a special syntax for a temporary binding and not make them a word, but store them in a different place
2022-11-21 21:33:54 <vms14       > this way the compiler can even store them into a subroutine by creating a function that pushes that value on the stack
2022-11-21 21:34:30 <vms14       > well it has no sense storing it as it will have to be a subroutine that pushes that value on the stack
2022-11-21 21:35:02 <vms14       > and if statements are not a bottleneck anyways, also the main goal of compiling now is not performance, but have words that use the old definitions
2022-11-21 21:36:39 <vms14       > I mean, now even if you make a package, if you define a word like: : word some-other-word ; when word is executed it will use the actual some-other-word definition, if you make a new package and define some-other-word, it will use that definition instead of the older one
2022-11-21 21:37:29 <vms14       > the "compiling" process stores the definition into a subroutine, so the definition will be the one that is found when you actually compile it, newer definitions won't affect it
2022-11-21 21:38:07 <vms14       > I like to have both methods, so you can decide whether mess with a definition or not, also to protect your whole package by "compiling" it
2022-11-21 21:38:45 <vms14       > the only problem is temporary bindings will be ignored, so I'll make them a different thing instead of words
2022-11-21 21:40:48 <vms14       > about the dots, I was already using .name to use it as a key index from a object property or array
2022-11-21 21:40:57 <vms14       > [ 1 2 3 ] .0 => 1
2022-11-21 21:41:58 <vms14       > but I can choose different ways to do stuff since I'm just starting again
2022-11-21 21:49:35 <vms14       > now that I think about, it does not feel that bad to use . to indicate a drop operation as . is sometimes even used just for that
2022-11-21 21:50:22 <KipIngram   > Ok, will this qualify?  Just for a timing check - I don't really have smooth array declaration or any kind of jazz like that.  I created a constant 'array' that provides a usable address for the list:
2022-11-21 21:50:25 <KipIngram   > : fill_it  dup dup 3 << array + ! 1- .0>me drop ;  ok
2022-11-21 21:50:26 <KipIngram   > : sum_it  >r r@ 3 << array + @ + r> 1- .0>me drop ;  ok
2022-11-21 21:50:28 <KipIngram   > : test  dup fill_it 0 swap sum_it ;  ok
2022-11-21 21:50:30 <KipIngram   > 1000000 test . 500000500000  ok
2022-11-21 21:50:31 <vms14       > but I'd prefer to have .name to indicate object property access than an implicit drop since people seem to be used to use object.key
2022-11-21 21:50:52 <KipIngram   > If that seems fair I'll go figureout how to time it.
2022-11-21 21:50:56 <vms14       > it seems
2022-11-21 21:51:04 <vms14       > at least returns the same value xD
2022-11-21 21:51:11 <KipIngram   > Yeah; that's comforting.
2022-11-21 21:51:31 <KipIngram   > But it does all the same stuff to all the entries.  Stores the value into a succession of cells, then reads them all back and sums them.
2022-11-21 21:51:40 <KipIngram   > Seems like a reasonable comparison case to me.
2022-11-21 21:51:42 <vms14       > in real forth arrays are just a memory address, so it's fine
2022-11-21 21:52:23 <vms14       > I mean, you don't need to implement any array, as you can store a sequence in memory
2022-11-21 21:52:48 <vms14       > it feels better and more efficient
2022-11-21 21:54:10 <vms14       > how are you going to time it?
2022-11-21 21:54:19 <vms14       > do you have access to the internal clock or alike?
2022-11-21 21:55:03 <vms14       > I use time from unix, it also involves the startup and alike, but still it's 0.5 seconds in js and 12 in perl
2022-11-21 21:55:22 <vms14       > and the range operator is not builtin in js, I'm using a for loop to generate it xD
2022-11-21 21:55:47 <vms14       > I was worried about the performance so I'm using UintNArray depending on the number
2022-11-21 21:56:19 <vms14       > https://hastebin.com/vewipijada.php
2022-11-21 21:56:40 <vms14       > idk if it actually does something in terms of performance anyways
2022-11-21 21:57:03 <vms14       > I could do the same for negative numbers but I was lazy and just used [] there
2022-11-21 21:57:29 <KipIngram   > Here we go:
2022-11-21 21:57:34 <KipIngram   > 1000000 measure 20390 500000500000
2022-11-21 21:57:50 <KipIngram   > 20390 microseconds, so 0.02 seconds.
2022-11-21 21:57:54 <vms14       > :0
2022-11-21 21:58:14 <KipIngram   > : measure >r uet drop r> test swap uet drop swap - . . ;
2022-11-21 21:58:21 <vms14       > I wonder if I can achieve that without the startup overhead xd
2022-11-21 21:58:37 <vms14       > I don't think so anyways
2022-11-21 21:58:56 <KipIngram   > Well, it will be interesting to see - my guess is that you'll need to get closer to an actual Forth to do that.
2022-11-21 22:01:01 <KipIngram   > The whole point of a test like this is that the startup overhead is ammortized over all the iterations; it should be negligible.
2022-11-21 22:01:22 <KipIngram   > You could try it with 5000000 instead of 1..., or 10... and see how it scales.
2022-11-21 22:01:43 <KipIngram   > The part that's per iteration should just scale - to the extent it doesn't, you can calculate how much start overhead you have.
2022-11-21 22:02:46 <KipIngram   > Are you having to start up your whole system as part of the time you're measuring?
2022-11-21 22:04:13 <vms14       > I just do: time node file.js
2022-11-21 22:16:01 <vms14       > 431 ms
2022-11-21 22:16:30 <vms14       > let code = get();    let time = Date.now();    code.forEach(interpret);    put(Date.now() - time);
2022-11-21 22:16:31 <vms14       > 
2022-11-21 22:17:03 <vms14       > Date.now() returns the time in milliseconds from unix epoch
2022-11-21 22:20:29 <vms14       > seems the startup time is only 0.1 seconds
2022-11-21 22:21:15 <vms14       > added another 0 to the million and takes 4 seconds
2022-11-21 22:22:03 <vms14       > still is quite remarkable for being js
2022-11-21 22:22:09 <vms14       > js performance amazes me
2022-11-21 22:23:47 <vms14       > in the browser one million takes 1 second without the startup overhead
2022-11-21 22:23:56 <vms14       > adding another 0 takes 12 seconds xd
2022-11-21 22:26:11 <vms14       > and using Uint32Array instead of a normal [] seems to add a bit of performance
2022-11-21 22:26:29 <vms14       > mostly in the browser, it takes 16 seconds if it's a [] array
2022-11-21 22:26:43 <vms14       > in node 1 second more, 5 seconds
2022-11-21 22:27:04 <vms14       > this is with 10000000 instead of 1000000
2022-11-21 22:27:59 <vms14       > 12 seconds was taking perl to sum one million where js takes 0.5
2022-11-21 22:28:18 <vms14       > optimizing it by avoiding the interpreter overhead took 2 seconds in perl
2022-11-21 22:28:43 <KipIngram   > Oh, ok - there's no telling how much crap you're measuring.
2022-11-21 22:28:44 <vms14       > in js I did no optimization
2022-11-21 22:29:11 <KipIngram   > I'm measuring more or less nothing except the inner interpreter execution of test.
2022-11-21 22:29:26 <vms14       > well didn't care about performance until I saw a guy that had a benchmark in his own lang and wanted to try
2022-11-21 22:29:29 <KipIngram   > And I guess I have to get "out of" the first call to uet and 'into" the second.
2022-11-21 22:29:37 <KipIngram   > But that's spread over all iterations.
2022-11-21 22:29:47 <vms14       > then saw how perl was taking 12 seconds and was quite discouraged
2022-11-21 22:30:09 <vms14       > but the same stuff in js takes 0.5 so I'm quite happy
2022-11-21 22:30:15 <KipIngram   > Well, perl isn't a language renowned for its speed.
2022-11-21 22:30:20 <KipIngram   > Its strengths lie in other areas.
2022-11-21 22:30:36 <vms14       > no, but I expected hash tables to be fast since they're overused in perl
2022-11-21 22:30:46 <vms14       > it just tells me how crappy perl is
2022-11-21 22:31:22 <vms14       > and I expected it to be fast for being an interpreted lang, but nope
2022-11-21 22:31:32 <vms14       > still for unix scripting is the best thing you can find
2022-11-21 22:31:51 <vms14       > but for more than that, just use another thing :/
2022-11-21 22:32:00 <vms14       > 
ACTION cries

2022-11-21 22:32:35 <KipIngram   > I got on a timing jag with my Forth one night, and compared it in a few ways with GForth.  I don't have the same looping structures as it, but I just tried to write some things as well as the respective languages allowed.
2022-11-21 22:32:49 <KipIngram   > What I found was that just EXECUTING compiled code, I compared pretty favorably.
2022-11-21 22:33:03 <KipIngram   > But on dictionary lookups GForth just totally kicked my butt.
2022-11-21 22:33:27 <KipIngram   > I decided that GForth can't possibly be using a standard linked dictionary walk as its routine way of finding words.
2022-11-21 22:33:39 <KipIngram   > I think they'e got a hash table in there somewhere.
2022-11-21 22:34:20 <KipIngram   > i don't see how else it could be so much faster on that.
2022-11-21 22:42:31 <vms14       > can't find info about
2022-11-21 22:42:40 <vms14       > so it seems the only answer is to look at the code
2022-11-21 22:47:16 <KipIngram   > Yeah, I wasn't able to find anything either.  But it wasn't "somewhat" faster - it was wildly faster.
2022-11-21 22:48:09 <KipIngram   > I tested that by writing a word that would conditionally reset >in to zero.
2022-11-21 22:48:26 <KipIngram   > so I was able to have it interpret the line up to there over and over.  Then I just timed that.
2022-11-21 22:49:03 <KipIngram   > Oh, wait - never.  That's how I did the early tests of my interpret speed.  Once I had that uet word I used it.
2022-11-21 22:54:52 <vms14       > I see several *cache* stuff on the gforth source code, but no idea what is caching for
2022-11-21 22:55:03 <vms14       > still makes sense it could be fast because of caching
2022-11-21 22:55:16 <vms14       > I see in some comments it has several threading methods
2022-11-21 22:57:44 <vms14       > https://github.com/forthy42/gforth/search?l=c  this is the C code
2022-11-21 23:04:07 <vms14       > KipIngram: Words are usually searched through the hash table
2022-11-21 23:04:15 <vms14       > so you were right it seems :D
2022-11-21 23:04:21 <vms14       > http://www.euroforth.org/ef19/papers/paysan.pdf
2022-11-21 23:05:05 <vms14       > but then how does forget work
2022-11-21 23:06:41 <KipIngram   > It could just flip a bit in the hash entry.  Mark it invalid.
2022-11-21 23:07:10 <KipIngram   > But a hash table doesn't give you order of creation, so they might have to use a different method for that.
2022-11-21 23:07:20 <KipIngram   > They could still have a list - just have a hash also.
2022-11-21 23:12:31 <vms14       > Gorth uses a hash table to speed up dictionary searches. This hash table is in allocated memory; it is built on system startup by inserting all the words from the linked-list representation of the wordlists, and is rebuilt in the same way when necessary
2022-11-21 23:13:21 <vms14       > well now you know for sure it's a hash table xD
2022-11-21 23:13:48 <vms14       > seems they mantain both a linked list and a hash
2022-11-21 23:23:47 <KipIngram   > I was pretty convinced anyway, just because of its s peed.
2022-11-21 23:24:45 <KipIngram   > It's actually a smart way to use an enormous RAM space you're not otherwise needing for anything.
2022-11-21 23:25:18 <KipIngram   > And if you need to know, for any reason, what order you defined words in, you need a linked list too.
2022-11-21 23:25:48 <KipIngram   > And a hash table like that would be an extremely easy feature to add.
2022-11-21 23:26:15 <KipIngram   > You'd just have WORD compute the hash as it parsed the word, and stow it somewhere.
2022-11-21 23:26:51 <KipIngram   > Basically by time you finish parsing the word, you've got an array index - that index either has the word or doesn't.
2022-11-21 23:27:31 <KipIngram   > Collisions happen in hash tables as they get fuller of course, but if I were doing it I'd just make it so big that the probability of a collision was really low.
2022-11-21 23:28:05 <KipIngram   > If your table will hold N items, then after you put in one word, the probability that the second word collides with it is 1/N.
2022-11-21 23:28:25 <KipIngram   > Then the  probability that the third word collides with the first two is 2/N, then 3/N for the fourth word, and so on.
2022-11-21 23:29:05 <KipIngram   > Say you have a thousand words.  If your hash table holds a million entries, then even the last word -  the 1000th - has just a 0.001 probability of colliding with one of the others.
2022-11-21 23:29:26 <KipIngram   > Although actually you have to compound those.
2022-11-21 23:30:16 <KipIngram   > The probability of "no collision" for 1000 words in a million word table would actually be 0.999999*0.999998*0.999997*...*0.999001.
2022-11-21 23:33:05 <KipIngram   > which turns out to be about 60%
2022-11-21 23:34:07 <KipIngram   > If the table holds 10 million entries, that goes up to about 95%