2024-05-10 04:36:09 <KipIngram   > Ah - this is a breath of fresh air:
2024-05-10 04:36:11 <KipIngram   > https://www.youtube.com/watch?v=dDUC-LqVrPU
2024-05-10 04:36:25 <KipIngram   > Finally someone talking about "maybe there's NOT going to be a singularity in AI."
2024-05-10 04:36:33 <KipIngram   > I find that MUCH more likely than "there will be."
2024-05-10 04:36:57 <KipIngram   > The argument in the paper he discusses is that diminishin returns set in.
2024-05-10 04:36:58 <thrig       > wikipedia had a section on "critics of singularity" last I looked a while back
2024-05-10 04:37:28 <KipIngram   > Honestly I think the whole idea violates the TANSTAAFL principle.
2024-05-10 04:37:57 <KipIngram   > When does ANYTHING become exponentially better without us having to continue to invest our energies in it?
2024-05-10 04:38:10 <thrig       > uh, "the market". next question.
2024-05-10 04:38:38 <KipIngram   > I think most of that can be associated with the industrial revolution and the master of electromagnetism.
2024-05-10 04:38:44 <KipIngram   > We get to do those things ONCE.
2024-05-10 04:38:59 <KipIngram   > Steam engine, chemistry, electromagnetics.
2024-05-10 04:39:44 <KipIngram   > Gravity is too weak, and the strong and weak nuclear forces are too short range.  So we've already exploited the one that's really useful.
2024-05-10 04:40:00 <thrig       > nuclear, though those trend towards white elephant for various reasons
2024-05-10 04:40:13 <KipIngram   > I think we probably have a boon left in genetics.
2024-05-10 04:40:18 <KipIngram   > I'm not sure if there is anything after that.
2024-05-10 04:40:51 <KipIngram   > Yeah, I do think nucelar can help us out on the energy front.
2024-05-10 04:41:05 <KipIngram   > If the public can ever wake up and realize there's no dodging it long term.
2024-05-10 04:41:56 <KipIngram   > But that's kind of a limited exploitation - we'll get energy from it.  But we won't find the myriad ways to use it that we did with electromagnetism.
2024-05-10 04:42:25 <KipIngram   > Genetics, on the other hand, has a whole lot of upside potential.
2024-05-10 04:43:26 <KipIngram   > Well, and downside potential too.
2024-05-10 04:43:28 <KipIngram   > :-|
2024-05-10 04:44:28 <KipIngram   > Anyway, I haven't looked at the paper itself yet.
2024-05-10 04:44:43 <KipIngram   > I've generally found the guy talking there to seem competent, though.
2024-05-10 12:41:52 <rendar      > do you think Forth is hard to debug? i mean, reading very long :  ..  ; can be misleading, because you can't keep the stack in mind for so long?
2024-05-10 12:43:15 <veltas      > There's more overhead debugging IMO but not prohibitively so
2024-05-10 12:43:33 <veltas      > You're encouraged by nature of language to test more and smaller functions as-you-go
2024-05-10 12:43:48 <veltas      > It's not any harder to debug than anyone might imagine
2024-05-10 12:43:56 <KipIngram   > Well, the main way I've debugged is by moving some kind of "visible effect word" (like a debug print, but when first bringing a system up it might just be an "exit") through my code until I locate where my problem occurs.  I think Forth has the potential to support a very good debugging environment, but I've not written one yet.
2024-05-10 12:44:28 <KipIngram   > ^ +1 on being encouraged to factor and test in smaller increments.
2024-05-10 12:44:32 <veltas      > You've got more tools at your disposal for debugging than most languages give you out the box
2024-05-10 12:45:11 <veltas      > Stuff like ' DUMP and .S are quite standard
2024-05-10 12:45:19 <GeDaMo      > There's a rule-of-thumb which says to try and keep definitions to between 7 and 10 words
2024-05-10 12:45:42 <veltas      > Everyone's got their own rules for that
2024-05-10 12:45:48 <KipIngram   > That rule of thumb seems to get violated quite a lot.
2024-05-10 12:46:20 <KipIngram   > I've seen it tied to the number of items we can hold in our short term memory effectively.
2024-05-10 12:46:40 <GeDaMo      > Yeah
2024-05-10 12:48:37 <KipIngram   > What I want eventually is a fairly standard debugger that will let me set breakpoints, single step, monitor RAM, the stack, the call situation, etc.
2024-05-10 12:49:53 <KipIngram   > What would be extra nice would be if my code could run in one window and the debugger in a separate one.
2024-05-10 12:50:30 <GeDaMo      > God's eye view :P
2024-05-10 12:50:57 <veltas      > One advantage of non-STC forths is you can swap out NEXT code for step debugging
2024-05-10 12:51:00 <KipIngram   > Exactly.
2024-05-10 12:51:15 <veltas      > STC forths you can use arch's debugging features
2024-05-10 12:51:18 <KipIngram   > To both of those comments.
2024-05-10 12:53:36 <GeDaMo      > I quite like this idea from https://en.wikipedia.org/wiki/Pilot_(operating_system)
2024-05-10 12:53:36 <GeDaMo      > "A typical Pilot workstation ran 3 operating systems at once on 3  different disk volumes : Co-Co-Pilot (a backup debugger in case the main  operating system crashed), Co-Pilot (the main operating system, running  under co-pilot and used to compile and bind programs) and an inferior  copy of Pilot running in a third disk volume, that could be booted to  run test programs (that might crash the main development environment)."
2024-05-10 13:44:19 <veltas      > I think the situation in e.g. Linux is good enough
2024-05-10 13:45:22 <veltas      > Where you catch/report what's catchable and write to a log before resetting, can run with a debugger attached if you want but most people don't
2024-05-10 13:45:43 <veltas      > This is possible because of a solid CPU architecture, older archs the Pilot situation might have been necessary(?)
2024-05-10 13:46:57 <GeDaMo      > I don't think Pilot used hardware protection
2024-05-10 13:47:29 <GeDaMo      > It was written in Mesa and was a single language system
2024-05-10 13:55:46 <veltas      > That's the sort of thing I was expecting
2024-05-10 13:57:02 <GeDaMo      > Yeah, all the process separation was done in software
2024-05-10 16:07:20 <crc         > re: forth debugging; I don't find it particularly difficult
2024-05-10 16:07:38 <crc         > factoring definitions helps with keeping things readable, and it gets easier to keep track of the stack with experience
2024-05-10 16:07:53 <crc         > (and use of additional stack comments in the definition can help if the stack permutations get tricky to follow)
2024-05-10 16:08:11 <crc         > depending on the forth, you can have some reasonable debugging tools
2024-05-10 16:09:22 <crc         > e.g., I have things for execution & stack tracing, disassembly / decompilation, watching variables, and single stepping
2024-05-10 16:50:30 <lf94        > I find once you become more familiar with stack movements, your brain easily holds onto at least 6 stack items.
2024-05-10 16:50:47 <lf94        > Which, is like 99% of cases is more than you'll typically mess with
2024-05-10 16:50:54 <lf94        > is/in
2024-05-10 16:51:12 <lf94        > I find myself using `hex .s bye` very often
2024-05-10 16:52:13 <lf94        > It'd be ULTRA cool if there were a forth that can backstep.
2024-05-10 16:52:34 <lf94        > Sure, it'll be less efficient. But developer time would go down.
2024-05-10 17:00:54 <zelgomer    > you have the power
2024-05-10 17:02:23 <GeDaMo      > "Win - You've Got The Power" https://www.youtube.com/watch?v=hl4gPjyrnfI
2024-05-10 17:12:21 <veltas      > "your brain easily holds onto at least 6 stack items"  not mine lol
2024-05-10 17:14:11 <zelgomer    > this is your brain. this is your brain easily holding onto at least 6 stack items.
2024-05-10 17:22:04 <GeDaMo      > Most stack words operate on the top three items (or top three doubles)
2024-05-10 17:57:47 <KipIngram   > Wow - you're doing well to think of six items as "easy."
2024-05-10 17:58:14 <KipIngram   > I've had to deal with that many stack items (once I added command history to QUERY), but it wasn't particularly FUN.
2024-05-10 17:58:32 <KipIngram   > And standard Forth doesn't make it terribly easy, either.
2024-05-10 17:58:44 <KipIngram   > I added a new mechanism for coping with that.
2024-05-10 17:59:08 <KipIngram   > A very frowned upon one that lets me index into the stack.
2024-05-10 18:00:19 <KipIngram   > I first thought I'd index off of the stack pointer, but it changes every time you do something, which makes your items slide around in offset space.  So I added a new "frame pointer" register for that purpose.
2024-05-10 18:00:39 <KipIngram   > It also can be used to allow one task to access data in another task's stack.
2024-05-10 18:00:53 <KipIngram   > Though that can bring up cache thrashing issues.
2024-05-10 18:01:07 <KipIngram   > So it's not something to over-use.
2024-05-10 18:01:37 <KipIngram   > But it's easy to have a child task get its own stack pointer but inherit its parents frame pointer.
2024-05-10 18:02:24 <KipIngram   > I think MOST stack words operate on the top one or two items, but yes, there are some standard words that work on three.
2024-05-10 18:38:10 <crc         > 
ACTION thinks of 10.6.2.2292 TIME&DATE, which returns six values

