2023-02-03 02:27:53 <KipIngram   > Wow.  If I take the 64-bit table entries, pre-corrected for base address, then I can get next, docol, and slick timer tick functionality all into just nine instructions.
2023-02-03 02:28:03 <KipIngram   > It would look like this:
2023-02-03 02:28:29 <KipIngram   > ick:   mov     rrTICK, TICKS
2023-02-03 02:28:31 <KipIngram   >         mov     rrW, tickxt
2023-02-03 02:28:33 <KipIngram   > nest:   add     rrRP, 8
2023-02-03 02:28:35 <KipIngram   >         mov     [rrRP], rrIP
2023-02-03 02:28:37 <KipIngram   >         mov     rrIP, [rrPFA+8*rrW]
2023-02-03 02:28:39 <KipIngram   >         dec     rrTICK
2023-02-03 02:28:41 <KipIngram   >         jz      tick
2023-02-03 02:28:43 <KipIngram   > next:   lodsw
2023-02-03 02:28:45 <KipIngram   >         jmp     [rrCFA+8*rrW]
2023-02-03 02:28:47 <KipIngram   > Ooops.
2023-02-03 02:28:49 <KipIngram   > First line label was supposed to be "tick" - I missed copyng the t.
2023-02-03 02:29:09 <KipIngram   > This ticks on each entry to a colon def instead of each next.
2023-02-03 02:30:26 <KipIngram   > It does the counter expiration handling when it's already pushed the old IP and gotten the new IP loaded.  So it just reloads the tick counter and loads a "reserved xt" into the W register, and falls into the nest operation again.
2023-02-03 02:30:54 <KipIngram   > I figure that tickxt would be initialized to a noop colon definition at startup - you could re-vector that guy to anything you wanted after you got started.
2023-02-03 02:32:31 <KipIngram   > That next is just five bytes - short enough that I'm considering just appending it to the end of each primitive rather than doing a register jump to it.  The register jump is just two bytes, though, so that would cost three extra bytes per primitive.
2023-02-03 02:32:52 <KipIngram   > But that would only be a few hundred bytes.
2023-02-03 02:33:31 <KipIngram   > And it frees a register that would otherwise just have to sit there pointing at NEXT all the time.
2023-02-03 05:23:42 <veltas      > KipIngram: Also info about "machine forth" would be nice, I've seen Chuck write a bit about that before, nice to know more about what that would actually look like
2023-02-03 05:24:37 <veltas      > Compile speeds do matter IMO
2023-02-03 07:36:25 <veltas      > > modern applications are much more about "moving data around" than they are about computations
2023-02-03 07:36:46 <veltas      > This impacts C-style languages as well, which have syntax tuned for computation and not moving stuff around / business logic
2023-02-03 07:36:52 <veltas      > Makes me wonder how things like COBOL compare
2023-02-03 07:38:44 <veltas      > What is kind of funky about vim is you can lose your undo history by jumping to definitions
2023-02-03 07:38:59 <veltas      > And also you need to save your buffer and essentially leave it by jumping
2023-02-03 07:47:11 <KipIngram   > Ok, I misspoke.  I didn't mean it doesn't matter AT ALL.
2023-02-03 07:47:23 <KipIngram   > Just that I don't think there's lot to worry about there.
2023-02-03 07:47:41 <KipIngram   > Gien the speed of modern processors.  Obviously, if compiles were SLOW it wouldn't be good.
2023-02-03 07:49:30 <KipIngram   > I just think it's unlikely a modern machine will give you a worrisomely slow compile time
2023-02-03 07:51:52 <KipIngram   > And yes - Chucks writings often talk about some aspects of a piece of his work but still leave it "opaque."
2023-02-03 07:52:10 <KipIngram   > It took me ages to find any real details on his CAD setup.
2023-02-03 07:54:00 <KipIngram   > when I finally did, and drilled into his claim that his fixed point transistor models give "better results than the SPICE type models," I decided that my opinion was that probaby managed that by virtue of working at a fairly coarse process scale.
2023-02-03 07:54:39 <KipIngram   > That probably makes a rougher transistor model wok better, and in fact having the wrong defaults for all the subtle nuances of a spice model might indeed throw you off.
2023-02-03 07:55:04 <KipIngram   > I can't say for sure but I'd e surprised if his approach still worked well at cutting edge scales.
2023-02-03 07:55:08 <Zarutian_iPad> SPICE simulators in my experience are too often crap
2023-02-03 07:56:09 <KipIngram   > Well, I suspect there's crap in all arenas.  But those models try to do an awful lot, and that can translate into "an awful lot to get right."
2023-02-03 07:56:16 <Zarutian_iPad> if you use the original Scheme one with a proper numerical tower you get okay result even with default models
2023-02-03 07:56:54 <Zarutian_iPad> but if you use LTSPICE like in MultiSim 11 you too often get nonsense
2023-02-03 07:58:36 <KipIngram   > That just sounds like a general software quality thing to me.
2023-02-03 07:58:36 <Zarutian_iPad> I traced down an impossible voltage in rather simple circuit I ran, to signed short underflow
2023-02-03 07:58:40 <KipIngram   > Crap in, crap out.
2023-02-03 07:59:01 <KipIngram   > Also it's worth noting that Chuck was only trying to model the digital behavior of the transistors.
2023-02-03 07:59:23 <KipIngram   > He wasn't trying to predice musical reproduction fidelity in a fancy amplifier or anything like that.
2023-02-03 07:59:37 <Zarutian_iPad> so I decided to trace the linage of that particular SPICE simulator
2023-02-03 08:00:27 <Zarutian_iPad> nor was I. This was a circuit that used a power mosfet to turn on a lightbulb
2023-02-03 08:03:08 <Zarutian_iPad> so turns out LTSPICE was a fork of some univeristy students C implementation of SPICE because the proper Scheme one didnt fit on his dinky 386
2023-02-03 08:03:12 <KipIngram   > My point is merely that not every parameter is necessarily going to be relevant and every process scale.
2023-02-03 08:06:47 <Zarutian_iPad> that Chuck got the Design Rule Set from the chip foundry and made his own CAD is just how he rolls
2023-02-03 08:08:40 <KipIngram   > Oh, I'm wildly impressed with it.
2023-02-03 08:09:17 <KipIngram   > And it really is just "how he rolls" to look at how to get the answers he needs and nothing further.
2023-02-03 08:09:38 <KipIngram   > He made chips that worked - the proof was in the pudding.
2023-02-03 08:10:09 <KipIngram   > All of those chips were impressive, but the GA144 is a fairly stunning accomplishment.
2023-02-03 08:27:43 <veltas      > In Pursuit of Szechuan
2023-02-03 09:25:01 <KipIngram   > So, getting this really small amount of code in next, docol, etc. arises from allowing the table entries to be eight bytes.  But there are so many ways to do this, potentially.  If I wanted the most compact system I could get, I could accept a couple more instructions in next, and recognize that in almost any Forth system all of the machine code you'll ever right would fit in 64kB, and the CFA table entries
2023-02-03 09:25:03 <KipIngram   > could be two bytes each.  The PFA table is the one that really needs the full address space span, but those could still be reduced to four bytes.
2023-02-03 09:25:24 <KipIngram   > And if we jump to the next code via  register, then our per-word next can be just two bytes.
2023-02-03 09:25:47 <KipIngram   > I am curious as to how small I could make the thing if I tried.
2023-02-03 09:26:16 <KipIngram   > But I'm also very pleased with that nine-line coverage of all of that critical code.  So... tradeoffs.
2023-02-03 09:26:41 <Stalevar    >   https://images.computerhistory.org/timeline/timeline_computers_1960.neac2203.jpg an early Japanese computer based on transistors
2023-02-03 09:27:26 <KipIngram   > Ah, nice.  :-)
2023-02-03 09:27:36 <KipIngram   > I think those would have been exciting days to work in.
2023-02-03 09:28:34 <Stalevar    > https://images.computerhistory.org/timeline/timeline_computers_1962.linc.jpg Linc. One of first computers meant to be used by a single person
2023-02-03 09:32:20 <KipIngram   > Anyway, I want to write this so that how I do those bits I just alluded to is flexible.  I'd like to be able to compile it either way.
2023-02-03 09:34:46 <Stalevar    > https://images.computerhistory.org/timeline/Scamp.png that's the first microcomputer made by IBM, it could run APL
2023-02-03 09:35:32 <KipIngram   > Wow, look at the size of that monitor!!!
2023-02-03 09:36:01 <thrig       > one person?! https://www.youtube.com/watch?v=6v4Juzn10gM
2023-02-03 09:38:35 <KipIngram   > I think I may only need to save eight of the registers on context switches.  Several of them are just "fast access" pointers that remain fixed across threads.
2023-02-03 09:43:34 <KipIngram   > That probably means that 32-deep stacks will be adequate for all threads.  So 512 byte thread blocks.
2023-02-03 09:43:55 <KipIngram   > Some will need some ram for that "environment" I mentioned, but simple ones wouldn't.
2023-02-03 09:48:29 <KipIngram   > I do intend to include the "simple memory manager" in this design - I'll need it for threads to make themselves an environment if they need it.
2023-02-03 09:49:04 <KipIngram   > New thread will start out without one, but certain things it does will detect that and add one - it'll crawl up the thread parent chain and inherit the initial values from an ancestor.
2023-02-03 09:50:18 <KipIngram   > In my last system I used that memory manager to get a place to put transient name information for .: / .wipe.  But it occurred to me last night that there's a simple way to do that without dynamic RAM.  I'll have some existing block of RAM where names are going, and it will normally grow from the bottom up.
2023-02-03 09:50:28 <KipIngram   > But I could put .: names at the top of that block, growing down.
2023-02-03 09:50:37 <KipIngram   > Then they'll be easy to get rid of via .wipe.
2023-02-03 09:51:31 <KipIngram   > However, I won't be able to recover the header table entries.  Those words will still consume xt's, and that means they have to consume space in all three tables.
2023-02-03 10:04:32 <KipIngram   > Actually I should probably do that in a way that doesn't require that table.  I tend to use a lot of transient words.  And anything involving the headers isn't as speed critical.
2023-02-03 10:19:27 <veltas      > "FIG UK hosts IRC sessions on the first Saturday of the month. on channel #forth using the IRC server irc.eu.freenode.net. Sessions start at 9:00pm UK time and are open to everyone."
2023-02-03 10:19:45 <veltas      > So tomorrow I think we're meant to have a British IRC meeting
2023-02-03 10:20:03 <veltas      > 9pm is quite late though, near my bedtime
2023-02-03 10:20:45 <KipIngram   > Oh cool.  That may be worth dropping in on.  It'll be afternoon for me.
2023-02-03 10:20:56 <KipIngram   > I'll try to remember to drop in.
2023-02-03 10:22:33 <veltas      > KipIngram: That's from some archive of the fig UK website from like 10+ years ago, so don't get your hopes up :P
2023-02-03 10:22:56 <veltas      > But I think we should make sure to mark the occasion on first saturdays if we remember
2023-02-03 10:23:36 <KipIngram   > Ah.  Ok.
2023-02-03 10:23:56 <KipIngram   > So that predated the whole freenode / Libera conflagration.
2023-02-03 10:24:13 <veltas      > Yes
2023-02-03 10:26:38 <veltas      > And that's the Democratic People's Republic of Freenodia to you
2023-02-03 10:27:00 <KipIngram   > Hah hah hah!
2023-02-03 10:27:06 <KipIngram   > That whole thing was quite the business.
2023-02-03 10:27:43 <thrig       > much the same is playing out on Twitter
2023-02-03 10:27:51 <KipIngram   > You know, Chuck's really something.  He has gone to these very shallow stacks, like four or eight deep.  A Jeff Fox writing I saw last night commented on how that changes the way you code.
2023-02-03 10:27:54 <KipIngram   > Ok, fair enough.
2023-02-03 10:28:13 <KipIngram   > But at the same time I also saw Fox say that an analysis of Chuck's code showed that he averages 44 characters per definition.
2023-02-03 10:28:35 <KipIngram   > Short defs means lots of factoring, and that implies  more calls.
2023-02-03 10:28:47 <KipIngram   > So how he managed BOTH of those things... that's pretty impressive.
2023-02-03 10:29:03 <KipIngram   > I checked my system to see how deep my stacks get.  Not really any application code, but the system itself.
2023-02-03 10:29:09 <KipIngram   > I ran around 17-18 on both stacks.
2023-02-03 10:29:19 <KipIngram   > And my defs are generally around 40-50 chars.
2023-02-03 10:29:36 <KipIngram   > That's how I decided 32-deep stacks should suffice.
2023-02-03 10:30:02 <KipIngram   > That's 17 or 18 for both stacks, and has more than enough room left to save eight registers on context switches - with several entries to spare.
2023-02-03 10:31:14 <KipIngram   > I actually wanted to try out the circular stack approach, just for the memory protection it offers.  But I won't have just stacks in my stack zone; there will be a few user varaibles too.  And once you take up any of the space with something other than stack data, your stack isn't REALLY in a power of two block anymore, and the simple modulo way of circularizing the stacks doesn't work anymore.
2023-02-03 10:31:25 <KipIngram   > So I don't quite see a good way to do circular stacks in software.
2023-02-03 10:31:34 <KipIngram   > It's easy in hardware, though.
2023-02-03 10:31:52 <veltas      > 4-8 deep stacks... so basically you just use stacks for arithmetic and to stage addresses and stuff, and put most of your state in variables or roll into code context
2023-02-03 10:31:53 <KipIngram   > Essentially free.
2023-02-03 10:32:03 <KipIngram   > Yeah, I guess so.
2023-02-03 10:32:04 <veltas      > Which is how us plebs have been writing forth since starting forth :P
2023-02-03 10:32:09 <KipIngram   > :-)
2023-02-03 10:32:25 <veltas      > Elizabeth would rather you don't
2023-02-03 10:32:30 <KipIngram   > I don't use many variables.  When I do keep stuff in RAM, it's usually related to a structure of some kind.
2023-02-03 10:32:36 <KipIngram   > A linked list, or a tree or something.
2023-02-03 10:34:12 <KipIngram   > I don't know a great deal about her.  I know who she is, of course, and the very limited stuff I've seen from her seems sensible enough.
2023-02-03 10:34:20 <KipIngram   > But, it's only a small exposure.
2023-02-03 10:34:42 <KipIngram   > I tried to find out where she was from one day - I saw a video with her in it and definitely felt like she had a Southern US sound to her voice.
2023-02-03 10:35:01 <KipIngram   > But I wasn't able to turn that kind of info up.
2023-02-03 10:36:01 <KipIngram   > These user variables are going to be a bit inefficient.  They live in the stack block.  I have the stack POINTERS, of course, but I don't have anything else designating a fixed address in that region.
2023-02-03 10:36:22 <KipIngram   > So I'll have to take a stack pointer and mask it to get the region's base, then offset from that to get a user var address.
2023-02-03 10:36:46 <KipIngram   > Those blocks will all be 512-byte aligned.
2023-02-03 10:38:02 <KipIngram   > Right now I'm picturing just one cell of user var info in that block - a 32-bit parent thread designator and a 32-bit pointer to the thread's environment.
2023-02-03 10:38:11 <KipIngram   > The actual vars will be in that environment block.
2023-02-03 10:38:27 <KipIngram   > Which will get allocated on the fly when it's needed.
2023-02-03 10:39:26 <KipIngram   > That extra step is purely to allow threads that don't need an environment to be maximally compact.
2023-02-03 10:40:22 <KipIngram   > I could push it down in size, because really simple threads wouldn't need as much stack space.  But then I'd have thread blocks of different sizes floating around, and that would complicate things.
2023-02-03 10:40:29 <veltas      > Personally I don't care what Chuck or Elizabeth or anyone wants, I will do what's easiest
2023-02-03 10:41:08 <KipIngram   > Well, me to.  I'm interested, though, just for general edification.
2023-02-03 10:41:16 <veltas      > But Chuck's approach of not actually using stack much apart from simple calculations and staging sounds easier, and it's not far off what I do for many applications
2023-02-03 10:41:16 <Zarutian_iPad> who is Elizabeth in this context?
2023-02-03 10:41:19 <KipIngram   > There's definitely stuff Chuck does that I don't intend to follow.
2023-02-03 10:41:25 <veltas      > Zarutian_iPad: Liz Rather
2023-02-03 10:41:25 <KipIngram   > Elizabeth Rather.
2023-02-03 10:41:30 <KipIngram   > Forth Inc.
2023-02-03 10:41:34 <Zarutian_iPad> right
2023-02-03 10:41:47 <veltas      > And pretty important to Forth, style, culture, etc
2023-02-03 10:41:54 <KipIngram   > Yeah.
2023-02-03 10:42:08 <KipIngram   > She pops up in a lot of the old forum content.
2023-02-03 10:42:11 <veltas      > Not that it's a sin for not knowing her or thinking of her, but she is probably the second most famous person in the sphere
2023-02-03 10:42:19 <Zarutian_iPad> indeed
2023-02-03 10:42:22 <veltas      > After Nixon
2023-02-03 10:42:30 <KipIngram   > lol...
2023-02-03 10:42:40 <Zarutian_iPad> no, just slow contrxt paging by me
2023-02-03 10:42:46 <Zarutian_iPad> context*
2023-02-03 10:42:59 <veltas      > Fair enough, I'm also a bit of a Pentium 4
2023-02-03 10:43:12 <KipIngram   > It was a forum post of hers where I saw the claim that using separate words for interpreting and compiling simplifies cross-compiling.
2023-02-03 10:43:29 <veltas      > That sounds correct
2023-02-03 10:43:36 <KipIngram   > Yeah, it seems reasonable to me.
2023-02-03 10:43:40 <veltas      > She would know, Forth Inc have made a lot of cross compilers
2023-02-03 10:44:05 <Zarutian_iPad> one local hacker that has gone through many of the Forth books said that it changed how he writes programs and solves certain problems
2023-02-03 10:44:08 <KipIngram   > cmForth does it that way, and I saw Chuck say somewhere that (at that time) he thought of it as one of the best Forths he'd created.
2023-02-03 10:44:24 <KipIngram   > I totally believe that, Zarutian_iPad.
2023-02-03 10:44:44 <KipIngram   > I saw one scienctific researcher guy say it had also changed how he designed lab work hardware too.
2023-02-03 10:45:03 <veltas      > It's changed me in good and bad ways
2023-02-03 10:45:03 <KipIngram   > His hardware had become more "modular" and more flexibly inter-connectablve.
2023-02-03 10:45:18 <Zarutian_iPad> the Starting Forth, Thinking Forth, Koopmans book are the ones I recommend
2023-02-03 10:45:27 <KipIngram   > Me too - I think it's reduced my patience level with verbose software.
2023-02-03 10:45:41 <KipIngram   > Seems to have lowered by "eye glaze over" threshold.
2023-02-03 10:45:46 <KipIngram   > s/by/my/
2023-02-03 10:45:57 <Zarutian_iPad> plus I also recommend Structure and Interpretation of Computer Programs
2023-02-03 10:46:50 <Zarutian_iPad> now, I am trying to find a good copy or book or articles on propagators
2023-02-03 10:48:24 <Zarutian_iPad> one thing that has always irritated me is that quite a lot of folks have and still confuse static typing with strong typing
2023-02-03 10:49:34 <Zarutian_iPad> static typing is just when the type check happens at compile time instead of runtime, pretty much
2023-02-03 10:50:51 <Zarutian_iPad> I am still looking for a decent compiler and language that emits runtime type check when it can not finish the static type check
2023-02-03 10:51:11 <Zarutian_iPad> heck with an infered type even
2023-02-03 10:51:57 <veltas      > TypeScript does that I assume
2023-02-03 10:52:11 <veltas      > JavaScript is the major programming language, let that sink in
2023-02-03 10:52:34 <Zarutian_iPad> something that one can pretty much get somewhat gratis with futamura transform of a interpreter into a compiler
2023-02-03 10:53:30 <Zarutian_iPad> well I have tryed TypeScript in online runtimes with certain test that should result in emitting the runtime checks but it just fails
2023-02-03 10:54:51 <Zarutian_iPad> but I quite like TypeScript extentsions of jsdoc comments
2023-02-03 10:55:51 <Zarutian_iPad> documents nicely and feeds the code completion and hover doctips well
2023-02-03 10:55:53 <veltas      > If I was a web dev I would probably just use JavaScript
2023-02-03 10:57:10 <Zarutian_iPad> when writing webstuff I do use javascript but add the aforesaid jsdoc comments when I can
2023-02-03 10:58:08 <Zarutian_iPad> I do not do seperate compile or bundling step
2023-02-03 10:59:32 <KipIngram   > That seems like an odd thing to get confused about (static vs. strong).
2023-02-03 11:00:21 <veltas      > Zarutian_iPad: Do you put type checking stuff into your code?
2023-02-03 11:01:21 <Zarutian_iPad> depends. Sometimes I put somesort of guards as in guards from E (see erights.org )
2023-02-03 11:03:37 <Zarutian_iPad> for instance I sketched out in a short note the idea of making MeasurementUnit guards that are basically the SI units
2023-02-03 11:04:08 <Zarutian_iPad> the building ontop of that certain equation invariants guards
2023-02-03 11:05:09 <Zarutian_iPad> a rather basic thing that most static type systems either choke on or can not express at all
2023-02-03 11:17:24 <KipIngram   > you're talking about confirming that some equation you wrote uses consistent units?
2023-02-03 11:18:27 <Zarutian_iPad> uses consistent units and the data fed into it is in those units
2023-02-03 11:22:14 <KipIngram   > That's an interesting idea.
2023-02-03 11:25:45 <veltas      > It's called dimensional analysis if I remember right
2023-02-03 11:26:25 <KipIngram   > Sure, though dimensional analysis goes a lot deeper than that.
2023-02-03 11:28:08 <KipIngram   > I linked a really good writup on that not long back.
2023-02-03 11:28:15 <Zarutian_iPad> just want to be sure that certain calculations are not fed wrong units
2023-02-03 11:29:01 <KipIngram   > Yeah, sure.
2023-02-03 11:29:03 <Zarutian_iPad> “Ya trying to stuff in a temperture into a length slot!” kind of thing
2023-02-03 11:30:22 <KipIngram   > https://web.mit.edu/2.25/www/pdf/DA_unified.pdf
2023-02-03 11:30:44 <KipIngram   > I think there are methods in there that basically aren't really taught anymore, at least not as a routine thing.
2023-02-03 11:31:32 <KipIngram   > At least it wasn't taught to me as a general topic.  Dimensional analysis was often mentioned, and was used here and there in the stuff we did cover, but not in a strongly formal way the way that doc presents it.
2023-02-03 11:31:51 <KipIngram   > Maybe my uni was just lame.
2023-02-03 11:32:57 <Stalevar    > mysterious lozenge sign
2023-02-03 11:33:16 <Stalevar    > common on old systems, and almost never seen nowadays ¤
2023-02-03 11:34:53 <thrig       > U+00A4 PLANET WEARING BONDAGE COLLAR
2023-02-03 11:38:08 <Stalevar    > IBM chain printers had this set of 48 chars in 50s: A..Z 0..9 $/¤*%@&-#.,
2023-02-03 11:40:07 <Stalevar    > So it was deemed more essential than + = < > ?  ! : ; ( )  " ' let alone [\]^_`{|}~
2023-02-03 11:42:43 <Zarutian_iPad> isnt that the Swedish letter used to indicate that a special letter could not been printed?
2023-02-03 11:44:04 <Stalevar    > Hm... I don't think it's swedish
2023-02-03 11:44:30 <Stalevar    > Mystery of lozenge
2023-02-03 11:44:45 <Stalevar    > Zarutian_iPad, it's said to be universal currency symbol or something
2023-02-03 11:44:52 <Zarutian_iPad> right!
2023-02-03 11:45:05 <Stalevar    > But why both $ and ¤?
2023-02-03 11:47:37 <rendar      > can we say that in forth there aren't any l-values and r-values?
2023-02-03 12:07:51 <KipIngram   > Well, you do have addresses and contents.
2023-02-03 12:08:08 <KipIngram   > But aside from that, that does seem reasonable to me.
2023-02-03 12:08:39 <KipIngram   > Isn't l-value about where to put the information and r-value about what the information *is*?
2023-02-03 12:08:47 <KipIngram   > I.e., the contents?
2023-02-03 12:50:17 <crc         > given that forth has variables, words, and such that can be addressed, I'd think those could qualify as l-values
2023-02-03 12:55:34 <rendar      > KipIngram, yep
2023-02-03 12:55:42 <rendar      > crc, i see
2023-02-03 12:55:56 <rendar      > in the very early version of Forth, we had only the stack, right?
2023-02-03 12:56:02 <rendar      > no variables or memory locations?
2023-02-03 12:56:58 <crc         > I'm not aware of any published Forth without variables or memory locations
2023-02-03 12:58:58 <crc         > https://mschuldt.github.io/www.colorforth.com/HOPL.html lists VARIABLE and ! as existing by 1961 in Chuck's early work
2023-02-03 13:07:13 <rendar      > i see :)
2023-02-03 13:44:08 <KipIngram   > One thing that didn't exist early on was colon definitions as we now know them.  I got the impression from that self-published book of his that what he did was more like text-based macro expansion.
2023-02-03 13:49:24 <KipIngram   > So you could do something like colon definitions, and maybe it even had similar syntax.  But it was really all "interpreted."
2023-02-03 13:49:32 <KipIngram   > "compiling" came later, I think.
2023-02-03 13:49:47 <KipIngram   > And to me that's what REALLY made it Forth.
2023-02-03 13:50:55 <dlowe       > KipIngram: you get my email?
2023-02-03 13:51:11 <KipIngram   > Yeah.  Haven't taken a good look yet.
2023-02-03 13:52:18 <KipIngram   > Hey - that looks pretty good.
2023-02-03 13:52:31 <KipIngram   > Opened it up in Calibre.
2023-02-03 13:52:41 <KipIngram   > I'll move it to my Kobo later.
2023-02-03 13:55:55 <dlowe       > I did it to spec and epub renderers are trash so who knows what it will look like
2023-02-03 13:56:49 <KipIngram   > I scrolled through it at least somewhat, and it looked pretty good in Calibre.
2023-02-03 13:57:06 <KipIngram   > Not absolutely like it looked before, but... plenty adequate.
2023-02-03 13:57:20 <KipIngram   > It had a bit more of a "web page" type of look.
2023-02-03 13:57:33 <KipIngram   > I.e., the fonts were somewhat changed.
2023-02-03 13:57:45 <KipIngram   > But that really isn't a big deal.
2023-02-03 14:34:06 <dlowe       > most ebook readers ignore the font settings
2023-02-03 14:35:35 <dlowe       > but there wasn't much likelihood of replicating every bit of the book in any case.  That's not really playing to ebook's strengths
2023-02-03 14:36:23 <KipIngram   > Yeah, totally understand.
2023-02-03 14:36:39 <KipIngram   > Being able to search it more than compensates for any "cosmetic" alteration.
2023-02-03 14:55:46 <dlowe       > The diagrams are also all remade, some corrections to the text.  The OCR was surprisingly terrible - I didn't expect it to be so bad.
2023-02-03 14:56:00 <dlowe       > I redid it with the latest tesseract and it was just as bad.
2023-02-03 15:21:33 <veltas      > rendar: Forth is not some kind of abstract or theoretical thing, it's meant to be a practical minimalist programming language
2023-02-03 15:22:10 <veltas      > It borrows features from languages like FORTRAN, ALGOL, COBOL. The stack enables us to calculate expressions and pass arguments around. It's not meant to be everything
2023-02-03 15:25:20 <veltas      > Forth is a refinement of portable productive code Chuck Moore developed over years, with the contributions of many other intelligent people
2023-02-03 15:25:53 <veltas      > Part of its early advantage was being able to port it very rapidly to different computers
2023-02-03 15:29:40 <veltas      > And also the fact that you can tap straight into the compiler and generate code
2023-02-03 15:30:19 <veltas      > Lots of mature Forths would go on to have effective storage features, assemblers
2023-02-03 15:30:41 <veltas      > Also had lots of early success in Astronomy, Forth was the first high level language deployed in Space
2023-02-03 15:32:36 <KipIngram   > Yeah, it's brutally pragmatic, and in no way "academic."
2023-02-03 15:32:59 <veltas      > It's brutal by today's standards, but yesterday's standards it was just 'lite'
2023-02-03 15:33:10 <KipIngram   > True.
2023-02-03 15:33:45 <veltas      > Some aspects are friendly and ahead of its time, the interactivity, having a fully functional REPL and eval built-in
2023-02-03 15:34:08 <veltas      > Incredible flexibility
2023-02-03 15:34:13 <KipIngram   > It gives you abilities most languages don't.
2023-02-03 15:34:38 <KipIngram   > Most languages have some kind of function / subroutine capability, but Forth actually exposes the return stack, so you can manipulate that process in creative ways.
2023-02-03 15:59:34 <UngratefulCheese> .join ##c
2023-02-03 15:59:41 <UngratefulCheese> ugh sorry
2023-02-03 16:45:05 <dlowe       > What KipIngram and I were discussing - he sent me a scan of the extremely out-of-print Forth Fundamentals Volume 1, and I converted it to epub by hand.
2023-02-03 16:45:23 <dlowe       > You can find the first draft at https://dlowe.net/ffv1/ffv1.epub
2023-02-03 16:45:38 <dlowe       > YMMV depending on what reader you're using
2023-02-03 16:53:36 <dlowe       > I tried to find the author but couldn't
2023-02-03 18:10:53 <veltas      > dlowe: 13:22 goes off the page
2023-02-03 18:11:21 <veltas      > At least on mupdf, not sure how epubs work
2023-02-03 18:13:06 <veltas      > I get these errors in console too https://pastebin.com/raw/DWEDfN9n
2023-02-03 18:15:21 <veltas      > -W 550 -H 700 works better
2023-02-03 18:15:45 <veltas      > So I guess that's why it went off the page, I wonder if there is a sort of 'standard' EPUB size?
2023-02-03 18:20:55 <remexre     > I thought epubs were zip files of html
2023-02-03 18:21:05 <remexre     > so they "ought to" scale to any size
2023-02-03 18:28:10 <veltas      > Nah doesn't work apparently
2023-02-03 18:28:28 <veltas      > If EPUB is a ZIP of HTML then why can't my browser display it, that's the real question
2023-02-03 18:28:35 <veltas      > Why is everything so ass-backwards
2023-02-03 18:29:10 <thrig       > most everything is backwards compared to forth
2023-02-03 18:33:34 <dkordic     > https://nanovms.com/learn/docker-vs-unikernels is promising.  A ray of hope...
2023-02-03 18:45:02 <veltas      > I've got this kind of retro lightweight alternative to Linux+unikernel called Linux
2023-02-03 19:03:57 <Stalevar    > It seems IBM has chosen to assign obscure graphic characters to control codes to make people less inclined to use them?  ␢ for exampe
2023-02-03 19:09:35 <thrig       > perhaps ␢ is important to the lizard people
2023-02-03 19:14:18 <veltas      > Everyone knows ␢ is the language that came before ¢
2023-02-03 20:12:38 <Glider_IRC_ > Just use a proper keyboard.