00:00:00 --- log: started forth/19.03.01
00:32:06 <the_cuckoo> cool - one more thing off my list :) - i can now create a new 'substack' which has its own data stack and inherits a copy of the dictionary of the stack which creates it (the dictionaries and data stack of either can change without affecting the other)
00:57:00 --- quit: yrm (Quit: yrm)
01:17:33 <yunfan> what does the word docol means? i mean the full name
01:44:19 <dave0> jonesforth speculates that it's "do colon"...   line 487    https://github.com/nornagon/jonesforth/blob/master/jonesforth.S
02:01:42 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
02:04:05 --- quit: ashirase (Ping timeout: 250 seconds)
02:10:01 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:12:13 --- quit: nighty- (Remote host closed the connection)
02:16:28 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
02:19:19 --- quit: dave0 (Quit: dave's not here)
02:20:52 <WilhelmVonWeiner> tell that to my wife
02:27:34 --- join: yrm (~yrm@KD106130203254.au-net.ne.jp) joined #forth
02:44:32 --- quit: Keshl_ (Quit: Konversation terminated!)
02:49:33 --- quit: yrm (Quit: yrm)
02:55:52 --- join: yrm (~yrm@KD106130203254.au-net.ne.jp) joined #forth
03:00:32 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
03:07:32 --- quit: yrm (Quit: yrm)
03:13:58 --- join: yrm (~yrm@KD106130203254.au-net.ne.jp) joined #forth
03:24:29 --- quit: yrm (Quit: yrm)
04:11:00 <corecode> hi
04:39:26 <KipIngram> yunfan: Yes, docol is the runtime that "handles" colon definitions.  It pushes the instruction pointer to the return stack and sets it to the first word of the new definition being executed, then goes to NEXT.
04:39:42 <KipIngram> I've also seen it written as (:).
04:40:31 <KipIngram> (;), the runtime compiled by the ; word, is the converse - it restores the instruction pointer to the previous value by popping it from the return stack, then runs NEXT, moving on through the higher level definition.
04:40:54 <KipIngram> Basically docol aka (:) and (;) are Forth's "call" and "return" operations.
04:41:35 <KipIngram> You may also see references to "dovar," "docon," and so on - those are the handlers for variaables, constants, etc.
04:43:01 --- quit: mark4 (Remote host closed the connection)
04:47:32 <KipIngram> ; itself is an immediate word that executes right away when it's encountered at the end of a definition.  It does two things: 1) compiles code that will cause the definition being made to end properly when it's executed, and 2) exits compile mode by setting STATE to 0.
04:48:03 <KipIngram> Item 1 there might be compilation of (;), or it might be transforming the item compiled just before from a call to a jump (tail optimization).
04:55:41 <corecode> i think you're explaining more than what was asked :)
05:00:24 <presiden> good
05:00:43 <KipIngram> I suppose.  Didn't seem like a whole lot else was going on, though.
05:01:47 <KipIngram> Good morning, btw.  Or good afternoon or evening - whatever works for you.  :-)
05:11:49 <KipIngram> Got a simple crufty little editor put together last night.  It just clears the screen and lists a section of my target block (these blocks are 4096 bytes --> 64 lines, which is too many to fit on my screen at once), and gives me a set of commands to do a few simple things like insert line, delete line, edit line, etc.
05:11:58 <KipIngram> Each command re-lists the block at the end.
05:12:18 <KipIngram> I added a bit of cursor control this morning so that line edits happen in place now - cursor jumps back to the bottom when I'm done.
05:13:01 <KipIngram> Shouldn't be too much more work to put this in a loop, keep up with the line I'm on, and trigger the commands with keystrokes, so it will essentially be a working screen editor.
05:13:19 <KipIngram> It's dodgy code right now, but I'll clean it up before long.
05:13:50 <KipIngram> I want to paint the edit area with a slightly different background, so it's visually distinct.
05:16:49 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
05:28:54 --- quit: mtsd (Remote host closed the connection)
05:29:50 --- join: inode (~inode@unaffiliated/inode) joined #forth
06:41:16 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
06:44:27 --- quit: MrMobius (Ping timeout: 250 seconds)
06:44:27 --- nick: [1]MrMobius -> MrMobius
07:39:06 --- quit: tabemann (Ping timeout: 250 seconds)
08:31:00 --- join: mark4 (~mark4@148.80.255.161) joined #forth
08:31:05 <mark4> msg nickserv identify wesdxc
08:31:12 <mark4> for christ sake i keep doing taht
08:32:14 <PoppaVic>  mark4 program a command string /foo
08:32:36 <PoppaVic> yay.. engine is working.. 'prims' and 'secondaries'.. Huzzah
08:33:41 <mark4> engine?
08:34:19 <PoppaVic> yeah. I been coding a simple DTC 'engine' with a synthetic set of opcodes.
08:34:36 <PoppaVic> in yer fav: C ;-)
08:34:57 <mark4> yay
08:35:14 <mark4> i promis to only THINK about banning you for even THINKING C :P
08:35:33 <PoppaVic> yeah.. all the opcodes wee working - HAH! - and I just added NEXT, ENTER and EXIT
08:35:41 <PoppaVic> wee/were
08:35:51 <mark4> enter = nest?
08:36:06 <mark4> or docolon etc etc
08:36:15 <PoppaVic> mark4: well, I just wanted something to try on avr's and samd's and emulate as well on linux.
08:36:44 <PoppaVic> right: I went the route of Super8 chip, and ENTER is the same as DTC[ and EXIT is ]DTC
08:37:26 <PoppaVic> so, I can get into an ITC list from a packed bytecode sequence and out again
08:37:50 <PoppaVic> needless to say, I wish I had a beer to raise and toast with ;-)
08:37:53 <mark4> maybe i should send you my avr assembler
08:38:09 <PoppaVic> go for it, never hurts to have another assembler.
08:39:13 <mark4> need to clean up the sources, and you would have to make a definitions file for YOUR device :)
08:39:16 <mark4> devices
08:39:41 <PoppaVic> wot! you don't strip the avr-gcc files? shameful!
08:40:25 <PoppaVic> how bad are your macros? I heard about you assembler-writers before! ;-)
08:41:25 <mark4> if you can code avr assembler using any other avr assembler you can use this one
08:41:45 <PoppaVic> heh. cool ;-)
08:42:23 <mark4> no 5 # eax mov bullshit either
08:42:26 <mark4> mov eax, # 5
08:42:30 <mark4> except thats x86
08:42:34 <mark4> but u get what i mean
08:44:40 <PoppaVic> yeah
08:44:40 <PoppaVic> You mean it's readable ;-)
08:45:08 <zy]x[yz> isn't that antithetical to forth
08:45:32 <PoppaVic> zy]x[yz: wot?
08:46:34 <zy]x[yz> that a non-rpn syntax would be more readable?
08:47:53 <PoppaVic> zy]x[yz: all assemblers already suffer readability. Forth assemblers can make it even worse
08:48:58 <zy]x[yz> assemblers suffer readability??  it's an instruction per line.  how more straightforward can you get?
08:50:16 <PoppaVic> mark4: he's all yers ;-)
08:51:39 <zy]x[yz> i don't know if mark4 is going to defend you since he just touted a very traditional-looking assembler syntax as being more readable than what a forth assembler usually looks like
08:52:28 <PoppaVic> I don't need defense, as I am not offended.
08:52:39 <zy]x[yz> defend your position, i mean
08:52:57 <PoppaVic> Why?
08:53:15 <zy]x[yz> nevermind.  i forgot you don't speak a human language
08:54:19 <PoppaVic> memory issues too, eh?
09:05:19 <corecode> hi
09:07:31 <presiden> Forth is like Euclid's Element
09:09:28 <presiden> You have small number of postulates. That becomes the building blocks for larger theorems
09:09:56 <zy]x[yz> this is how programming works in general though
09:10:03 <zy]x[yz> why is that always presented as though it's unique to forth?
09:10:54 <mechaniputer> Forth takes it nearly to one extreme and makes such compositional thinking essential to using it at all.
09:11:29 <zy]x[yz> forth doesn't do that, though
09:11:34 <presiden> There's only 5 postulates in euclid's element iirc
09:11:48 <presiden> and every theorem are derived from them
09:11:57 <zy]x[yz> i know it doesn't because i keep hearing about how the worst forth is when people try to write c in forth
09:12:03 <zy]x[yz> which tells me forth does nothing to prevent it
09:12:31 <corecode> so how should i extend this irc bot
09:13:03 <zy]x[yz> likewise, modern wisdom generally frowns on giant, long-winded function definitions in other languages, as well
09:13:54 <WilhelmVonWeiner> very true
09:14:23 <zy]x[yz> you have to separate good software design philosophy from the language.  chuck may have preached a lot of good philosophy, but that doesn't necessarily make it a quality of forth itself
09:14:38 <mark4> before i learned forth i learned asm on multiple devices
09:15:03 <mark4> whil i have NO trouble with mov dst, src OR mov src, dst i have extreme problems with src, dst, mov
09:15:24 <mark4> i cant read it. in order to read it i have to make a copy of it, sanitize it and then i can understand it
09:15:39 <WilhelmVonWeiner> I think the difference between small functions in Forth and C is a small Forth word allows you still to be more expressive than a small C function
09:15:47 <mark4> also, with x4 my sources are built for NASM
09:16:12 <mark4> if/when i implement an x86 assembler the ONLY edits i want to have to do is to inject some spaces here and there
09:16:25 <mark4> NOT totally rewrite the entire thing just for the assembler
09:16:36 <mark4> i never liked backwards assembly
09:18:02 <zy]x[yz> i was just noting that it's an odd complaint from a forther
09:18:23 <zy]x[yz> because if someone complained about rpn notation being backwards, you'd tell them it isn't or that they can adjust to it
09:20:01 --- quit: Zarutian (Ping timeout: 250 seconds)
09:25:15 <presiden> anyway, my shower of thought was, "5 postulates is enough to derive any theorem in (euclidean) geometry", and that realization kinda reminds me of Forth
09:25:44 <corecode> what about lisp
09:25:53 <corecode> does it remind you of lisp too?
09:26:04 <presiden> that's god language
09:39:08 --- quit: cantstanya (Remote host closed the connection)
09:41:52 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth
09:44:12 <mark4> zy]x[yz: just saw a comment of yours above about the industry discouraging wall of text functions... not in my experience.  function growth hormone imbalance syndrome is a requirement from what I have seen after 30+ years as a consultant.
09:45:31 <mark4> had one job where one source file had one function. it was a 6 case switch statement. every case was a 20 case switch statement where every case was a 5 case switch statement where ever... . . ..
09:45:35 <mark4> the file was 200 pages long
09:46:14 <PoppaVic> mark4: and how many vars in the func? ;-P
09:50:42 <zy]x[yz> mark4, i see it too.  sure, of course it happens, and usually the perpetrators are people whose employment i question in general.  that doesn't mean it isn't discouraged
09:52:24 <mark4> i know they talk the talk, very VERY few walk the walk
09:52:46 <zy]x[yz> the problem that i've seen in the workplace is more fundamental than that: management only sees results, so those who crank out garbage code which appears to work today are deemed "rock start programmers" and rewarded, and then they're put on the front line of the next project while the rest of us spend the next 5 years rewriting their shit so that it actually works
09:52:57 <zy]x[yz> but i would never complain about that because it keeps me employed
09:53:28 <mark4> :)
09:54:13 <john_cephalopoda> In industrial settings, long functions are discouraged.
09:54:51 <john_cephalopoda> MISRA and the like got guidelines on that.
09:55:20 <zy]x[yz> i will say one thing about forth that really appeals to me is its use of screen space
09:55:35 <zy]x[yz> i appreciate that you get to code in two dimensions
09:55:47 <zy]x[yz> if you tried to write c like that, it would be unintelligible
10:04:26 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
10:10:14 --- quit: nighty- (Remote host closed the connection)
10:32:09 <WilhelmVonWeiner> 100%
10:32:39 <WilhelmVonWeiner> forth's unique syntax and so code style and formatting makes it really appeal to me
10:32:46 <pointfree> zy]x[yz: It's true that nearly every language talks about composability. Most other languages try to bake-in a minimal composable syntax ...but without implicit parameter passing, composability is not going to be extensible.
10:33:30 <zy]x[yz> yeah, i guess that's true
10:33:43 <WilhelmVonWeiner> the stack (or a queue or something similar) is so good
10:33:56 <WilhelmVonWeiner> i wish all languages had it
10:34:17 <zy]x[yz> i don't know, i'm torn on that one.  it's awesome when it flows well, but when it doesn't it sucks
11:03:59 <corecode> WilhelmVonWeiner: gforth's gforth.el unfortunately also doesn't align code
11:04:17 <corecode> tho maybe it is not necessary with syntax hilighting
11:05:07 <WilhelmVonWeiner> I don't use syntax highlighting
11:05:21 <WilhelmVonWeiner> which is why formatting holds importance
11:05:25 <corecode> yea
11:05:43 <corecode> do you have align hooks for emacs?
11:05:46 <WilhelmVonWeiner> Leo Brodie's forth style guide is what I'll follow
11:05:47 <WilhelmVonWeiner> no
11:05:55 <WilhelmVonWeiner> I just turn on fundamental mode
11:06:27 <corecode> and push space a lot?
11:06:57 <WilhelmVonWeiner> tab-align 4 somewhere in my emacs config 
11:07:01 <WilhelmVonWeiner> something like that anyhow
11:07:13 <WilhelmVonWeiner> I like to avoid multiline definitions
11:08:14 <corecode> yes
11:08:20 <corecode> why no syntax hilight?
11:09:49 <pointfree> mecrisp uses .txt for forth source files, I guess because forth has no syntax.
11:12:40 <corecode> but it has semantics
12:13:22 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
12:55:27 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
12:58:02 <dave0> hi
13:03:36 <crc> I don't use syntax highlighting when editing code, but do sometimes use it when reading code; it can be helpful when skimming quickly
13:16:39 --- quit: mtsd (Quit: WeeChat 1.6)
13:18:38 <crc> http://forth.works/60d80f497ff2a21548cc9bb356377306.png - I color the start of words, immediate words, numbers, pointers, strings, characters, and comments
13:19:37 <the_cuckoo> i like the colouring which vim gives with the forth syntax - but the behaviour is all wrong
13:22:28 <the_cuckoo> as in, when i do a 'change word' (cw), it greedily gobbles up punctuation and alphanumerics rather than just the type of thing i was on when i started (like it does for others) - have looked at the config, but don't have a clue what to do
13:25:51 <john_cephalopoda> crc: Geany does horrible syntax highlighting for forth xp
13:29:15 <dave0> ah so when it's syntax hilighting, it looks up each word and colours it?
13:29:59 <dave0> i expected you could only colour numbers and non-numbers
13:30:15 <crc> I use nano, the stock (n)vi shipped by openbsd, a line editor I wrote on the terminal/ssh, and Textastic on iOS
13:30:32 <crc> No X11 on my machines currently, so things like Geany aren't an option
13:31:12 <crc> and the only one I have with syntax highlighting is nano; I have to manually enable it on the command line to use it
14:32:23 --- quit: mark4 (Quit: Leaving)
14:45:09 --- join: mstevens_ (sid285816@gateway/web/irccloud.com/x-wsjtnouwqhjbtciq) joined #forth
14:53:00 --- quit: mstevens (*.net *.split)
14:53:04 --- nick: mstevens_ -> mstevens
15:47:30 --- quit: proteusguy (Ping timeout: 245 seconds)
15:51:48 <KipIngram> It's slightly annoying to have a word to set the background color called bg.bgr instead of bg.rgb.  But it makes the generation of the ANSI sequence so much tidier.  :-|
15:52:08 <KipIngram> Hey, I did up a couple of kind of nice words to help with that.
15:52:26 <KipIngram> I have #; which prints a number (with no trailing space) from the stack, followed by a semicolon.
15:53:01 <KipIngram> And then #. which takes ( n ch --); it prints the number followed by emitting the char (to wrap up the ansi sequence).
15:53:13 <KipIngram> With that, that background color word becomes this:
15:53:28 <KipIngram> : bg.bgr  csi 48 #; 2 #; #; #; 109 #. ;
15:54:15 <KipIngram> I'm only using it for a shade of gray right now, but it's generic.
16:03:47 <john_cephalopoda> KipIngram: opencv uses a lot of BGR
16:05:50 <KipIngram> :-)
16:06:03 <KipIngram> Ok, maybe I'm in acceptable company rather than "weird."
16:06:32 <KipIngram> This editor is coming along nicely - got the code to something I consider an acceptable state of cleanliness, and functionally it seems solid.
16:07:06 <KipIngram> No cut/copy/paste capabilities yet, though, and I want to "power up" the basic "read a line" utility (more editing and navigation power).
16:07:29 <KipIngram> And then finally I want to wrap it in a loop so that it functions as a screen editor instead of a "one line op at a time" command driven editor.
16:07:45 <KipIngram> 25 lines of code so far.
16:09:23 <KipIngram> That includes seven lines of ANSI sequence utilities, that really should be considered general utilities rather than part of the editor, though.
16:15:25 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
16:24:42 <rdrop-exit> Good morning Forthwrights c[_]
16:30:17 <KipIngram> Good "morning," rdrop-exit.  :-)
16:30:23 <KipIngram> Saturday morning for you?
16:30:50 <rdrop-exit> Hi KipIngram, yes I'm still half-asleep
16:31:02 <KipIngram> Coffee is your friend.
16:31:41 <rdrop-exit> Coffee is life
16:32:14 <KipIngram> : wakefulness  coffee brew cup get coffee cup pour coffee drink ;
16:33:06 <KipIngram> Or maybe that should be cup drink-from at the end.
16:33:29 <presiden> good morning saturday
16:33:43 * KipIngram is still basking in Friday evening.
16:33:49 <rdrop-exit> Hi presiden
16:37:32 <rdrop-exit> You're missing GRIND and a few more steps at the beginning, I use an espresso machine.
16:40:08 <KipIngram> :-)
16:40:21 <KipIngram> that would be in the definition of BREW, right?
16:40:27 <KipIngram> I just wasn't detailed enough.
16:41:26 <rdrop-exit> :)
16:42:22 --- quit: dddddd (Remote host closed the connection)
16:42:44 <rdrop-exit> machine operate
16:43:18 <rdrop-exit> zombie-mode off
16:54:17 --- quit: john_cephalopoda (Ping timeout: 264 seconds)
16:55:52 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:01:01 <rdrop-exit> Any word-of-the-day?
17:04:08 <KipIngram> Um, "above."
17:04:38 <KipIngram> Number of bytes required for the cmove or <cmove when inserting or deleting a 64-byte blank line in a block buffer.
17:05:24 <rdrop-exit> Cool
17:08:08 <rdrop-exit> I partially reworked my ui, split the screen into 3 panes (console, viewport, side panel)
17:08:17 <KipIngram> : above  63 over - 6 << swap ;
17:08:31 <KipIngram> Um, that's for a 4096 byte block.
17:08:34 <KipIngram> so it has 64 lines.
17:09:01 <KipIngram> Oh, I misdescribed it.
17:09:17 <KipIngram> Well, I described it right, but it has this:
17:09:35 <KipIngram> : above ( line -- bytes line) ... ;
17:11:41 <rdrop-exit> cool
17:16:19 <rdrop-exit> This is my new word to set the user interface focus to the console pane:
17:16:34 <rdrop-exit> a : console ( -- )
17:16:35 <rdrop-exit> b   'focus references console-focus
17:16:35 <rdrop-exit> c   blinking underline cursor !  console-keys keymap ! ; compiled
17:18:35 <rdrop-exit> This one sets it to the viewport (which displays the current block):
17:18:47 <rdrop-exit> 2 : viewport ( -- )
17:18:47 <rdrop-exit> 3   'focus references viewport-focus
17:18:47 <rdrop-exit> 4   blinking box cursor !  viewport-keys keymap ! ;
17:21:41 <KipIngram> Should I try to look at that as an "imperative set of actions," or more as a structural definition?
17:22:05 <KipIngram> the single characters are just line #'s or something?
17:22:14 <PoppaVic> yes
17:22:17 <rdrop-exit> Yes
17:24:41 <rdrop-exit> They're actions
17:25:54 <rdrop-exit> These are the changes to the user interface state that move the focus of interaction to the particular pane, the console pane or viewport pane as the case may be
17:26:09 <KipIngram> Ok, got it.  Cool.
17:26:19 <KipIngram> I haven't had to think about that sort of thing yet, but I will.
17:26:52 <rdrop-exit> Each pane has its own key mappings
17:27:21 <KipIngram> Oh, neat.
17:27:54 <rdrop-exit> A little too modal, but its a start
17:28:23 <KipIngram> I didn't opt for a table driven approach for that.  I do process keys different ways in different places, but I do it via code.
17:28:52 <KipIngram> Inner words that are used in multiple places return on all keys they don't know how to handle, and the word outside that supplies that handling and then recalls / restarts the inner word.
17:29:14 <KipIngram> For example, EXPECT and QUERY both use the same basic line input word.
17:29:31 <KipIngram> EXPECT ignores vertical motion keys, but QUERY handles them to provide command history navigation.
17:29:48 <KipIngram> The editor will handle them to move up and down in my buffer.
17:31:30 <rdrop-exit> I feed the keys to REACT as they come in, REACT executes the corresponding action registered with the current keymap, then refreshes the display.
17:33:36 <rdrop-exit> REACT uses REACTION to get the behavior of the key from the current keymap
17:33:46 <rdrop-exit>  : reaction ( c -- a ) cells keymap @ + ;
17:35:15 <rdrop-exit> I use 7-bit ASCII in my host Forth, so a keymap is 128 cells
17:42:19 <rdrop-exit> Not the way I would do it in a target Forth, but I want the flexibility on a host Forth.
17:45:20 <rdrop-exit> Also makes parsing simpler.
17:57:48 <dave0> is there any advantage to separating the word headers/dictionary from the machine code/threaded words?
17:59:52 <rdrop-exit> There are tradeoffs. You could have the headers on a different machine from the runtime code for example.
18:04:04 <rdrop-exit> Separated headers allows certain coding techniques which you can't do when header data is interspersed with code.
18:04:21 <PoppaVic> you can decapitate it easier, too
18:04:28 <rdrop-exit> right
18:05:46 <presiden> decapitate?
18:06:00 <rdrop-exit> delete a header
18:06:39 <presiden> is there a reason why you want that?
18:06:50 <rdrop-exit> Save space on a target
18:06:58 <presiden> ah, I see
18:11:28 <rdrop-exit> It's a tradeoff, extra pointer field is required, and more administrivia words.
18:11:47 <PoppaVic> presiden: you also might develop the entire application, decapitate the forth - and you have a turnkey app they can't extend/break.
18:12:17 <rdrop-exit> Also makes it harder to reverse engineer.
18:15:03 <rdrop-exit> On DOS with it's 64k segments, it often made sense to headers in a separate segment.
18:15:10 <rdrop-exit> * its
18:16:33 <rdrop-exit> * ... to have headers in ...
18:17:24 <rdrop-exit> It simplifies some things, complicates others.
18:19:55 <rdrop-exit> On x86 systems interspersing native code and data can have major performance implications.
18:23:38 <rdrop-exit> Although I'm out of touch with low level x86, so don't take my word for it.
18:25:01 --- join: tbemann (~androirc@2600:380:643d:3071:6598:4f7d:b18c:11ee) joined #forth
18:25:21 <tbemann> hey guys
18:25:41 <rdrop-exit> Hi tbemann, any relation to tabemann? :)
18:25:50 <tbemann> ah yah
18:25:55 <rdrop-exit> :))
18:27:34 <tbemann> now that I have a non-crashy hashforth, I should work on a proper line editor for it
18:30:24 <rdrop-exit> ok
18:31:02 <rdrop-exit> I don't do line editors, only block editors
18:31:08 <tbemann> there are to many differences between hashforth and attoforth for me to easily port attoforth's line editor to hashforth, especially if I want to avoid ALLOCATE, which attoforth's line editor uses liberally
18:31:30 <tbemann> you're inspired by LaForth
18:31:38 <rdrop-exit> Right
18:33:22 <presiden> stupid question, what's block editors?
18:33:27 <rdrop-exit> I haven't done a line editor in decades
18:33:46 <PoppaVic> presiden: desgined for block-files, not text-files
18:34:32 <rdrop-exit> presiden: on a block-based forth, source code is stored in 1024 byte blocks, your editor treats each block as a small file, it's like coding on index cards.
18:35:25 <rdrop-exit> In traditional forth terminology a 1k block used to store source code is often called a "screen".
18:36:29 <tbemann> oh there's my dinner - bbl
18:36:30 <rdrop-exit> A 1024 byte block is displayed and edited as 16 lines of 64 characters each.
18:36:45 <rdrop-exit> bon appetit tbemann
18:36:51 --- quit: tbemann (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
18:40:11 <rdrop-exit> A block used to store only comments is traditionaly called a "shadow" block
18:42:17 <rdrop-exit> Some Forth programmers prefer files, some prefer blocks.
18:44:33 <rdrop-exit> Bare metal Forths tend to use blocks.
18:44:41 <presiden> so, compared to files, what advantage you get from blocks?
18:46:36 <rdrop-exit> From an architecture standpoint you don't need an OS. From a usage standpoint blocks are simple.
18:47:08 <rdrop-exit> The rest is more a matter of taste and coding style.
18:48:58 <presiden> i see
18:50:27 <rdrop-exit> It you care about the Forth Standard, note that files are optional, while block support must be provided if files are provided.
18:51:26 <rdrop-exit> OS based Forths will usually let you work with blocks stored in an OS file.
18:53:27 <rdrop-exit> Blocks vs files has often been a divisive topic in the Forth world.
18:53:55 <PoppaVic> but, tastes great with popcorn
18:54:11 <rdrop-exit> :)
18:55:27 <rdrop-exit> Some considered block based source one of the major stumbling blocks (no pun intended) for newcomers to Forth.
18:56:11 <rdrop-exit> You can't just fire up your favorite editor, you have to use a special editor.
18:56:26 <rdrop-exit> Personally I luv blocks.
18:58:00 <rdrop-exit> But I'm a greybeard.
18:59:31 <rdrop-exit> A similar debate occured in the APL world with their special keyboards and characters.
19:02:36 <rdrop-exit> And in the IBM world with their block mode terminals and editors (e.g. Xedit) vs the Unix world's character-oriented terminals and editors.
19:03:56 <rdrop-exit> brb
19:07:15 <rdrop-exit> back
19:16:33 <Zarutian> here is a challange for you: You know Bittorrent mainnet Kadmila p2p overlay network used for Distributed Hash Table for magnetic-link based torrents? Turns out there is an extension that is somewhat widely implemented (havent checked that much) that allows for storing up to 1000 bytes of payload.
19:17:13 <Zarutian> Under an sha1 hash. Two options are available, immutable and mutable.
19:17:44 <Zarutian> The latter uses the sha1 hash of an ed25519 key as the lookup-key
19:18:06 <Zarutian> the former? It just the sha1 hash of the payload
19:18:36 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
19:19:46 <Zarutian> so, if we store 512 byte 'sectors' as immutable payloads (dont worry, two hours is how long these payloads usually live without refreshing) then you can use the Bittorrent DHT as a 'lossy/lousy' block storage.
19:20:58 <Zarutian> hmm.. better yet. Lets have each even 'sector' also have the sha1 hash of the following odd 'sector' in the payload.
19:21:21 <Zarutian> the challange is of course, who would be the first here to implement this?
19:21:32 <rdrop-exit> You?
19:22:06 <Zarutian> perhaps, but not now as I am off to bed. Just thought of mentioning this here.
19:22:48 <rdrop-exit> One of our #forth denizens uses the gopher protocol for block storage
19:23:13 <crc> that would be me... :)
19:23:22 <rdrop-exit> There you go! :)
19:27:38 <crc> I haven't tied the new block editor to the gopher-based block storage yet, but will do so as soon as I'm done the refactoring.
19:32:44 <rdrop-exit> Neat concept
19:39:29 <rdrop-exit> Gotta go, catch you all later. Keep on Forthin'
19:39:39 --- quit: rdrop-exit (Quit: Lost terminal)
20:05:53 <KipIngram> crc: Can you tell me a little about that?  I remember gopher from long, LONG ago; I had no idea it was even still relevant.
20:06:23 --- quit: dave0 (Quit: dave's not here)
20:06:34 <KipIngram> I'm refreshing my "gopher memory" on Wikipedia right now.
20:06:54 <KipIngram> Ok, so it would be network deployable - that's... rather interesting.
20:07:03 <KipIngram> And as old as it is, it's probably rather simple.
20:07:13 <PoppaVic> it was, from what I recall
20:07:39 <PoppaVic> also crude, primitive and irritating - but I only recall it from pre html ;-)
20:08:31 <KipIngram> So, it looks like with this you could have an embedded gadget or something access block storage from pretty much anywhere it could reach on the internet?
20:08:55 <PoppaVic> sounds like it
20:09:20 <crc> KipIngram: I have a gopher server that accepts specially constructed selectors to update a block on the server.
20:09:43 <KipIngram> That's a pretty damn fascinating idea.  I mean, clearly we'd all know that such a thing was technically possible.  But I didn't realize that there was a ready and waiting protocol.
20:09:58 <crc> http://forth.works/321cc29e29a5c26d561e5637adfe92aa or 
20:09:58 <crc> gopher://forth.works/0/321cc29e29a5c26d561e5637adfe92aa for the server
20:09:58 <KipIngram> That's really cool.
20:10:24 <crc> http://forth.works/232e8e09ee888a86249a43af4dd5d6dd or
20:10:25 <crc> gopher://forth.works/0/232e8e09ee888a86249a43af4dd5d6dd for the old block editor using it
20:10:26 <PoppaVic> ah, Gran Torino - I needed that ;-)
20:11:26 <KipIngram> Ok, that's the neat new knowledge of the day.
20:12:01 <crc> gopher://forthworks.com:8008/ allows browsing the blocks via a standard gopher client
20:12:12 <crc> it works petty well in practice
20:13:05 <KipIngram> What really gets my attention is that it's based on something *standard*, but yet something that's from the "simple days" of computing.  I haven't studied it yet, but just based on its period of origin I'm betting that it would prove easier to implement than a lot of more modern stuff.
20:13:46 --- quit: rprimus_ (Ping timeout: 255 seconds)
20:14:14 <crc> I do rather a lot of stuff with gopher. It's more limited than HTTP, but is very easy to work with
20:16:06 --- join: rprimus (~micro@unaffiliated/micro) joined #forth
20:32:21 <siraben> I'm jealous of those Smalltalk systems, why can't Forth do the same with the right abstractions?
20:36:11 <PoppaVic> .sigh
20:51:15 <KipIngram> Forth *can* do anything.  It's as powerful as machine code, and everything is machine code.
20:52:03 <KipIngram> So I think the answer has to be just that no one has built those abstractions yet.
20:52:15 <KipIngram> Or, rather, let me say "to date."
20:52:26 <KipIngram> "Yet" makes it sound like it's gonna happen - it may or may not.
20:52:31 <PoppaVic> I think the answer is "why bother?"
20:53:00 <KipIngram> The thing that stands out re: Smalltalk to me is the drag and rop user interface.
20:53:02 <PoppaVic> if you want smalltalk, use smalltalk. If you want ada, use ada. C++? use c++
20:53:08 <KipIngram> Is there some part of it that you like that isn't captured by that?
20:53:52 <PoppaVic> KipIngram: kewl! then you can youtube yer programming lectures!
20:54:04 <KipIngram> Well, I'll say again - one of the strengths of Forth is that you can do absolutely anything with it.
20:54:22 <KipIngram> It's a very "personal" thing.
21:00:39 <KipIngram> ?
21:01:45 <KipIngram> This is going to sound pretty elitist, but I actually think that the graphical user interface is one of the worst things that has happened to computing in ages.  It encouraged... well, damn near *everyone* to wade into computing as though they have something to offer.
21:01:52 --- join: yrm (~yrm@KD106132216087.au-net.ne.jp) joined #forth
21:02:20 <KipIngram> When in reality it's like any other field - only a few people, who have studied that field for a long time and who have natural talent in the area, *really* have something to offer.
21:02:37 <KipIngram> It raised the signal to noise ratio in our field enormously.
21:02:43 <KipIngram> I'm sorry - lowered it.
21:03:35 <PoppaVic> graphics are useful. I don't need to D&D code whatzits.
21:03:44 <KipIngram> That, combined with social and political changes - it's no longer ok to look at someone's position / offering and just delcare "That is bullshit - rejected," have put us in a very unfavorable "progress position."
21:04:09 <PoppaVic> although, I freely admit: that D&D interface to program the circuitPython modules is damned slick
21:04:11 <KipIngram> Damn - I buggered my grammar there - sorry about that.
21:04:22 <KipIngram> It's Friday evening - I've had ethyl alcohol.
21:04:38 <PoppaVic> and you didn't share, either
21:04:44 <KipIngram> "Quality down, inhibitions down."
21:05:10 <KipIngram> I didn't share?  I'm sorry - I lost your thread.
21:06:33 --- quit: yrm (Client Quit)
21:26:56 <PoppaVic> ok, predoc.c updated. Yay.. Modified sources to use another include for the control-ops.
21:31:14 --- join: yrm (~yrm@KD106132216087.au-net.ne.jp) joined #forth
21:34:04 <KipIngram> What's predoc.c do?
22:17:51 --- quit: yrm (Ping timeout: 250 seconds)
22:39:46 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
22:40:13 <dave0> re
23:02:31 --- join: yrm (~yrm@KD106132216087.au-net.ne.jp) joined #forth
23:59:59 --- log: ended forth/19.03.01