2024-01-20 01:40:43 <KipIngram   > Damn nonconformists...
2024-01-20 01:52:26 <thrig       > Zangband made the 64-bit transition... poorly... and had a soft-lock in character creation as a result
2024-01-20 15:43:51 <zelgomer    > forth: a little for allot
2024-01-20 16:01:43 <KipIngram   > thrig: 32 bit -> 64 bit is a pretty major change.  It's not exactly easy in a complicated application to not let that size "matter" anywhere at all.  And you only have to miss one spot to run into trouble.
2024-01-20 16:02:41 <KipIngram   > I used to think about trying to write my Forths so that I could just change a symbol value to change the cell size.  I mostly have given up on that; there's just a lot to juggle.
2024-01-20 16:03:02 <olle        > I think I'd feel more at ease with a GC forth :d
2024-01-20 16:03:13 <olle        > But that's Factor I guess.
2024-01-20 16:03:17 <KipIngram   > It can be done; I've done it.
2024-01-20 16:03:57 <olle        > No doubt
2024-01-20 16:04:13 <KipIngram   > In the end it ran entirely as a proper Forth, except I never got around to replacing the c stubs that implemented my primitives.
2024-01-20 16:04:19 <olle        > Wonder if factor still has the create/does mechanics
2024-01-20 16:04:35 <KipIngram   > My c source wound up awfully ugly, though.
2024-01-20 16:05:09 <olle        > Hehe
2024-01-20 16:05:09 <KipIngram   > By the time I'd added everything - create/does> in particular contributed to the ugliness.
2024-01-20 16:05:25 <KipIngram   > And after setting it aside for a year or so it was really hard to decipher the c source.
2024-01-20 16:05:48 <olle        > I guess a more modern forth dialect would just use constructor and invoke logic instead of create/does
2024-01-20 16:06:09 <olle        > could*
2024-01-20 16:06:44 <KipIngram   > The biggest downside of it performance-wise was that it used variables for all the stuff you'd normally want to use registers for.
2024-01-20 16:07:01 <olle        > Hm
2024-01-20 16:09:07 <KipIngram   > And since I was still running *some* bits of C code I couldn't change that.
2024-01-20 16:09:25 <KipIngram   > Since there really wasn't any way to know what those C bits were doing with the registers.
2024-01-20 16:11:25 <KipIngram   > I did look at the generated code some, and gcc hadn't really done the best job in my opinion.  There were numerous extraneous jumps.
2024-01-20 16:16:26 <olle        > Yea?
2024-01-20 16:16:35 <olle        > Well well
2024-01-20 16:16:49 <olle        > Can't beat hand-crafted ASM I guess :)
2024-01-20 16:21:52 <zelgomer    > geez i only just now realized abort" is supposed to be conditional
2024-01-20 16:22:03 <zelgomer    > why is this not ?abort" ??
2024-01-20 16:22:14 <zelgomer    > sometimes the naming inconsistencies confuse me
2024-01-20 16:25:08 <KipIngram   > Yeah, there definitely is some inconsistency in that kind of thing.
2024-01-20 16:25:31 <KipIngram   > I agree with you that trying for some rigor on that front is a desirable thing.
2024-01-20 16:26:07 <KipIngram   > I've been a little inconsistent about where I put the ? - I think I do like putting it at the front like you just did.
2024-01-20 16:27:08 <KipIngram   > And if a word can potentially produce the effect of a return (even if it's conditional), I usually try to put ; at the end of the name.
2024-01-20 16:27:41 <KipIngram   > I'm not 100% consistent with the ?, though - for example, I have 0=; instead of ?0=;
2024-01-20 16:28:00 <KipIngram   > Just because 0= has such a strong 'traditional behavior.'
2024-01-20 16:28:49 <GeDaMo      > You can see 0= as not asking a question but transforming a value
2024-01-20 16:29:33 <KipIngram   > that's true, but when you put ; onto it it's now conditionally 'doing something."
2024-01-20 16:29:48 <GeDaMo      > Ah
2024-01-20 16:31:01 <KipIngram   > At any rate, the ability to name tings "arbitrarily" is nice, but I think trying for some level of consistency makes things easier to remember.
2024-01-20 16:31:42 <olle        > 
ACTION needs a hash table implementation in C

2024-01-20 16:31:43 <KipIngram   > I've got over a hundred conditional return or recurse primitives, but they're named in a systematic enough way that I never have any trouble popping out the right name.
2024-01-20 16:31:57 <KipIngram   > olle: That's got to be "out there."
2024-01-20 16:32:52 <olle        > KipIngram: yea, checking glib source... also stackoverflow. or even chatgpt lol.
2024-01-20 16:37:14 <zelgomer    > KipIngram: i usually put the ? at the back when something returns a flag, and ? at the front when something consumes a flag. although it sometimes results in weird patterns like  foo? ?bar
2024-01-20 16:41:36 <KipIngram   > Oh, that seems like a nice touch.
2024-01-20 16:42:08 <KipIngram   > I've mostly transitioned to conditional actions and I'm pretty light on "flag use" these days.
2024-01-20 16:48:14 <KipIngram   > I think GeDamo's point about looking at things as a function/transformation is a good one, though.  0= always takes something and always leaves something; it's not like it might or might not leave a result.
2024-01-20 16:48:33 <KipIngram   > Whereas 0=; might or might not cause a return in my system.
2024-01-20 16:50:12 <zelgomer    > olle: i have written several. they not that hard
2024-01-20 17:02:07 <KipIngram   > I seem to recall that in hash systems where you do additional probes if you get a collision, generating the "next" value is easier if you still have the intermediate results for the previous one.  I've seen algorithms that generate the whole list, and you'd then just check them until you found one available.
2024-01-20 17:04:07 <KipIngram   > I think of it as somewhat like cryptography - if I were doing it I'd definitely find the algorith documented and copy it.  I might "re-arrange" the pieces a little bit, but I figure someone has figured this out - may as well use it.
2024-01-20 17:05:24 <thrig       > folks have written very bad hash functions
2024-01-20 17:05:46 <zelgomer    > there are several ways to handle open addressing. the way i usually do it is you generate the primary hash and then you hash that to come up with a secondary hash. or 1 into the secondary hash to guarantee that your stride isn't an even multiple of the table (which is a power of two), and then loop nbuckets times until you find what you're looking for
2024-01-20 17:05:49 <KipIngram   > Definitely.  It would be code worth testing.
2024-01-20 17:06:11 <KipIngram   > And the goal is straightforward - you just want there to be an equal probability of each storage slot in your table being chosen.
2024-01-20 17:06:37 <KipIngram   > So a histogram made using random strings would be simple enough to create.
2024-01-20 17:07:20 <KipIngram   > I didn't mean to imply you could just blindly copy the first thing you ran across.  :-)
2024-01-20 17:07:38 <KipIngram   > But the experts have been working on this for a long time.
2024-01-20 17:07:41 <olle        > http://burtleburtle.net/bob/hash/evahash.html
2024-01-20 17:07:45 <olle        > Some hash functions
2024-01-20 17:08:25 <olle        > http://www.partow.net/programming/hashfunctions/#AvailableHashFunctions
2024-01-20 17:08:27 <olle        > And that
2024-01-20 17:09:05 <thrig       > and you may need a better function if random (malicious) users can supply keys
2024-01-20 17:10:13 <olle        > no, this is just for a hobby compiler project ^^
2024-01-20 17:24:36 <KipIngram   > That's where I usually am.  Writing it for me, so I don't spend much time worrying about "malicious users."
2024-01-20 17:25:10 <KipIngram   > Forth offers you any number of ways to completely slag your system.  Preventing all of them would put a lot of overhead on the system.
2024-01-20 17:26:07 <KipIngram   > I did go to the trouble to put exception handling in there for bogus address references, but that was really for me - I just got tired of having to start all over after the resulting segfaults.
2024-01-20 17:26:46 <KipIngram   > Now it just handles those things the same way it handles the usual "handled errors."
2024-01-20 17:27:58 <KipIngram   > Plus it was kind of fun figuring out how to do it.  That turns out to be something that's not documented very well "out there."