00:00:00 --- log: started forth/18.11.09
00:14:28 --- quit: dys (Ping timeout: 252 seconds)
00:23:11 --- quit: reepca (Remote host closed the connection)
00:58:32 --- quit: rdrop-exit (Quit: Lost terminal)
01:02:04 --- quit: nighty- (Quit: Disappears in a puff of smoke)
01:30:58 --- join: wa5qjh (~quassel@175.158.225.222) joined #forth
01:30:58 --- quit: wa5qjh (Changing host)
01:30:58 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
02:02:55 --- quit: ashirase (Ping timeout: 246 seconds)
02:09:02 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:24:43 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth
02:41:15 <dave0> forth code is hard to write :-(
02:46:34 --- quit: pierpal (Quit: Poof)
02:46:56 --- join: pierpal (~pierpal@host210-193-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
02:53:37 --- quit: pierpal (Ping timeout: 252 seconds)
02:54:51 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
02:56:29 --- join: WilhelmVonWeiner (dch@ny1.hashbang.sh) joined #forth
02:56:48 <WilhelmVonWeiner> did I miss anything
02:57:29 <dave0> last message was about 8 hours ago :-p
03:00:10 <WilhelmVonWeiner> Waiting for a *blegh* C++/*PUKE* C# job to call me back
03:00:30 <WilhelmVonWeiner> hoping they want me and assign me to the C++ division 
03:02:36 <WilhelmVonWeiner> I saw a post on Reddit where someone was experimenting with words that don't inherently consume the top stack item
03:03:16 <WilhelmVonWeiner> so 2 3 + would leave <3> 2 3 5 on the stack
03:03:39 <WilhelmVonWeiner> which is interesting because I start a *lot* of words with DUP
03:07:32 <dave0> i must look up the Forth standard for accept!
03:08:47 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
03:11:08 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
03:12:10 <dave0> hmm
03:12:25 <john_cephalopoda> Hey
03:12:31 <dave0> hi john_cephalopoda 
03:12:52 <WilhelmVonWeiner> I was thinking og using ACCEPT in my editor but I decided on a KEY loop so I don't have to faff about with strings
03:13:07 <WilhelmVonWeiner> and I just slowly move around chunks of memory instead
03:14:24 <dave0> accept requires some thought, it looks like it is the interface to the user
03:15:11 <dave0> Tali-Forth that i am reading, has it's command history here (also it's coded in assembler, not forth)
03:16:17 <dave0> ctrl-p and ctrl-n to go backwards and forwards though the history.. it also handles backspace and beeps if you try to back up too far
03:19:30 <dave0> i have some very basic forth that is working... it only lets you input characters to the length parameter, or when you press return
03:19:40 <dave0> but i think that is wrong
03:19:41 <WilhelmVonWeiner> in what?
03:20:04 <dave0> for accept... i'm trying to write accept in forth
03:20:11 <WilhelmVonWeiner> oh right
03:21:47 <dave0> i have to make a choice of what happens if the user types more characters than the length of the string
03:23:36 <dave0> in the current code, if i ask for 5 characters, and i type 'abcde' it returns immediately after pressing 'e', without waiting for the enter key
03:23:52 <WilhelmVonWeiner> I think that's fair
03:24:04 <WilhelmVonWeiner> user wouldn't have the illusion of having entered more characters
03:24:20 <dave0> but there's another way
03:25:22 <dave0> if i ask for 5, and type 'abcde' it takes all those characters, but doesn't return right away... if i type 'f' it could beep at me and not add 'f' to the string... it only returns when i press enter
03:26:10 <dave0> that lets you type eg. 'abcdf' then press backspace, and change the 'f' to an 'e', then press enter
03:26:32 <dave0> ACCEPT would only return when enter is pressed
03:27:07 <dave0> WilhelmVonWeiner: what do you think of that idea?
03:34:10 <KipIngram> dave0: I approve of your second approach.  Don't return immediately when the buffer is full - just stop accepting and echoing characters.
03:34:27 <KipIngram> Let the user choose whether to hit Enter to input the full field, or whether to backspace and type something different.
03:34:43 <dave0> yes i think that makes more sense
03:35:19 <WilhelmVonWeiner> i turn off bells
03:35:27 <WilhelmVonWeiner> but I suppose you have a point
03:35:39 <KipIngram> I think sound would be optional.
03:35:43 <WilhelmVonWeiner> replacing e would be useful
03:36:08 <KipIngram> I don't think so - you're typing e with the notion it's going to be appended; not that it's going to repalce the last character you typed.
03:36:23 <KipIngram> It's not possible to handle it in the way that the user would expect it to be handled.
03:36:43 <KipIngram> Anyway, mine doesn't make any sounds.
03:36:58 <KipIngram> I find the visual feedback of no more characters appearing on the screen to be adequate.
03:37:12 <dave0> ah yeah Tali-Forth that i'm following sends a 'beep' character if you try to backspace too far
03:37:46 <KipIngram> Yeah, bash on my MacOS does that.
03:38:06 <KipIngram> dave0: Are you planning to support any sort of command history?
03:38:09 <dave0> so i was just going with it for no reason except tali-forth did it
03:38:33 <dave0> KipIngram: eventually :-)
03:38:37 <KipIngram> If so, you want that to be invoked by ACCEPT, since you're typing a command at that point, but not by EXPECT, which is often used just for data.
03:38:56 <dave0> oh i'll have to look up expect
03:39:06 <KipIngram> I found it useful (in terms of sharing code) to have a lower level word, which I just called (READ) that handles the basic line editing.
03:39:30 <KipIngram> Then EXPECT just wrappered that with no extra functionality, but ACCEPT wrappered it with a wrapper that handled the history navigation.
03:39:38 <dave0> but first before history i want to do arrow keys to go back&forth on the line, so you cango back and insert chars anywhere on the line
03:39:55 <KipIngram> (READ) handles regular keys, backspace, and left and right cursor keys.
03:40:16 <KipIngram> If it gets any key other than those it returns to its caller, but it can be "restarted" by just calling it again with the stack intact.
03:40:35 <KipIngram> So ACCEPT can add an interpretation for the vertical cursor keys, which navigate the history.
03:40:53 <KipIngram> Right, that ought to come first.
03:41:53 <KipIngram> When (READ) returns with a vertical cursor key, EXPECT just drops those keys and recalls (READ).
03:41:57 <KipIngram> So those keystrokes are ignored.
03:42:13 <dave0> EXPECT doesn't seem to be in forth 2012
03:42:16 <KipIngram> ACCEPT does something with them - updates the text entry buffer with new content, from the history.
03:42:24 <KipIngram> Hmmm.
03:42:36 <KipIngram> Ok.  What does it provide to just read a key sequence into some arbitrary memory buffer
03:42:38 <KipIngram> ?
03:43:03 <dave0> ah EXPECT is in ANS '94
03:43:04 <KipIngram> Maybe that's what ACCEPT does - I'm not up on the latest standards.
03:43:31 <KipIngram> Basically there used to be QUERY, which just called EXPECT against a specific buffer; the one that was used for input parsing.
03:44:24 <KipIngram> So my (READ) uses a stack frame; even when it's first called you have to set that up.
03:44:35 <KipIngram> Hence the need for a wrapper even in the EXPECT case.
03:44:43 <KipIngram> But it makes (READ) restartable.
03:44:47 <dave0> ANS '94 says EXPECT is obsolescent and it's superceded by ACCEPT
03:45:12 <KipIngram> Ok.  Is there still a QUERY?  Or did they just drop that "thin wrapper" altogether?
03:45:21 <dave0> looking
03:45:54 <KipIngram> All in the world QUERY used to be was just TIB <TIB size> EXPECT.
03:46:11 <KipIngram> So they could have just decided to write that out when fetching input to interpret.
03:46:17 <dave0> there is QUERY in ANS '94
03:46:56 <dave0> obsolscent, but it doesn't say what else to use... it's not in forth-2012
03:47:22 <KipIngram> Ok.  They must expect you to use ACCEPT and manually provide the buffer address and size.
03:48:11 <KipIngram> QUERY always struck me as a somewhat poor excuse for a word - it's only used once in a typical system, and it just supplies two "easy" parameters to EXPECT/ACCEPT.
03:48:38 <KipIngram> You're not really saving anything by having it, and in fact your system would be ever so slightly larger and slower, so I can see them deciding to drop it.
03:48:59 <KipIngram> It was a factoring that wasn't really justified by any objective payoff.
03:49:10 <dave0> yep accept takes a   c-addr n1 -- n2    where up to n1 chars are put in c-addr, and n2 returns the actual amount of characters the user typed
03:49:23 <KipIngram> Right.
03:49:39 <KipIngram> I don't think my EXPECT returns the actual count - I should probably add that.
03:49:50 <KipIngram> my EXPECT null terminates the input string.
03:50:19 <KipIngram> That makes me think that in FIG it didn't return a count; I would have been following FIG back when I wrote it for the first time years ago.
03:50:39 <KipIngram> But having such a count returned definitely seems useful to me.
03:51:07 <dave0> i'm going to make mine slightly different where it's   c-addr1 n1 -- c-addr2 n2    c-addr1 n1   is the buffer and maximum length, and   c-addr2 n2   is what the user actually typed... in reality, c-addr2 = c-addr1, but i like the idea of keeping them as "strings"
03:52:03 <KipIngram> If I recall correctly, my stack frame for (READ) is <buffer address> <buffer size> <current number of bytes in the buffer> <cursor position in the buffer>
03:52:51 <dave0> so for example    SOURCE ACCEPT TYPE    will read a line from the user and print it back to him
03:52:55 <KipIngram> So when EXPECT gets called, the buffer address and the buffer size are already on the stack.
03:53:18 <dave0> yeah there's lots of state to juggle
03:53:36 <KipIngram> EXPECT adds 0 0 (no characters entered yet, cursor at position 0), frames up with {{ and then loops on (READ) until (READ) returns with Enter on the stack.
03:53:49 <KipIngram> Then it unframes with }} and tears down the stuff on the stack.
03:54:10 <KipIngram> Having the frame buffer capability was extremely useful in that case.
03:54:30 <KipIngram> Especially when I wanted to add even more functionality with QUERY and command history navigation.
03:55:15 <KipIngram> QUERY can check (READ)'s return - if it's a vertical cursor key then it moves to the right command history spot, reloads the buffer with that command, puts the cursor at the right end of that line, and recalls (READ).
03:55:50 <KipIngram> So QUERY has a stack frame of its own, that adds a couple of items related to where we are in the command history.
03:56:23 <KipIngram> So there's REALLY a lot on the stack in that case.  
03:56:51 <KipIngram> That was a huge motivator for the stack frame and the frame-based access words; it was becoming a coding nightmare without those things.
03:57:37 <KipIngram> (READ) doesn't return on horizontal navigation keys - it handles those itself.
03:57:44 <KipIngram> It returns only on Enter.
03:57:49 <KipIngram> Wait - wrong.
03:57:58 <KipIngram> It returns on any key it doesn't know the meaning of.
03:58:03 <KipIngram> That was sort of the whole point.
03:58:21 <KipIngram> But it has all the info it needs to handle cursor left / cursor right.
04:11:26 <KipIngram> I know they say "don't write words that need that much stuff on the stack."  But I honestly don't see any really good way to avoid it in this case.  Yes, I could have saved that information in variables instead, but that doesn't really lower the "verbosity" of the problem.  You're still doing EXACTLY THE SAME THING - just with permanently defined dictionary names instead temporary identities of stack cells.
04:11:36 <KipIngram> you could interpret what I've done as a way of having local variables.
04:14:49 <john_cephalopoda> Phew, retro is a little more complex than gforth and pforth.
04:17:46 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:20:27 --- quit: pierpal (Quit: Poof)
04:20:47 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
04:39:18 <dave0> this is what i came up with
04:39:19 <dave0> http://termbin.com/65z4
04:44:40 <john_cephalopoda> dave0: Nice code!
04:45:09 <dave0> ehehhe thanks :-)
04:45:14 <dave0> it's not too long?
04:45:17 <john_cephalopoda> dave0: Why are you using the return stack instead of the regular stack?
04:46:00 <dave0> to make it easier to access the string c-addr n on the data stack
04:46:18 * KipIngram smiles
04:46:25 <KipIngram> Looks like C layout.  ;-)
04:46:32 <dave0> lol
04:46:50 <dave0> i have a lot of years of C to unlearn :-)
04:47:47 <KipIngram> Mine's ultimately about as long, but is organized into a fair number of short definitions - none  longer than 40-50 characters.
04:48:12 <KipIngram> Just the top part of the hierarchy looks like this:
04:48:30 <KipIngram> : EXPECT  OVER 0 SWAP C! 1 0 {{ (EXPECT) }} 4 DROPS ;
04:48:41 <KipIngram> :: (EXPECT)  _READ DROP ME [
04:48:48 <KipIngram> :: _READ  KEY ?EDIT 0<>ME ACCEPT ME [
04:48:58 <KipIngram> :: ?EDIT  COUNT ?ENTER ?BS ?CL ?CR ?CTRL 0 ;
04:49:00 <KipIngram> etc...
04:49:53 <KipIngram> (EXPECT) is where I just keep calling _READ indefinitely.
04:50:11 <KipIngram> It drops the terminating keystroke returned by _READ and loops (no handling of any higher keys).
04:50:32 <KipIngram> "Enter" is handled down below, and does a multi-level return to (EXPECT)'s caller - breaking the loop.
04:51:51 <dave0> the loop was hard.. at first i tried to write it like c...    while(true) { ... if(pressed_enter) break; ... }    but forth doesn't seem to like that
04:52:02 <KipIngram> So it's similar to your code; I've found that my conditional and multi-level returns sort of cause my "control structures" to spread out "vertically," across multiple definition levels.
04:53:09 <KipIngram> In ?EDIT, each of the words called (?ENTER, ?BS, etc.) checks for a particular character - if that is the character then they put a true flag on the stack and *double return*, taking control back out of ?EDIT.
04:53:21 <KipIngram> if I make it to the end of the list without that happening, I put the false flag on the stack and return.
04:54:08 <KipIngram> I suppose if you're not "in the mindset" of that sort of structure it might not be very readable, but I found that I *could* get into that mindset and it all seemed easy and clean - to me.
04:54:38 <KipIngram> Just as an example, this is ?CR:
04:54:40 <KipIngram> ?CR  12 .<>; DROP _CR 1 ;;
04:54:44 <KipIngram> Very short and terse.
04:55:13 <KipIngram> Ooops - failed to include the :: at the start there.
04:55:24 <dave0> i could use words to check for enter? and backspace?
04:55:52 <KipIngram> "if it's not 12 (the CR character code), return the zero flag.  Otherwise, drop that flag, handle CR, and return true."
04:56:07 <KipIngram> Rather, *double* return true.
04:56:16 <john_cephalopoda> dave0: I'll try to implement that same thing at home. I believe that it can be done with similar ease without the return stack.
04:57:08 <dave0> cool!
04:57:10 <john_cephalopoda> The scratch address is never changed so "addr - n - key" would mean that you only have to mess with the top two elements which is trivial in forth.
04:57:20 <john_cephalopoda> Brb
04:57:23 --- quit: john_cephalopoda (Quit: Trees can see into your soul. They lurk everywhere.)
04:57:49 <dave0> not trivial for me :-(
04:58:10 <dave0> i'm still a newbie :-)
05:07:19 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
05:08:13 --- quit: MrMobius (Ping timeout: 264 seconds)
05:08:13 --- nick: [1]MrMobius -> MrMobius
05:10:23 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
05:39:38 <dave0> brb need a cup of tea
06:08:21 <dave0> not real sure why i used the return stack...
06:08:43 <dave0> my first attempt (that didn't work) did it that way
06:14:36 <john_cephalopoda> Hmm, hard issue.
06:14:38 <john_cephalopoda> Brb
06:14:39 --- quit: john_cephalopoda (Quit: Trees can see into your soul. They lurk everywhere.)
06:18:46 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
06:59:49 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
07:10:45 <dave0> nite all
07:11:32 --- quit: dave0 (Quit: dave's not here)
07:17:37 <john_cephalopoda> Ahrg
07:17:43 <john_cephalopoda> I just finished dave's getline script.
07:18:23 <john_cephalopoda> https://thecutecuttlefish.org/tmp/getline.fth
07:20:46 <john_cephalopoda> It basically ended up being the same thing that dave wrote, but written from scratch.
07:21:40 <john_cephalopoda> I tried to put some definition out of the big thing but it doesn't work well
07:24:24 <WilhelmVonWeiner> You should try breaking code down into smaller words.
07:24:39 <WilhelmVonWeiner> makes it a lot easier to see what you can factor.
07:25:09 <john_cephalopoda> I tried to break it down into stuff like "enter?" "backspace?" and "key?".
07:26:04 <john_cephalopoda> But I _have_ to handle enter before anything and backspace before key and thus using nested ifs is basically the only possibility.
07:26:32 <WilhelmVonWeiner> Look up RDROP
07:27:59 <john_cephalopoda> If I would RDROP in a definition, it won't be able to return and FORTH would burn.
07:28:39 <john_cephalopoda> Or wait...
07:28:56 <john_cephalopoda> It will drop the return of the caller, which will be the getline process.
07:29:00 <WilhelmVonWeiner> That's why you write multiple definitions. I usually do ` : ESC? DUP 27 = IF RDROP .. THEN ;`
07:29:02 <john_cephalopoda> So it could kinda work.
07:29:24 <WilhelmVonWeiner> and then ESC calls whatever you want to do when you get ESC?
07:30:19 <john_cephalopoda> I am not really used to playing around with the return stack. Putting stuff onto it is fine but I like to leave it as I found it.
07:30:49 <WilhelmVonWeiner> get used to it, because it makes your code faster and the logic much less complicated
07:30:56 <WilhelmVonWeiner> no nested IFs required
07:31:05 <WilhelmVonWeiner> just skip all that code entirely
07:39:29 <WilhelmVonWeiner> Your control flow becomes real confusing
07:42:27 <KipIngram> john_cephalopoda: That's exactly how mine's broken down - into things like ?enter ?bs ?cr etc.
07:42:35 <KipIngram> Would you like me to post the code somewhere?
07:42:48 <KipIngram> But remember I have, and use, stack frames, so it wouldn't port to just any Forth.
07:43:18 <WilhelmVonWeiner> I mean `: CRNL? DUP 10 = SWAP 13 = OR ;` doesn't need stack frames or that
07:46:46 --- join: proteusguy (~proteus-g@159.192.218.105) joined #forth
07:46:46 --- mode: ChanServ set +v proteusguy
07:47:34 <KipIngram> No, that doesn't - it's really the overall functioning that uses the frame.  I just meant that my code would port "en masse" to another Forth.
07:47:41 <KipIngram> But it might still be fine for harvesting some ideas.
07:48:04 <KipIngram> s/would/wouldn't/
07:48:35 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
07:55:34 --- quit: tabemann (Ping timeout: 252 seconds)
07:57:20 <rdrop-exit> If you can afford the space, the simplest way to process keyboard input is using a keymap
07:57:57 <KipIngram> I agree - if space isn't an object that's far and away the cleanest solution.
07:58:21 <rdrop-exit> cells keymap + perform
08:05:18 <rdrop-exit> If limit the keymap to the ASCII control-codes (except DEL) that's just 32 cells
08:05:39 <rdrop-exit> *if you limit...
08:08:21 <KipIngram> Right.
08:10:24 <WilhelmVonWeiner> rdrop-exit: I really like that idea
08:10:31 <WilhelmVonWeiner> might nick it
08:10:46 <KipIngram> :-)
08:10:56 <rdrop-exit> A keymap is also useful for utilities such as editors, and macros, and input parsing etc...
08:11:11 <rdrop-exit> :)
08:11:15 <KipIngram> Also for formatted output.
08:11:20 <KipIngram> The various formatting chars.
08:11:28 <KipIngram> I actually do use a table for that.
08:12:11 <KipIngram> A little clever arithmetic to collapse those chars into one table range, then a table lookup and execution.
08:15:00 <rdrop-exit> right
08:15:41 <KipIngram> I actually treat format strings as little "programs" for a virtual machine.
08:15:57 <KipIngram> Digits accumulate into the top element of a little stack.
08:16:12 <KipIngram> That stack lives in one cell - it has eight one-byte "cells."
08:16:44 <KipIngram> So a format string can push numbers for field width, number of decimal places, etc. onto that stack, and then the actual format chars are "instruction" to execute.
08:17:08 <KipIngram> Works really well, and it's SO easy to remember what the strings should be, because I can just think of it in terms of running that little machine.
08:17:22 <rdrop-exit> nice
08:21:57 <rdrop-exit> Wilhelm: If you temporarily reassign key behaviors, be careful to restore them if there's an exception
08:24:55 <rdrop-exit> Gotta hit the sack, goodnight all
08:25:03 --- quit: rdrop-exit (Quit: Lost terminal)
08:46:57 <WilhelmVonWeiner> dave9: https://ghostbin.com/paste/ovsqg/raw
08:47:09 <WilhelmVonWeiner> That's my implementation
08:47:22 <WilhelmVonWeiner> lot of RDROPping for good measure
08:47:31 <WilhelmVonWeiner> I only write in uppercase for that retro feeling
08:48:38 --- quit: proteusguy (Ping timeout: 268 seconds)
08:48:42 <KipIngram> :-)  He went to bed, but can see it later.
08:50:11 <john_cephalopoda> WilhelmVonWeiner: Heh, I also like to write in UPPERCASE but in the case of this code I kept it lowercase (except for IF, ELSE, THEN, DO, UNTIL) to adhere to dave's coding standard.
08:55:34 <WilhelmVonWeiner> Dave can run it through sed or something. 
08:56:44 <john_cephalopoda> I tried to make my Mandelbrot stuff retro but didn't manage to do so yet.
08:57:16 <john_cephalopoda> I don't know how I can output things like with emit and CR in ANS.
08:57:56 <john_cephalopoda> When I use "rre", it will print nothing, when I use "listener" it will print "ok" after every line.
08:58:08 <WilhelmVonWeiner> `c:put` and `nl`
08:58:16 <WilhelmVonWeiner> rre runs a script and exits.
08:58:34 <WilhelmVonWeiner> Did you read through the docs/ folder and check some of the examples?
08:59:01 <john_cephalopoda> I used the put command with rre, without any result.
08:59:15 <john_cephalopoda> It just exits although it should theoretically print something.
08:59:25 <WilhelmVonWeiner> `retro` doesn't print `ok` after every line but I think it includes less features than `listener` since the latter is meant to be embedded into the rre executable.
08:59:29 <john_cephalopoda> When I use ri, it doesn't understand floats.
08:59:34 <WilhelmVonWeiner> john_cephalopoda: did you enclose your code in ~~~ ~~~
08:59:54 <john_cephalopoda> No, I didn't enclose my code in anything.
09:00:11 <WilhelmVonWeiner> https://ghostbin.com/paste/fhwfo
09:00:40 <WilhelmVonWeiner> rre only runs code in blocks of `~~~ (newline) ~~~`
09:01:20 --- quit: FatalNIX (Ping timeout: 272 seconds)
09:01:27 <WilhelmVonWeiner> the bundled tool `unu` can extract code from between those blocks. Retro source is written in some kind of markdown, aiding literate programming.
09:01:51 <WilhelmVonWeiner> check the examples/ folder for some interesting ways of problem solving - like `sort-on-stack.forth`
09:06:23 --- join: proteusguy (~proteus-g@159.192.218.105) joined #forth
09:06:23 --- mode: ChanServ set +v proteusguy
09:14:16 --- quit: ncv (Remote host closed the connection)
09:15:50 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:1ec6:932f:1b02:d27e) joined #forth
09:15:51 --- quit: ncv (Changing host)
09:15:51 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
09:21:03 --- quit: ncv (Remote host closed the connection)
09:21:44 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
09:50:40 --- join: FatalNIX (~FatalNIX@caligula.lobsternetworks.com) joined #forth
09:54:08 --- quit: ncv (Remote host closed the connection)
09:54:28 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
10:13:03 --- join: dys (~dys@tmo-106-168.customers.d1-online.com) joined #forth
10:46:09 --- quit: dys (Ping timeout: 244 seconds)
10:56:39 --- quit: pierpal (Read error: Connection reset by peer)
11:28:52 --- quit: dddddd (Ping timeout: 246 seconds)
11:43:14 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
11:45:57 --- join: dys (~dys@tmo-119-120.customers.d1-online.com) joined #forth
12:26:30 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
12:29:28 --- quit: MrMobius (Ping timeout: 252 seconds)
12:29:28 --- nick: [1]MrMobius -> MrMobius
12:36:24 --- quit: groovy2shoes (Quit: moritura te salutat)
13:40:07 <crc> http://forthworks.com/temp/EXPECT is an implementation of ANS style SPAN EXPECT and a `getline` using them (in retro, not ans forth)
14:43:55 --- join: wa5qjh (~quassel@175.158.225.222) joined #forth
14:43:56 --- quit: wa5qjh (Changing host)
14:43:56 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
15:34:09 --- join: dave0 (~dave@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
15:34:29 <dave0> hi
15:38:12 <WilhelmVonWeiner> dave0: you see my link to you?
15:38:19 <WilhelmVonWeiner> wrote your GETLINE in Forth
15:38:22 <WilhelmVonWeiner> so did john_cephalopoda 
15:38:51 <WilhelmVonWeiner> his is what i'd call ANS-Style, mine is FIG style
15:39:04 <WilhelmVonWeiner> Code-oriented vs Problem-oriented
15:39:30 <dave0> missed the link, can you re-paste please?
15:39:54 <WilhelmVonWeiner>  https://ghostbin.com/paste/ovsqg/raw
15:43:46 --- quit: Keshl_ (Quit: Konversation terminated!)
15:44:12 <dave0> ah cool
15:44:43 <WilhelmVonWeiner> you could change all those drops to putting junk on the stack really
15:44:51 <WilhelmVonWeiner> except in CRNL?
15:45:05 <dave0> PRINTER is the tricky one for me
15:45:20 <WilhelmVonWeiner> Yeah I wrote it a little verbose
15:45:37 <WilhelmVonWeiner> I think i'll start adding stack comments but I'll explain it
15:46:29 <WilhelmVonWeiner> you have <c-addr n c> on the stack, c-addr being your buffer, n being count, c being key
15:46:54 <WilhelmVonWeiner> move it to the return stack, to put it out the way for a second
15:47:29 <WilhelmVonWeiner> get the address of the current position in c-addr but duplicating both n and c-addr and adding them
15:47:39 <WilhelmVonWeiner> get back `c``
15:48:00 <WilhelmVonWeiner> and now your stack will be <c-addr n c-addr+n c>
15:48:19 <WilhelmVonWeiner> emit it, then store it at c-addr+n, then increment n
15:48:30 <WilhelmVonWeiner> did I exaplin that well enough
15:48:35 <dave0> i think your handling of c-addr n is much better than mine
15:48:44 <dave0> yep, i got it :-)
15:48:48 <WilhelmVonWeiner> what do you do with em?
15:49:44 <dave0> when i add a new character, i increment c-addr and decrement n, i treat it like a pointer in C
15:50:07 <dave0> you treat c-addr more like an array,where the base doesn't change, only n
15:50:54 <KipIngram> Is this for printing a string?
15:51:01 <WilhelmVonWeiner> think of c-addr to a pointer to the start of your memory block
15:51:23 <KipIngram> Or for getting a string?
15:51:23 <WilhelmVonWeiner> and then n is just however many bytes you're extending past that pointer.
15:51:38 <dave0> KipIngram: getting a string
15:51:38 <KipIngram> I also keep the base address fixed.
15:51:47 <KipIngram> I have base address and field width, neither of which change.
15:52:00 <KipIngram> Then I have character count in the buffer, and a cursor address.
15:52:01 <WilhelmVonWeiner> field width?
15:52:10 <KipIngram> Buffer size.
15:52:12 <dave0> WilhelmVonWeiner: why do you use all uppercase? :-)
15:52:24 <WilhelmVonWeiner> to pretend i'm living in 1979
15:52:27 <KipIngram> With separate character count and cursor position, I can move the cursor back into the middle of the string and insert there.
15:52:46 <WilhelmVonWeiner> also Lina forth is all uppercase and if i were on Linux i'd be using that
15:52:53 <KipIngram> The character count just sets the upper limit on how far right the cursor can move.
15:53:00 <Zarutian> hmm.. regarding angle calculations such as theta control of a diffrentially steered robot is okay to use a scaled range? that is from 0x0000 - 0xFFFF for 0°-359.99..° ?
15:53:03 <dave0> i will google lina forth
15:53:08 <KipIngram> And of course it's what gets compared to the buffer size.
15:53:21 <KipIngram> Even if cursor is in the middle, if I try to insert a char that will make count > size, it won't "take."
15:53:31 <WilhelmVonWeiner> yeah
15:53:39 <WilhelmVonWeiner> Zarutian: yeah, I did that for a uni project
15:54:00 <WilhelmVonWeiner> because the embedded boards didn't do fp
15:54:07 <WilhelmVonWeiner> well they didn't have FPUs
15:54:12 <Zarutian> WilhelmVonWeiner: have any good words/routines for such calculations?
15:54:19 <WilhelmVonWeiner> No, this was in C
15:54:48 <Zarutian> WilhelmVonWeiner: C is fine, I can translate it to the forth avr assembly code I am writing.
15:54:55 <Zarutian> forthy*
15:55:09 <WilhelmVonWeiner> I didn't do anything special is my point
15:55:52 <crc> ANS requires uppercase support for standard words, but not lowercase (3.3.1.2)
15:56:16 <WilhelmVonWeiner> crc: did not know that, thanks
15:56:49 --- quit: ashirase (Ping timeout: 264 seconds)
15:57:06 <KipIngram> Oh, I got my copy of that instruction path coprocessing book a couple days ago.
15:57:32 <WilhelmVonWeiner> I ordered two books off amazon yesterday
15:57:42 <WilhelmVonWeiner> Programming a Problem Oriented Language by our boy Chuck
15:57:46 <WilhelmVonWeiner> (read it online)
15:58:01 <WilhelmVonWeiner> and Data Oriented Programming (also read it online) by... some guy
15:58:07 <WilhelmVonWeiner> *Data Oriented design
15:58:14 <WilhelmVonWeiner> also, sorry for flooding the channel
16:00:35 <Zarutian> WilhelmVonWeiner: links to the online versions of those two books?
16:00:55 <WilhelmVonWeiner> lemme grab them, i'll query you
16:01:17 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
16:29:59 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth
16:39:55 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
16:49:50 --- join: TheCephalopod (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:53:48 --- quit: john_cephalopoda (Ping timeout: 272 seconds)
17:13:16 --- quit: proteusguy (Ping timeout: 246 seconds)
17:49:55 --- quit: ncv (Ping timeout: 250 seconds)
17:52:04 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
18:14:39 --- quit: wa5qjh (Remote host closed the connection)
18:18:29 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
18:25:59 --- quit: wa5qjh (Remote host closed the connection)
18:31:31 --- join: tabemann (~androirc@2600:380:664b:a999:bff3:a9a9:608b:bdd8) joined #forth
18:35:03 <tabemann> I'm not sure how those two bugs didn't cause attoforth to crash
18:41:12 --- join: wa5qjh (~quassel@110.54.182.240) joined #forth
18:41:12 --- quit: wa5qjh (Changing host)
18:41:13 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
18:50:02 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
18:50:02 --- quit: wa5qjh (Read error: Connection reset by peer)
18:50:50 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
18:55:20 <siraben> I've been thinking a lot about the benefits/drawbacks of static vs. dynamic/no type systems recently.  And I think each has their own benefits.  It's very easy to sketch out ideas in a dynamically typed or untyped language (like Forth) even if it means sacrificing correctness or security guarantees initially.  But if you want to "formalize" the idea, static type systems can help shape that.
18:55:41 <siraben> Although it is possible to do exploratory programming in statically typed languages, I still find it somewhat limiting
18:56:16 <siraben> Especially if I want to work with heterogeneous data structures.
18:59:22 <siraben> Anyone else have their own ideas on type systems?
19:04:46 --- join: proteusguy (~proteus-g@2001:44c8:4249:aa28:295a:8a85:8420:6052) joined #forth
19:04:46 --- mode: ChanServ set +v proteusguy
19:04:57 --- quit: wa5qjh (Remote host closed the connection)
19:09:34 --- nick: MrMobius -> [1]MrMobius
19:10:30 --- join: wa5qjh (~quassel@110.54.182.240) joined #forth
19:10:30 --- quit: wa5qjh (Changing host)
19:10:31 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
19:12:20 --- nick: [1]MrMobius -> MrMobius
19:17:33 --- quit: ncv (Remote host closed the connection)
19:19:08 --- nick: MrMobius -> [1]MrMobius
19:19:50 --- nick: [1]MrMobius -> MrMobius
19:21:45 --- nick: MrMobius -> [1]MrMobius
19:22:05 --- nick: [1]MrMobius -> MrMobius
19:22:06 <rdrop-exit> I view types as something implicit, in the end the only concrete types are those of the machine. Bullet proofing is done at input. The exceptions would be in very special cases high integrity cases such as space-born systems.
19:26:55 --- quit: tabemann (Ping timeout: 252 seconds)
19:29:09 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:1870:3255:3792:ba89) joined #forth
19:31:08 <siraben> Space-borne systems are amazing stuff. Radiation-hardened CPUs, temperatures near absolute zero, and not a lot of power
19:31:32 --- quit: proteusguy (Remote host closed the connection)
19:31:59 <siraben> Forth was used in the Philae spacecraft.
19:32:01 <siraben> http://www.mpeforth.com/press/MPE_PR_From_Telescope_to_Comet_2014_11_13.pdf
19:36:23 <rdrop-exit> Forth's been used in many spec-born and space-related applications
19:36:32 <rdrop-exit> *sace-born
19:36:38 <rdrop-exit> **space-born
19:36:52 <rdrop-exit> Damn, my typing is atrocious
19:37:29 <rdrop-exit> *** spaceborne
19:38:10 <rdrop-exit> Need ... more ... coffee :)
20:15:30 <tabemann> lol
20:15:40 --- quit: wa5qjh (Remote host closed the connection)
20:19:38 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
21:36:20 --- quit: pierpal (Quit: Poof)
21:36:38 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
21:39:51 --- quit: rdrop-exit (Quit: Lost terminal)
22:29:58 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
22:31:48 --- quit: ncv (Remote host closed the connection)
22:32:07 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
22:32:07 --- quit: ncv (Changing host)
22:32:07 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
22:41:44 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
22:48:27 --- quit: dys (Ping timeout: 244 seconds)
22:54:09 --- quit: dddddd (Remote host closed the connection)
23:37:28 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
23:38:13 --- quit: wa5qjh (Remote host closed the connection)
23:40:40 --- join: wa5qjh (~quassel@175.158.225.202) joined #forth
23:40:40 --- quit: wa5qjh (Changing host)
23:40:40 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
23:43:12 --- quit: wa5qjh (Remote host closed the connection)
23:54:56 --- join: wa5qjh (~quassel@175.158.225.202) joined #forth
23:54:56 --- quit: wa5qjh (Changing host)
23:54:56 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
23:59:59 --- log: ended forth/18.11.09