2022-04-28 02:52:16 <eris[m]     > rho(cuboid - 1) is what occurs
2022-04-28 02:58:40 <eris[m]     > cuboid - 1 doesnt change the shape
2022-04-28 03:33:42 <eris[m]     > KipIngram:
2022-04-28 04:00:12 <veltas      > KipIngram: That's how C etc do it, they let you give extra precision and it gives you the closest representable float
2022-04-28 04:00:23 <veltas      > Only way that makes sense IMO
2022-04-28 06:22:41 <KipIngram   > But ≢⍴cuboid is just a number isn't it?
2022-04-28 06:23:38 <KipIngram   > and whatever it is, it looks like it should be "thing" - 1 vs. -1 + "thing".
2022-04-28 06:23:54 <KipIngram   > adding -1 and subtracing 1 should be the same.
2022-04-28 06:24:00 <KipIngram   > subtracting
2022-04-28 06:24:43 <KipIngram   > Oh, wait
2022-04-28 06:24:47 <KipIngram   > Now I see.
2022-04-28 06:24:56 <KipIngram   > Right to left.
2022-04-28 06:25:16 <KipIngram   > The  - 1 subtracts one from everything IN cuboid; before the shape is taken.
2022-04-28 06:25:20 <KipIngram   > Ok - got it.
2022-04-28 06:25:40 <KipIngram   > Just was slipping back into "school math mode" yesterday.
2022-04-28 06:26:01 <KipIngram   > And now it makes total sense why they wrote it the way they did.
2022-04-28 06:26:54 <KipIngram   > I guess I'll do this periodically - it's an old old habit, deeply in me.
2022-04-28 06:27:57 <KipIngram   > veltas: Yes, it absolutely seems like the "right thing to do."
2022-04-28 06:30:57 <KipIngram   > I mentioned re-writing NUMBER at some point yesterday, for general hygiene purposes.  It tries to do a lot - the goal I set for myself was not only to covert every valid number string correctly, but also to reject *every* non-valid number string.  If you write that the simplest most straightforward way, you wind up with something that will accept, say --4 as 4, and that would let you specify base multiple
2022-04-28 06:30:58 <KipIngram   > times, e.g. 16:18:123, which would be 123 converted using base=24 decimal, etc.
2022-04-28 06:31:04 <KipIngram   > I wanted to throw an error on such strings.
2022-04-28 06:31:32 <KipIngram   > So it does quite a lot.  But I wrote it as an integer converter, with "hooks" were I later went back and pushed in floating point.
2022-04-28 06:31:48 <KipIngram   > By the end of all of that it had gotten a bit spaghetti.
2022-04-28 06:32:43 <KipIngram   > These conditional returns of mine are powerful, but they will LET me write spaghetti - they don't prohibit it as well as the standard control structures do.  Not that you can't write obtuse code using them; it's just a different kind of obtuse.
2022-04-28 06:33:21 <veltas      > I'm not too keen on adding too many features to NUMBER, I'm uncomfortable even with the Forth 200x additions like $hex #dec etc
2022-04-28 06:33:54 <KipIngram   > You could think of that one as softening the requirement of space delimitation.
2022-04-28 06:34:04 <KipIngram   > 200 x could do that too, and would be more Forthy.
2022-04-28 06:34:41 <KipIngram   > I've felt some strong temptations toward that softening since picking up the APL study.  I think those APL "idioms" look more like idioms without spaces.
2022-04-28 06:34:42 <veltas      > That's not very forthy either :P
2022-04-28 06:35:06 <KipIngram   > Well, I guess in Forth you really should just write the number to be the right value to start with.
2022-04-28 06:35:16 <KipIngram   > Anyway, yes, I feel a lot of discomfort about that temptation too.
2022-04-28 06:35:27 <KipIngram   > Very on the fence.
2022-04-28 06:35:51 <KipIngram   > It first occurred to me when we were discussing JSON parsing the other day.
2022-04-28 06:36:26 <KipIngram   > If you could selectively recognize certain characters as stand-alone words, even if they aren't spaced apart, you could pretty easily get the built in interpreter to parse JSON.
2022-04-28 06:36:57 <KipIngram   > MrMobius pointed out what is likely the right answer there, though - just make a pass through the JSON first and insert spaces, then pass that to the interpreter.
2022-04-28 06:37:53 <KipIngram   > But I still felt the temptation - it could be made a completely optional rather simple "add-on."
2022-04-28 06:38:01 <KipIngram   > "switch on," rather.
2022-04-28 06:38:32 <KipIngram   > Those spaces seem very near the "heart" of Forth.
2022-04-28 06:39:55 <KipIngram   > A lot of Forths do do that, though, in a single case.  A null character sometimes gets recognized as a stand-alone word even if not space delimited.
2022-04-28 06:40:13 <KipIngram   > It's an old-fashioned way of breaking the infinite loop in INTERPRET.
2022-04-28 06:40:48 <KipIngram   > That was in as far back as FIG.
2022-04-28 06:41:02 <KipIngram   > I've never not done it.
2022-04-28 06:41:47 <KipIngram   > With that you don't need the interpret loop to check anything - the null word just forces the termination on you by doing a double return from EXECUTE.
2022-04-28 08:15:13 <eris[m]     > you can also write it with swap
2022-04-28 09:55:37 <KipIngram   > You mean the APL I posted earlier?
2022-04-28 09:55:55 <KipIngram   > If you're making a Forth comment I don't quite follow.
2022-04-28 11:33:49 <eris[m]     > yea, the apl
2022-04-28 11:57:48 <Zarutian_HTC> veltas: I didnt add that to number but to the word that calls it when it is done searching the dictionary
2022-04-28 11:59:13 <Zarutian_HTC> could have though, just as an preamble to detect those ?signitures? and set base accordingly
2022-04-28 12:01:04 <Zarutian_HTC> re JSON parsing, I prefer just to code that parser myself
2022-04-28 12:02:35 <Zarutian_HTC> just I like I did with parsing Tcl (well doing the core of what lindex lrange and such do)
2022-04-28 12:03:38 <Zarutian_HTC> the beuty of using ( addr length ) is that you can slice out a substring eazy
2022-04-28 12:17:05 <nature      > That's also how I ended up doing my JSON parsing in the end, returning the substring based on a "selector"
2022-04-28 16:43:53 <Zarutian_HTC> nature: with tcl parsing I am basically doing : tcl_lindex_first ( str1 len1 -- restStr restLen itemStr itemLen ) ... ;
2022-04-28 16:52:28 <Zarutian_HTC> if per the twelf parsing rules of tcl the first item is not complete then itemStr and itemLen will both be zero
2022-04-28 17:00:26 <Zarutian_HTC> basically unbalanced double qoutes, curly braces and such
2022-04-28 18:24:45 <Zarutian_HTC> an idea, should unicode support quite the subset of turtle graphics to have an escape hatch to deal with glyphs not in yet unicode?
2022-04-28 18:38:40 <KipIngram   > You know, I think all I need to do to get these APL characters to work right in my system is add two things to EXPECT: 1) if a new keystroke has the high bit set, then I fetch more characters until I reach a final character and still move the cursor just one notch, and 2) if I'm rubbing out a character the cursor always move one notch left, but I remove bytes until I come to a starting character.
2022-04-28 18:38:53 <KipIngram   > I think with those in it will work the way it should.
2022-04-28 18:40:05 <KipIngram   > Right now it picks up all the right bytes, but moves the cursor over for all of them, and then it removes only one byte at a time on rubout.
2022-04-28 18:45:13 <KipIngram   > If I just tolerate the extra spaces on the screen and stay careful about backing up, defined words work just fine.
2022-04-28 18:50:16 <KipIngram   > I have a word "insert" that gets called after I've checked for control characters - I think (1) goes in there.  Then bs? handles rubouts, and now that I'm thinking about cursor right and cursor left will need to be touched to.  And if I add fancy features in the future like word left and word right, they'll need suitable attention.  But they're not in yet, so... problem for another day.
2022-04-28 18:53:09 <KipIngram   > Ok, buffer full checking too.  Damn - not quite as simple as I was telling myself.
2022-04-28 18:53:41 <KipIngram   > But at least they're functions with a very clear place in the code to work with them.
2022-04-28 18:58:53 <KipIngram   > Maybe it would be better to decide thath KEY returns the full UTF-8 character bytes in one shot.  Any thoughts/opinions on thatt?
2022-04-28 18:59:13 <KipIngram   > It seems architecturally cleaner.
2022-04-28 19:01:07 <Zarutian_HTC> I got þ æ ö ð on my keyboard so, yes
2022-04-28 19:13:42 <KipIngram   > I may just re-write this little section.  It's not THAT much stuff, and I'd probably wind up with nicer code.