00:00:00 --- log: started forth/19.02.21 00:35:35 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 00:51:10 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 00:51:46 re 00:51:56 Hi dave0 00:52:16 hi rdrop-exit 00:55:47 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 01:01:41 Morning all 01:01:55 Hi Wilhelm 01:04:44 0902 and I can't wait for my lunch break, Redis and ELK stack and JSON queries and whatever is aching my balls 01:04:51 0904 even 01:05:42 --- quit: yrm (Quit: yrm) 01:06:17 --- join: yrm (~yrm@KD106130204082.au-net.ne.jp) joined #forth 01:07:03 what's your problem with redis? WilhelmVonWeiner 01:08:01 --- quit: yrm (Read error: Connection reset by peer) 01:22:09 I have absolutely no idea how it's been configured and what's sending it data and where the data is going 01:22:23 apart from that it seems pretty cool 01:28:56 --- quit: spestov (Ping timeout: 268 seconds) 01:49:14 --- quit: rdrop-exit (Quit: Lost terminal) 01:58:46 --- join: yrm (~yrm@KD106130204082.au-net.ne.jp) joined #forth 02:00:25 --- quit: yrm (Client Quit) 02:00:35 WilhelmVonWeiner: it could read configuration items from its cmd options 02:00:49 WilhelmVonWeiner: also stdin 02:01:20 and it store data in ram mainly, also harddisk if you open some options 02:04:21 --- quit: ashirase (Ping timeout: 250 seconds) 02:15:17 ours appears to have been configured to read json from two servers and send it to logstash to it can be indexed with Elasticsearch 02:16:41 I have to get the data out of elasticsearch and match it with data kept in CSV on two load balanced machines and combine that to send to a MySQL database 02:17:06 No idea why they're mixing SQL and NoSQL in this weird way 02:20:28 well mostly its the legacy problem 02:20:43 like someone want nosql to be spread 02:20:57 while in the end, the product cant solve all the problems 03:07:52 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 03:25:52 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 03:48:19 hmm - anyone used asciinema here? was just playing with it - https://asciinema.org/a/IfgtdGC0QM4lcMBoLDw5SmbwU - really needs to play faster though :-/ 03:55:55 --- quit: spestov (Ping timeout: 255 seconds) 04:06:42 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 04:32:43 --- quit: dave9 (Ping timeout: 272 seconds) 04:33:53 --- quit: dave0 (Ping timeout: 264 seconds) 04:38:40 --- quit: spestov (Ping timeout: 255 seconds) 04:50:46 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 04:51:56 --- join: dave9 (~dave@193.060.dsl.syd.iprimus.net.au) joined #forth 04:54:14 re 05:08:02 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 05:37:26 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 06:01:15 --- quit: spestov (Ping timeout: 245 seconds) 06:03:34 --- quit: nighty- (Quit: Disappears in a puff of smoke) 06:20:41 --- quit: dave0 (Quit: dave's not here) 06:27:18 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 07:21:53 --- quit: tabemann (Ping timeout: 264 seconds) 07:27:37 --- quit: spestov (Ping timeout: 250 seconds) 07:32:15 --- quit: Zarutian (Read error: Connection reset by peer) 07:32:45 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 07:54:32 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 08:20:32 hmm - the forth parse word... been really struggling with that one... 08:22:34 have something which works for me, but it's definitely not standard - kinda weird even 08:24:39 what's the issue? 08:28:55 implementation specific i guess - kinda difficult to go into all the details - but i do think it's just an awkward thing in general 08:30:15 parsing is as simple as SKIP+SCAN - everything else is noise 08:31:22 yeah - i think it just comes down to my own approach and the placement of the tokensizing logic - that 08:31:45 that's kinda on the outside... though i suppose it really doesn't need to be now 08:34:30 my parse is ugly 08:34:34 i should rewrite it 08:37:04 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 08:37:21 always feels more natural to get stuff from the data stack then the incoming tokens - but then you hit cases where it's far easier to explain a prefix operation - esp. when there's a constant involved which only makes sense in a specific context 08:41:10 (in my case, i have c-style string specifiers - i can use $ hello $ world $ "%s %s" fprint, but for reasons i can't quite get, this is clearer to me: $ hello $ world format "%s %s" - probably just me though :)) 08:42:48 because subject verb is a very natural way of speaking and thinking 08:42:57 that's why OO is so popular 08:43:19 object verb 08:43:48 file.write(data) 08:43:50 yeah 08:43:51 ^ subject 08:46:18 The parsing and tokenizing words are nonstandard, I have routines for dealing with basic types of delimited text, passages and tokens, tokens can be either mandatory or optional. The main differences are laid out in the following table: 08:46:24 9 token | (token) | passage 08:46:25 a -------+---------+-------- 08:46:25 b Ignores leading delimiters? yes | yes | no 08:46:25 c Can straddle lines? no | no | yes 08:46:25 d End of input delimits? yes | yes | no 08:46:27 e Can be zero-length? no | yes | yes 08:47:26 seems sensible to break it up that way, yeah - very clear 08:48:01 ah well - need to go cook :) - later :) 08:48:11 Ciao :) 08:57:55 --- quit: spestov (Ping timeout: 245 seconds) 09:07:38 If your system also handles block-based source, keep in mind that the end of line isn't content-based. 09:09:53 --- quit: dzho (Ping timeout: 264 seconds) 09:21:46 the_cuckoo: do you have an input buffer 09:22:03 parsing the input stream will kick your ass without 09:32:05 In traditional FIG like systems, you're promised that there's a null or two at the end of the input, be it console or block. 09:32:18 And FIG actually has an immediate word in the dictionary. 09:32:28 Excuting that word is what terminates the INTERPRET infinite loop. 09:32:38 Does a double-return, back to the QUIT loop. 09:32:49 Damn clever solution, if you ask me. :-) 09:33:28 A kludge if you ask me :) 09:33:42 Heh. 09:34:14 I like it. It "just works." 09:34:55 But yes, it does make it so an uninformed person trying to read the code could slowly lose their mind trying to figure out how INTERPRET ever finished. 09:40:58 --- quit: nighty- (Quit: Disappears in a puff of smoke) 09:44:20 You needed a couple of nulls at the end of each block buffer which kludged things up further. 09:44:30 Yes. 09:45:09 And that is annoying if you have multiple buffers one after another, because they're no longer on power-of-two boundaries. 09:47:59 And further, it affects the definition of WORD. 09:48:30 If WORD has picked up non-null characters, then null functions as a terminator. But if it hasn't, it functions as content. 09:48:58 And regardless of what comes after the null, it has to pick up only the null. 09:49:03 So that is a bit awkward. 09:49:04 Exactly, messes up with address translation and precludes dropping in a more sophisticated virtual memory mapping scheme. 09:49:29 And I'm thinking of doing exactly that, now that I have that "cheap heap." 09:49:36 so I may wind up having to change it. 09:51:07 That's what I'm about to work on now - the disk interface. 09:51:14 That's basically why I have both TOKEN and (TOKEN) 09:53:19 It all boils down to discerning between expected and unexpected end of input. 09:54:13 I have QUERY null pad the console input buffer (no CR/LF there), so it looks the same at the higher levels. 09:54:49 That way I don't have to worry about it echoing CR/LF. 09:55:29 WilhelmVonWeiner: nope - it's what i meant about it being 'external' - at the most basic level, i use bash arg handling to provide tokens, and internally, the main method to the stack is push which accepts tokens - iow, even there, the tokenising isn't specifically a function of the stack (but as ack'd, yeah, it could be) 09:55:44 The canonical terminal configuration is NOT such that it gives you the traditional Forth output. 09:56:15 s/bash/shell/ 09:56:29 If you're input is coming from a terminal (as opposed to a file or blocks) then any end of input is unexpected. 09:56:37 It echoes everything you type immediately, including CR/LF, so there's no good way to get a command line's output on the same line, and then do the ok prompt and CR. 09:58:28 Ah, you're talking about an unknown AMOUNT of input. 09:58:47 Just use a raw terminal. 09:58:52 I do. 09:59:03 I meant Cuckoo 09:59:18 I'm planning a source compression scheme, so that will be similar - there will be no knowing in advance exactly how much decompressed stuff is in a block. 09:59:21 Ah, sorry about that. 09:59:31 np 09:59:50 why compress? 10:00:43 Well, mostly "because I can," and I'm interested in seeing how it goes. But also, one of my targets is a little Cortex M4 board with about half a meg of flash space, which is where I'll put source. 10:01:14 --- join: dzho (~dzho@unaffiliated/dzho) joined #forth 10:01:15 That may still be plenty for anything I'll do, but at least it's not using compression in an "unlimited" capacity environment. 10:01:33 KipIngram: and 2M of spi-flash ;-) 10:01:49 I got on that track from reading about some of the stuff Chuck did around ColorForth, and that Jeff Fox did with Aha. 10:02:07 Mine doesn't have that, PoppaVic. 10:02:14 It's 520k of flash. 10:02:14 aww 10:02:21 * KipIngram pouts 10:06:24 You could keep the compression scheme transparent, so that the upper layers are still dealing with 1k blocks. 10:06:24 rdrop-exit: heh - it's an api - you push tokens to the stack in the api, how they are created is not my concern - i could push them to an input end of a stream and split them out again on the other side, but it seems unnecessary to do that 10:07:27 rdrop-exit: but, yeah, it would probably work i guess 10:07:58 I stand corrected - my M4 DOES have 2 MB of SPI flash. 10:08:10 I'd just never read that part before. 10:08:10 If how they are created is not your concern, then I guess you don't need to worry about parsing. 10:08:11 Groovy. 10:08:23 Cool 10:09:30 rdrop-exit: well, i need to parse quite a lot of stuff as it comes in - loops, conditions and so on - app pushes stuff in, i parse as i get them and then evaluate each as they close 10:10:11 or rather, the outer thing closes 10:11:59 OK, I've made kip's day - so I might as well leave for work on that note ;-) 10:12:34 Have fun PoppaVic 10:12:52 well, I just try to be productive, but fun is nice ;-) 10:14:39 the_cuckoo: I'm not grokking your system, but it is 2:15am here. 10:21:44 Forth doesn't really parse loops in the way a normal language does. Forth mostly just looks things up and executes them. 10:23:46 Get a word, look it up, execute it's behavior, rinse, repeat. 10:24:33 It's more of a command interpreter than a language. 10:26:49 Anyway, I need my beauty rest. Catch up with you soon. 10:27:02 --- quit: rdrop-exit (Quit: Lost terminal) 10:36:24 Yeah, what he meant by that is that it has no "grammar" to speak of. It doesn't place requirements on collections of words, such that they have to form some sort of valid "higher level construct" like an "expression" or whatever. 10:36:56 I'll often refer to it "parsing," but that's mostly a convenience - the word doesn't really apply in its formal sense. 10:50:07 All this talk of laforth and parsing makes me want to revisit parse-time execution https://twitter.com/lowfatcomputing/status/932660560428195841 ...but this time with a few performance enhancements. 10:51:06 rdrop-exit: no worries :) 10:54:52 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 10:55:13 Explicitly calling `compare` or `cmp r0, 'a'` within the header wasn't very space efficient for text only word names. 11:18:26 i don't think i understand those slides 11:28:20 --- quit: spestov (Ping timeout: 268 seconds) 11:29:51 --- quit: gravicappa (Ping timeout: 250 seconds) 11:33:52 corecode: The idea is to have word names other than matching of literal ascii text strings. For example put a piece of non-destructive code in a word header that will match if the water level in your basement is >5cm and in the body of the matching word would be code to start the sund pump. 11:33:52 This allows writing code from devices other than keyboards. 11:35:52 sounds like you turn the dictionary into a bad event dispatcher 11:48:51 The thing is, it's still a dictionary with hyperstatic scoping and composable words. 11:50:17 but why is that desirable 11:53:18 zy]x[yz: It's explained in the slides. 12:16:03 sorry, this is very meta 12:18:23 i think i see what you're suggesting 12:18:41 i think nothing is ever explained by just slides 12:19:06 (and if it is, your slides are overly verbose and therefore suck as slides) 12:19:06 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 12:19:16 yea 12:56:43 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 13:52:07 --- quit: mtsd (Quit: WeeChat 1.6) 14:09:08 --- quit: dddddd (Remote host closed the connection) 14:28:15 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 14:29:06 ahoy 14:37:56 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 14:40:46 --- quit: MrMobius (Ping timeout: 255 seconds) 14:40:46 --- nick: [1]MrMobius -> MrMobius 14:41:36 morning 14:42:33 finally, my forth is running 14:42:38 for now at least 15:08:14 --- quit: spestov (Ping timeout: 250 seconds) 15:10:50 cool 15:11:02 presiden: do you have the source up somwhere? 15:13:39 --- join: yrm (~yrm@KD106130204082.au-net.ne.jp) joined #forth 15:25:58 corecode, not currently, private repo only. 15:26:29 tho, it's just a port of jonesforth to nasm & x64 15:26:37 which I'm sure has been done before 15:31:20 I think it's easier to follow the jonesforth tutorial by writing some code and understand what they do 15:31:44 hence what motivate me to port it 15:37:07 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 15:48:39 --- quit: yrm (Quit: yrm) 16:05:41 --- quit: john_cephalopoda (Ping timeout: 264 seconds) 16:07:28 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:10:58 --- quit: spestov (Ping timeout: 246 seconds) 17:03:17 --- quit: john_cephalopoda (Ping timeout: 264 seconds) 17:04:41 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:13:24 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 17:17:19 --- quit: pierpal (Quit: Poof) 17:17:36 --- join: pierpal (~pierpal@host254-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 17:25:16 --- join: yrm (~yrm@KD106130204082.au-net.ne.jp) joined #forth 17:30:00 --- join: tabemann (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 17:47:05 --- quit: yrm (Quit: yrm) 17:51:32 --- join: yrm (~yrm@KD106130204082.au-net.ne.jp) joined #forth 17:55:47 --- quit: yrm (Client Quit) 18:07:38 --- quit: tabemann (Ping timeout: 250 seconds) 19:07:36 --- join: tabemann (~travisb@2600:1700:7990:24e0:a106:f1e:e4eb:7e2d) joined #forth 19:09:38 I was hoping to rewrite the keyboard driver in forth, but had to stop due to loss of feeling in my right hand. :( 19:11:07 It's *almost* done though: the only issue is with handling shift. Currently I have a hack that lets it work as a sort of sticky modifier (hit shift, then the character). 19:12:26 I left in the existing assembly driver for now, with the new one as a user selectable option until I can finish it. 19:14:50 --- quit: spestov (Ping timeout: 258 seconds) 19:21:33 This annoys me, as this is the only driver code that's not written in forth now. It'll be nice to reduce the non-forth code by about 90 lines, putting the non-forth parts under 400 lines (349 C, 41 assembly) 19:24:58 --- quit: dave0 (Quit: dave's not here) 19:31:08 --- join: gravicappa (~gravicapp@h109-187-233-79.dyn.bashtel.ru) joined #forth 19:47:30 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 20:39:10 --- quit: jedb (Remote host closed the connection) 20:39:48 --- join: jedb (~jedb@176.113.74.187) joined #forth 21:15:58 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 21:16:35 re 21:33:23 --- join: proteusguy (~proteusgu@66.96.196.172) joined #forth 21:33:23 --- mode: ChanServ set +v proteusguy 21:37:25 presiden: nice! I think I introduced a bug (or three) when I attempted the same a few years ago. I never got back around to trying to track it down. 21:38:15 I was too ambitous perhaps. since I also tried embedding it into my still work-in-progress bootable asm OS at the same time. so many variables I wasn't sure what to trust at that point. 21:48:44 --- quit: pierpal (Quit: Poof) 21:49:03 --- join: pierpal (~pierpal@host254-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 22:05:04 --- join: yrm (~yrm@host155.shizentai.jp) joined #forth 22:11:58 bluekelp, mine runs, but still segfault when executing the jonesforth.f 22:14:31 tho, for now, I'm happy that (1) it compiles, (2) it no longer segfault when run on it's own 22:15:28 maybe I'll put it on github later 22:15:37 cool. good job 22:16:15 i still want to come back to the project and have an x86_64 OS and forth in ~40k but for now I'm off in microcontroller land 22:31:07 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 22:39:00 --- quit: yrm (Quit: yrm) 22:49:45 --- quit: spestov (Ping timeout: 250 seconds) 22:54:43 --- join: yrm (~yrm@host155.shizentai.jp) joined #forth 22:58:37 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 23:02:09 --- quit: yrm (Quit: yrm) 23:06:25 --- quit: proteusguy (Ping timeout: 246 seconds) 23:07:27 --- join: yrm (~yrm@host155.shizentai.jp) joined #forth 23:21:28 --- quit: pierpal (Ping timeout: 246 seconds) 23:24:33 --- join: pierpal (~pierpal@host105-222-dynamic.3-87-r.retail.telecomitalia.it) joined #forth 23:28:29 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 23:30:51 --- quit: yrm (Quit: yrm) 23:39:58 --- join: proteusguy (~proteusgu@66.96.196.172) joined #forth 23:39:58 --- mode: ChanServ set +v proteusguy 23:41:50 bluekelp, what's your microcontroller efforts involving now? 23:59:59 --- log: ended forth/19.02.21