00:00:00 --- log: started forth/19.03.02
01:18:48 --- quit: yrm (Quit: yrm)
01:28:12 --- quit: cantstanya (Write error: Connection reset by peer)
01:31:35 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
01:35:37 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth
02:04:36 --- quit: ashirase (Ping timeout: 246 seconds)
02:07:31 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:40:37 --- part: inode left #forth
02:42:24 --- join: `presiden (~presiden@unaffiliated/matematikaadit) joined #forth
02:50:44 --- join: proteusguy (~proteusgu@cm-58-10-208-131.revip7.asianet.co.th) joined #forth
02:50:44 --- mode: ChanServ set +v proteusguy
03:00:58 --- quit: dddddd (Remote host closed the connection)
03:14:15 --- quit: proteusguy (Ping timeout: 250 seconds)
03:26:09 <yunfan> KipIngram: i'd saw NEXT's implementation of DTC/ITC they seems not reduce the code size compared to call/ret, but consider its x86, so is that call/ret were slower than those NEXT instructions?
03:26:40 <yunfan> i am interesting how a RISC forth's NEXT speed compared to the similar call/ret 
03:26:59 --- join: proteusguy (~proteusgu@cm-58-10-208-131.revip7.asianet.co.th) joined #forth
03:26:59 --- mode: ChanServ set +v proteusguy
03:37:09 <corecode> hi
03:37:24 <corecode> yunfan: are you implementing a forth?
03:42:30 <yunfan> corecode: nope, its my goal, but currently i am just learning arm asm. the x86 isa made me headache :[
03:43:16 <corecode> why
03:44:16 <yunfan> corecode: maybe my brain cant handles too many specific instructions :D
03:44:28 <yunfan> i prefer risc familly
03:51:50 <corecode> you don't need that many instructions
04:48:27 <WilhelmVonWeiner> Writing Elixir is cool, because of the pipeline operator
04:49:15 <WilhelmVonWeiner> it kind of gives you the implicit parameter passing you'd get in Forth, but in a procedural style
05:01:26 <`presiden> function composition?
05:01:38 <`presiden> a.k.a pointfree?
05:04:22 <WilhelmVonWeiner> f() |> g() |> h()
05:04:27 <WilhelmVonWeiner> ...I guess yeah
06:19:06 <KipIngram> yunfan: Exactly which approaches save space (and for that matter run faster) varies from processor to processor.  Forth was more likely save space back when the common Forths were 16-bit; when you go to 32-bit everything is twice as large, and you might not win on space anymore.  And if you did a true 64-bit implementation, Forth would start to get pretty fat.
06:20:00 <corecode> why?
06:20:26 <KipIngram> Why fat?
06:20:51 <KipIngram> Because the cells in your definitions and headers and so on are 2x or 4x their size in a 16-bit Forth.
06:21:03 <KipIngram> Now, you could still do a 16-bit Forth even on a 16-bit processor.
06:21:15 <KipIngram> But if you did adopt the larger cell size, your system gets bigger.
06:22:36 <KipIngram> I did a hybrid architecture on mine.  My stacks, variables, and so on are 64 bits, but the cells in my headers, definitions, etc. are just 32.
06:23:26 <corecode> for an n-bit forth, only your stack cells and general memory @! has to be n-bit, no?
06:23:48 <corecode> how you structure your wordlist is completely up to you
06:23:51 <KipIngram> I think it would be fair to call that an n-bit Forth, yes.
06:24:03 <KipIngram> I call mine a 64-bit Forth, in spite of the smaller internal cells.
06:24:15 <corecode> they don't even have to be cells
06:24:38 <KipIngram> What I meant by the above comment is that if you choose a larger size for your system structure, the code becomes bigger.  That's all.
06:24:50 <KipIngram> You could make a 64-bit data Forth with 16-bit internals.
06:25:01 <corecode> why does the code become bigger?
06:25:22 <KipIngram> :-|  If each cell of your definition is bigger, then the definition is bigger overall.
06:25:31 <KipIngram> I'm somehow not communicating here.
06:25:56 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
06:26:01 <corecode> but your definition doesn't need to use cells
06:26:33 <corecode> you can do token threaded code, subroutine threaded code, whatever
06:26:33 <KipIngram> :-|  Did you read what I typed above?
06:26:59 <corecode> well, if it's bigger it's bigger is of course correct
06:27:02 <KipIngram> IF you use 32-bit units in your inner workings, rather than 16, then your definitions and in general your whole system will become twice as large.
06:27:09 <KipIngram> -->  IF  <--
06:27:20 <corecode> yea but that's a tautology
06:27:25 <KipIngram> Yes, it is.
06:27:41 <KipIngram> That's why it was baffling me that we were haggling over it.
06:28:13 <KipIngram> But yunfan was asking about the topic, and I was just pointing out that to some extent the evolution of typical Forth systems has taken away some of its size advantages.
06:28:21 <corecode> i think i must have expected you to imply more
06:28:39 <KipIngram> No, I was being pretty darn obvious.
06:28:48 <corecode> because "larger is larger" is 0 information, and why would you make a 0 information statement
06:29:18 <KipIngram> Forth developed a reputation for "compact" in its early years, and a lot of people still hear that and expect it.
06:29:20 <corecode> i mean, obviously you design a forth for the specific target system
06:29:27 <KipIngram> It's not "as true" as it once was.
06:29:32 <corecode> why?
06:29:33 <KipIngram> I was just trying to explain.
06:29:43 <KipIngram> I'm done.  I think you're trolling.
06:29:43 <corecode> if you do it right, it can be compact
06:30:00 <KipIngram> If you do it to be compact it can be compact.
06:30:00 <corecode> ok
06:30:07 <KipIngram> If you do it to optimize other things it may not be.
06:30:19 <corecode> yes, like everything in engineering
06:31:07 <KipIngram> So, have I somehow annoyed you along the way?  Because you've seemed particularly nit-picky every time we've communicated the last few days.
06:31:40 <corecode> don't take it personal
06:31:52 <corecode> it's not about you, it's about the information
06:33:14 <KipIngram> This isn't a formal debating forum; it's just a friendly chat room.  Not everything everyone says is going to be perfectly crystalized.  Or even completely thought through when voiced.  
06:33:38 <corecode> and feedback can help crystalize it
06:33:42 <corecode> and formulate it better
06:41:25 <crc> my system is purely 32-bit for all but floats; nothing in it is 8, 16, or 64-bit.
06:44:22 <crc> (floats, when enabled, exist on their own stack, with words to encode/decode them into 32-bits if they need to be stored outside the stack)
06:45:18 <crc> In my model, switching to 64-bit would double the size of the system and not bring any improvements to performance. I'd get a greater number range, but 
06:45:36 <crc> I don't need that currently.
06:45:46 <KipIngram> crc: I just use the FPU stack for floats, so it's limited depth.
06:46:07 <KipIngram> My reasoning was that I got a lot done with my old HP calculator, which had a stack only half as deep.
06:46:17 <KipIngram> But whether I'll be happy with that long term or not I'll have to see.
06:46:28 <KipIngram> It just seemed like the best performance.
06:46:58 * Zarutian doesnt support floats at all other than via a proper numerical tower
06:47:03 <KipIngram> Yes, that's why I decided to implement 32-bit internals.  I just didn't see that 64 would really buy me much practically speaking.
06:49:05 <crc> My float stack currently allows 8k items (though I may drop that, as nothing I have uses that many values)
06:50:23 <KipIngram> Wow - that's a bunch.
06:51:39 <crc> stacks are 4000 items for data, 12000 for addresses, 8000 for floats
06:51:58 <KipIngram> Nice.
06:52:41 <KipIngram> My memory pages are 4k bytes right now - I use one for each task block.  At the low end of that block is a handful of variables, and the rest of the 4k is split between the data and return stacks, growing toward one another.
06:53:07 <KipIngram> So I have room for a few hundred.  500 or so total.
06:53:12 <crc> much deeper than necessary, but gives me lots of headroom to do deep recursions and keeping things around without resorting to ram, which is *slow* in my system
07:04:55 --- quit: Zarutian (Read error: Connection reset by peer)
07:05:12 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
07:24:09 <siraben> Why such a deep stack?
07:24:36 <siraben> If you're not using RAM, what are you using?
07:24:48 <siraben> crc:
07:28:18 <KipIngram> I'm guessing he just meant that the words he uses to access RAM other than stack operations are less efficient.
07:28:49 <siraben> KipIngram: the graphical user interface made many things possible that would be unthinkable with CLI, image editing, music composition, diagram drawing etc. What concerns me is that some GUIs have replaced the more efficient parts of command lines for end users, such as navigating the file system, doing searches etc anything text based
07:28:49 <KipIngram> Not that the stacks aren't in RAM.  But I may be wrong.
07:29:00 <siraben> Just caught up with the chat
07:29:10 <KipIngram> Yes, that's exactly how I feel about GUIs.  
07:29:17 <KipIngram> Sometimes they're absolutely needed, for the application at hand.
07:29:30 <KipIngram> But often they're just slapped on top of something that could certainly be done fine without them.
07:29:41 <KipIngram> Because "people love GUIs."
07:29:48 <KipIngram> "Expect" them, so to speak.
07:29:49 <siraben> But replacing a clearly superior tool with an inferior one is not good
07:29:57 <siraben> Exactly
07:29:59 <KipIngram> I totally agree.
07:30:12 <siraben> The problem is worse on mobile
07:30:41 <KipIngram> Well, maybe.  There's almost no such thing as *good* text entry on a phone.
07:30:54 <KipIngram> Even the best solutions are inferior, in my eyes, to a good keyboard.
07:30:59 <siraben> I cannot do anything apart from some typing and reading, I do have a shell app but the lack of physical key presses makes it hard
07:31:17 <KipIngram> I use Swype on my Android phone, and I'm pretty happy with it.
07:31:28 <siraben> Right, I'm actually using swipe to type right now (Gboard)
07:31:47 <siraben> Not perfect, but it works for this clunky interface.
07:32:03 <KipIngram> I use the actual Swype app keyboard, just because I find it more visually aesthetic.
07:32:41 <siraben> And because people who are joining the internet and who are computing for the first time are using phones, this again makes them passive users
07:32:56 <KipIngram> Also, graphical interfaces are less likely to perform well over a remote connection.
07:33:12 <KipIngram> Whereas a console CLI connection usually works so well you can't tell you're remote.
07:33:14 <siraben> I do love GUIs but only for specific domains
07:33:24 <siraben> Right.
07:33:28 <KipIngram> Right.  I think we're in exactly the same camp here.
07:33:56 <KipIngram> I've honed my workflow in my job so that I can do 99% of it with a simple ssh / mosh connection.
07:33:58 <siraben> And people say CLI is hard, I like GUIs are much harder
07:34:22 <KipIngram> There are one or two things that require a GUI, and I always grimace a little when I have to do those.
07:34:25 <siraben> Can't chain together operations on interfaces
07:34:42 <siraben> I use Emacs for anything that doesn't need a web browser
07:34:50 <KipIngram> People think GUIs are easy because there's always a menu system for people who haven't learned their apps.
07:35:14 <KipIngram> They make it easier to "do things without knowing what you're doing."
07:35:32 <siraben> "oo shiny button"
07:35:37 <KipIngram> :-)
07:35:50 <siraben> Also I can switch easily between tasks on the command line
07:35:58 <KipIngram> Window open/close animations, etc.  People seem to just love that stuff.
07:36:02 <siraben> Switching between apps or windows is much more confusing
07:36:17 <siraben> I like the i3 window manager
07:36:37 <siraben> No animations, tiling, blazing fast
07:36:50 <KipIngram> Good.  It would be more power efficient too.
07:37:10 <KipIngram> When I see those fancy animation effects, I usually just think "There goes more of my battery life than was necessary."
07:37:44 <siraben> It's funny that people can wait ten times longer with an animation
07:38:12 <KipIngram> Also, moving your hand away from the keyboard to the mouse - that actually takes a long time.
07:38:28 <siraben> It's well known that a short freeze "feels" longer than a spinning circle
07:38:31 <KipIngram> I like keeping my hands as close to home position as possible.
07:38:57 <siraben> And people wait seconds to open their documents in a browser!
07:39:17 <siraben> I wish there were a collaborative real time editor like Google docs but for Vim or Emacs
07:39:52 <siraben> Or a generic protocol
07:40:05 <jn__> there's a bunch of collaborative editing plugins for vim, but i haven't tried any of them
07:40:48 <siraben> Smalltalk systems get GUI done right. Introspection, composition, modularization
07:41:09 <siraben> Modern desktops are a step backwards
07:41:40 <siraben> And this is coming from someone whose first use of a computer ran Windows XP!
07:42:34 <crc> siraben: I use ram when necessary, but my processor is a MISC-based stack processor. Memory access requires multiple instructions ([push address to stack, fetch], [push value to stack, push address to stack, store]). The essential few stack operations are just one each, and can be done more quickly.
07:42:46 <KipIngram> I'm not familiar in detail with Smalltalk.
07:43:03 <siraben> Message passing, object orientated
07:43:18 <crc> my stacks are part of the MISC processor, not in addressable RAM
07:43:27 <siraben> I see
07:43:56 <siraben> Will have to sleep now, later folks
07:43:59 <KipIngram> Ah, ok.
07:44:05 <KipIngram> Night, siraben.
07:59:24 <dddddd> I use infinoted for simple collaborative real time edit
08:04:33 <corecode> crc: what is MISC?
08:05:04 <corecode> moderate?
08:05:10 <corecode> minimal?
08:05:41 <crc> minimal instruction set computer
08:06:03 <corecode> so a turing machine?
08:06:20 <corecode> read, write, and move?
08:07:22 <crc> not that minimal
08:07:24 <crc> http://www.ultratechnology.com/mup21.html
08:09:55 <crc> http://forth.works/eb5b34291c6172c822a147f18c93ac7d is a summary page and http://forth.works/37ca950ce0822f43c344df4fa5d65962 is the C source for the emulated processor I use (sans platform specific I/O devices)
08:10:44 <crc> I have 30 instructions
08:12:51 <corecode> ok
08:12:56 <corecode> i think i have fewer
08:13:05 <corecode> but then, i do different things
08:14:07 --- quit: rprimus (Ping timeout: 250 seconds)
08:14:31 <corecode> maybe i should optionally support multiply and multiply/add
08:16:04 --- join: rprimus (~micro@unaffiliated/micro) joined #forth
08:17:31 <crc> I could reduce this to about 15-16 instructions, but these are what I have settled on as a comfortable set over the last decade of use.
08:32:54 --- quit: proteusguy (Ping timeout: 244 seconds)
08:39:04 <corecode> i'd love a review on my design to see how i could improve it
08:39:46 <crc> do you have a link to it? I'll have some time later today to look at it
08:40:00 <corecode> sec
08:40:09 <corecode> https://github.com/corecode/forth-cpu/tree/master/rtl
08:42:27 <crc> thanks
08:49:54 <corecode> https://github.com/corecode/forth-cpu/blob/master/tb/cpu_tb.v#L91 instruction set
09:09:01 <crc> What is OP_EXECUTE?
09:10:21 <corecode> well, like execute
09:10:30 <corecode> indirect call to TOS
09:10:47 <crc> ok
09:11:28 <corecode> given that the stack ops are exposed in the instruction encoding, there are other opcodes possible as well
09:12:13 <crc> OP_BRANCH, OP_0BRANCH, OP_CALL take the target address as an operand?
09:12:42 <corecode> yes
09:12:54 <crc> sounds good
09:12:57 <corecode> OP_LIT takes an immediate too
09:13:13 <corecode> single cycle execution for all opcodes
09:14:30 <crc> The instruction set looks reasonable to me
09:15:14 <crc> I'll take a closer look later, have to go to a lunch meeting in a few minutes
09:24:30 * Zarutian got it the number of primitives down to less than sixteen
09:36:24 --- join: proteusguy (~proteusgu@cm-58-10-208-131.revip7.asianet.co.th) joined #forth
09:36:24 --- mode: ChanServ set +v proteusguy
09:52:19 --- quit: MrMobius (Ping timeout: 255 seconds)
09:54:46 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
09:55:06 --- quit: dave0 (Quit: dave's not here)
10:04:01 --- quit: proteusguy (Ping timeout: 255 seconds)
10:08:35 --- quit: nighty- (Remote host closed the connection)
10:17:31 --- join: proteusguy (~proteusgu@cm-58-10-208-131.revip7.asianet.co.th) joined #forth
10:17:31 --- mode: ChanServ set +v proteusguy
10:26:41 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
10:29:13 --- quit: MrMobius (Ping timeout: 255 seconds)
10:29:13 --- nick: [1]MrMobius -> MrMobius
10:37:21 --- join: tabemann (~travisb@2600:1700:7990:24e0:78df:6a9:450a:b439) joined #forth
12:31:29 --- quit: tabemann (Ping timeout: 264 seconds)
13:54:52 <WilhelmVonWeiner> as the pain in my hands from typing gets progressively worse I start to like the ColorForth keyboard more and more
13:56:33 <KipIngram> I really like the abstrat idea Chuck had going on with all of that.
13:56:44 <KipIngram> I do believe in the "collaboration of man and machine."
13:56:59 <KipIngram> I just was never able to follow it quite so far as he did.
13:58:03 <KipIngram> I could particularly get into collaborating with Six from Battlestar Galactica...
14:06:54 <WilhelmVonWeiner> I think he agrees it's all a bit esoteric for most others at this point 
14:07:24 <WilhelmVonWeiner> and it's why PolyForth was ported to the GA144
14:08:13 <KipIngram> Well, the idea that the whole Forth concept can so easily morph into whatever you as an individual need for it to be is just pretty cool.
14:12:02 <KipIngram> My hands occasionally get sore.  Usually one or the other at any given time.  I always fret and think "arthritis," but so far it's always gone away - I guess it's just overuse strain when I've been particularly active on the keyboard.
14:12:16 <KipIngram> I remain a HUGE fan of a good, real keyboard.
14:13:09 <WilhelmVonWeiner> just ordered two split keyboards today to test out
14:13:15 <KipIngram> I took typing in high school.  That was the late 1970's, and I really had no clue what was about to happen with computers.  I took it because it seemed like a great way to hang out with a lot of the cute girls.
14:13:18 <WilhelmVonWeiner> will return the worst one
14:13:27 <KipIngram> But it sure did turn out to be a useful skill to have acquired.
14:13:28 <WilhelmVonWeiner> LOL! 
14:14:05 <WilhelmVonWeiner> saved by the bell
14:14:07 <WilhelmVonWeiner> kekeke
14:14:09 <KipIngram> Unexpectedly, I wound up being good at it.
14:15:09 <KipIngram> I used to work quite hard to keep a straight face, at the job I had in late 1990's, when I'd be in the Executive Vice President's office and would watch him type with his two index fingers.
14:15:21 <KipIngram> Given how he was doing it, he was actually pretty quick.
14:15:59 <WilhelmVonWeiner> I've been trying to learn good typing but it's hard.
14:16:33 <WilhelmVonWeiner> I wish the enter key weren't so far away.
14:17:37 <KipIngram> Hmmm.  I could imagine it being like under the space key or something.
14:17:41 <KipIngram> Accessible to either thumb.
14:18:02 <the_cuckoo> i learnt to type properly on a traditional type writer - wasn't a lot of fun
14:18:07 <WilhelmVonWeiner> Yes, one of my split keyboards arriving next week has it like that.
14:18:16 <KipIngram> It's an interesting history - the keyboard layout.
14:18:29 <KipIngram> As the Dvorak studies show, it's nowhere near the "time motion optimum."
14:18:34 <KipIngram> The querty layout, I mean.
14:18:42 <the_cuckoo> i live in a country were azerty is the norm
14:18:54 <the_cuckoo> i seriously wonder how they manage
14:18:54 <WilhelmVonWeiner> I like colorForth's way of having a word buffered and the entered with space... though it makes entering a space marginally harder...
14:19:04 <WilhelmVonWeiner> azerty seems inane
14:19:09 * Zarutian got rather irritated with a traditional type writers. He nearly always near-chords when typing which will always result in level clash.
14:19:18 <KipIngram> In fact, I've read that they chose a layout to *keep* people from trying to type faster than the mechanisms could keep up with - with more efficient layouts people would jam the print arms all together.
14:20:14 <KipIngram> But once it was done, it stuck, because even as technology improved, there were too many people out there who knew it to change it.
14:20:21 <Zarutian> I heard it was because then salesmen could type the english word typewriter nearly onehanded
14:20:21 <KipIngram> Sort of like Windows.  :-(
14:20:38 <KipIngram> But you can't do that.
14:20:40 <Zarutian> Well, everyone knows that Window is nearly EOL
14:20:51 <KipIngram> You need W and P, and they're almost as far apart as it gets.
14:20:53 <Zarutian> Windos*
14:20:57 <Zarutian> Windows*
14:21:18 <KipIngram> Zarutian: I *hate* it when I try to issue a correction and make another mistake.
14:21:36 <WilhelmVonWeiner> KipIngram: the reality is pretty simple, it was mostly trial and error
14:21:56 <the_cuckoo> Zarutian: i don't think so - it'll be around for a lot longer
14:21:57 <Zarutian> Its been what? nearly nine years since Windows '10, no?
14:22:08 <WilhelmVonWeiner> they just kept moving things into places where they wouldn't clash often until they were satisfied
14:22:25 <KipIngram> Yes, I think that's likely true.
14:22:38 <Zarutian> WilhelmVonWeiner: yeah for english but not for many nordic languages.
14:22:43 <KipIngram> Actually *solving* problems like that optimally sort of required computers.
14:22:50 <KipIngram> In complex cases at least.
14:23:15 <Zarutian> naah, even tube electronics would have been enough
14:23:43 <KipIngram> Well, but the typewriter's been around since well before that, right?
14:23:55 <KipIngram> I don't actually know when it was invented.
14:24:04 <KipIngram> I would guess late 1800s or something - going to look now.
14:24:25 <KipIngram> 1873.
14:24:34 <Zarutian> heck I saw an typewriter whose typing head was a row of letters and one hole where the striker pushed an block through then retracted it
14:24:52 <john_cephalopoda> Ach naja
14:25:15 <KipIngram> Hi john_cephalopoda.
14:25:19 <WilhelmVonWeiner> Ach! hans, run!
14:25:47 <john_cephalopoda> Wrong channel
14:25:48 <Zarutian> then thing is typewriters arent that old relatively speaking. The first onces were around 1873 but none actually got into commercial use until perhaps 1910's or so
14:25:50 <Zarutian> iirc
14:26:08 <KipIngram> That seems likely.
14:26:18 <KipIngram> Probably took 'em a while to figure out how to produce them at low enough cost.
14:26:31 <WilhelmVonWeiner> initally people just didn't care
14:26:59 <WilhelmVonWeiner> just how it always seems to go
14:27:20 <Zarutian> the printing press is much older but better established but people didnt want to bother unless you were going to mass print a phamplet or some such
14:28:01 <KipIngram> Well, the printing press changed the world.  I guess the typewriter did too, but I don't think in as fundamental a way.
14:28:25 <KipIngram> Before the press, books were like Hope diamonds; reserved for the wealthy.
14:28:40 <Zarutian> what the hell are Hope diamonds?
14:28:51 <KipIngram> It may have just been one diamond.
14:28:54 <KipIngram> A famous one.
14:28:57 <KipIngram> A specific diamond.
14:29:03 <john_cephalopoda> Yeah, typewriters didn't speed up publication speed considerably.
14:29:04 <WilhelmVonWeiner> The hope diamond is a big un iirc
14:29:10 <KipIngram> https://en.wikipedia.org/wiki/Hope_Diamond
14:29:14 <WilhelmVonWeiner> Unlike De Beers...
14:29:42 <john_cephalopoda> De Beers… capitalists…
14:29:46 <Zarutian> Well there is the Eye of the Peacock that is part of the crown stuff owned by the British Crown.
14:31:00 <Zarutian> I do not see the point of diamonds frankly other than as used in industry, optics or molecularly nanotech fabricated window panes (many years to that though)
14:31:03 <john_cephalopoda> They convinced the population of the USA that you have to spend several salaries on an engagement ring.
14:31:52 <WilhelmVonWeiner> *the world
14:31:52 <KipIngram> Yeah - no kiding.
14:31:54 <KipIngram> kidding
14:32:02 <john_cephalopoda> Yeah, diamonds aren't really pretty. Industrial applications are all they are good for.
14:32:14 <Zarutian> well, you can convince 'Muricans of many untrue or contradictory things.
14:32:44 <KipIngram> I remember a scene from Mad Men, where this beatnick friend of the main dude's girl on the side told him, re: his advertising profession, "You *create WANT*."
14:32:47 <KipIngram> It wasn't a compliment.
14:32:59 <WilhelmVonWeiner> You know what bugs me? A lot of people seem convinced RPN is unreadable
14:33:00 <Zarutian> john_cephalopoda: now, zirconium crystals, they are pretty. Specially when properly cut.
14:33:12 <KipIngram> And I think that's pretty damn true - those guys program us to want stuff that we don't need, until they get into our heads.
14:33:35 <Zarutian> WilhelmVonWeiner: it is because they have not been exposed to it much.
14:33:42 <WilhelmVonWeiner> IMagine not learning C and telling a C programmer it was unreadable
14:33:49 <WilhelmVonWeiner> they'd laugh you out of the room
14:34:27 <john_cephalopoda> Imagine not learning to read and telling people that C is unreadable.
14:34:29 <Zarutian> Well, C is, specially its bloated offspring C++, quite unreadable and ambigious. Hence all the "Undefined Behaviours"!
14:34:46 <WilhelmVonWeiner> true, C++20 can actually be hard to read
14:35:16 <john_cephalopoda> ANS Forth has quite a bunch of undefined behavior.
14:36:01 <WilhelmVonWeiner> Doesn't really affect the readability though
14:36:20 <Zarutian> john_cephalopoda: yeah, hence no actual ANS Forth system exists. All that are claimed to be specify what they do in quite detail.
14:36:23 <WilhelmVonWeiner> it's not ambiguous because of the syntax (unless you have an example)
14:36:42 <Zarutian> ANS Forth is basically just a loose guideline as far as I can tell
14:37:08 <KipIngram> The main thing that makes Forth anything less than 100% readable is immediate words.
14:37:16 <KipIngram> Because it brings the timing of things into question.
14:37:17 <Zarutian> WilhelmVonWeiner: in C? well what does: a = b + c * d; do?
14:37:37 <KipIngram> Without those in play, A B C means "what ever A does happens, then whatever B does happens, then whatever C does happens."
14:37:41 <KipIngram> It doesn't get any simpler than that.
14:37:45 <WilhelmVonWeiner> probably won't compile kekeke
14:37:54 <WilhelmVonWeiner> I meant forth, was replying to john
14:38:12 <KipIngram> a = b + c*d; damn well better be c @ d @ * b + a !
14:38:17 <KipIngram> Or it's borked.
14:38:27 <KipIngram> Sorry - b @
14:38:34 <WilhelmVonWeiner> as in "the ANS undefined behaviours wouldn't be due to syntax"
14:39:04 <Zarutian> nope, it throws an compile error as a is an uint b is a scaled fixed point and c is an int while d is an double precision float.
14:39:45 <Zarutian> in C that is.
14:40:08 <Zarutian> this is why I like float@ float+ and such prefixed words
14:40:13 <WilhelmVonWeiner> C wouldn't throw an error, they'd all be implicitly cast
14:40:27 <KipIngram> lmao
14:40:29 <KipIngram> Ok.
14:42:25 <Zarutian> and one thing, C or C++ has no place on microcontrolers or in embedded systems. This MCU is not your grandmothers PDP-11, gcc, so stop trying to stuff all your string constants into WRAM instead of in Program Flash ROM where it belongs
14:43:26 <Zarutian> (nor is it your fathers legacy x86 for that matter)
14:47:10 <crc> WilhelmVonWeiner: which keyboards?
14:52:35 <WilhelmVonWeiner> ergodox and a "uk ergo pro" from keyboardco a UK keyboard store
14:55:43 <crc> I've ordered an ergodox as well. Working on a keymap while I wait for it to ship.
14:56:52 <WilhelmVonWeiner> Mine's an eBay bid at the moment, I'm working on the assumption nothing really changes
14:57:41 <WilhelmVonWeiner> Ordering an Ergodox EZ would be £200 + ~£25 wrist rests + customs fees 
14:58:19 <WilhelmVonWeiner> this is £230 and in the UK
15:03:50 <crc> Mine was $354 in the US, so about £268
15:04:43 * WilhelmVonWeiner sweats a little
15:05:02 <corecode> Zarutian: string constants are no rodata
15:05:52 <Zarutian> corecode: but they are, in any other sane macro assembler for MCUs
15:09:55 <corecode> i mean, in
15:09:58 <corecode> they are in rodata
15:12:41 <Zarutian> yet most C compilers for MCUs try to stuff them into WRAM when the MCU turns on.
15:14:24 <KipIngram> Isn't this sort of thing usually because someone ported in a C compiler intended for some other type of system rather than carefully writing a tool specific to the device?
15:14:56 <KipIngram> After all, leveraging pre-existing work seems to be what people are all about these days.
15:15:30 <corecode> Zarutian: yea, i don't know what other compilers do
15:15:48 <corecode> Zarutian: it makes sense in a harvard architecture
15:15:51 <KipIngram> "How can I take work someone else did and make money off of it?"  :-)
15:16:08 <corecode> for a long time, string constants were writable
15:16:22 <Zarutian> KipIngram: sure, usually by someone clueless about the MCU architecture.
15:16:25 <corecode> and people would do stuff like char *tmp = "foo123";
15:16:33 <KipIngram> Yes.
15:16:37 <corecode> tmp[4] = 'a';
15:16:54 <corecode> which ofc doesn't work if your string constant is readonly
15:17:17 <corecode> lots of segfaults back then when gcc changed that
15:18:18 <KipIngram> The concept of doing tasks "as well as they can possibly be done" is pretty much dead in the modern economy, except in marketing rhetoric.
15:19:16 <Zarutian> KipIngram: dont know which MCU maker did this but they actually provided the macro assembler as an one big .c file you could compile yourself.
15:20:39 <Zarutian> KipIngram: some, jobs have "yeah do a shoddy job at this and we will hunt you down and gradually shorten your limbs down to nothing" kind of risks to them. (Human rated spacefareing rockets for instance)
15:22:28 <KipIngram> Ok, that's fair.  And it's good.  I guess I'm mostly calibrated around run-of-the-mill consumer products.
15:38:31 --- join: yrm (~yrm@KD106132216087.au-net.ne.jp) joined #forth
15:44:15 --- join: tabemann (~travisb@2600:1700:7990:24e0:78df:6a9:450a:b439) joined #forth
15:49:19 --- quit: yrm (Quit: yrm)
16:12:17 --- quit: tabemann (Ping timeout: 264 seconds)
16:40:59 <siraben> I wonder if anyone made a Forth for turing machines
16:45:49 --- join: yrm (~yrm@KD106132216087.au-net.ne.jp) joined #forth
16:53:18 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
16:55:04 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:58:07 --- quit: proteusguy (Ping timeout: 268 seconds)
17:02:33 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
17:10:16 --- join: proteusguy (~proteusgu@cm-58-10-208-131.revip7.asianet.co.th) joined #forth
17:10:16 --- mode: ChanServ set +v proteusguy
17:10:46 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth
17:13:04 --- quit: dddddd (Remote host closed the connection)
17:45:54 <rdrop-exit> Good morning Forth aficionados
17:50:25 <crc> hi rdrop-exit 
17:50:34 <rdrop-exit> Hi crc
18:41:31 <siraben> Got FIND and EXECUTE working now: https://raw.githubusercontent.com/siraben/r216-forth/master/screenshot.png
18:41:52 <siraben> So the REPL boots up, reads a word, executes it and stops, I'll need to add stuff like WORD next
18:45:01 <rdrop-exit> Kudos Siraben
18:46:11 <siraben> Very interesting instruction set: https://lbphacker.pw/powdertoy/R216/manual.md#Instruction.reference
18:46:41 <siraben> Most of the instructions run in a single frame
18:46:53 <siraben> Except CALL, it seems, which takes 2 frames
18:51:37 --- quit: yrm (Quit: yrm)
19:37:28 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
19:44:46 <dave0> hi
19:46:32 <siraben> hi dave0 
19:46:44 <dave0> hi siraben 
19:48:23 <crc> hi dave0
19:48:37 <dave0> hi crc 
19:52:42 <siraben> I copied and pasted my WORD routine from my other Forth system and it worked just fine!
19:54:10 <PoppaVic> No drag and drop?
19:54:44 <siraben> Well I had to transcribe it from my lisp notation into ASM notation again
20:14:51 --- quit: proteusguy (Ping timeout: 246 seconds)
20:37:40 <siraben> Wow this Forth is SLOW
20:38:10 <siraben> This simple program took at least a minute to run at 120 frames per second ( = 120 instructions/sec), https://github.com/siraben/r216-forth/blob/3fc6fac35b9128a049b18ad6e0a27225b51346ca/forth.asm#L834
20:41:58 <siraben> To save space this time I only store the first three letters of each word + their length
20:42:14 <siraben> Might regret this later
23:08:54 --- join: proteusguy (~proteusgu@cm-58-10-208-131.revip7.asianet.co.th) joined #forth
23:08:54 --- mode: ChanServ set +v proteusguy
23:14:49 --- join: fftww (~va@46.211.51.127) joined #forth
23:15:10 --- quit: fftww (Client Quit)
23:15:43 --- join: fftww (~va@46.211.51.127) joined #forth
23:35:51 --- quit: fftww (Read error: Connection reset by peer)
23:40:01 --- join: fftww (~va@46.211.44.223) joined #forth
23:59:59 --- log: ended forth/19.03.02