00:00:00 --- log: started forth/19.03.16
00:16:47 <ttmrichter> dave0: What does a Lisp condition do differently from exceptions or error returns?
00:25:43 <dave0> i don't know lisp, but from diddling with gnu's CLISP if an error comes up, instead of unwinding the stack until some function handles the error, it instead pushes a copy of the REPL where you can recover from the error using the interpreter
00:26:54 <dave0> eg. if you try and call an undefined function, it will start the interpreter where you can define the function, and resume your program
00:27:08 <dave0> i believe that's called a "condition" but i'm not sure
00:27:36 <dave0> i reckon Forth could do it too
00:38:13 <dave0> say you wrote a sqrt in forth, and did     -1 sqrt .    but then in sqrt it's an error.. instead of aborting, you would start the interpreter and you would have -1 on the data stack and maybe sqrt on the return stack... then you could drop the -1 and push 5, drop the sqrt off the return stack and resume, and you would print "5"
00:38:21 <the_cuckoo> i'm with PoppaVic on the 'what's wrong with error return and errno?' thing - i do of course use exceptions in c++ and python, and exceptions can be clearer than multiple returns in a deeply nested c function (pet peeve), but single return points in c are fine
00:40:37 <the_cuckoo> i tried to make my filter graph mechanism entirely return oriented (since it then becoes easier to wrap in c), but i got overruled by a team leader some years back and he changed it to exceptions (and then left the company over a dispute about money :()
00:40:38 <dave0> i don't know python :-( but c++ and c are not interactive, so there's no chance to let the user possibly recover from an error
00:41:33 <the_cuckoo> well, no - the user isn't programming - and clearly for security, you wouldn't want them to either :)
00:42:20 <dave0> but it can be useful in other cases
00:43:22 <dave0> say you wrote an ftp client and you're downloading a file, and you run out of disk space... instead of just aborting the download, you could drop into the interpeter, delete a few files to free up some space, and resume the ftp
00:45:22 <dave0> or you could redirect the download to some other file on a partition with more space
00:47:50 <the_cuckoo> true :) - but we're still in the developer mindset there :)
00:48:56 <dave0> ah but if security were a concern, you could make the ftp program send an email to root saying "dave tried to download a huge file to a small partition to try and crash the system" :-)
00:49:13 <dave0> and abort the transfer
00:49:38 <dave0> and kick me off the ftp server
00:49:43 <dave0> damn BOFH haha
00:49:44 <the_cuckoo> email - ugh :)
00:50:01 <dave0> oh haha i'mold
00:50:10 <the_cuckoo> :)
00:50:37 <the_cuckoo> so am i - just never liked email 
00:51:27 <dave0> my friend said "send me an sms when you want me to pick you up" and i said "can i email you?" and she said "who uses email anymore?"
00:51:31 <dave0> lol
00:53:48 <the_cuckoo> my wife insisted on sms, i prefer skype, she resists that, "everyone uses sms" she said, then facebook messenger, "everyone uses facebook messenger" she said, "i'm not on facebook - skype", she grumbles, discovers whatsapp, "everyone uses..."
00:53:57 <the_cuckoo> grrr....
00:55:02 <the_cuckoo> skype was better before microsoft forced their corporate "standards" on it
00:57:42 <dave0> i bet the guy who wrote skype is filthy rich
00:58:04 <the_cuckoo> probably
01:22:40 <the_cuckoo> i'd also say that something like recovery in the case of out of disk space on a single download may well be manually handlable (if that's a word), but in most real world situations, things are somewhat more complex - often better to clean up, abandon and report the issues than to try to allow manual recovery (esp when the underlying tools aren't invoked directly)
01:28:11 <the_cuckoo> in our video stuff for example, typically jobs are scheduled in a queue by way of a high level interface - then a number of these run in parallel (possibly randomly distributed over a network) - failure of a job is easier to manage by way of total failure rather than attempting to leave the distributed state in a "potentially recoverable" manner
01:41:25 <dave0> the_cuckoo: but Forth's interactivity makes it so handy
01:45:42 <dave0> OTOH i don't have much experience with Forth or interactive languages either... writing and testing small words as you write them might make it less useful
01:49:48 <the_cuckoo> yeah - but that's a developer thing - not a user thing - ultimately, it wouldn't work at any level if the operators have to have knowledge of, or even access to, that level of the system
01:53:25 <the_cuckoo> for us, yeah - it's neat - as i've said before, i use an interactive stack based setup for testing combinations of components in filter graphs - this is mostly ideal - we can change the graph setup - remove/add filters and identify specifics which fail
01:55:01 <the_cuckoo> but not ideal either - we need to break out of that to correct issues in the underlying c++ implementations - still makes for a good debugging tool though (and generally speaking, the graphs the apps use are relatively stable once we establish them in this way)
01:59:12 --- quit: rprimus (Remote host closed the connection)
02:20:26 --- join: rprimus (~micro@unaffiliated/micro) joined #forth
02:38:09 --- join: dgi (~dg@s559515c3.adsl.online.nl) joined #forth
02:46:47 --- quit: dgi (Quit: reboot)
03:28:38 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
03:45:28 <yunfan> the_cuckoo: is everyone the name of your neighour? :D
04:07:04 <the_cuckoo> you've lost me on that one yunfan :)
04:07:52 <the_cuckoo> oh :) - gotcha :)
04:52:40 --- quit: xek (Ping timeout: 244 seconds)
06:02:41 --- part: KipIngram left #forth
06:03:23 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth
06:03:23 --- mode: ChanServ set +v KipIngram
07:20:26 --- quit: dave0 (Quit: dave's not here)
07:27:19 <siraben> Are there any other fun single-assembly-file Forths to read other than jonesforth?
07:27:43 <siraben> I'd like to see one that correctly does DO, LOOP, DOES>, IS, etc. etc.
07:35:11 <crc> yunfan: it'sa native forth os for one of the kestrel computers sam falvo has been working on
07:42:34 <KipIngram> siraben: I'd be likely to implement those words you listed in Forth, after I had the ability to load blocks.
07:44:19 <KipIngram> I always get conflicted over DOES> - it always feels like I'm shoehorning it into a system that doesn't want to *gracefully* accept it.  I'm perpetually tempted to add an extra field to the headers to make it work more cleanly.
07:44:48 <`presiden> what DOES> do?
07:45:07 <KipIngram> Because the words you wind up creating with DOES> words really want to point to to things: the data for that specific individual word, and also to the DOES> code they're all supposed to share.
07:45:17 <KipIngram> `presiden: It works like this:
07:45:21 <PoppaVic> to TWO too
07:45:40 <KipIngram> : <defining word>  CREATE ...allocate space... DOES> ...actions... ;
07:45:45 <KipIngram> Then when you say 
07:45:53 <KipIngram> <defining word> <new_word>
07:46:28 <KipIngram> <new_word> gets the space allocated by ...allocate space... associated with it - when you execute <new_word> a pointer to that space is put on the stack, and then ...actions... is executed.
07:47:03 <KipIngram> So if you define several new words with <defining word> then they each get their own private space, but they all share the same ...actions...
07:47:39 <KipIngram> If they weren't already defined in your system, you could do this:
07:47:51 <KipIngram> : VARIABLE  CREATE CELL ALLOT DOES> ;
07:48:06 <KipIngram> : CONSTANT  CREATE , DOES> @ ;
07:48:12 <KipIngram> Do those make sense?
07:49:18 <KipIngram> Ugh.  Yes, to TWO things.  Not enough caffeine.
07:50:49 <KipIngram> I usually wind up implementing <new_word> as a colon definition that I dynamically build - it contains a (LIT) <value) that puts the address of the right data on the stack, and then a (JUMP) <target> that jumps to the ...action... code.
07:51:03 <KipIngram> But it always feels hacky.
07:53:15 <KipIngram> It feel like it would be cleaner to me <new_word> had a header with CFA (dodoes) and *two* parameter field cells - one pointing to ...action... and one pointing to <new_word>'s private data.
07:54:39 <KipIngram> Then no dynamically created code would be required.
07:57:06 <KipIngram> When you ran <defining word>, CREATE would create a normal one-parameter header, that had its normal pfa already pointing to the right place, and the the data would get allocated.  Then DOES> would allocate the second parameter slot and point it at ...action..., and all would be well.
07:57:37 <KipIngram> That's probably how I'll do it this time, since I have separate headers.  Doing what I just said would be straightforward.
08:02:47 <`presiden> KipIngram, so when the interpreter see CONSTANT, it will execute CREATE and then , and then DOES> and it goes into compile mode and process the rest?
08:04:00 <KipIngram> Well, at the time CONSTANT is created, it will exectute DOES>, but DOES> will cause a return - you don't execute the rest of that stuff then. DOES> will arrange for the new word created to run that remaining stuff.
08:04:10 <KipIngram> You have to keep straight what happens at compile time and what happens at run time.
08:04:16 <KipIngram> There are three phases here:
08:04:25 <KipIngram> 1) when CONSTANT is defined
08:04:37 <KipIngram> 2) when CONSTANT is executed, defining <word>
08:04:43 <KipIngram> 3) when <word> is executed.
08:05:04 <KipIngram> During phase 1, everything is just compiled.
08:05:24 <KipIngram> During phase 2, the stuff from CREATE to DOES> is executed.
08:05:33 <KipIngram> During phase 3, the stuff after DOES> is executed.
08:06:28 <KipIngram> When DOES> begins execution during phase 2, what has been created so far is a variable with its value initially set to whatever value we fed in for the constant.
08:07:21 <KipIngram> DOES> has to make whatever changes are required to get things so that the @ will execute in addition to the variable address being put on the stack.
08:07:32 <KipIngram> The details will depend on exactly how you structure your system.
08:08:09 <KipIngram> To implement that last method I described above, DOES> would change the new word's CFA from dovar to dodoes, and add the second parameter field pointint to where the @ is compiled.
08:09:05 <KipIngram> I could see dodoes just immediately  preceeding docol in memory - it would do the same thing dovar usually does, getting the address onto the stack, but would then increment W to the extra parameter cell and fall through into docol.
08:21:43 <KipIngram> Ok, nifty.  I just implemented that exactly as I described.
08:21:51 <KipIngram> DOES> wound up being this:
08:22:34 <KipIngram> : does>  (does) srel latest hcell + h! r> srel h, ;
08:22:50 <KipIngram> the srel's have to do with my relocation requirements - just ignore them.
08:23:13 <KipIngram> Since does> is a definition, the return stack contains a pointer to the ...action... code.
08:23:29 <KipIngram> I pop that and add it as the extra header cell.
08:23:48 <KipIngram> So when does> returns it returns from the defining word - we're doine.
08:24:09 <KipIngram> If you think of what was already in my assembly as this:
08:24:20 <KipIngram> dovar: ...var stuff... NEXT
08:24:47 <KipIngram> docol: ... def stuff... NEXT
08:25:01 <KipIngram> Then I just added this, just before docol:
08:25:12 <KipIngram> dodoes: ...var stuff...
08:25:15 <KipIngram> with no next.
08:25:23 <KipIngram> (does) gets me the address of that dodoes.
08:32:35 --- quit: Guest69125 (Remote host closed the connection)
08:33:00 --- quit: jimt[m] (Remote host closed the connection)
08:33:01 --- quit: siraben (Read error: Connection reset by peer)
08:33:01 --- quit: bb010g (Read error: Connection reset by peer)
08:36:18 <KipIngram> I don't think this would have been nearly as simple if my system wasn't indirect threaded.
08:37:09 <PoppaVic> Yeah, ITC is still useful for FLEXIBLE - just a tad slower than most
08:41:05 --- quit: pierpal (Quit: Poof)
08:41:23 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
08:44:29 --- quit: pierpal (Remote host closed the connection)
08:47:46 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-fysjxmkxzcfpbwoe) joined #forth
08:48:53 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
08:51:59 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-wsefrepzbctopeao) joined #forth
08:52:00 <siraben> So DOES> is convenient for defining new defining words
08:52:15 <siraben> Which would have to be done manually with CREATE et al. otherwise
08:53:15 <siraben> It also lets you save space by denoting the "run time behavior" that is run, so you could make a defining word that pushes two addresses (like a pair) onto the stack at runtime
08:54:36 <siraben> By the way, I've been thinking about using a better strategy than primitive branches for IF/ELSE/THEN, LOOP et al, because things get quite tricky for nested loops and ?do more than i thought
08:55:10 <siraben> Also it's annoying to write manual relative jumps in assembly because it varies depending on each platform's cell size
08:55:31 <siraben> And it makes reading decompiled words with SEE more verbose
09:04:56 <crc> siraben: what woud you do instead?
09:05:24 <PoppaVic> frankly, I think SEE is also a clusterfuck.
09:06:30 <PoppaVic> I mean, I use it all the time - but it is face-smashing-obvious that you'd need a recompile to extend it at all - and gforth's solution with gdb is another mess.
09:06:52 <crc> my conditionals and loops use anonymous functions, but that's largely due to not having a conditional jump instruction
09:07:05 <PoppaVic> (and the weird part is 7.3 fails if you are not root, but 7.9 SEEs prims fine)
09:07:57 <crc> PoppaVic: I have an optional dissassembler, but no SEE
09:12:13 <PoppaVic> crc: My botton-line is that forths need either a VIEW or a SEE - and it needs to handle secondaries as well as prims. It's that simple. Otherwise, you are not "interacting" - and I can do the latter with C ;-)
09:13:15 <crc> what is VIEW ?
09:14:12 <PoppaVic> VIEW was something from the F83 era: there was a VIEW field in each word, and it was used to reference the sourcefile and line/block, to list the source
09:14:26 <crc> my dissassembler gives output like: http://forth.works/3c3a7a57787ed34f928e3aa2275761c5 which includes guesses as to call targets, etc
09:14:30 <crc> ahh
09:14:47 <siraben> PoppaVic: i found SEE to be very useful in quickly being able to port new words and verify certain correctness
09:14:59 <crc> I don't need either SEE or VIEW
09:15:02 <PoppaVic> absolutely
09:15:10 <siraben> Since it's a highly non-trivial yet useful word
09:15:44 <siraben> crc: no conditional jumps? What's your implementation built on?
09:16:14 <crc> siraben: conditional calls :)
09:22:28 <crc> I have a conditional call instructuon that takes an address and flag from the stack and calls the address if the flag is true or discards if it's not
09:23:03 <PoppaVic> crc: yer hairsplitting ;-P
09:24:56 <crc> PoppaVic: it makes a big difference in the end. no conditional jumps changes the implementation choices a lot
09:25:20 <PoppaVic> heh.. I cannot believe I gotta' [IF] my old code to insure running on these 2 gforths - I need to bitchslap someone
09:25:54 <PoppaVic> crc: well, when you call them "branches", they all apply - I know what yer saying, but some will grope in the dark ;-P
09:26:03 <siraben> Have conditional jumps
09:26:14 <PoppaVic> siraben: unnecessary
09:26:25 <siraben> Like 0BRANCH, BRANCH, JUMP and 0JUMP
09:26:43 <PoppaVic> PoppaVic> siraben: unnecessary
09:26:48 <siraben> BRANCH for relative jumping, JUMP for absolute
09:26:55 <crc> siraben: I don't *need* them
09:27:04 <PoppaVic> crc: see? you blew his mind ;-)
09:27:14 <crc> All jumps and calls in mine are absolute
09:27:15 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-dnswnueqcetdjcoi) joined #forth
09:27:15 --- join: alexshpilkin (alexshpilk@gateway/shell/matrix.org/x-gbdowypzvoezhamn) joined #forth
09:28:16 <crc> CCALL, CALL and JUMP take the address from the stack
09:29:39 <PoppaVic> siraben: for the record? either BRANCH or JUMP can be relative or absolute - so can calls and other gotos ;-)
09:45:38 <crc> I could implement 0jump, it just wouldn't be efficient
09:45:45 <crc> :0jump (af-) n:zero? &call &drop choose ;
09:47:28 --- quit: gravicappa (Ping timeout: 272 seconds)
09:51:52 --- quit: pierpal (Ping timeout: 264 seconds)
10:10:51 <`presiden> KipIngram, thanks, I think I kinda get it now.
10:11:17 <KipIngram> Cool - happy to help.
10:11:35 <KipIngram> I believe there's also cdoes> in some systems.
10:11:43 <KipIngram> Systems that have assembly words.
10:11:46 <KipIngram> There you'd say
10:12:09 <KipIngram> : defining_word  CREATE ...allocate... CDOES> ...assembly code.. NEXT;
10:12:23 <KipIngram> Same idea, except that you've specified the run-time in assembly.
10:13:11 <`presiden> ah, like native vs docol, 
10:16:03 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
10:19:02 <KipIngram> :-)
10:25:34 --- quit: pierpal (Ping timeout: 250 seconds)
10:44:41 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
10:46:25 --- quit: zy]x[yz (Quit: leaving)
10:49:12 --- join: zy]x[yz (~corey@unaffiliated/cmtptr) joined #forth
10:58:31 --- quit: pierpal (Quit: Poof)
10:58:51 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
11:24:00 --- quit: nighty- (Remote host closed the connection)
12:33:15 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth
14:07:15 <KipIngram> I guess whether native wins over docol really depends on whether those words get executed on your critical performance path.
14:07:32 <KipIngram> Obsessing over performance is a weakness I have to always monitor myself for.
14:07:39 <KipIngram> It only really matters now and then.
14:07:47 <KipIngram> For any particular bit of code, I mean.
14:47:58 --- quit: xek (Ping timeout: 246 seconds)
15:34:42 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
15:35:21 <dave0> hi C4[_]~ C8[_]~ C3[_]~ C2[_]~
15:44:11 <KipIngram> hi dave0.
15:44:52 <dave0> hi KipIngram 
15:45:01 <dave0> sup?
15:51:29 <KipIngram> Oh, let's see.  Not a whole lot today.  Just a bit of tidying up.  Added a clear screen keystroke.  Coudln't use ctrl-L like bash, because I use ot for something else.  I went with ctrl-\.
15:52:47 <KipIngram> Just piddly stuff like that.
15:53:02 <KipIngram> Made sure that everything was still working on the Linux box.
15:53:04 <KipIngram> OH!
15:53:12 <KipIngram> I implemented DONE>.  :-)
15:53:25 <dave0> what's DONE> ?
15:53:33 <KipIngram> Easier than ever before - in all my past implementations it's been all klunky.
15:53:38 <dave0> not like DOES> ? :-)
15:53:47 <KipIngram> Oh.
15:53:49 <KipIngram> Ooops.
15:53:52 <KipIngram> DOES>
15:53:55 <KipIngram> Sorry about that.
15:54:02 <dave0> oh lol
15:54:20 <KipIngram> Heh - I was about to launch into explaining it, but I was going to PM because we went through all that here earlier.
15:54:25 <PoppaVic> done> WITH DOES>
15:54:26 <KipIngram> But, my bad.
15:54:42 <KipIngram> Yeah - it was really simple and clean in this architecture.
15:54:45 <dave0> i had a first try of   >number
15:54:54 <KipIngram> I think it's the combo of indirect threading and headers separate from bodies.
15:55:05 <KipIngram> yeah?  how's that going?
15:55:24 <dave0> there's too many IF's
15:55:39 <KipIngram> Yeah, quite a few decisions to make in that one.
15:55:52 <KipIngram> I did them with conditional returns and such, but they're still "there."
15:56:06 <KipIngram> So I wound up with a stack of like 26 definitions.
15:56:13 <dave0> wow
15:56:19 <KipIngram> All of them nameless except for NUMBER itself.
15:56:32 <KipIngram> But none of them were longer than say 40-45 chars.
15:56:58 <KipIngram> And I believe it to be 100% correct - no "error cases" that slip through.
15:57:08 <KipIngram> If it's not an explicitly valid number string, it gets rejected.
15:57:16 <KipIngram> I think / hope
15:58:05 <KipIngram> What all bases are you handling?
15:58:51 <dave0> i looked how lbForth did it and it has about 20 lines of 40 chars over about 6 words
15:59:32 <dave0> it multiplies by BASE but it doesn't check the digit is within range :-)
16:00:01 <dave0> you can use the digit B in base 10 and you get 11 :-)
16:02:02 <KipIngram> Yeah, I don't have base.
16:02:06 <KipIngram> BASE
16:02:14 <KipIngram> I do check range.
16:02:44 <KipIngram> Mine defaults to base 10, but you can override by giving a <decimal base>: prefix.
16:02:55 <KipIngram> Like 16:ABCD
16:03:10 <KipIngram> x: and b: are acceptedas substitutes for 16: and 2:, respectiveily.
16:03:25 <KipIngram> Other bases don't have any "letter stand-in," though.
16:03:33 <KipIngram> It works up to base 62.
16:04:18 <KipIngram> If the working base is 36 or less, then it's case insensitive.  If the base is >36, then it switches to case insensitivity.
16:04:26 <KipIngram> I mean case sensitivity.  :-|
16:04:45 <KipIngram> PoppaVic suggested that nuance.
16:07:07 <dave0> i miss case insensitivity cos i'm used to unix
16:07:38 <dave0> case-insensitivity and case-preserving is the best
16:10:59 <KipIngram> I had pretty much decided I'd make it case insensitive and just accept base 2-36, until he made that suggestion.  Then it seemed obvious - it wasn't that hard.
16:11:29 <KipIngram> So this thing will do up to base 62, but if you're 36 or less you can use upper or lower case.
16:11:57 <dave0> cool
16:12:05 <KipIngram> I have this idea I might tinker with Sumerian astronomy one of these days - they used base 60, and word is they got better precision for any particular number of digits.
16:12:20 <dave0> does it match base64 ?
16:12:46 <dave0> you know the mime encoding?
16:13:37 <dave0> that would be an "interesting" use of >number if it worked directly with base64 encoding :-)
16:13:47 <KipIngram> No - it treats 0-9 as 0-9, A-Z as 10-35, and a-z as 36-61.
16:14:00 <KipIngram> I have no idea how mime works.
16:14:04 <dave0> that's almost the same
16:14:12 <KipIngram> Ok.
16:14:26 <KipIngram> It was as "computationally obvious" as I could make it.
16:14:35 <dave0> let me google
16:15:13 <KipIngram> It's kind of fun to type my name in as a number.  :-)\
16:15:36 <dave0> KipIngram: https://en.wikipedia.org/wiki/Base64
16:15:59 <dave0> it encodes 3 bytes of binary data in 4 characters of ascii
16:16:35 <KipIngram> Oh, that's weird - it has 0-9 at the END.
16:16:39 <dave0> oh wait it's weird...
16:16:43 <dave0> yes!
16:16:43 <KipIngram> At least in that first table.
16:16:56 <dave0> okay that spoils everything.. nvm :-)
16:17:01 <KipIngram> That's a silly way to do it.
16:17:54 <KipIngram> It was while developing that that I really began to catch on to how handy the conditional returns would be.
16:18:12 <KipIngram> That problem has a lot of very interesting control flow aspects.
16:19:11 <KipIngram> So other than the DOES> thing all I did today was a minor tidy-up to how the clear screen stuff works.
16:19:27 <KipIngram> I can do it with a cls word, or with a ctrl-\ keystroke.
16:19:39 <KipIngram> and the way the prompts behave din the aftermath of those was a bit different.
16:19:49 <KipIngram> So, totally no big deal, but it bugged me anyway.
16:20:31 <KipIngram> I finally decided that issuing "<cursor left> <cursor right>" before the prompt was the right way to go.
16:21:07 <KipIngram> There are two spaces involved with the interpreter loop.  You put in a space to separate the input from the output on the sxreen, and that's before you execute the sommand.
16:21:17 <KipIngram> And you put in a space to separate the output from the OK prompt.
16:21:20 <KipIngram> And that's after.
16:21:47 <KipIngram> But if the command is cls, then that "erases" the first of those, and your first ok at the top of the screen only has one space before it.
16:21:57 <KipIngram> which is technically, rigorously, correct.
16:22:02 <KipIngram> But it still bugged me.
16:22:57 <KipIngram> So if you put that <cursor left>-<cursor right> in after executing the command, it does NOTHING if the cursor is beyond column 1.  But if the cursor is IN column one, which can only happen with a cls command, it nudges it one to the right.
16:23:07 <KipIngram> makes all the ok's line up.
16:23:23 <KipIngram> So - yeah.  A really stupid thing to fret over, but I was fretting anyway, so I fixed it.
16:23:45 <KipIngram> Sometimes I fret over how my source code LOOKS on the screen.  :-)
16:23:55 <KipIngram> Must have a touch of autism or something.
16:32:13 <KipIngram> If cls is used in an application, it WILL put the cursor in the top left.  The extra motion is ussued in QUERY, so it really will only happen when I'm typing commands in from the keyboard.
16:32:24 <KipIngram> Which is the only time the prompt is issued, so thaat works out.
17:36:33 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
17:49:53 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:58:11 --- quit: Zarutian (Ping timeout: 252 seconds)
17:59:32 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
20:09:12 --- join: gravicappa (~gravicapp@h109-187-202-26.dyn.bashtel.ru) joined #forth
20:29:45 --- quit: dddddd (Remote host closed the connection)
23:14:34 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
23:57:09 --- join: dgi (~dg@s559515c3.adsl.online.nl) joined #forth
23:59:59 --- log: ended forth/19.03.16