2023-10-11 06:16:17 <rendar      > why historically we have '=' and not '=?' for eq comparisons?
2023-10-11 06:25:04 <dave0       > i don't know for sure, but it might have been common at the time .. i know basic uses = for equality (also for assignment) ... i think fortran does too but i'm not sure
2023-10-11 06:26:14 <dave0       > just asking if lisp uses = for equality
2023-10-11 06:26:38 <GeDaMo      > Lisp has a few equality tests
2023-10-11 06:26:43 <dave0       > c might be the off man out with ==
2023-10-11 06:26:48 <dave0       > odd man out*
2023-10-11 06:27:16 <dave0       > pascal might also use = for eqality
2023-10-11 06:27:33 <GeDaMo      > https://stackoverflow.com/questions/547436/whats-the-difference-between-eq-eql-equal-and-equalp-in-common-lisp
2023-10-11 06:28:27 <dave0       > using = as equality is closer to mathematics too
2023-10-11 06:28:53 <dave0       > i'm speculating
2023-10-11 07:34:23 <dzho        > concision to the point of obscurity is a forth hallmark, in which light using a single character for perhaps the most common test fits
2023-10-11 07:34:51 <dzho        > I mean, really: @ ! . ,
2023-10-11 08:06:14 <veltas      > In BASIC you tend to give more context for assignment vs comparison, like "LET x=0" vs "IF x=0"
2023-10-11 08:06:32 <veltas      > Classic Forth doesn't have that kind of context in its words
2023-10-11 10:27:20 <KipIngram   > rendar: I don't see how to say - Chuck just chose it, I guess.  It's shorter.  And Forth has no other use for = since it doesn't use it for assignment.
2023-10-11 10:28:18 <KipIngram   > In my (non-standard) system, most of my control flow is done with conditional returns and conditional recursion.  I have a whole family of words for getting at all the possible cases, and I follow a clean naming convention for those so that it's easy for me to remember the names.
2023-10-11 10:29:03 <KipIngram   > There are six comparison cases, cases for two arguments or one argument with an implied 0 for the other, signed and unsigned cases, and I also have an option whether to discard all of the arguments or all except one.
2023-10-11 10:29:10 <KipIngram   > So by the end of it I have over a hundred such words.
2023-10-11 10:29:43 <KipIngram   > Oh, and also options for single return and double return.
2023-10-11 10:30:57 <KipIngram   > So I might have >=; for "return if greater than equal," and that implies that I also have 0>=; and u>=; and u0>=; etc. etc.  Tack a second ; on the end and you get double returns.  Tack "me" onto the end instead of ; or ;; and that's conditional recursion.
2023-10-11 10:31:20 <KipIngram   > I start it off with a . if I want the flavor that retains one of the arguments.
2023-10-11 10:31:51 <KipIngram   > Retaining an argument is handy - it works well in cases where you have, say, a character from the keyboard and want to compare it to each item of a list of characters.
2023-10-11 10:32:09 <KipIngram   > The comparison discards the item from the list, but keeps the original data.
2023-10-11 10:32:56 <KipIngram   > Doesn't get me anything I couldn't do otherwise; .<comparison> is the same as dup <comparison>.  Just adds a smidge of performance.
2023-10-11 10:33:25 <KipIngram   > The naming scheme is simple enough, though, that I have no trouble popping in these names when I need them.
2023-10-11 10:34:14 <veltas      > It's like asking "why isn't WITHIN WITHIN? "
2023-10-11 10:34:32 <veltas      > I suppose you've got more discretion for making words shorter if they're going to be in the core set
2023-10-11 10:34:33 <KipIngram   > Yes.  Someone chose, and not always consistently.
2023-10-11 10:35:23 <veltas      > The lack of consistency is controversial, some people prefer a more consistent system, but many are happy with the compromises in normal forth names
2023-10-11 10:35:35 <KipIngram   > rendar: Are you "big on standards"?  I'm not - I always feel free to rename anything any way I want.
2023-10-11 10:35:50 <veltas      > If you want to try more consistent names then have a look at something like retro
2023-10-11 10:36:51 <KipIngram   > My guess is that a naming strategy that "resonates" with you will always be easier for you to remember and use intuitively.
2023-10-11 10:37:25 <KipIngram   > It's even worse in APL.  All those glyphs, and pretty much no reason that they were assigned the way they were.
2023-10-11 10:37:49 <KipIngram   > Of course, you could ask why we use + for addition - it all goes back to someone just choosing something way long ago.
2023-10-11 10:38:33 <KipIngram   > Why is ! used for "store"?  It feels right to us now, but that's just because we've used it ever since we picked Forth up.
2023-10-11 10:39:41 <KipIngram   > I could have included a ? in all of my conditional words, to just scream out "this is a conditional word."  But it really wouldn't have helped me and would have made all of those words a character longer.
2023-10-11 10:39:53 <rendar      > KipIngram, me too
2023-10-11 10:40:41 <KipIngram   > I would just say that if you're writing a system and you want it to conform to some standard, well, then you're stuck with the names.  But otherwise just do whatever makes sense to you.
2023-10-11 10:40:53 <KipIngram   > Names in Forth are 100% arbitrary.
2023-10-11 10:41:37 <KipIngram   > Well, beyond the fact that they can't contain a space.
2023-10-11 10:42:36 <KipIngram   > And even that isn't a system wide limitation - the dictionary is entirely capable of storing a name with a space in it.  It's just that the input parsing won't gather two space-separated pieces into "something to search for."
2023-10-11 10:43:19 <KipIngram   > But if you had some strange application where it made sense, you certainly could use the dictionary to store names with spaces, and you could search for them - you'd just have to construct those search strings manually.
2023-10-11 10:43:27 <KipIngram   > FIND will only take one word out of the input stream.
2023-10-11 10:44:34 <KipIngram   > CREATE usually uses FIND, so it has the same limitation, but I have a second entry point (CREATE) that would let me push in an arbitrary counted string.
2023-10-11 10:44:57 <KipIngram   > I also have (FIND) that will do the same.
2023-10-11 10:45:22 <KipIngram   > Basically those are just something like
2023-10-11 10:45:27 <KipIngram   > : FIND  BL WORD
2023-10-11 10:45:34 <KipIngram   > : (FIND) ...the rest of it... ;
2023-10-11 10:46:05 <KipIngram   > Note - not all Forths will let you use : inside a definition like that.
2023-10-11 10:47:00 <KipIngram   > But my compiled code is just one big wall of code - the headers are "elsewhere" and just point into that wall.
2023-10-11 10:47:59 <KipIngram   > So FIND points somewhere, and (FIND) just points two cells after that.
2023-10-11 11:22:07 <crc         > rendar: I use longer names (e.g., eq? lt? gtq? -eq? store fetch push pop) in my system. I use symbols for sigils, but generally not word names.
2023-10-11 11:22:30 <rendar      > crc, cool
2023-10-11 11:22:36 <rendar      > -eq? what's that?
2023-10-11 11:22:42 <crc         > Shorter names can make sense in terms of the constraints on older systems
2023-10-11 11:22:59 <rendar      > not eq?
2023-10-11 11:23:06 <crc         > -eq? is "not equals" (I use a leading - to indicate "not" in my naming conventions)
2023-10-11 11:28:28 <thrig       > last I checked forth names were quite a bit shorter than say common lisp symbols
2023-10-11 11:35:29 <crc         > my average word name is 8 characters
2023-10-11 13:44:32 <KipIngram   > I prefer shorter names because it gets more "effect" into the chunk of code I can  "hold in my short term memory" somehow.  I don't know exactly how to explain it, and it may be a trait that have that isn't common to everyone, but somehow I feel like I can just mentally process a chunk of code better if it's more compact.
2023-10-11 13:45:13 <KipIngram   > I think it's related to that "visual channel" I've mentioned, like when I talk about the "shape" of a digital logic circuit being informative somehow.
2023-10-11 13:45:44 <KipIngram   > If the code sprawls across more of the screen, it's harder for me to process it internally.
2023-10-11 13:46:16 <KipIngram   > In his APL videos and blog posts, Aaron Hsu says some very very similar things - I think he clearly has the same kind of thing going on.
2023-10-11 13:46:44 <thrig       > https://thrig.me/tmp/ans-vs-clhs.txt
2023-10-11 13:46:51 <KipIngram   > The same idea is why I usually wind up not wanting comments intermingled with my code.
2023-10-11 13:47:17 <KipIngram   > The comments spread things out and it doesn't flow through my mental process as well.
2023-10-11 14:34:49 <crc         > with files, I alternate between sections of comments and code; with blocks I either use dedicated comment blocks, or sometimes a few lines at the start or end of the block (e.g., http://forth.works/temp/block.png )
2023-10-11 14:47:52 <KipIngram   > Just watched a couple of nice videos on chess engines.  First one just gets a basic chess bot up and running:
2023-10-11 14:47:54 <KipIngram   > https://www.youtube.com/watch?v=U4ogK0MIzqk
2023-10-11 14:48:04 <KipIngram   > Second one makes some significant improvements to it:
2023-10-11 14:48:20 <KipIngram   > https://www.youtube.com/watch?v=_vqlIPDR2TU
2023-10-11 14:48:42 <KipIngram   > Makes me want to do a Forth chess engine.
2023-10-11 14:48:50 <thrig       > real innovation is when a bot starts kicking the opponent under the table
2023-10-11 14:51:24 <GeDaMo      > There's a ##chessprogramming channel
2023-10-11 14:52:06 <KipIngram   > crc: Yes, I'm a lot more likely to do "block comments" as opposed to mingled one-line comments.
2023-10-11 14:52:25 <KipIngram   > I still don't exactly love it, but it reduces the "dissonance" it creates for me.
2023-10-11 14:53:06 <KipIngram   > Ultimately I want my dev system to let me store the comments completely somewhere else - sort of like shadow screens but more fine-grained than that.
2023-10-11 14:53:31 <KipIngram   > If I move the cursor into a region that has a comment attached to it, I want that to just open a separate window on the screen that shows the commentary.
2023-10-11 14:53:46 <KipIngram   > And i see no reason that can't be a hierarchical thing, kind of like a wiki.
2023-10-11 14:54:29 <KipIngram   > b*tree looks like it could handle that job at scale.
2023-10-11 14:54:40 <KipIngram   > Or a pair of b*trees, if I want bi-directionality.
2023-10-11 14:56:16 <KipIngram   > I figure the first layer would hold what we'd think of as "source comments" and level by level it would move toward "general documentation."
2023-10-11 16:55:33 <veltas      > I'm ashamed to admit I've only seriously thought about alloca() recently and I quite like it
2023-10-11 16:56:12 <veltas      > Shame there's no obvious way of doing the same in Forth, as far as I know
2023-10-11 17:26:09 <KipIngram   > What's that do?
2023-10-11 17:27:23 <KipIngram   > I looked it up.
2023-10-11 17:27:54 <thrig       > allocates temporary storage on the stack (some consider it hilariously unsafe, especially for large allocations)
2023-10-11 17:28:12 <KipIngram   > I've thought some about that sort of thing.  I already have my frame pointer, and non-negative offsets from the frame pointer are used to access stack items in a consistent, unchanging way during the duration of the frame.
2023-10-11 17:28:50 <KipIngram   > It's occurred to me that negative offsets from the frame pointer could be used to access something akin to "local variables".  All I'd need to do would be to pull the stack pointer down by the size of the locals space, and then it would all just work.
2023-10-11 17:29:00 <KipIngram   > Closing the frame would get rid of all of that temporary space as usual.
2023-10-11 17:29:15 <KipIngram   > I haven't tried it out, but I see no reason it shouldn't work just fine.
2023-10-11 17:29:53 <KipIngram   > Meanwhile, you could continue to use the stack, which would just use the stack pointer that you hauled down out of the way.
2023-10-11 17:30:38 <KipIngram   > A long exception return like I use in FIND would also clean all of that up as well, just like it cleans other stuff up.
2023-10-11 17:31:07 <KipIngram   > Thing is, though, I never really feel much inclination toward using anything akin to local variables.
2023-10-11 17:31:52 <KipIngram   > I'm pretty comfortable working with the stack, and I only even use the frame pointer in the upward direction when I'm dealing with a word that just has an excessive number of frequently accessed things on the stack.
2023-10-11 17:32:26 <KipIngram   > The main place I use it in my current system is in EXPECT - when it's called from QUERY and I have command history involved, things get... busy.
2023-10-11 17:47:37 <thrig       > e.g. one systemd whoopsiedoodle is https://nvd.nist.gov/vuln/detail/CVE-2021-33910
2023-10-11 18:27:04 <KipIngram   > Sometimes I just feel like we've screwed up our software ecosystem so badly.
2023-10-11 18:27:37 <KipIngram   > I can't beat the feeling that it's at least partially associated with focusing processor advancement on "legacy C code performance."
2023-10-11 18:28:00 <KipIngram   > I feel like we should have advanced along a path more like the GA144.
2023-10-11 18:28:26 <KipIngram   > Instead of investing so much in making one core go fast, just swallow the multi-core pill right from the start and invest the progress in ever more cores.
2023-10-11 18:28:32 <KipIngram   > Figure out how to program them.
2023-10-11 18:28:54 <KipIngram   > but each core would be so simple that you could actually keep up with what was going on in it, completely.
2023-10-11 18:28:57 <thrig       > but that would take money and investment!
2023-10-11 18:29:19 <KipIngram   > It certainly wasn't the highest short term payoff path.
2023-10-11 18:29:27 <KipIngram   > But I think it would have been the highest long-term one.
2023-10-11 18:29:54 <KipIngram   > We'd probably all be running computers with thousands or tens of thousands of cores now.
2023-10-11 18:30:54 <KipIngram   > That's one facet of the problem, and the other is "too much library focus."
2023-10-11 18:31:11 <KipIngram   > Young prorammers want to just be able to snap together tinkertoys and have an application.
2023-10-11 18:31:40 <KipIngram   > Without investing the learning time in understanding exactly what they're doing.
2023-10-11 18:32:05 <KipIngram   > Both of those problems lead to "too many moving parts that aren't understood."
2023-10-11 21:31:40 <KipIngram   > So, how hard would it be to make just a stack of GPU units, that you connected to via network so that you could offload number crunching work to it from you usual computer?  Is it necessary for each GPU card to have a PCI connection to a host, or can they free-stand on a network like that?
2023-10-11 21:32:24 <KipIngram   > I've seen pictures online that "look like" just a stack of GPUs, but I haven't dug down to the details yet.
2023-10-11 23:51:57 <KipIngram   > Hey - I finally found a Python program that actually interacts with my notebook's GPU via pyOpenCL.  When I first started trying that my then-current version of Fedora just didn't support the necessary features.
2023-10-11 23:52:08 <KipIngram   > Now I'm up to Fedora 36 and it seems the world is a happier place.
2023-10-11 23:52:22 <KipIngram   > Files are here:
2023-10-11 23:52:24 <KipIngram   > https://github.com/PyOCL/pyopencl-examples/tree/master/1-1
2023-10-11 23:53:08 <KipIngram   > I have Intel graphics, but that's apparently supported.
2023-10-11 23:55:15 <KipIngram   > It uses a GPU kernel program that's written in C.