00:00:00 --- log: started forth/19.03.27
00:04:00 --- join: rdrop-exit (~markwilli@112.201.169.15) joined #forth
00:49:47 --- quit: MrMobius (Ping timeout: 246 seconds)
00:50:11 --- quit: proteusguy (Ping timeout: 255 seconds)
01:02:25 --- join: proteusguy (~proteusgu@mx-ll-180.183.96-95.dynamic.3bb.co.th) joined #forth
01:02:25 --- mode: ChanServ set +v proteusguy
01:10:52 --- quit: pierpal (Ping timeout: 268 seconds)
02:04:53 --- quit: ashirase (Ping timeout: 255 seconds)
02:07:58 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:23:47 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
02:35:38 <WilhelmVonWeiner> shalom Forth
03:03:49 <rdrop-exit> Hi WilhelmVonWeiner
03:04:05 <WilhelmVonWeiner> how art thou
03:04:55 <rdrop-exit> Ok, finally doing some programming after a few week hiatus, just minor stuff fixed a bug
03:04:56 <WilhelmVonWeiner> was writing a cross compiler earlier for a cpu I was writing in Python
03:05:20 <WilhelmVonWeiner> only like 5 lines atm, very early and simple, but I think I have a good base
03:06:03 <WilhelmVonWeiner> When I have a break from doing some python/google cloud crap, I shall ask for feedback from you lot
03:06:27 <rdrop-exit> I still haven't looked into Python, I should watch a youtube video or something to check it out
03:09:40 <rdrop-exit> I'm out of touch with the current computing mainstream
03:12:09 <rdrop-exit> I used to enjoy trying out new languages when I was younger, remember Computer Language magazine
03:16:53 <presiden> I enjoy trying out old languages instead
03:17:07 <rdrop-exit> Cool
03:17:52 <presiden> forth is included in this category
03:20:45 <rdrop-exit> I've never really considered Forth a language per se
03:20:50 <WilhelmVonWeiner> Python is awesome imo
03:21:08 <WilhelmVonWeiner> someone best described it as "pseudocode you can run"
03:23:28 <rdrop-exit> I know nothing about it really, from what I gather it's what I call a "glue" language
03:25:22 <rdrop-exit> Glue languages have their place, especially in mainstream computing
03:31:12 <rdrop-exit> Much of the current Forth standardization effort seems to be oriented to tuurning Forth into a glue language
03:33:56 --- quit: pierpal (Ping timeout: 246 seconds)
03:45:19 <WilhelmVonWeiner> not really glue imo
03:45:34 <WilhelmVonWeiner> it works great for that
03:46:41 <rdrop-exit> It sure took off in the last few years
04:23:49 --- quit: proteusguy (Remote host closed the connection)
04:35:20 --- quit: rdrop-exit (Quit: Lost terminal)
04:46:17 <presiden> me trying out some library on python, https://xkcd.com/1987/
05:06:18 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
05:30:18 --- quit: Keshl (Read error: Connection reset by peer)
05:30:52 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
05:56:07 --- quit: gravicappa (Ping timeout: 250 seconds)
05:56:36 --- join: gravicappa (~gravicapp@h109-187-213-103.dyn.bashtel.ru) joined #forth
06:10:41 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
06:11:05 <WilhelmVonWeiner> it's so disappointing that the ecosystem is so messed up they recommend you make a new virtual environment for every project
06:24:09 --- join: mark4 (~mark4@148.80.255.161) joined #forth
06:56:28 --- quit: pierpal (Remote host closed the connection)
07:06:00 --- quit: tabemann (Ping timeout: 250 seconds)
07:40:13 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
07:40:54 --- quit: dave0 (Quit: dave's not here)
07:48:13 <crc> I've never used virtual environments with python
07:59:09 <WilhelmVonWeiner> I'm using it at work so it's for the best.
08:00:02 <WilhelmVonWeiner> don't want to kill one script fixing another
08:02:40 <KipIngram> What opinions do you guys  hold as to whether the first directory searched for word matches should be CURRENT?
08:03:06 <KipIngram> I'd previously thought "no," but I'm reconsidering and leaning pretty strongly toward "yes, search it first, and then the context stack."
08:04:03 <zy]x[yz> no
08:04:14 <KipIngram> What's your reasoning?
08:04:17 <zy]x[yz> sometimes you want you definitions to go into a dictionary that's not on the search order stack
08:04:36 <KipIngram> Well, here's the problem I ran into.
08:04:48 <KipIngram> I had a vocabularly with word foo defined in it.
08:04:55 <KipIngram> I needed that vocabularly, so I called it out.
08:05:04 <KipIngram> I re-used the name foo in my new local code.
08:05:18 <KipIngram> But it found the one in the vocabularly first.
08:05:33 <KipIngram> Exactly what it should do, the way it's written, but it took me a few minutes to click.
08:05:54 <KipIngram> My new reasoning was that local names should always trump remote names.
08:06:14 <zy]x[yz> so you should have set up your search order like   vocabulary V  V definitions also local
08:07:31 <KipIngram> Yes, that would work.  Can you give me an example of when you would not want your new definitions to get searched?
08:07:46 <zy]x[yz> sandboxing
08:08:03 <KipIngram> I factor a LOT, and almost always have some "supporting words" building up to a definition of any complexity.
08:08:05 <zy]x[yz> or metacompiling
08:08:28 <KipIngram> Ok, metacompiling - that makes sense.
08:08:49 <zy]x[yz> which is basically a specific case of sandboxing
08:08:56 <KipIngram> I need to think about it more, but it seems reasonable it could have some unique requirements.
08:09:29 <KipIngram> But yeah, a huge part of my technique involves multiple words that work together.
08:09:37 <zy]x[yz> but also, the ability to do what you needed was already there.  why would you remove flexibility in favor of protecting you from yourself?
08:09:41 <KipIngram> I build control structures "vertically" through the call stack.
08:10:13 <KipIngram> That's a very valid point, but I'm just thinking about *how often* I would need this.
08:10:58 <KipIngram> But anyway, your points are good.
08:11:08 <zy]x[yz> i know that's why i made them
08:11:10 <KipIngram> And it's *simpler* to search just context.
08:11:13 <KipIngram> lmao
08:11:14 * PoppaVic chortles
08:16:50 <WilhelmVonWeiner> instead of solely chortling, can you perhaps explain why you're doing so
08:19:34 <zy]x[yz> KipIngram, another use-case: sometimes you want the vocabulary you're currently defining to shadow your "local" vocabulary
08:20:03 <zy]x[yz> say you define foo, then you start a vocabulary and you define a different foo, and then also a bar which builds off the vocabulary's foo
08:20:24 <zy]x[yz> that's probably a more common case than what i was driving at earlier
08:30:47 <zy]x[yz> oh wait, nevermind.  you said current would be searched first
08:30:59 <zy]x[yz> so that's actually the case where your proposal would work
08:31:33 <zy]x[yz> can a freenode admin please delete my past five posts
08:31:41 * PoppaVic chuckles
08:31:48 <PoppaVic> more coffee
08:51:04 <KipIngram> So, I know what I'm about to say would mean a little *extra* coding, but I suspect that if I wanted to have CURRENT be optional in the search order I'd default it in and then have a word to REMOVE it.
08:51:26 <KipIngram> I'm 90% sure that is more complex than the opposite, but I just know that I'm going to want it in there 99% of the time.
08:51:51 <KipIngram> So rather than having to add it every time (and occasionally forgetting), I'd rather remove it when a special case has arisen.
08:51:55 <PoppaVic> that's why we have only/also/previous, etc
08:52:35 <KipIngram> Yes, I know, but what I'm saying is that I want things to "just work" as simply and naturally and with as little verbage as possible forl MY COMMON CASE.
08:53:02 <KipIngram> Word might be NOLOCAL
08:53:05 <KipIngram> or something like that.
10:00:41 <WilhelmVonWeiner> https://hastebin.com/onikapoxam.shell
10:00:55 <WilhelmVonWeiner> this is not a shell file, it's RETRO Forth
10:02:11 <WilhelmVonWeiner> `&delimited? parse-until` reads stdin until sp, nl, or cr, and [ ] are like :NONAME ;. `if` is postfix.
10:05:08 <WilhelmVonWeiner> only works at the opcode level. Not sure how I'd expand it to let you build threaded words - probably have each opcode do the store and increment?
10:24:40 * Zarutian been implementing bare bones RFB server in forth
10:26:59 <crc> fwiw, http://forth.works/c7d8ef05b921f552c35e32040d63bd4d
10:26:59 <crc>  is a glossary for the retro words used by WilhelmVonWeiner's paste (may be helpful to anyone looking at it)
10:28:49 <WilhelmVonWeiner> using & instead of a quotation always feels like cheating :^)
10:32:01 <crc> you could use `tri` in `delimited?`
10:35:18 <crc> `[ #32 eq? ] [ #10 eq? ] [ #13 eq? ] tri or or` as opposed to `dup #32 eq? swap #10 over eq? swap #13 eq? or or`
10:39:45 <mark4> vocabulary stuff stuff definitions forth ' foo alias foo previous
10:40:18 <mark4> or vocabulary stuff stuff definitions : foo .... foo ... ;
10:40:35 <mark4> where foo in the stuff vocabulary references a word of the same name in the forth voc
10:40:46 <mark4> vocabulary stuff stuff definitions previous  
10:40:54 <mark4> new words go in stuff vocabulary but it is not in the search order
10:41:15 <mark4> usually you do some thng like only forth also stuff 
10:41:27 <mark4> i.e. you define the search order and where definitions go
10:43:33 <KipIngram> Hi Mark.  I'd say that "most' of my Forth code, beyond the very simplest stuff, involves a significant amount of factoring.  I definitely need to find words I've just defined in that case.
10:43:55 <KipIngram> So I want that to be the "natural" way my system works, without me doing any "special" things.
10:44:05 <KipIngram> I'll do "special" things to move *away* from that scenario.
10:45:00 <mark4> you just make sure that what ever vocabulary is current is also in context
10:45:17 <mark4> but you can define the order of search
10:45:41 <KipIngram> Sure, but occasionally I'll for get.
10:46:01 <KipIngram> I'm thinking I'll have it search CURRENT (without it being IN CONTEXT) unless a flag is set saying not to.
10:46:07 <KipIngram> I realize that is excess complexity.
10:46:31 <mark4> i have added complexity with my forths by not defining "also"
10:46:44 <zy]x[yz> it's worse than excess complexity.  it's a special case that's hard to remember
10:46:54 <KipIngram> You've got the "stack of context stacks," right?
10:47:03 <mark4> yes
10:47:06 <mark4> good memory
10:47:08 <KipIngram> No - it will be EASY for me to remember.
10:47:14 <KipIngram> I made mine work that way.
10:47:40 <KipIngram> Just used the same stack - stacked the new context on top of the old one, with a 0 in between.  A zero at the very bottom was already how the search terminated.
10:48:00 <mark4> only the top context on the contexts stack is actually searched
10:48:06 <KipIngram> Right.
10:48:13 <KipIngram> I search down until I find a zero.
10:48:14 <mark4> i can create a new context stack with context: my-context
10:48:18 <KipIngram> The other contexts are further down.
10:48:26 <KipIngram> It was easy to remember - I was impressed with it.
10:48:32 <mark4> i can now add/remove from that at will and i can make IT "the" context or revert back to the previous context stack
10:48:39 <mark4> ya
10:48:49 <mark4> comp lang forth was not impressed lol
10:49:18 <KipIngram> I made mine so that when I open a new context (with path: ) it gives me only Forth and current Forth.
10:49:34 <KipIngram> I have a word "PRIOR" that will copy forward the next outer context to mine.
10:50:21 <KipIngram> When I first fired it up I was saving/restoring only CONTEXT, but I decided it really should manage CURRENT as well.
10:50:32 <KipIngram> Otherwise if you change it you're not really giving the last guy back his env.
10:50:56 <mark4> thats a point
10:51:19 <KipIngram> It was easy; path: just pushes CURRENT to the context stack before stacking on the zero.
10:51:26 <KipIngram> It's not searched, so that's ok.
10:51:28 <mark4> you could make "current" is always the 0th item of the context stack but only the 1th onwards are searched
10:51:41 <mark4> yea same idea :)
10:51:42 <KipIngram> Then ;path pops down until it pops the zero, then pops into CURRENT.
10:51:45 <KipIngram> And we're back.
10:52:37 <KipIngram> I have ONLY, which just takes the top item of the stack (whatever it is), throws away everything, and makes that item the only item on the stack.
10:53:11 <KipIngram> And also makes it CURRENT, I believe.
10:53:55 <KipIngram> Anyway, I'm finding that path: ... ;path just slides into my coding style very naturally.
10:55:10 <mark4> in my forths ALL vocabulary and context related words are in the root vocabulary
10:55:36 <mark4> ONLY remvoes everything from context and adds in root to the search order
10:55:56 <mark4> it HAS to add root because every time you create a vocabulary its definition is added to the root vocabulary
10:56:05 <mark4> if root is ever out of context you have no way to modify context any more
10:56:45 <mark4> vocabulary foo  -- no matter what is current at the time you define foo foo is always defined within the root vocaulary
10:59:10 <mark4> however, it is EXTREMELY rare that you even need this kind of context manipulation, having every module you load in create its own vocabulary is rare
11:00:03 <mark4> it would be like an assembler module defining an assembler vocabulary then loading in various modules for different processors and each processor uses its own vocabulary
11:00:06 <mark4> no need
11:04:37 <KipIngram> I believe that's how Forth-79 was (all vocabularies gre from the root).
11:04:49 <KipIngram> FIG had a more complete tree structure.
11:05:09 <KipIngram> I find it easier to code the complete tree.  It's just "what you get naturally" if you follow the algorithm through.  
11:05:31 <KipIngram> When you create a vocabulary, you're just creating a word.
11:05:37 <KipIngram> Whereever any word would go - in CURRENT.
11:06:02 <KipIngram> It creates a dummy header that becomes the "terminal element" of that vocabulari's word chain.
11:06:31 <KipIngram> In the past I've searched all the way back to the root from whereever I started, but this time I'm searching JUST the specified vocabulary.
11:06:40 <KipIngram> The search finds that terminal element and we're done with that on.
11:11:35 <mark4> i never really used either fig or the 79 std, my forth education was with tom zimmers FPC for dos :)
11:11:37 <mark4> 83 std
11:11:54 <mark4> based on laxen and perrys F83 (and the rest is silence)
11:21:22 <KipIngram> :-)
11:21:42 <KipIngram> I think F79 / F83 - right in there - was when the standard reached its high water mark.
11:22:23 <mark4> i f83 fixed bugs from legacy standareds that ans totally FSCKED UP!!!
11:22:50 <mark4> oooh nooo!!! we have two non compatible definitons for NOT ! we cant make the BROKEN versions fix themselves!
11:23:01 <mark4> we have to come up with a new limp wristed word called INVERT !!!
11:23:24 <mark4> cant remember if it was FIG or F79 that define not as 0=
11:23:33 <mark4> 83 standard fixed not to be a 1s comp
11:24:22 <mark4> and dont get me started on "postpone" lol
11:24:22 <KipIngram> UGH.
11:24:43 <KipIngram> They must have had NO EE's on the standards committee.
11:24:55 <KipIngram> The one that made it like 0=.
11:24:57 <mark4> they had CM till he abandoned it in frustration
11:25:00 <mark4> they ahd E.R. on there
11:25:22 <KipIngram> Why would you THROW AWAY INFORMATION?
11:25:59 <mark4> the word NOT was used incorrectly in legacy versions, it was used as though it was a 0=, not as though it was a mathematical operation
11:26:08 <mark4> that was fixed in the 83 standard
11:26:24 <KipIngram> Yes, I understood that's what you were saying.
11:26:26 <mark4> : blah foo 5 = not if do this then ;  scans better in english
11:26:30 <KipIngram> I'm just wondering what the earlier people were thinking.
11:26:34 <mark4> but is incorrect
11:26:55 <mark4> it would fail on any forth that defined false = 0 and true = 1
11:26:58 <KipIngram> Or you just have 0<>
11:27:23 <KipIngram> Little families of primitives like that are so compact it costs almost nothing to have them.
11:27:35 <KipIngram> Instant performance.
11:27:35 <mark4> and the fix was IN!!!!
11:27:44 <mark4> so the ans team totallhy fscked things up and UNfixed it
11:28:01 * KipIngram sighs
11:28:04 <mark4> 1: if it aint broke dont fix it
11:28:11 <mark4> 2: if its fixed dont break it
11:28:18 <KipIngram> I'm glad I didn't feel I had to track a standard.
11:28:38 <mark4> my forth is absolutely 100% x4 standard compliant :)
11:28:46 <mark4> guaranteed
11:28:58 <mark4> there is not ONE SINGLE ans standard forth that is 100% compliant
11:29:06 <mark4> because tahts a physical imposibility
11:29:12 <KipIngram> The sad thing is that one of the causes of all that might have been that person A made a snarky email or forum remark to person B, and person B was powerful on the committee and thought "I'll show you..."
11:29:29 <KipIngram> Anyone who things humans are above that kind of behavior doesn't have a clue.
11:32:43 <KipIngram> ;-)   Well, good job.
11:32:50 <KipIngram> Mine's compatible with nothing except my whims.
11:33:35 <KipIngram> I used to sling a lot of power around at work.  Small pond, but part of it was mine.  I control NOTHING at work these days.  This is my thing to control as I see fit.
11:34:14 <KipIngram> And that makes it something that I find working on to be incredibly relaxing.
11:34:31 <KipIngram> No timeline, no other cooks trying to muck with my stew.
11:36:16 --- quit: nighty- (Quit: Disappears in a puff of smoke)
11:42:11 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
11:45:08 <mark4> x4 was designed primarilly for ME to be able to develop linux applications in without even THINKING of C lol
11:45:36 <mark4> i think C is one of the single worst thing to ever happen to the software engineering field and yet is also one of the best things too
11:46:09 <mark4> kind of like the charli brown joke about "i love mankind, its just people i cant stand"
11:46:14 <mark4> I love c, its just c coders i cant stand :P
11:49:04 --- quit: nighty- (Ping timeout: 244 seconds)
11:49:11 <KipIngram> I'm fine with C.  Not an amateur, but also not a seasoned pro.  I can just "get around" as I need to.
12:10:45 <MrMobius> the great thing about C is we have optimizing compilers for it
12:11:32 <mark4> and i am diametrically opposed to any compiler making changes to the way I have expressed something simply because IT thinks it knows better
12:11:41 <MrMobius> heh
12:11:51 <MrMobius> then enjoy your massively slow code
12:11:57 <mark4> c's optimizers are nothing more than a kludge fix for the horrendously bad code they produce
12:12:14 <mark4> oh you mean my slow compilation of 4+ megs of source code per second?
12:13:08 <MrMobius> horrendously bad? you couldnt write better assembly in most cases on bigger architectures
12:13:16 <mark4> on my old laptop an emerge of libreoffice would take over 8 hours. if libreoffice were coded in forth it would take about 3 minutes to compile.
12:13:48 <mark4> MrMobius, thats incorrect, it has been shown that a code asm coder can almost always write better code than that produced by any c compiler
12:14:22 <MrMobius> and how much slower would that code be that took 3 minutes to compile?
12:14:45 <zy]x[yz> also do you have an implementation of libreoffice written in forth to make that claim, or is that just out of your ass?
12:14:58 <mark4> i was developing an android NDK forth and had some functions written in C (gcc) and dumped the asm and rewrote them.  my code was about 1/50th the size of what gcc puked out with optimizations on
12:15:08 <MrMobius> maybe on a 8051
12:15:13 <mark4> MrMobius, probably no slower
12:15:14 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
12:15:19 <mark4> maybe even faster in places
12:15:52 <mark4> zy]x[yz, im going by how much code there is to libreoffice
12:15:58 <mark4> and how fast i can compile that code
12:16:25 <mark4> or.. how fast i can compile a similar amount of code
12:16:48 <mark4> one of the things on my todo list is a random legal, syntatially correct forth source puker
12:17:12 <mark4> something that produces do nothing code that i can simply benchmark compile times with
12:17:31 <mark4> produce 400 megs of source code, time how long it takes to compile it
12:17:40 <mark4> not all in one file but in modules etc
12:18:11 <MrMobius> its amazing that you think that
12:25:11 * crc is happy to not obsess over how fast he can compile code
12:27:08 <mark4> its not an obsession, it was not a design requirement
12:27:47 <crc> I wouldn't benchmark the compile times
12:27:47 <mark4> its a result of the efficiencies wtithin my compiler and the language itself
12:28:04 <mark4> efficiencies that translat directly into code compiled by my compiler
12:31:20 <crc> my compiler doesn't optimize apart from inlining the primitives that map directly to single instructions and a few others that map to single instruction bundles
12:33:03 --- quit: gravicappa (Ping timeout: 250 seconds)
12:37:54 <presiden> I've read somewhere that some forth compiler do peephole optimization
12:39:06 <crc> presiden: I've seen some things on this
12:40:45 <mark4> marcel hendrix if thats how you spell his name, makes highly optimizing forth compilers
12:41:12 <crc> I dislike it as it make disassembly harder and the code less predictable
12:41:21 <mark4> exactly
12:41:29 <mark4> you lose the 1:1 corelation between source and object
12:43:22 <MrMobius> its fine to argue that you dont like optimization as long as you arent claiming that it is just as fast without optimization
12:49:49 <crc> I can (with a little knowledge of my system's design) reconstruct the source (sans formatting & comments) from a disassembly listing
12:50:07 <crc> MrMobius: I won't ever make that claim... :)
12:53:36 <crc> http://forth.works/8bbdacff8426320452516926a75b7bd7 (example disassembly from a word in WilhelmVonWeiner's code from earlier, and a variation on it)
12:54:14 <MrMobius> why would you want to do that though? to make sure it's producing good assembly?
12:57:11 <crc> (1) easier debugging and (2) I don't need more performance at present
12:59:06 <MrMobius> you debug by looking at the disassembly rather than the forth you wrote?
13:00:34 <crc> looking at disassembly is helpful at times, particularly while tracing execution and single stepping
13:05:10 <mark4> MrMobius, optimized C is not the most efficient object code, its optimzing at the opcode level, NOT at the function/algorithm level
13:05:35 <mark4> i can guarantee my code is at least as efficient, maybe more so than the equiv code written in optimized c
13:14:06 <MrMobius> mark4, thats just not true
13:14:13 <MrMobius> it gets optimized at both levels
13:14:30 <zy]x[yz> are you guys still arguing about this
13:16:14 <MrMobius> ya maybe we should stop arguing about this
13:16:40 <MrMobius> I will consider your argument when can show a nontrivial example of the same code written in forth and C where yours in faster
13:17:06 <zy]x[yz> it's just not productive when one side makes completely baseless claims
13:27:10 <mark4> MrMobius, look at my curses code example in x4, its at least as fast as libncurses, in some places faster and can do things that are almost impossible to do with libncurses and its 6 to 8k of object code as opposed to 500k++ of object code
13:27:59 <mark4> look at my memory manager smoke test and compare its speed with gcc's malloc/free
13:29:22 <mark4> the memory manager smoke test repeatedly allocates 20,000 buffers of random eize from 16 bytes to 16k and then frees them in random order
13:46:14 <the_cuckoo> mark4: what's the name of your project? is the code online somewhere?
13:46:35 <crc> the_cuckoo: https://github.com/mark4th
13:46:42 <the_cuckoo> cheers
13:46:51 <crc> x4 (formerly isforth) and t4
13:52:31 <mark4> its on github
13:52:39 <mark4> github.com/mark4th i think
13:52:42 <the_cuckoo> mark4: so - you check no bounds on your stack? you pop and push with complete faith?
13:52:47 <mark4> yea lol what crc said
13:53:04 <mark4> i trust the coder NOT to shoot himself in the foot
13:53:12 <mark4> there is a very old quote related to unix
13:53:29 <mark4> the unix operating system was not designed to stop you from doing stupid things beause that would stop you from doing clever things
13:55:23 <the_cuckoo> hmm - well, i suppose there is some truth to that :) - still, most complex systems are somewhat resillient to fault, and this resillience has a cost
13:55:38 <mark4> im SEMI working on x64 and a64 (aarch64)
13:55:58 <mark4> im not opposed to that cost if it is at compile time
13:56:12 <mark4> and no i didnt excluse these tests so i can claim my fast compile times lol
13:57:01 <the_cuckoo> no - it's about runtime - coders need to introduce some some kind of error detection at runtime 
14:01:38 <the_cuckoo> the c api for example provides a lot of checks and balances, though arguably, in arbitrary way - io stuff tends to have quite a bit while, memory use has little - but there are conventions - like, say, returning NULL on a malloc when an error occurs for example - blindly ignoring the return isn't a good idea
14:02:38 <mark4> C is mommy holding your hand, protecting you from you
14:02:48 <the_cuckoo> hmm
14:03:03 <mark4> NO!!!! You ant write taht BYTE data into that memory location because that memory location is reserved for CHAR data!!!
14:03:47 <zy]x[yz> wut
14:03:52 <zy]x[yz> what c are you using
14:04:12 <mark4> it was a contrived example lol
14:04:16 <mark4> of the sort of thing C does for you
14:05:31 --- quit: nonlinear (Remote host closed the connection)
14:05:52 <MrMobius> you can write any data there you want if you know how to use pointers
14:05:52 <zy]x[yz> in my experience, c will generally do what you ask unless you ask it to do something it /can't know how/ to do, e.g. dereference a void *
14:06:39 <the_cuckoo> let's assume you're right - you've turned on the highest level warning and are treating warnings as errors - fair?
14:07:39 <the_cuckoo> in that case, if you know what you're doing, you can cast your pointer to the type you want, and it's clear to anyone reading the code that this was intentional
14:08:25 <zy]x[yz> you shouldn't have to cast to assign an integer of one size to an integer of another size, even with the highest level of warnings as errors
14:08:28 <the_cuckoo> is that a bad thing? does it matter that it takes a little longer to compile?
14:08:37 <crc> I have C code to write to data in different sizes to arbitrary addresses in the retro/native vm. Not pretty, but works fine.
14:08:45 <the_cuckoo> zy]x[yz: sure - i'm continuing the contrived example :)
14:09:02 <zy]x[yz> but the example isn't contrived, it's straight up dishonest
14:09:37 <the_cuckoo> i'd go with mistaken or wrong, but either way, it's illustrative of mark4's thoughts
14:09:45 <zy]x[yz> i've seen c++ complain about stuff like that, but c++ is stupid
14:11:07 <the_cuckoo> c++ will rale aginst it for sure :) - but warnings mostly, unless you turn up the error/warning equivalence
14:11:44 <the_cuckoo> and again, you can cast, and while the compilation may take longer, it's clear that this was the intent, and again, i don't see any of that as a bad thing
14:14:26 <the_cuckoo> it's like this - if your code sets the precedent of anything goes, then the next guy comes along and goes 'wee... anything goes', but it's different set of anything goes to yours - a third person comes along and has a pretty hard time determining any kind of pattern and adds his own
14:14:56 <mark4> yes i can do foo = (xxxx) bar; but type casting is visual clutter. i dont even like the fact that there are data types at all
14:15:06 <mark4> cm says data types are a crutch for poor programmers
14:15:51 <the_cuckoo> they're visual clue and courtesy to both your memory and the understanding of others
14:18:00 <the_cuckoo> they set precedent and guide people toward consistent coding - as part of a team, rather than just that of an individual
14:18:31 <mark4> they impose the same set of rules on everyone, thus leveling the playing field
14:18:41 <the_cuckoo> yes
14:18:47 <mark4> or we can simply impose NO rules and thus have a naturally level playing field
14:19:31 <mark4> forth when done right is much easier to read and write than C is. i have 30 years as a consultant software engineer and thats almost always C based
14:19:58 <mark4> and most of the time the entire reason i am there is because of how badly someone wrote something
14:20:52 <mark4> i worked for a company in indianapolis and was given a project to clean up.  the build had over 4000 warnings and 3 errors and for some reason still produced the object code even WITH the errors in the build
14:20:56 <mark4> PIC dev tools?
14:21:10 <mark4> nobody knew about the errors because of all the warnings
14:21:35 <mark4> i set -werr -wall plus various other warnings enabled and slowly reduced it all down to ZERO warnings, ZERO errors
14:22:03 <the_cuckoo> i have spent a similar period in consultancy - i have worked in many domains and in many disciplines - proprietary, c, java, python, c++, assembly and a host of others
14:22:13 <mark4> i then took functions that had been hacked on and hacked on and hacked on and hacked on over the past 20 years to the point that NOBODY there knew what they did, totally refactored the code ...
14:23:13 <mark4> in the end the "filed" what i had done, sent me packing, shipped the code to the team in india who all went "ZOMG!!!!!!!!!!!" so they scrapped the project
14:23:22 <mark4> because it had been coded into oblivion
14:24:14 <mark4> after I refactored the code it was obvious to me what the code was doing, i had more of an understanding of that code than anyone else in the entire worldwide corporation.
14:24:46 <mark4> you hack on C code over 20 years and it goes to shit almost every time
14:25:01 <mark4> yes there are exceptions lol
14:25:37 <mark4> but over the past 30 years all the C code i have had to deal with tells me that either C is horrendously bad or most c coders are
14:25:43 <mark4> i think c encourages bad coding
14:25:54 <mark4> forth ALLOWS it. C encourages it
14:26:29 <the_cuckoo> an interesting take :) - i don't agree, but i don't care to argue the point either :)
14:27:29 <mark4> c lends itself to obfuscation and has quirks that a beginner might stumble over like the infamouse i+++++i thing
14:27:58 <mark4> a good example is my first ever c program where i did something like foo(bar(), bam());
14:28:09 <mark4> where bar and bam had to execute in a specific order
14:28:16 <mark4> and that order is undefined :)
14:28:37 <mark4> worked great when i left the project but there was no way that code was portable
14:28:39 <mark4> or even sane
14:29:18 <mark4> i.e. for THAT compiler on THAT architecture the call order was always going to be the same. move to a different compiler or different architecutre and all bets were off
14:29:26 <mark4> you dont have bullshit like that in forth
14:30:27 <mark4> C can have some very funky order of operation issues with math stuff too which is why you almost always ()((())()()(((((()))))) your c code
14:30:28 <MrMobius> this is a strange argument
14:30:34 <mark4> visual clutter
14:30:40 <MrMobius> people pay me to fix bad C code, therefore all C code is bad
14:30:40 <mark4> not really an argument
14:30:54 <mark4> not what i said. in fact i stated exactly the opposite
14:31:25 <mark4> im saying the c language encurages bad code
14:32:02 <mark4> but i have to go home now, ive goofed off enough lol
14:32:38 <the_cuckoo> have a good one :)
14:37:44 --- quit: mark4 (Ping timeout: 255 seconds)
14:47:18 <the_cuckoo> british politics is nuts :)
14:47:55 <the_cuckoo> fascinating watching, but jesus - wtf are they doing? 
14:53:03 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth
14:57:04 <Zarutian> the_cuckoo: you know how often old people get dementia? it is similiar
14:58:19 <the_cuckoo> could be - certainly seems like the old empire is sinking fast
15:01:00 <the_cuckoo> find it kinda sad
15:03:29 <the_cuckoo> at least there is the entertainment of their politics though - it's like fawlty towers, not the nine o'clock news, monty python as directed by david brent, john cleese and charlie chaplin
15:05:56 <the_cuckoo> (david brent is misplaced and a remnant of a bad edit - i stand by the rest)
15:17:11 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
15:17:34 <dave0> hi
15:17:57 <the_cuckoo> g'day dave0
15:18:06 <dave0> hi the_cuckoo 
15:23:54 <the_cuckoo> just spending the evening looking for sense in british politics - it requires a lot of looking... 
15:33:42 <zy]x[yz> the eu sucks the end
15:35:15 <the_cuckoo> belgium says hi :)
15:43:38 <the_cuckoo> i'll shut up :) - but before i do, i will clarify - i did mean it 'seems like it was sinking fast' not that it was - and i do find it sad - as a uk citizen abroad with friends and family, it concerns me deeply - i however, was only passing comment on the politics
15:44:39 <the_cuckoo> ('friends and family back home' was the intent there of course)
15:51:26 <zy]x[yz> i'm american.  you're not offending me
15:52:55 <the_cuckoo> heh - ok
15:54:38 <the_cuckoo> for what it's worth, you didn't offend me either - it was just the aggressive tone that made me think that i was offending you :)
15:58:32 <zy]x[yz> oh, that's just me
15:58:43 <the_cuckoo> np :) - and i did mean that about about being sad about the whole situation - it's ugly and uncertain - i'm pretty sure i'm fine (set up fairly well over here), but my thoughts are with those who are back home
15:59:12 <PoppaVic> let 'em eat cake
15:59:25 <the_cuckoo> i'll joke about it, but it can get personal if i argue it iyswim :)
16:00:39 <PoppaVic> I never argue about swimming
16:00:44 <the_cuckoo> :)
16:01:04 <the_cuckoo> that'd be going against the tide
16:01:23 <PoppaVic> I've a sinking feeling this is gonna' continue
16:01:45 <the_cuckoo> nah - think we've sunk this one
16:24:30 <the_cuckoo> plumbed the depths would have worked better
16:36:37 --- join: rdrop-exit (~markwilli@112.201.169.15) joined #forth
16:39:15 <rdrop-exit> Good morning Forthwrights c[_]~~
16:40:30 <dave0> hi rdrop-exit 
16:40:37 <rdrop-exit> Hi dave0
16:54:14 <rdrop-exit> Any Forth word of the day?
16:57:46 <rdrop-exit> KipIngram mentioned his Forth's TYPE was unusual
16:57:53 <rdrop-exit> Here's mine:
16:58:08 <rdrop-exit> 5
16:58:08 <rdrop-exit> 6 : (type) ( lim a -- ) ?stream  b@+ emit  onward ;
16:58:08 <rdrop-exit> 7
16:58:08 <rdrop-exit> 8 : type ( a # -- ) bounds (type) ;inline
16:58:08 <rdrop-exit> 9
16:59:06 <KipIngram> My TYPE is unusual?
16:59:09 <KipIngram> OH.
16:59:14 <KipIngram> I think I know what you mean.
16:59:26 <KipIngram> You're right - it *will* be unusual, in a sense.
16:59:45 <KipIngram> Right now I have an entirely "conventional" TYPE, and also have a _TYPe. 
16:59:48 <KipIngram> _TYPE.
16:59:55 <KipIngram> That's purely for short term developmental purposes.
17:00:07 <KipIngram> _TYPE has the formatted numeric output support integrated into it.
17:00:31 <KipIngram> I didn't want to make some stupid mistake and wind up with a broken system.
17:01:06 <dave0> : um+ ( u u -- d) 0 swap 0 d+ ;
17:01:08 <KipIngram> And yes, when I was describing the formatted output the other day, I *said* TYPE, not _TYPE.
17:01:38 <dave0> wtf is "onward" lol
17:01:53 <KipIngram> ?
17:02:08 <dave0> in rdrop-exit's paste line 6
17:02:46 <rdrop-exit> It's part of a streaming loop: ?STREAM ... ONWARD
17:03:04 <dave0> lol
17:04:16 <rdrop-exit> Similar to a DO ... LOOP but the parameters are on the limit and start parameters stay on the data stack instead of going to the return stack
17:04:41 <dave0> it's a cool name :-)
17:04:52 <rdrop-exit> Oops, leet me reword that...
17:05:26 <rdrop-exit> Similar to a DO ... LOOP but the limit and start parameters stay on the data stack instead of going onto the return stack
17:06:06 <rdrop-exit> A streaming loop is useful in conjuction with streaming operators such as @+ and b@+
17:06:37 <rdrop-exit> Thanks dave0
17:07:06 <KipIngram> I LOVE seeing how people choose their "groovy Forth names."  :-)
17:07:20 <rdrop-exit> Me too :)
17:08:05 <rdrop-exit> 5
17:08:05 <rdrop-exit> 6 onward  Complete a streaming loop that terminates when the loop
17:08:05 <rdrop-exit> 7         reaches the limit <lim>.
17:08:06 <rdrop-exit> 8
17:08:17 <rdrop-exit> 7
17:08:17 <rdrop-exit> 8 : onward { a*# # -- }( lim x -- {lim x}| )( r: a -- a| )
17:08:17 <rdrop-exit> 9   & (onward) converge ; directive
17:08:17 <rdrop-exit> a
17:09:00 <PoppaVic> KipIngram: I call it a THESAURUS ;-)
17:09:03 <crc> my equivalent to TYPE is:
17:09:17 <crc> :s:put (s-)  [ c:put ] s:for-each ;
17:11:14 <KipIngram> put is a good name.
17:11:32 <KipIngram> My TYPE is a primitive.
17:11:45 <KipIngram> I flipped the usual EMIT/TYPE relationship around.
17:12:00 <KipIngram> EMIT became a one-char TYPE, delivered directly from the top stack cell.
17:12:24 <KipIngram> I felt that would have a better shot at good performance when it came to updating full screens and so on.
17:12:56 <KipIngram> crc: You have some sort of hardware stack, right?  I'm not sure if that option would work for you.
17:13:24 <crc> KipIngram: yes, the emulated processor has hardware stacks
17:13:41 <crc> my EMIT analog is    :c:put (c-) hook #0 io:invoke ;
17:14:26 <crc> I don't assume that it's a screen; it could be a line printer or some other source
17:16:04 <rdrop-exit> On my host Forth emit writes to a buffer that later gets flushed, >TTY is the word I use to write to the console terminal.
17:16:05 <KipIngram> Right.  That's best.  It will probably take me a little while to hone mine down to that level.
17:16:35 <KipIngram> (reply to crc)
17:19:38 <rdrop-exit> My type is a primitive as well
17:22:09 <rdrop-exit> Correction (type) is the primitive
17:23:09 <rdrop-exit> brb
17:24:28 --- quit: rdrop-exit (Quit: Lost terminal)
17:26:06 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
17:40:06 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:40:19 <KipIngram> Hmmm.  I'm going to look at mine - it may be structured as TYPE and (TYPE) as well.
17:40:47 <KipIngram> I find that I frequently wind up with that struture given the way I stretch my control structures up and down in the call stack.
17:41:04 --- join: rdrop-exit (~markwilli@112.201.169.15) joined #forth
17:41:07 <rdrop-exit> back
17:41:10 <KipIngram> Actually, no - I don't on that one.
17:41:17 <KipIngram> TYPE directly does an OS system call.
17:58:29 --- quit: lchvdlch (Ping timeout: 250 seconds)
17:59:13 --- join: lchvdlch (~nestr0@191.98.151.137) joined #forth
18:01:09 <dave0> forth lets me have a truly awesome interface for    >digit (char -- n true | false)    where if the char is a valid digit it returns the value and true, and if it fails it just returns false
18:02:06 <dave0> i will use it everywhere it makes sense :-)
18:02:33 <PoppaVic> Use your powers only for Good, Jungean Jedi
18:07:40 <KipIngram> I'm always hesitant to have words that return a variable number of items.
18:07:46 --- quit: lchvdlch (Ping timeout: 246 seconds)
18:08:05 <KipIngram> FIG FIND was like that.
18:08:24 <KipIngram> Returned either a true flag and a couple of other cells - maybe a counted string, or just a flse flag.
18:08:43 --- join: lchvdlch (~nestr0@191.98.151.137) joined #forth
18:08:47 <rdrop-exit> Sometimes it's makes things easier, sometimes it gets in the way
18:08:52 <KipIngram> I set mine up so that it either returns TRUE and the *result* of the search or FALSE and a pointer to the string (which was the same pointer that was passed in).
18:08:54 <dave0> but you can   c@ >digit IF ( do something with the digit) ELSE ( print an error ) THEN
18:08:59 <KipIngram> But it's always 2 items.
18:09:18 <KipIngram> Sure - there are always local reasons for such things.
18:09:27 <KipIngram> You need to think about them in a global context as well.
18:09:50 <KipIngram> Variable stack effects complicate some of the things I'm hoping to do eventually.
18:10:59 <rdrop-exit> ?DUP deals effectively with most situations
18:11:24 <crc> I have 6 words that have varied stack effects:  0;  ?dup  case  s: case   reorder  class:data
18:11:45 <KipIngram> Yeah - ?dup sticks right out there like a sore thumb.
18:11:52 <KipIngram> And it truly is "handy."
18:12:13 <KipIngram> It's particularly handy in conection with some of my conditional returns.
18:12:18 <rdrop-exit> I also have +DUP and -DUP
18:13:11 <rdrop-exit> Similar to ?DUP but for positive and negative
18:13:54 <KipIngram> In the case of FIND, dave0, if the search succeeds, then the result is an address - of the word's symbol table index field.  If the search fails, the result is still an address - of the word's string.  The index field pointer is suitable for converting to a CFA and executing or compiling, and the string pointer is suitable for passing to NUMBER.
18:14:12 <KipIngram> so in that case it's just arranging for what comes next.
18:14:22 <KipIngram> But if you think about it, that is really sort of a questionable practice.
18:14:31 <KipIngram> Words should DO SOMETHING.
18:14:37 <KipIngram> Something specific and well-defined.
18:14:50 <KipIngram> Not just adapt themselves to the specific case they're being clled in right here right now.
18:15:38 <dave0> KipIngram: i was gonna do    find ( c-addr n -- xt true | false)    which takes a string and returns an xt and true if found or false if not found
18:15:50 <KipIngram> There's probably a better program structure for all of these things, that doesn't require a variable-format output, but we've done what we've done as an efficiency measure.
18:16:00 <dave0> i think it's better because maybe 0 for xt is valid
18:16:12 <dave0> maybe 0 is a valid xt
18:16:22 <rdrop-exit> unlikely
18:16:56 <dave0> ( c-addr n -- xt | 0)   is also a nice interface
18:17:38 <rdrop-exit> My FIND alternatives return the link address, {la -1}|0
18:19:03 <rdrop-exit> Variable output works well when you're going to immediately follow the call with an IF
18:19:18 <KipIngram> Hmmm.  That would be an unusual processor.
18:19:32 <KipIngram> I'd expect 0 to reset, or be part of the interrupt vector table, or something.
18:19:46 <KipIngram> Of course some aspects of the "knowledge" that leads me there is 30 years old.
18:20:08 <KipIngram> Yes, they work *efficiently*.
18:20:20 <KipIngram> But you really can't claim you're factoring out a generally useful word.
18:20:23 <crc> my `d:lookup` returns either a pointer to the dictionary header or 0 if not found.
18:20:57 <KipIngram> I think it makes great sense for FIND to give you back the same string pointer you gave it, if the search fails.
18:21:03 <KipIngram> That's what you want to pass to NUMBER.
18:22:07 <KipIngram> So find fails, and returns false.
18:22:10 <KipIngram> What do you do now?
18:22:24 <crc> report an error 
18:22:49 <KipIngram> Oh, well, I figured the answer was try for a number.
18:22:49 <crc> numbers in mine are handled by a prefix handler
18:23:07 <KipIngram> But error recovery resets a bunch of stuff, so in that case it doesn't really  matter what the exact stack config is.
18:23:16 <KipIngram> Ah, I see.
18:23:26 <rdrop-exit> 1
18:23:26 <rdrop-exit> 2 : interpreter ( -- ? )
18:23:26 <rdrop-exit> 3   interpretation lookup if
18:23:26 <rdrop-exit> 4    >code execute
18:23:26 <rdrop-exit> 5   then;  number ; compiled
18:23:28 <rdrop-exit> 6
18:23:50 <rdrop-exit> In the above code LOOKUP is my FIND alternative
18:24:05 <crc> if the token starts with a prefix, it's passed to the corresponding prefix handler; if not, it's passed to d:lookup
18:24:15 <KipIngram> I see.
18:24:21 <KipIngram> I thought about thins like that.
18:24:30 <KipIngram> Do you also remove the space between : and word name?
18:24:38 <KipIngram> That's how I saw it coming in.
18:24:52 <KipIngram> I was going for something very general, like this:
18:24:59 <KipIngram> var:<name>
18:25:02 <KipIngram> const:<name>
18:25:07 <KipIngram> voc:<name>
18:25:10 <KipIngram> :<name>
18:25:23 <KipIngram> the last case just has NULL as a handler.
18:25:36 <KipIngram> And we'd use that for : defs.
18:26:11 <crc> KipIngram: yes; I have no forward parsing words
18:26:24 <KipIngram> At that point in time I was trying to conceive a VERY minimal C program that could start reading a text file, and would wind up generating your entire system image.
18:26:35 <crc> prefixes are just one character though
18:26:42 <KipIngram> Clean.
18:27:00 <KipIngram> Forward parsing here and there has a lot of "utility," but it does add a "concept" to the system.
18:27:10 <crc> http://forth.works/book.html#prefixes
18:27:30 <KipIngram> I bet dollars to donuts it wouldn't be terribly hard for you to make them multi-char.
18:27:34 <crc> (book is a work in progress)
18:27:45 <KipIngram> As a "concept" it still stands strong.
18:27:51 <PoppaVic> KipIngram: sure, you just advance 1+prefix len
18:27:58 <KipIngram> After all, you already know how to parse words.
18:27:59 <crc> I could, but haven't needed to yet
18:28:07 <KipIngram> Right.
18:28:39 <KipIngram> That's not awfully far from what Chuck did with ColorForth.
18:28:47 <KipIngram> He set a color (prefix) and typed a word.
18:28:52 <crc> yes
18:29:00 <KipIngram> It just didn't show up as a string on the screen.
18:29:53 <KipIngram> Wow - a couple of the guys I chat with in another channel (one in particular) just really lost their you-know-what over colors having "input meaning" to the system.
18:30:02 <KipIngram> They just couldn't wrap their heads around that.
18:30:05 <crc> this is similar to a non-colored colorforth, but with conventional source rather than a custam format and editor
18:32:58 <rdrop-exit> I played around with the Color Forth approach, but in the end I concluded I prefer a word to be a plain word
18:33:35 <Zarutian> words are colourfull characters in of themselfs, no?
18:33:46 <rdrop-exit> :)
18:34:58 <KipIngram> I think the main objection the guys I'm referring to had was really just "that's a bigger step than I'm comfortable taking."
18:36:07 <KipIngram> Though there's no way I could have said that out loud over there, right PV?
18:36:08 <ttmrichter> KipIngram: There are loads of reasons not to want colours to be part of the syntax and semantics of programming.
18:36:18 <KipIngram> Rage would have ensuied.
18:36:34 <KipIngram> Well, a good one for me is that not everyone can SEE colors.
18:36:39 <ttmrichter> The first thing that leaps to mind would be ... colourblind?  Straight-up blind?
18:36:47 <KipIngram> ^
18:36:48 <ttmrichter> Yeah, that right there.
18:36:49 <KipIngram> Right.
18:36:52 <Zarutian> "I see your problem right here, this is supposed to be maroon and not just red"
18:36:57 <PoppaVic> I can see brass, or lead.
18:37:13 <KipIngram> If I were implementing it, I'd just have it all be "config options," and color woul dbe just one way to express it.
18:37:19 <KipIngram> I think Chuck's said as much.
18:37:26 <KipIngram> That stops that argument cold, right there.
18:37:35 <PoppaVic> KipIngram: Some folks have blinders, some have rose-colored glasses.
18:37:40 <ttmrichter> Then we get into the emacs problem.
18:38:01 <ttmrichter> Everybody has so configured their environment up the wazoo that nobody can use it but they themselves.
18:38:22 <PoppaVic> Frankly, I do use color/highlighting in most editors now - but I almost always have to customize them for contrast and blind-guy fonts.
18:38:35 <ttmrichter> Hell, I use Rexx scripts in my build process and this has people screaming.  Picture if I had configurable colour options instead.  :D
18:38:51 <KipIngram> Oh, lots of people are fine with color OUTPUT.
18:38:55 <KipIngram> Syntax highlighting.
18:38:59 <PoppaVic> yup
18:39:00 <KipIngram> That bothers almost no one.
18:39:09 <ttmrichter> Because it doesn't impact what the code means.
18:39:17 <PoppaVic> KipIngram: well, the default schemes are almost invariably total trash
18:39:21 <ttmrichter> And you can always just cat <filename>.
18:39:28 <PoppaVic> 'less'
18:39:34 <KipIngram> Yes - that ^.
18:39:49 <ttmrichter> Try cat <colorforth-filename>...  :D
18:40:01 <PoppaVic> I'd really rather not ;-)
18:40:15 <ttmrichter> I mean I get what Chuck was going for, but I think his approach was wrong.
18:40:45 <ttmrichter> There was another language that used formatting ... I want to say Eiffel, but I'm not sure? ... and it tanked hard for similar reasons.
18:41:11 <PoppaVic> CM is a special guy spinning in his own pocket-universe - and I wish him only well, as well as accept he was hugely productive. I just do this shit for fun.
18:41:17 <KipIngram> I remember the name.
18:41:19 <KipIngram> No details.
18:41:27 <Zarutian> APL?
18:41:34 <rdrop-exit> I remember Eiffel, had the book
18:41:42 <KipIngram> Chuck has at least a bit of a compulsive nature in him.  
18:41:54 <PoppaVic> KipIngram: a wee bit?
18:42:13 <KipIngram> There is that principle that "even if some is good, more isn't always better."
18:42:35 <KipIngram> A wee.
18:42:49 <PoppaVic> Hey, as long as he never forced his shit on everyone else - like the GNU's have forever - more power to him
18:43:08 <ttmrichter> Yeah, I like Chuck.
18:43:10 <PoppaVic> gnu's and gnomes - stop screwing my fucking desktop and setups!
18:43:33 * Zarutian will kvetch at anyone that brings up 'licenses' discussion.
18:43:36 <ttmrichter> Can't say I like the extraverted ideologues.
18:49:47 <KipIngram> All these things just become vehicles to gathering power / influence / celbrity.
18:55:39 <rdrop-exit> The Dude abides
18:58:24 <KipIngram> lmao
18:58:36 <KipIngram> Absofreakinglutely.
19:00:12 <ttmrichter> KipIngram: What amuses me endlessly is things like how BernieBros to an alarming degree voted Trump when Sanders wasn't the Democrat candidate in the USA.  It's clear from this that their interest was NOT Sanders' politics or policies, given that something like 15% of them shifted to Trump, an almost polar opposite.  Their interest was purely sidin
19:00:12 <ttmrichter> g with the "winner" who would give them power over others in some way or another.
19:01:07 <KipIngram> Or maybe they just hated Hillary.
19:01:11 <ttmrichter> I think the real conflict in politics is not "left vs. right" (the bizarre fascination people have with French government's physical layout from the 18th century) but "control" vs. "independence".
19:01:24 <KipIngram> I doubt there's any really sound way to draw conclusions.
19:01:44 <PoppaVic> hire some more liberals to poll their friends ;-)
19:01:49 <rdrop-exit> 9
19:01:49 <rdrop-exit> a : abide ( e -- )
19:01:49 <rdrop-exit> b   " Uncaught Exception..." alert  execute ; compiled
19:01:49 <rdrop-exit> c
19:02:34 <PoppaVic> Man, a hot shower is nice - not as good as soaking in a big tube with a paperback, but.. nice
19:02:41 <PoppaVic> tube/tub
19:02:46 <KipIngram> OH THAT IS GREAT.
19:02:52 <KipIngram> I have to come up with an abide for mine.
19:03:21 <rdrop-exit> I was ecstatic when I finally figured out a way to have ABIDE in my Forth
19:03:29 <KipIngram> Strangely, PV, that made sense either way.
19:03:39 <KipIngram> I bet.
19:21:17 --- join: tabemann (~tabemann@2600:1700:7990:24e0:35d8:344b:3716:9530) joined #forth
19:25:48 --- quit: X-Scale (Ping timeout: 244 seconds)
19:25:53 --- join: X-Scale` (~ARM@223.10.108.93.rev.vodafone.pt) joined #forth
19:26:23 --- nick: X-Scale` -> X-Scale
19:49:15 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
20:12:41 --- quit: pierpal (Quit: Poof)
20:12:59 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
20:22:19 --- quit: rdrop-exit (Quit: Lost terminal)
21:05:20 --- join: gravicappa (~gravicapp@h109-187-213-103.dyn.bashtel.ru) joined #forth
21:21:18 --- join: proteusguy (~proteusgu@110.164.217.65) joined #forth
21:21:18 --- mode: ChanServ set +v proteusguy
21:49:43 --- quit: dddddd (Remote host closed the connection)
22:25:29 --- quit: proteusguy (Ping timeout: 246 seconds)
22:39:04 --- join: proteusguy (~proteusgu@110.164.217.65) joined #forth
22:39:04 --- mode: ChanServ set +v proteusguy
22:50:27 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
22:52:59 --- quit: MrMobius (Ping timeout: 244 seconds)
22:53:00 --- nick: [1]MrMobius -> MrMobius
23:59:59 --- log: ended forth/19.03.27