00:00:00 --- log: started forth/18.06.23
01:05:41 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
02:04:40 --- join: dave9 (~dave@207.213.dsl.syd.iprimus.net.au) joined #forth
02:04:56 <dave9> re
02:38:07 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
03:52:26 <dave9> back in a bit
04:07:28 <dave9> bit of an emergency, back in half an hour
04:20:01 --- quit: Labu (Quit: WeeChat 2.0.1)
04:20:12 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth
04:39:47 <KipIngram> Ok, so the number conversion stuff was pretty involved, because it was heavy on the stack.  At some points in it I have five things on the stack, because there's just that much to keep up with in that problem.  The sign character didn't cause much grief - I learn about it at the very beginning and shove a 1 or a -1 onto the stack, and then don't need it again until the very end where I multiply my accumulated
04:39:49 <KipIngram> number by it.
04:39:58 <KipIngram> But next was the base, which is needed at times during the work.
04:40:15 <KipIngram> In the 16 definitions I have 26 stack manipulation words.  Not really that bad - barely over 1.5 per word.
04:40:20 <KipIngram> So I think I did a pretty good job.
04:40:44 <KipIngram> But seven of those are in one word, and it's all about getting a copy of the base from way down in the stack when I need to multiply my accumulated value by it.
04:41:07 <KipIngram> I can't help thinking that using PICK here would be shorter and faster.
04:41:21 <KipIngram> I know it's frowned upon, but in this case, where I"m stuck with a heavy stack, it would be a win.
04:41:43 <KipIngram> Having realized that, I realized that the opposite of PICK - a store to deep in the stack - would occasionally be useful too.
04:42:33 <KipIngram> And from there I thought that having a small set of words with depths hard-coded, like 2@ 3@ 4@ 3! 4! and so on, would be better because I then wouldn't need to supply numbers.
04:42:46 <KipIngram> Just pick the word that gets or sets that item down there in the stack.
04:42:52 <KipIngram> I'm leery of going down that road.
04:43:07 <KipIngram> I worry that I'd become reliant on those and would wind up not struggling for the best solution as hard.
04:43:19 <KipIngram> But there's no doubt in my mind that SOMETIMES they would be the way to go.
04:43:43 <KipIngram> I don't want to touch ROLL with a ten foot pole, because its cost is O(depth) - you have to move everything between the top and "there."
04:43:55 <KipIngram> But PICK and a store equivalent are O(1).
04:44:51 <KipIngram> In other words, the argument against ROLL is real - it's a poor performance word.
04:45:01 <KipIngram> But the argument against PICK is really just purely philosophical.
04:45:27 <KipIngram> I agree with all the usual wisdom - better to have short words that only work with the top couple of items on the stack.
04:45:36 <KipIngram> But when you CAN'T...
04:46:13 <KipIngram> This really would have required six items on the stack if I insisted on working with what I was given, because the incoming string is a counted string and I'd have to have that count on the stack too.
04:46:56 <KipIngram> I dodged that by having a word CSTR that takes the address of the counted string, puts a null after it, and bumps the address forward to the first actual contetn byte.  Takes a "forth string" and gives me a c string.
04:47:06 <KipIngram> Then I just wached out for the null.
04:47:58 <KipIngram> Anyway, I'm giving strong consideration to including a small set of those words.
04:48:19 <KipIngram> 0@ is DUP.  1@ is OVER.  And we don't have 2@ or beyond.
04:49:01 <KipIngram> 0! is NOOP. 
04:49:23 <KipIngram> 1! is NIP DUP.
04:50:11 <KipIngram> And we don't have 2! and beyond, I don't believe.
04:50:51 <KipIngram> I think if I had up to 4@ and 4! that the NUMBER code would simplify quite a bit.
04:53:08 <KipIngram> Actually maybe the ! words give up the item at the top.  So 0! would be DROP, 1! would be NIP, and 2! would be -ROT?
04:55:18 <KipIngram> I guess it depends on whether the ! words pop the top item or not.
05:00:08 <dave9> my neighbor had a fall, but it doesn't seem too serious. the ambulance people have taken her to hospital. afaik nothing was broken, but my neighbor was shaken up
05:00:24 <KipIngram> Good - I'm glad it wasn't bad.
05:01:24 <dave9> she'll probably be in hospital overnight. her family has been notified. it's all good
05:01:38 <KipIngram> :-)
05:01:44 <KipIngram> You're a good neighbor.
05:01:58 <dave9> bit of dramas on a saturday night
05:02:40 <dave9> i didn't do much... just being there helped i think
05:02:52 <dave9> you wouldn't want to fall down and no one knows
05:02:57 <KipIngram> Well, but many neighbors wouldn't have been.  Wouldn't have even known it had happened.
05:03:13 <KipIngram> I like the idea of neighborhoods helping one another along.
05:03:39 <dave9> this is got housing, lots of people here are elderly
05:03:44 <dave9> govt
05:22:19 --- quit: dys (Ping timeout: 264 seconds)
05:44:49 --- join: dys (~dys@tmo-116-95.customers.d1-online.com) joined #forth
05:45:40 --- quit: pierpal (Quit: Poof)
05:45:58 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
07:32:35 --- quit: jedb (Ping timeout: 256 seconds)
07:53:17 --- quit: dave9 (Quit: one love)
10:01:35 --- quit: dddddd (Remote host closed the connection)
10:09:06 --- join: fftww (~va@quaking-professor.volia.net) joined #forth
10:29:44 --- quit: fftww (Quit: WeeChat 1.9.1)
11:07:12 --- quit: dys (Ping timeout: 260 seconds)
11:28:21 --- quit: pierpal (Quit: Poof)
11:28:38 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
11:33:45 --- join: dys (~dys@tmo-122-136.customers.d1-online.com) joined #forth
11:52:19 --- quit: pierpal (Quit: Poof)
11:52:35 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
12:16:41 <zy]x[yz> KipIngram, heh, re: your lax - rules (1-4 == -14), I just remembered I accept the radix character an number of times
12:17:05 --- quit: Zarutian (Read error: Connection reset by peer)
12:17:21 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
12:17:36 <zy]x[yz> so if you wanted to be really confusing you could write, e.g., 2#1000#20 ( 16 in base 8 )
12:17:42 --- quit: pierpal (Remote host closed the connection)
12:24:16 <KipIngram> Yes.  :-)
12:24:19 <KipIngram> Fun times.
12:24:29 <KipIngram> This one won't allow any monkey business like that.
12:25:22 <KipIngram> It will allow something like 16: which is 0, or for that matter 1:0 or even 0: which are both also zero.
12:26:59 <KipIngram> Or x: or b:
12:28:03 <KipIngram> Hah!  It gives 0 without error for -
12:28:18 <KipIngram> It just occurred to me sitting here thinking about it that it would.
12:30:48 <KipIngram> And :
12:31:11 <KipIngram> and -:
12:31:19 <KipIngram> Hmmm.  Maybe I'll fix that.
12:31:28 <zy]x[yz> mine will reject ,123 but it does accept 16#,123
12:31:45 <KipIngram> That's the , do?
12:31:48 <KipIngram> Are you in Europe?
12:32:07 <zy]x[yz> no
12:32:20 <zy]x[yz> the , is just ignored, so you can write 1,000,000
12:32:25 <KipIngram> s/That's/What's/
12:32:55 <KipIngram> Ah, I see.
12:33:37 <KipIngram> - and : are going to get found in the dictionary, so I'm not too wound up over those passing - it will never see those strings.
12:34:44 <KipIngram> :- won't fly, though, because the - has to be first.
12:34:56 <zy]x[yz> right
12:35:01 <KipIngram> I could require a digit following -
12:35:26 <KipIngram> Pretty easily, I mean.
12:36:02 <KipIngram> I have word that insists on a : after x or b, so I could use it as an easy template.
12:36:25 <KipIngram> It moves the pointer past that : once it confirms it's there, but the digit forcing word would do the same thing but not move the pointer.
12:36:38 <KipIngram> Just check for not null.
12:38:59 <KipIngram> Let's see.  Force a digit after I check for -.  Force a digit after I detect :.
12:39:04 <KipIngram> I think that would cover all the cases.
12:39:37 <KipIngram> Forcing digit after *checking* for - (whether it was there or not) would prevent both :<digits> and -:<digits>
12:39:51 <KipIngram> And forcing a digit after detecting : would prevent <anything>:
12:40:07 <KipIngram> So it's just one test - called from two spots.
12:40:23 <KipIngram> And it's a test that doesn't change the stack - just drops out the bottom to the error handling system or returns.
12:42:34 <zy]x[yz> that's nice.  mine is ugly and would probably just require a rewrite to fix its shortcomints
12:43:55 <KipIngram> Well, this is probably the 4th or 5th time I've coded this over the years, so I'd like to think I'd learned something along the way.
12:56:57 <KipIngram> Ha ha ha ha.
12:56:59 <KipIngram> I defined this:
12:57:01 <KipIngram> : !0  CHR 0= 4 ?ERR ;
12:57:08 <KipIngram> And called it from three places.
12:57:32 <KipIngram> I do think that may have plugged all the holes.
12:59:34 <KipIngram> No digits after : fail via explicit check.
12:59:35 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
12:59:59 <KipIngram> No digits before colon fails because that replaces the base with the accumulator, which is zero at that point, so in base 0 there are no valid digits.
13:03:31 --- quit: ncv (Ping timeout: 256 seconds)
13:11:20 <zy]x[yz> nice
13:12:45 <KipIngram> Yeah, that was about as painless as I could ask for.
13:13:04 <KipIngram> I had no right to expect it to fix :<digits> and -:<digits>.
13:13:09 <KipIngram> I didn't expect it to.
13:13:34 <KipIngram> Maybe those already failed and I didn't check carefully enough.
13:13:42 <KipIngram> Because I don't see how what I added would affect those cases.
13:19:11 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
13:36:27 --- join: pierpa (4f2c3a2d@gateway/web/freenode/ip.79.44.58.45) joined #forth
14:52:50 --- join: epony (~nym@77-85-141-85.ip.btc-net.bg) joined #forth
14:54:11 --- quit: Zarutian (Read error: Connection reset by peer)
14:54:17 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
14:56:18 --- nick: Zarutian_2 -> Zarutian
15:38:09 <KipIngram> Oh man, there's one spot in this code that makes me feel slightly soiled.
15:38:25 <KipIngram> At the end of one of the definitions, I use ;; to possibly do a double return.
15:38:54 <KipIngram> I say "possibly," because at the beginning of that definition I >R an item over to the return stack, and the corresponding R> is in an IF THEN.
15:39:09 <KipIngram> So if I run through the conditional code the stack is cleared and ;; returns to caller's caller.
15:39:33 <KipIngram> But if I don't do the conditional code ;; gives me my R> DROP effect but only returns to the caller.
15:39:45 <KipIngram> It's exactly what I want to happen, but let's just say that would DEFINITELY need good commenting.
15:52:17 <Zarutian> KipIngram: this sounds like your code is pretty clever. But are you clever enough to debug it?
15:54:28 <KipIngram> Well, as I've found problems with it I've been able to fix them, so I think that means yes.
15:54:57 <KipIngram> I found some of the niggling last problems myself; a friend found a few as well.
15:55:26 <KipIngram> Maybe you mean "test it"?
15:55:31 <KipIngram> as in rigorously?
15:55:54 <KipIngram> I've tried to probe around the corner cases that occur to me, but I haven't written a real test harness for it that does any sort of exhaustive testing.
15:55:56 <zy]x[yz> ur the niggling
15:56:47 <Zarutian> KipIngram: nope. I mean like in the adage about you often need to be twices as clever to debug code as who wrote it at the time.
15:57:07 <KipIngram> Oh.  Well, I think that's certainly true if you're not the original writer.
15:57:21 <KipIngram> I think I'm too close to it to experience it from that perspective, though.
15:58:05 <Zarutian> let me know in six weeks from now when you find a bug in that code and havent looked at it in the interm.
15:58:13 <KipIngram> So I notice I have several places in here of the form DUP <fixed value> <comparison test>.  I'm wanting to test the data in some way, but I want to keep the data too.
15:58:30 <KipIngram> It occurs to me that partially non-destructive comparison primitives would be nice for that.
15:58:36 <KipIngram> Like DUP 10 U< 
15:58:49 <KipIngram> In that case the 10 is just a parameter, and would get consumed; it's really "part of the test."
15:59:10 <KipIngram> But if I had something, say, .U< that left the bottom datum then I wouldn't need the DUPs.
15:59:25 <KipIngram> Seems like it's a pretty common paradigm.  
16:00:01 <KipIngram> And .U< would be just as fast as U<, so it would be all win.
16:00:21 <KipIngram> It actually would be faster than U< in my system, I think.
16:00:55 <KipIngram> Just compare the TOS reg to a memory location and leave the result in the TOS reg; only one memory read and no adjustment of the stack pointer.
16:05:19 <Zarutian> yeah, I have written words like : u<const DUP R> DUP CELL+ DUP CELL+ >R @ >R @ U< IF R> SWAP DROP ELSE RDROP THEN ; \ or similiar
16:14:34 <Zarutian> quite handy when doing lots of these comparisions.
16:17:57 --- quit: pierpal (Ping timeout: 265 seconds)
16:32:28 <KipIngram> I think I'll include them, using that . prefix convention.
16:55:12 <WilhelmVonWeiner> Maybe you should keep a log of this on a webcvs or blog. 
18:23:42 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
18:24:13 --- quit: Zarutian (Read error: Connection reset by peer)
18:24:38 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
18:28:12 --- quit: pierpal (Ping timeout: 260 seconds)
18:47:37 --- quit: pierpa (Quit: Page closed)
18:47:49 --- quit: dys (Ping timeout: 268 seconds)
19:00:41 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
19:08:34 --- quit: pierpal (Quit: Poof)
19:08:55 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth
19:54:43 --- join: dave9 (~dave@207.213.dsl.syd.iprimus.net.au) joined #forth
19:55:27 <dave9> hi
20:04:49 --- quit: dddddd (Remote host closed the connection)
20:39:32 --- quit: Keshl (Quit: Konversation terminated!)
21:18:57 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
21:19:11 --- join: jedb (~jedb@199.66.90.113) joined #forth
21:34:49 --- quit: ThirtyOne32nds (Ping timeout: 240 seconds)
21:47:33 --- quit: dave9 (Quit: one love)
21:50:49 --- quit: Keshl (Quit: Konversation terminated!)
21:58:51 --- join: Keshl (~Purple@24.115.185.149) joined #forth
23:15:36 --- join: dave9 (~dave@207.213.dsl.syd.iprimus.net.au) joined #forth
23:41:52 --- join: ThirtyOne32nds (~rtmanpage@180.sub-174-204-11.myvzw.com) joined #forth
23:59:59 --- log: ended forth/18.06.23