2024-05-10 19:49:03 <KipIngram   > Oh, that's fun.  Ok - no traditional Forths I'm familiar with.  I'm really not up on the standard.
2024-05-10 20:07:38 <veltas      > I think the thing about TIME&DATE is you probably don't leave it as six values the whole time usually
2024-05-10 20:07:49 <veltas      > It's more about being very 'generic'
2024-05-10 20:08:02 <veltas      > Although you can
2024-05-10 21:06:57 <lf94        > Yes, you need to see things as basically in groups of 3
2024-05-10 21:07:01 <lf94        > to think farther
2024-05-10 21:07:04 <lf94        > in stack world
2024-05-10 22:37:55 <veltas      > Profound words
2024-05-10 22:43:22 <lf94        > i realize also rot / -rot is generally bad. it's worse than using >r >r if you can
2024-05-10 22:43:39 <lf94        > unless you can subsidize the cost of rot with the underlying hardware of course
2024-05-10 22:44:28 <lf94        > my own experiences is leading me to stick to swap, drop, dup, over, r> and >r. anything more seems to always lead to worse code, worse thinking, etc
2024-05-10 22:45:32 <lf94        > and everything more complex seems to be a variant of these
2024-05-10 22:45:37 <lf94        > 2dup, 2swap, etc
2024-05-10 22:51:37 <GeDaMo      > No love for nip and tuck? :P
2024-05-10 23:02:34 <zelgomer    > lf94> i realize also rot / -rot is generally bad. it's worse than using >r >r if you can
2024-05-10 23:02:37 <zelgomer    > why is that?
2024-05-10 23:03:34 <lf94        > zelgomer: rot and -rot end up using >r and r> internally usually
2024-05-10 23:03:42 <lf94        > usually, less efficiently if you end up using >r and r> directly
2024-05-10 23:03:50 <zelgomer    > "usually" ??
2024-05-10 23:03:59 <lf94        > in the forths ive seen, yea
2024-05-10 23:04:05 <zelgomer    > i usually implement rot as a code word and -rot is "rot rot"
2024-05-10 23:04:12 <lf94        > > lf94 │ unless you can subsidize the cost of rot with the underlying hardware of course
2024-05-10 23:04:14 <lf94        > :)
2024-05-10 23:04:45 <lf94        > if your hardware has a "rot" instruction that has forth rot semantics... go for it
2024-05-10 23:04:59 <zelgomer    > what
2024-05-10 23:05:11 <lf94        > ?
2024-05-10 23:05:23 <zelgomer    > why do you require a rot instruction?
2024-05-10 23:05:29 <lf94        > *i* dont
2024-05-10 23:05:59 <lf94        > generally, i extremely rarely need rot (so far, I havent needed it.)
2024-05-10 23:06:14 <lf94        > (I have typed it a few times, but always end up removing it)
2024-05-10 23:06:19 <zelgomer    > nor do i. i implement it as a code word without an instruction in the isa
2024-05-10 23:08:25 <lf94        > is the code more efficient than >r swap r> ?
2024-05-10 23:08:35 <lf94        > er
2024-05-10 23:08:39 <lf94        > >r swap actually
2024-05-10 23:08:48 <zelgomer    > of course. it's one word instead of four.
2024-05-10 23:09:36 <lf94        > i think it'd really depend on the forth, instead of "of course"
2024-05-10 23:10:01 <zelgomer    > how do you figure that?
2024-05-10 23:11:04 <zelgomer    > how do you possibly imagine a forth in which a word implemented as an assembly primitive is less efficient than implementing it has a high level word composed of four other primitives?
2024-05-10 23:13:24 <lf94        > 2 other primitives if your goal is to get at the 3rd stack item
2024-05-10 23:13:28 <lf94        > but lets say four
2024-05-10 23:13:37 <lf94        > there are optimizing forths man.
2024-05-10 23:13:55 <lf94        > also: those 4 words may be extremely efficiently written versus the rot
2024-05-10 23:14:04 <lf94        > like, holy man, there are a few ways you can imagine this !
2024-05-10 23:14:10 <lf94        > not very imaginative I guess?
2024-05-10 23:14:46 <zelgomer    > lf94> there are optimizing forths man.  -- and you think they wouldn't implement rot as an optimizing primitive?
2024-05-10 23:14:56 <zelgomer    > lf94> also: those 4 words may be extremely efficiently written versus the rot
2024-05-10 23:15:02 <zelgomer    > i think you don't understand what a code word is
2024-05-10 23:16:12 <lf94        > and you think they wouldn't implement rot as an optimizing primitive?  <- no im saying that's a case where they could be equal. but objectively, >r swap is more efficient than rot at accessing the 3rd stack item.
2024-05-10 23:17:07 <zelgomer    > this is simply not true, both because it assumes the implementation of rot is a high level word and because it assumes my goal is only to "access the third item" and not to rearrange order
2024-05-10 23:17:52 <zelgomer    > i don't understand why you argue instead of choosing to learn
2024-05-10 23:18:17 <lf94        > arguing is learning
2024-05-10 23:18:30 <lf94        > i know why im arguing, because you wanted to :)
2024-05-10 23:20:07 <zelgomer    > i saw demonstrably false statements being made. just trying to help.
2024-05-10 23:22:24 <lf94        > from our little argument, it seems there's truth in what we both said
2024-05-10 23:22:48 <lf94        > a code word is a word written in assembly, isnt it?
2024-05-10 23:24:09 <zelgomer    > yes. >r, r>, and swap are usually code words.
2024-05-10 23:28:29 <lf94        > but rot ? it seems it's hit or miss
2024-05-10 23:28:40 <lf94        > that's just based on my minimal exposure to 2 forth systems
2024-05-10 23:29:15 <zelgomer    > LOL
2024-05-10 23:32:02 <lf94        > I know I know :) But it's also based on reading standard-forth.org or whatever's comment in ROT
2024-05-10 23:32:16 <lf94        > Where the "minimal implementation" uses >r r> swap
2024-05-10 23:32:35 <lf94        > So like, how many /other/ people are using this
2024-05-10 23:35:11 <MrMobius    > what did you find in your "minimal exposure" for rot?
2024-05-10 23:35:26 <lf94        > I mentioned it already :p
2024-05-10 23:35:42 <lf94        > rot: usually better to use r> swap and >r as needed.
2024-05-10 23:35:49 <lf94        > that's been my experience
2024-05-10 23:37:27 <MrMobius    > you saying it's better doesn't answer my question. is that what the z80 forth you were talking about before uses?
2024-05-10 23:39:09 <MrMobius    > the minimal implementation doesn't necessarily mean the best implementation btw