00:00:00 --- log: started forth/19.03.23
01:00:35 --- quit: Keshl__ (Quit: Konversation terminated!)
01:14:20 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
01:35:19 --- join: dys (~dys@tmo-116-37.customers.d1-online.com) joined #forth
02:02:54 --- quit: ashirase (Ping timeout: 252 seconds)
02:10:28 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:17:49 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
02:20:29 --- quit: MrMobius (Ping timeout: 246 seconds)
02:20:29 --- nick: [1]MrMobius -> MrMobius
04:59:19 --- quit: pierpal (Remote host closed the connection)
05:12:59 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
05:55:58 <WilhelmVonWeiner> good morning forth 
06:01:40 --- quit: dys (Ping timeout: 245 seconds)
06:08:14 --- join: dys (~dys@tmo-085-126.customers.d1-online.com) joined #forth
06:32:28 <crc> good morning 
07:06:34 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
07:10:17 <WilhelmVonWeiner> need to write me a DSL to generate XML this weekend
07:10:25 <WilhelmVonWeiner> I am sick of having to write xml
07:22:29 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
08:14:15 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
08:16:07 --- quit: dave0 (Quit: dave's not here)
08:22:13 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
10:03:27 --- join: proteusguy (~proteusgu@cm-58-10-208-131.revip7.asianet.co.th) joined #forth
10:03:27 --- mode: ChanServ set +v proteusguy
11:28:27 --- quit: nighty- (Quit: Disappears in a puff of smoke)
11:41:12 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth
13:13:35 --- quit: gravicappa (Ping timeout: 255 seconds)
14:02:08 --- quit: tabemann (Ping timeout: 250 seconds)
14:20:45 --- join: tabemann (~tabemann@71-13-2-250.static.ftbg.wi.charter.com) joined #forth
14:42:52 <KipIngram> Ok, got in pretty slick support for vocabularies:
14:42:54 <KipIngram> https://pastebin.com/Z4th3MKi
14:44:25 <KipIngram> path: and ;path provide a mechanism like the one we've discussed here - path: opens me a completely new bare context (just FORTH) for me to do with as I please.  Then ;path drops that entirely and leaves me with whatever existed before path:.
14:46:49 <tabemann> I should implement something like that for hashforth
14:47:01 <KipIngram> I might decide that I prefer to inherit a copy of the previously existing context rather than get a bare one.
14:47:41 <KipIngram> That way the external environment could pass in a chosen implementation of a set of words.
14:47:58 <KipIngram> Like debug vs. performance or something like that.
14:49:09 <tabemann> in hashforth's implementation I end up doing something in a lot of source files where I start each source file with get-current get-order base @ and end it with base ! set-order set-current
14:49:30 <tabemann> which implies some kind of stack may be desired
14:50:09 <KipIngram> Yes, my CONTEXT is a stack.
14:50:23 <KipIngram> Implemented in a memory range.  It's just an array of cells.
14:50:36 <KipIngram> CONTEXT[0] points to the "top" used cell.  
14:50:44 <KipIngram> CONTEXT[1] is zero.
14:50:59 <KipIngram> CONTEXT[2] is FORTH, and that's where CONTEXT[0] initially points.
14:51:14 <KipIngram> Executing a vocabulary word just pushes it to that stack.
14:51:24 <KipIngram> path: pushes a 0 followed by FORTH again.
14:51:35 <KipIngram> ;path just pops until it pops a zero.
14:51:56 <tabemann> I rely on the words GET-ORDER SET-ORDER GET-CURRENT SET-CURRENT and WORDLIST
14:52:09 <KipIngram> oops? provides protection in case I ;path without having path:'d or -voc my only copy of FORTH.
14:53:32 <KipIngram> My word search crawls down that stack until it either finds the word of finds a 0 cell in the stack.
14:54:41 <KipIngram> I'm also considering a word -forth that will remove the copy of FORTH from the current context.
14:54:53 <KipIngram> That would let me set up "kiosk" style things with limited command sets.
14:55:05 <KipIngram> Unless the command set provided a way out, you'd be stuck there forever.
14:55:35 <tabemann> for me that's simple - execute SET-ORDER without FORTH-WORDLIST in the provided order
14:55:44 <KipIngram> Right. 
14:56:00 <KipIngram> But mine "defaults FORTH in," so I'd need a way to remove it.
14:56:27 <tabemann> it's too simple, actually - I've had to restart hashforth at times just because I accidentally forgot to include FORTH-WORDLIST in the order
14:56:59 <KipIngram> Well, but that's really what you want to be ABLE to do.
14:57:07 <KipIngram> You just usually don't want to do it.  :-)
14:57:48 <KipIngram> The question would be what would I put in that cell.  Possibly another zero, but I'd have to make sure the other words were prepared to encounter more than one.
14:57:53 <KipIngram> Possibly a copy of the voc right above it.
14:57:59 <KipIngram> So what if you search that one twice.
14:58:26 <KipIngram> In old FIG Forth the search of a single vocabularly rolled on back through Forth - vocabularies just "sprouted" from the Forth word list.
14:58:41 <KipIngram> Mine doesn't work that way - searching one voc searches ONLY that voc.
14:59:07 <tabemann> hashforth has separate notions of wordlists and a wordlist order
14:59:34 <KipIngram> Well, I guess I have that too; the order is captured in the context stack.
15:01:00 <KipIngram> I really need to add .variable and .constant to my .: / .wipe setup.
15:01:14 <KipIngram> I love hiding these defs with .:, but I need to be able to hide the other little stuff too.
15:01:21 <tabemann> the wordlist order could be treated like a stack, except that GET-ORDER dumps the entire wordlist order out onto the stack and likewise the SET-ORDER reads the entire wordlist order from the stack
15:01:51 <KipIngram> Oh - variable size entities on the stack?  Um, ew.
15:02:23 <tabemann> well they could be hidden behind other words
15:03:42 <KipIngram> So, mark4 and crc - I apologize, but I always forget which one of you two has the various cools things.  Which one of you had the nifty setup for managing search contexts?
15:04:03 <KipIngram> When you open a new "context frame," is it bare and you build it, or do you inherit from the next level out?
15:06:17 <KipIngram> Oh, what this implementation is NOT doing right now is checking to see if an invoked vocabulary is already in context, and if it is move it to the top.
15:06:21 <KipIngram> I just get two copies.
15:06:36 <KipIngram> I don't think it makes a huge difference, but it's... inefficient.
15:07:01 <tabemann> I don't check for multiple copies of a wordlist in the wordlist order myself
15:07:19 <KipIngram> I can't really think of any harm it would do.
15:07:50 <KipIngram> Though I can concoct a way for it to make a differernce.
15:08:09 <KipIngram> If I invoke a voc for a second time and then run -voc, I just drop the second copy, but the first copy is still there.
15:08:25 <KipIngram> If I were moving to the top that would be dropping the only copy of that voc, and things would be different.
15:09:09 <KipIngram> So I guess if I had that feature I could remove any voc from my context with voc -voc.
15:09:15 <tabemann> I'd just keep the second copy myself
15:09:15 <KipIngram> <voc> -voc rather.
15:09:39 <KipIngram> The code to do that would be at least a little tedious, and I'm so happy with how concise and clean this turned out.
15:10:43 <KipIngram> I really don't like *moving* stuff around in RAM.
15:15:37 <tabemann> in attoforth I had MOVE as a primitive because MOVING things in Forth is, well, expensive, relatlvely
15:16:15 <tabemann> in hashforth because I didn't care about speed I implemented CMOVE and CMOVE> in Forth, and implemented MOVE in terms of those
15:16:37 <KipIngram> Yes, I wrote cmove and <cmove as primitives.  I'e yet to implement move and <move, but they'll be primitives to.
15:16:55 <KipIngram> Can't miss out on that rep movs facility - it's one of x86's niftiest things.
15:17:13 <KipIngram> In fact, I actually chose rcx for my TOS register so that the counts would already be in the right place.  ;-)
15:19:57 <KipIngram> I really couldn't think of any other compelling reason to choose a particular one.
15:24:29 <PoppaVic> KipIngram: the only reason for move/<move in ADDITION to byte variant is: aligned, fat cell-slamming. I doubt it's worthwhile.
15:25:15 <KipIngram> Well, later when I have that general heap-based numerical environment and am dealing with big arrays it might be worth picking up that factor of EIGHT.
15:25:56 <KipIngram> But I won't be making a MOVE that will handle things that aren't a multiple of the cell size.
15:26:11 <KipIngram> Some implementations I've seen handle the odd bytes at the beginning or the end with an extra little bit of code.
15:26:17 <KipIngram> No - just use  CMOVE.
15:26:27 <tabemann> MOVE is byte-aligned, CMOVE is supposed to be character-aligned but that's only different on implementations with non-byte characters (but the real difference on byte-character impls. is that MOVE tests for overlapping buffers)
15:26:52 <KipIngram> Oh, really?
15:26:52 <tabemann> well, MOVE is address-aligned
15:27:04 <KipIngram> I thought that's why you had MOVE and <MOVE.
15:27:11 <KipIngram> So you could use the one that was right for your situation.
15:27:42 <KipIngram> I'll implement MOVE as cell-aligned.
15:28:58 <KipIngram> In other words, it'll just be a copy of my CMOVE code, with rep movsq instead of rep movesb.  I may even let the count be a cell count; I'm not sure what's assumed in the standard for that.
15:30:26 --- join: tabemann_ (~tabemann@24.196.100.126) joined #forth
15:30:41 --- quit: tabemann (Disconnected by services)
15:30:47 --- nick: tabemann_ -> tabemann
15:32:55 <reepca> ]\ b]
15:36:09 <tabemann> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Memory-Blocks.html
15:37:15 <tabemann> ANS Forth at least doesn't seem to have <MOVE but rather character-oriented CMOVE and CMOVE>, which differ in the direction they copy, and address-oriented MOVE, which is smart and copies overlapping blocks properly
15:55:41 <tabemann> bbiab
16:00:05 --- quit: tabemann (Ping timeout: 255 seconds)
16:26:20 --- join: tabemann (~tabemann@rrcs-98-100-171-35.central.biz.rr.com) joined #forth
16:43:16 <KipIngram> Cool - got .var and .const in place - now I can have temporary words of all flavors.
16:48:31 <PoppaVic> until you add a new flavor ;-)
16:49:08 <john_cephalopoda> How about cheesecake?
16:57:37 <the_cuckoo> cheesecake is horrible
16:58:24 <the_cuckoo> right up there with anchovies - similar texture at least
17:05:42 <tabemann> I can't see how one can compare cheesecake with anchovies... anchovies are supersalty with lots of little bones, not things I associate with cheesecake
17:21:56 <the_cuckoo> they just freak me out - as does cheesecake
17:23:58 <the_cuckoo> i don't necessarily think that the associations you make in your mind need be rational to another :) - it's why i end up with &{ [ +> ... { } ] * etc } as a case statement
17:24:34 <the_cuckoo> :p
17:26:24 <KipIngram> Well, actually I already have another flavor - I just did the vocabulary stuff today.
17:26:53 <KipIngram> But vocs won't "slide in" as easy as vars and consts did, and I have to wonder, will I really find myself wanting "temporary vocabularies"?  
17:27:00 <KipIngram> Maybe I will, but I think I'll wait and see.
17:27:15 <KipIngram> They're different because they have a second PFA in the header.
17:27:31 <KipIngram> (as does any word arising from DOES> defining words).
17:27:53 <KipIngram> In my system, I mean.
17:30:22 --- quit: john_cephalopoda (Ping timeout: 268 seconds)
17:43:22 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:59:03 --- quit: tabemann (Ping timeout: 250 seconds)
18:02:53 --- quit: dys (Ping timeout: 272 seconds)
18:27:05 --- join: jedb_ (~jedb@103.254.153.113) joined #forth
18:27:26 --- quit: jedb_ (Remote host closed the connection)
18:27:39 --- join: jedb_ (~jedb@103.254.153.113) joined #forth
18:29:49 --- quit: jedb (Ping timeout: 250 seconds)
18:57:45 --- nick: jedb_ -> jedb
18:59:24 <crc> KipIngram: that's probably mark4; I have no search contexts in my system
19:19:06 <KipIngram> Ok, thanks.  Anyway, it was those ideas that inspired me, and I suddenly realized today there was a really clean way to roll them into what I'd already planned.
19:19:46 --- quit: ashirase (Ping timeout: 250 seconds)
19:19:54 <KipIngram> Anytime you can get a major new system functionality with just 15 short lines of code, you know things hav broken your way.  :-)
19:21:54 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
19:32:03 <KipIngram> Ah, you know, I think I will split the difference on how to intialize a new context space.
19:32:39 <KipIngram> I will have it do what it's dong now - start out just with FORTH, but will provide a word PARENT that will modify my space into a copy of the next outer context space.
19:33:11 <KipIngram> PATH: PARENT <voc I need> <voc I need> <voc I need>
19:33:13 <KipIngram> ... code
19:33:15 <KipIngram> ... code
19:33:17 <KipIngram> ... code
19:33:20 <KipIngram> ;PATH
19:34:00 <KipIngram> Any suggestions for better names than PARENT?
19:34:47 <KipIngram> I still plan to add -FORTH to prune FORTH out of the search space.
19:39:21 <PoppaVic> PREDICATE   PRIOR  REQUIRE   
19:39:53 <PoppaVic> PREDICATES - with the S is quite applicable
19:40:30 <KipIngram> PRIOR is definitely reasonable.
19:46:21 <KipIngram> Hah!  My wife suggests ccat (short for "copycat.")  8-D
19:46:33 <KipIngram> Obviously I'm not doing that, but it's cute.
19:48:15 <KipIngram> PoppaVic: I think I like PRIOR better than PARENT.
19:51:52 <PoppaVic> or pretend yer a cop and use PRIORS ;-)
20:00:16 <KipIngram> Oh, cute.
20:00:23 <KipIngram> :-)
20:00:33 <KipIngram> that fits well also.
20:00:53 <KipIngram> I decided that OOPS? was my "word of the day."
20:05:00 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
20:06:03 <dave0> hi
20:19:12 --- join: tabemann (~tabemann@2600:1700:7990:24e0:35d8:344b:3716:9530) joined #forth
20:21:10 <KipIngram> hi dave0
20:21:50 <dave0> hi KipIngram 
20:21:53 <dave0> sup?
20:22:06 <KipIngram> Oh, good day.
20:22:10 <KipIngram> Vocabulary support!
20:22:23 <KipIngram> Added variables and constants to my "temporary definitions" system.
20:22:34 <dave0> cool!
20:22:54 <KipIngram> Got a little more to do on the vocabs, but the major portion is working.
20:23:06 <KipIngram> And it went into place so easily - only 15-16 short lines of code.
20:23:22 <KipIngram> A day or two ago I added DOES> support, but I think you may already know that.
20:23:31 <KipIngram> And then used that today for the vocs.
20:24:17 <dave0> i looked at qemu and openbios.. it has a forth in it, and it's standardised... i'm going to try and find that standard
20:24:32 <dave0> i'm pretty sure it's called "open bios"
20:24:54 <KipIngram> Ah, neat.  I didn't know open bios was Forth based.
20:25:01 <KipIngram> Oh, I found a flaw today too, and fixed it.
20:25:03 <dave0> i'll double check
20:25:07 <KipIngram> You know how I've got that symbol table?
20:25:18 <KipIngram> My name strings live there, instead of in the defintion headers.
20:25:23 <KipIngram> The headers contain a symbol table index.
20:25:33 <KipIngram> So, when I fail to find a word, there are two ways that can happen.
20:26:00 <KipIngram> It can a) not be in the symbol table, or b) be in the table, and thus give me and index, but then that index is not in any of my context vocabularies.
20:26:12 <KipIngram> Well, historically I pretty much NEVER failed the second way.
20:26:29 <KipIngram> I didn't have vocabularies, and once I defined a word it was there for good.
20:26:49 <KipIngram> But recently I added those temporary defs, and today vocabularies, so it's becoming possible for a word to be in the symbol table but not in the dictionary.
20:27:11 <KipIngram> Eventually I'll have usage counts in my symbol table entries, but that could still happen, if a name is used more than once across the system.
20:27:21 <KipIngram> So anyway, my FIND would first search the symbol table.
20:27:39 <KipIngram> If it doesn't find my string there, that's a fail, and it returns 0 and a pointer to the name string that I passed in.
20:28:18 <KipIngram> If it finds the word in the table, it replaces the string pointer stack parameter with a pointer to a cell holding the symbol table index, and I then search the dictionary for that.
20:28:22 <KipIngram> If I find it, no problem.
20:28:30 <KipIngram> But if I don't find it, my next step is to call NUMBER.
20:28:41 <KipIngram> I was passing a pointer to that *index* - an INTEGER - into NUMBER.
20:28:45 <KipIngram> Obviously that's wrong.
20:29:00 <KipIngram> Most of the time it just throws an error, which is the desired right outcome anyway.
20:29:08 <KipIngram> But the possibility exists for obtuse weird corner cases.
20:29:16 <KipIngram> I ran into one of those while working on the vocabulary stuff.
20:29:29 <KipIngram> The solution was to put DROP PAD right before the call to NUMBER.
20:29:35 <PoppaVic> so, you have a nice clean word that can take the word in LAST and stuff it into a voc now? ;-)
20:29:38 <KipIngram> The existing parameter MIGHT point to PAd, but it might not.
20:29:41 <KipIngram> So I need to make sure.
20:29:50 <KipIngram> All the weird behavior vanished when I did that.
20:30:01 <KipIngram> LAST?
20:30:04 <KipIngram> You mean LATEST?
20:30:24 <KipIngram> I don't know if my voc stuff is working exactly the way you imagine, but it's working very cleanly.
20:30:30 <KipIngram> I haven't found any problems with it so far.
20:31:27 <PoppaVic> yeah
20:31:57 <PoppaVic> LATEST, sorry - it's just I been thinking "well, why the fuck not just [re]link the latest word?
20:32:28 <KipIngram> Well, that's exactly what it does.
20:32:45 <KipIngram> LATEST is the most recent word in the CURRENT vocabulary, so that's the one you want to link to when you create a new word.
20:33:08 <KipIngram> All the stuff I just described was stuff that happens during the search process, not when we're creating a header.
20:33:14 <PoppaVic> ah, I thought of LATEST as the "latest word defined" - silly me ;-)
20:33:42 <KipIngram> Close, but not quite.  Latest in the vocabulary you're buidling onto right now.
20:33:53 <KipIngram> Well, I don't know if that's standard or not.
20:33:56 <KipIngram> But it makes sense to me.
20:34:21 <KipIngram> It's a convenience word anyway.
20:34:56 <KipIngram> Really you want CURRENT @ @ for the latest word in the definition voc, and CONTEXT @ @ (and one more @ for me, given how I implemented CONTEXT) for the "first word in your search order."
20:34:58 <KipIngram> )
20:35:05 <PoppaVic> You just KNOW I am sitting here with a HUGE grin going: "yup, uhuh, sure ;-)"
20:35:07 <KipIngram> s/)//
20:35:24 <KipIngram> :-)  I've been immersed in it the last few days.  Sorry about that.  :-(
20:35:32 <KipIngram> It's easy when you have it all thoroughly in mind.
20:35:55 <KipIngram> It's Forth, not quantum electrodynamics.
20:36:08 <KipIngram> Easy is the name of the game.
20:37:17 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
21:08:47 <siraben> What is that optimization technique called that simulates parallel arithmetic by using a single register?
21:08:57 <siraben> e.g. I can add 3 and 5, and 1 and 8 simultaneously if I do
21:09:28 <siraben> 31 + 58 (in hex of course)
21:09:34 <siraben> And extract the values out as needed
21:09:47 <PoppaVic> "lucky"
21:11:58 <siraben> Ah it's https://en.wikipedia.org/wiki/SIMD
21:15:17 <siraben> So you could perform 8-bit vector (x,y) arithmetic with just 16 bit register operations
21:17:11 <siraben> (1,2) + (3,5) and so on, Forth could easily support that
21:17:11 <siraben> P+ P- P-SCALE P. (adding, subtracting, scaling and printing 2D points)
21:28:56 <siraben> Just an interesting idea.
21:37:41 --- join: gravicappa (~gravicapp@h37-122-117-136.dyn.bashtel.ru) joined #forth
21:40:46 <KipIngram> I want to support those instructions in some nice way at some point.
21:40:54 <KipIngram> Haven't even BEGUN to look at it, though.
21:41:15 <KipIngram> A good graphics card interface, for numerical computing, would be nice too.
21:41:36 <KipIngram> PoppaVic: I am going with PRIORS.  I just LIKE it.  Thanks.
21:41:54 <KipIngram> Speaks to the mischief in me.
21:42:20 <KipIngram> Just got that working, actually.
21:47:16 <PoppaVic> np, enjoy ;-P
21:54:51 <KipIngram> My wife's ok with me not picking ccat.  She knew she was just being silly. 
21:55:25 <PoppaVic> she's so generous
21:55:27 <tabemann> back
21:55:30 <KipIngram> :-)
21:55:30 <tabemann> hey guys
21:55:37 <KipIngram> Hey tabemann.
21:56:08 <KipIngram> So, it looks like all the places I'm pushing a new voc to the stack I'm calling voc.x, the primary runtime for when you execute a voc word.
21:56:33 <KipIngram> So I can just tuck an extra word into that to implement the "remove deep copies of the new top voc" if I want to.
21:56:38 <KipIngram> And it should apply everywhere.
21:56:51 <tabemann> is it me, or does the business about Beto O'Rourke having been a member of the cDc make it *more* likely that I'd vote for him?
21:57:49 <KipIngram> cDc?  The only thing I know for that is Centers for Disease Control, but that can't be what you're referring to.
21:58:09 <tabemann> even if all he did was write screeds, run a BBS, talk about punk rock, engage in phreaking, and pirate games
21:58:18 <tabemann> Cult of the Dead Cow
21:58:30 <KipIngram> He was a kid at some point - we should allow him to have behaved as one.
21:58:54 <tabemann> that's my thought
21:58:59 <KipIngram> One of the worst things about the internet is how it marks down EVERYTHING about us, and it's ridiculous to hold things from decades ago when someone was a kid againts them.
21:59:36 <KipIngram> We should just look at their adult, professional record.  And decide based on that.
22:00:07 <tabemann> he stopped being involved in the cDc when he went off to college
22:00:34 <KipIngram> Depending on what the thing is - the thing with Kavanaugh, if it were proven true, is a pretty big one.  The main issue for me there is that there was no REAL proof.
22:00:50 <KipIngram> And I just can't go down the road of condemning people without proof.
22:01:00 <KipIngram> Whether I agree with them or not.
22:01:16 <KipIngram> What is cDc?
22:01:30 <tabemann> whereas with O'Rourke he admits all this, but the worst he's done is steal some phone time and pirate some video games
22:01:44 <tabemann> all past the statue of limitations by this point
22:01:48 <KipIngram> There's no way I'm holding that against him.
22:01:49 <KipIngram> Peanuts.
22:01:50 <tabemann> Cult of the Dead Cow
22:01:56 <KipIngram> lmao
22:01:59 <KipIngram> ... ok.
22:02:03 <KipIngram> Truly never heard of that.
22:02:17 <KipIngram> I'm very unlikely to vote for him, but I'm not going to try to paste THAT on him.
22:02:58 <KipIngram> Who cares, really?  :-)
22:03:01 <tabemann> they're named after an abandoned Texas cattle slaughterhouse
22:03:51 <tabemann> I'd vote for him, if he gets the nomination; otherwise I probably wouldn't vote for him in the primaries, because I don't really care too much about any of the Democrat candidates individually
22:04:21 <KipIngram> I haven't even begun to think about it yet.
22:04:38 <KipIngram> 80% of this Democrat crowd will fall out - then I'll start to pay a little attention.
22:04:50 <PoppaVic> I enjoy Arkancides and cigar-sex, so vote HRC.
22:04:59 <KipIngram> Ugh.
22:05:09 <KipIngram> I hope I never have to vote against her again.
22:05:14 <KipIngram> I want her to just go away.
22:05:24 <PoppaVic> we ain't gonna get that lucky
22:06:18 <KipIngram> Well, we will see.  She will never, ever, EVER get my vote.  I think the Republicans could run Lucifer and I'd probably still vote against HRC.  
22:06:23 <KipIngram> That's a joke, but...
22:06:42 <PoppaVic> Lucifer would prolly work out well
22:06:45 <KipIngram> Well, anyway - turning in.
22:06:47 <KipIngram> :-
22:06:49 <KipIngram> :-)
22:06:53 <KipIngram> Have a good evening, guys.
22:09:23 <dave0> nite KipIngram 
22:09:52 <tabemann> if I had to choose between The Donald and Lucifer I'd vote for Lucifer
22:23:40 --- quit: dddddd (Remote host closed the connection)
23:58:45 --- quit: gravicappa (Ping timeout: 245 seconds)
23:59:59 --- log: ended forth/19.03.23