2023-03-16 12:50:40 <DKordic     > KipIngram: IMHO that representative being ""Evil"" was expecting such outcome, some kind of success even.
2023-03-16 12:51:19 <DKordic     > A true Orc.
2023-03-16 16:51:31 <KipIngram   > Well, there's no doubt he was a creep in every possible way.  But there are "processes" for meetings like that - they shouldn't be undermined.
2023-03-16 16:51:48 <KipIngram   > The "good guys" shouldn't be the ones to break the rules.
2023-03-16 16:52:02 <KipIngram   > It calls into question just how good they really are.
2023-03-16 16:52:11 <KipIngram   > But - most importantly - it's not how it was told in the book.
2023-03-16 16:52:32 <KipIngram   > It was a thoroughly brazen message change.
2023-03-16 16:52:58 <KipIngram   > And a fairly cheap "shock factor grab."
2023-03-16 17:48:26 <qartis      > I've got a question about forth best practices: in my system I've defined the word pad:  : pad  here 80 + ;
2023-03-16 17:48:36 <qartis      > and it's used for formatting numbers for output
2023-03-16 17:50:03 <qartis      > later on I'm calling the posix function accept(2) which requires me to provide a pointer to a struct that it will use to provide me with some additional return values
2023-03-16 17:51:28 <qartis      > correction: it wants an int pointer, and it'll write an integer there
2023-03-16 17:52:13 <qartis      > in any case, I don't care about the value, so I've got a forth 'variable' whose only purpose is to be the recipient of that integer
2023-03-16 17:52:39 <qartis      > how bad would it be if I use the existing word "pad" for that scratch space instead?
2023-03-16 17:53:48 <qartis      > it would certainly work, and there's a pretty low risk of anything trying to use that same "here+80" pad space for number conversions at the same time
2023-03-16 17:54:49 <qartis      > but semantically it feels a bit weird
2023-03-16 17:55:25 <qartis      > according to forth-standard.org the pad space is a 'transient region that can be used to hold data for intermediate processing'
2023-03-16 17:56:32 <qartis      > so in that case it seems like this usage would be pretty legitimate
2023-03-16 17:56:34 <qartis      > thoughts?
2023-03-16 18:00:52 <thrig       > could go terribly wrong if you call over to something else that uses the same pad
2023-03-16 18:03:42 <koisoke     > i assume you plan on writing *something* in the dictionary or else you would just use HERE instead of PAD. in that case i wouldn't do it..
2023-03-16 18:04:06 <koisoke     > if your stacks are guaranteed to be downward-growing arrays in memory, then the simple and thread-safe thing to do would be to decrement the stack pointer and pass that
2023-03-16 18:04:24 <qartis      > ah interesting
2023-03-16 18:04:49 <koisoke     > but if you are using a Variable i guess you aren't concerned with thread-safety in whatever you are doing
2023-03-16 18:05:08 <qartis      > in this case I'm not adding anything into the dictionary or playing with the stack, so both of those should work too
2023-03-16 18:05:09 <koisoke     > (or it doesn't matter becasue you discard the result anyway?)
2023-03-16 18:05:23 <qartis      > I do discard the result, but it's a single-threaded forth
2023-03-16 18:07:14 <qartis      > I kind of like the additional info that using 'pad' implies, vs using 'here' or 'sp@'
2023-03-16 18:07:58 <qartis      > I'm new to forth so I have a bad habit of thinking too much like a c programmer
2023-03-16 18:08:27 <qartis      > in addition to my ignorance of forth best practices
2023-03-16 18:13:44 <qartis      > hah.. ironically 'pad' didn't work at first because the address wasn't aligned properly for an int store