00:00:00 --- log: started forth/18.06.19 00:06:19 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 00:14:56 --- join: ncv__ (~neceve@2a02:c7d:c5c9:a900:14fa:fcbb:861b:b7e6) joined #forth 00:14:56 --- quit: ncv__ (Changing host) 00:14:56 --- join: ncv__ (~neceve@unaffiliated/neceve) joined #forth 00:22:47 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 00:47:42 --- quit: groovy2shoes (Ping timeout: 276 seconds) 00:51:01 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 00:51:19 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 00:53:41 --- join: ThirtyOne32nds (~rtmanpage@62.sub-174-204-2.myvzw.com) joined #forth 01:14:49 --- quit: ThirtyOne32nds (Ping timeout: 256 seconds) 01:33:22 --- join: dys (~dys@tmo-113-10.customers.d1-online.com) joined #forth 01:53:02 --- quit: mtsd (Remote host closed the connection) 02:32:59 --- nick: ncv__ -> ncv 02:39:32 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 02:49:24 --- quit: nighty- (Quit: Disappears in a puff of smoke) 03:20:57 --- quit: mtsd (Quit: leaving) 03:21:29 --- join: ThirtyOne32nds (~rtmanpage@206.sub-174-204-22.myvzw.com) joined #forth 03:37:15 --- quit: dys (Ping timeout: 256 seconds) 03:51:37 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 03:57:13 --- join: dys (~dys@tmo-097-95.customers.d1-online.com) joined #forth 04:02:58 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 04:34:07 --- quit: pierpal (Quit: Poof) 04:34:26 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 04:52:13 --- quit: ncv (Ping timeout: 265 seconds) 04:55:24 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 05:02:26 --- quit: pierpal (Quit: Poof) 05:02:45 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 05:06:35 --- quit: ncv (Remote host closed the connection) 05:06:57 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:14fa:fcbb:861b:b7e6) joined #forth 05:06:57 --- quit: ncv (Changing host) 05:06:57 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 05:32:48 --- quit: mtsd (Remote host closed the connection) 05:44:35 --- quit: ncv (Remote host closed the connection) 05:44:55 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:c1c7:50c:8461:8572) joined #forth 05:44:55 --- quit: ncv (Changing host) 05:44:55 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 05:48:04 It's really pretty annoying how no system I've ever worked on "naturally" supports Forth's typical way of doing the "ok". 05:48:35 They all let their system "read line" calls handle echoing, and they all echo the carriage return. 05:49:08 So by the time you get back with a line of text to process, you're already on the next line and can't put the output on the same line as the input. 05:49:58 This usually leads me to putting the console into raw mode so I can handle it all myself. 05:50:35 I don't feel like fighting through that on the Mac yet, though (since I'm not using the C library this time I'd have to research how to do it). 05:51:13 I'm just going to live with it for now - I made "ok > " a beginning-of-line prompt and I'll just take what I get. 05:51:21 Maybe I'll change it later. 05:56:31 --- quit: jedb (Remote host closed the connection) 05:57:07 --- join: jedb (~jedb@199.66.90.113) joined #forth 06:01:46 --- quit: pierpal (Read error: Connection reset by peer) 06:51:17 the forth "ok" doesn't make any sense to me. the readlink/c way of doing it is better 06:51:44 that always struck me as an artifact from a time before people figured out the best way to be consistent with their newlines 06:52:10 --- join: hegemoOn (~netmonk@hub.netmonk.org) joined #forth 06:52:28 hello 06:55:24 Morning hegemoOn 06:55:41 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 06:56:20 zy]x[yz: I agree intellectually - what it ought to be saying to you is "now I need you to type something again," and that really makes more sense as a conventional prompt. 06:56:51 I just got used to the other way and found it mildly annoying that it didn't do what I wanted. So it became a "challenge" of sorts. 06:57:07 But I think this time I'll just roll with the flow, since it's really more sensible anyway. 06:58:06 I've got QUIT complete now except for INTERPRET. I'm looking over my previous implementation of INTERPRET and find it kind of offensive - it's long and complex. 06:58:14 Looking at nice ways to factor it right now. 06:59:37 I wrote EXPECT and TYPE earlier; that's where I'm doing the MacOS system calls right now. Later on those words will just work with stdin and stdout buffers that I set up, but this moves me forward for now. 07:00:15 just out of curiosity, where do you parse words and strings into? do you have a static buffer area for that, and you just write over it with each successive call? 07:01:09 Well I have a TIB buffer (each process will have one) that QUERY aims EXPECT at. But you mean the next step, right? When I parse out individual words? 07:02:15 I guess it's a two-parter: a) after a word is parsed, where does your interpreter find it, and b) if I wrote " hello" at the interpreter, what is the address returned? 07:02:43 I haven't made a final decision on that yet. The two options are 1) use a scratch buffer (in the past I've used PAD, which just floats a ways above the dictionary) or 2) try to position it where it's in the right spot to become a header if the word is being CREATEd. 07:03:14 I started with PAD, but found some situations where I kept colliding 07:03:37 I'm temporarily putting names in the headers, but eventually the names will go into my symbol table. So I'll probably go with the PAD approach this time. 07:03:54 so then I tried to fix that by writing this "dynamic scratch pad" monstrosity that you have to explicitely free. that's what I'm using now, but I'm thinking of replacing it 07:04:03 Yes, PAD has always worried me. I've never encountered the problem myself, but I've always felt like it's "lurking" out there. 07:04:34 I'm thinking of doing some kind of circular buffer thing 07:04:56 I'm going to set my stdin/stdout up as circular buffers. 07:05:46 actually I think one of my early implementations had a PAD that would cycle between four areas on successive calls, so you'd have to call it four times before overwriting old data 07:06:05 that worked sort of ok I guess, but when it did overwrite something still in use it was hard to debug 07:06:33 Yeah. In this case we parse the word into PAD, and the very next thing we do is search the dictonary for it, so I'm not sure I see how a problem could arise there. 07:06:48 but what about strings? 07:07:08 Right - other uses of PAD are the ones that could cause problems. 07:07:24 The way the outer interpreter uses it it's pretty safe. 07:08:03 I'm planning some sort of more sophiticated literal support (which would include strings, lists, etc.) in this Forth. 07:08:32 Those streams I designed for stdin/stdout can also be used to make a literal stack. 07:08:49 When a literal's parsed out of the input stream, it would be added to the end of that stream, as a msgpack. 07:09:11 And I can treat that stream as a "complex literal stack." 07:09:33 It will be circular, so if you tried you could fill it up, but I expect to make it big enough for that not to be a problem. 07:10:07 I need to be able to navigate the output stream by lines, for re-drawing process output windows, so the lines are stored as a doubly linked list. 07:10:42 That means I could compute a new result and add it to the end, and if I needed to "pop" stuff under it and hadn't had the opportunity to during computation I can adjust the links. 07:10:57 The buffer would be fragmented at that point, but once it circles around again that space would be recovered. 07:11:23 For example, I might have two arrays on the stack and be computing a matrix product. 07:11:41 I couldn't overwrite the inputs during the calculation, so the product would have to go beyond both of the inputs. 07:11:50 But I wouldn't want them to remain on the stack, so I'd link them out. 07:12:07 And just not worry about that space until I used it on the next wrap-around. 07:12:35 Stack operations on that guy like SWAP would work by adjusting the links as well. 07:13:21 I'd long planned something of this sort, and always just figured I'd need "something like a heap" for it, so I was very pleased when I realized that the stream design offered a nice implementation. 07:15:00 This may lead me to use bson instead of msgpack - msgpack looked better for input/output and inter-process streaming, but I read that bson is more efficient when it comes to in-buffer scanning. 07:15:47 I probably won't worry about all of this for the outer interpreter, since it's pretty safe to use PAD in that case. 07:16:15 KipIngram: thank you for you welcome. i just started learning forth ! :) 07:16:23 Anyway, this idea is pretty similar to what you're doing, except my buffer will be a lot bigger than 4. 07:16:50 :-) Glad to have you here - love seeing new people "come into the fold." 07:18:19 oh, I'm not using the 4-pad thing anymore. that's so last year 07:19:56 my current implementation treats the pad like a stack (in the x86 sense, not the forth sense) where you explicitely allocate space on it and then later deallocate. but it's "smart" in that you can deallocate in random order, but it will never rewind over something that isn't deallocated yet 07:20:26 for example, you allocate A, B, and C, and then deallocate A and C, then it will rewind to the end of B until you deallocate B, and then it can rewind back to zero 07:20:57 but I want to get rid of that. it's neat I guess, but ugly to manage 07:21:14 not very "forthy" 07:31:44 --- quit: pierpal (Quit: Poof) 07:32:01 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 07:34:53 KipIngram: im doing those assignements https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Stack-Manipulation-Tutorial.html#Stack-Manipulation-Tutorial 07:35:11 am i correct to suggest that nip is equivalent to dup rot rot ? 07:35:28 nope 07:35:37 sorry 07:35:40 i mean tuck ! :) 07:36:06 oh, sure 07:36:14 it's also the same as swap over 07:36:29 nip = swap drop 07:36:33 yes 07:36:41 swap over ? 07:36:47 didnt see over yet 07:37:02 erm wrong, i dont know how to read 07:37:08 :) 07:37:23 is there a command to flush the stack 07:37:34 quit 07:37:37 instead of repeating drop several time ? 07:38:10 you can use 2drop half as many times 07:38:19 doens't seem to work with gforth 07:38:23 afaik the standard respnse to an undefined word drops everything in a lot of Forths 07:38:56 WilhelmVonWeiner: i just typed "fuck" and it worked ! :) 07:39:05 Yeah I just habitually type ZZ 07:39:08 with a backtrace of course 07:39:15 not so clean 07:39:35 well it's not something you would normally do in a program 07:41:26 damn i need to get accustomed with stack top/bottom 07:41:57 out of topic question: are forth programming fetishist of HP RPN calculators ? 07:41:59 :) 07:42:15 i mean i own 5 hp48 and 1 hp32Sii 07:42:34 and i use droid48 on my mobile anytime i need handy calculator 07:42:37 using rpn 07:53:52 hegemOn: Some Forth's have a variable sp0 that contains the bottom of stack address. 07:54:04 And a word sp! that lets you set the stack pointer. 07:54:12 So in those Forths you can sp0 @ sp! 07:54:50 WARM, if you have it, usually resets the data stack as well. 07:55:02 But it's not usable in a definition - it's a "reset" of sorts. 07:59:34 hegemoOn: My install of GForth seems to have sp0 and sp!. 08:19:38 ok 08:19:43 thanks for the tip 08:29:29 By the way, there is sp@ to, that fetches the current stack pointer. You could use sp@ and sp0 to implement depth if it wasn't already there. 08:34:17 Sam Falvo II returns with moar Over the Shoulder Forth: https://twitter.com/SamuelAFalvoII/status/1009093330884411392 08:38:50 --- quit: pierpal (Quit: Poof) 08:39:09 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 08:54:09 --- join: yuiop (9f7f20fe@gateway/web/freenode/ip.159.127.32.254) joined #forth 09:06:23 --- quit: pierpal (Quit: Poof) 09:06:40 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 09:15:25 --- mode: crc set +o koisoke 10:15:06 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 10:28:16 --- quit: pierpal (Quit: Poof) 10:28:29 PoppaVic: Changed my mind about FIND. I think it should return a flag, but it should always return another result - even if the word isn't found. 10:28:34 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 10:29:18 I think it should return a flag on top of the stack. If the flag is true, then the other result is the address of the word's header in the dictionary. If it's NOT found, then it's the address of the word string, placed at PAD or something, ready for a numeric conversion attempt. 10:29:53 So basically it's FIND IF ELSE THEN 11:02:42 --- quit: ncv (Ping timeout: 245 seconds) 11:05:51 --- quit: Keshl (Quit: Konversation terminated!) 11:28:48 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 11:40:26 --- quit: yuiop (Ping timeout: 260 seconds) 12:09:09 --- quit: pierpal (Quit: Poof) 12:09:26 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 12:35:43 --- quit: pierpal (Quit: Poof) 12:36:02 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 13:15:33 --- nick: dzho -> deejoe 13:15:37 --- nick: deejoe -> dzho 13:51:09 --- quit: pierpal (Read error: Connection reset by peer) 13:59:45 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 14:03:49 --- quit: pierpal (Ping timeout: 240 seconds) 14:21:06 --- join: pierpa (4f2c3a2d@gateway/web/freenode/ip.79.44.58.45) joined #forth 15:21:11 hi 15:39:38 --- quit: dys (Ping timeout: 260 seconds) 15:58:19 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:11:27 --- join: pierpa_ (4f2c3a2d@gateway/web/freenode/ip.79.44.58.45) joined #forth 16:12:16 --- quit: pierpa (Ping timeout: 260 seconds) 17:30:12 --- quit: dddddd (Remote host closed the connection) 18:05:25 gforth syntax for arrays...is ugly 18:05:36 what's the forth everyone is using here? 18:05:42 also factor: love the idea 18:05:50 wish I had 3 months to play with it 18:10:13 is that a forth furry 18:15:50 lf94: I use my own 18:20:12 lf94: I mean Factor looks like a good Forth to be honest 18:20:21 I use crc's 18:21:14 Factor is too heavy for my needs 18:21:26 I just want a basic forth experience 18:21:31 that is elegant 18:21:32 :D 18:21:37 and standard 18:21:57 If you want a Forth that's like a self contained system, try x4 18:22:19 do all standard forths use gforth's array syntax 18:22:41 variable mynumbers 2 cells allot 18:23:04 But ANS-compliance doesn't appear to mean much anymore (if it ever did I wouldn't know) 18:23:47 should be "create mynumbers 2 cells allot" and yes, probably most forths look like that 18:23:58 lf94: that is a standard way to create an array but it's not "gforth's array syntax", just one possible way 18:24:03 http://forth.org/svfig/Len/arrays.htm 18:25:04 looks like I have some syntax to get used to x_x 18:25:28 you need to not think of that as "array synax" but rather as words that do things 18:25:49 that's not specifically allocating an array. maybe you're just reserving memory for a 2-cell-sized structure 18:26:09 Don't forget, you can treat the stack as an array (but it *can* get complicated) 18:27:11 I wouldn't recommend much pick and rolling but its there 18:36:03 Right, everything is just words 18:36:45 yes but I mean even aside from that, "create foo 2 cells allot" is not just about arrays 18:37:14 it's more analogous to malloc in that what you're doing is creating a word and reserving memory. how you use it is up to you 18:37:47 (not like malloc in how that memory is managed) 18:39:19 --- quit: reepca (Ping timeout: 240 seconds) 18:42:50 yeah that's what I figured 18:42:58 not sure how I feel about this 18:43:04 too low level - maybe 18:53:45 only until you build up a vocabulary of words at the level you want 18:57:45 --- quit: jedb (Ping timeout: 276 seconds) 19:09:26 --- join: jedb (~jedb@199.66.90.113) joined #forth 19:17:15 --- join: dave9 (~dave@207.213.dsl.syd.iprimus.net.au) joined #forth 19:17:28 hi 19:18:50 Hi Dave. 19:20:02 hi KipIngram 19:22:37 KipIngram: after i read rodriguez on DOES> , i have been running the logic through my head and it is making sense 19:23:09 i will read the article again now :-) 19:24:18 :-) Good. 19:24:32 I made a lot of outer interpreter progress today. 19:25:06 Working on INTERPRET now - decided I didn't like the implementation I did in my previous Forth. 19:25:10 Too long and messy. 19:25:25 Trying to factor it is some nice way, and it's coming along ok. 19:26:00 do you write your INTERPRET in machine code? 19:26:36 that's part of the read-eval-print-loop yeah? 19:26:52 Well, it led me to implement a few new primitives, but no - it's written in Forth. 19:27:02 Yes, it's basically that loop. 19:27:46 it's awesome how forth is minimal 19:28:06 (after reading a lot :-) you can get it all in your head 19:28:53 Yes. 19:28:57 sigh neighbors are swearing at eachother again... too many domestics near my flat 19:34:01 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 19:59:50 --- quit: pierpa_ (Quit: Page closed) 20:48:50 --- quit: comietek (Ping timeout: 256 seconds) 20:49:16 --- quit: rodarmor (Ping timeout: 256 seconds) 20:50:12 --- quit: crc (Ping timeout: 276 seconds) 20:51:43 --- quit: pointfree (Ping timeout: 260 seconds) 20:51:48 --- quit: ovf (Ping timeout: 260 seconds) 20:51:59 When I do "2 cells", I see the result on the stack is "16", why? 20:52:06 --- quit: jhei (Ping timeout: 256 seconds) 20:52:28 2 cells is...16...each cell is 8...8 bytes? 20:52:36 (for the allot call) 21:33:21 --- quit: ThirtyOne32nds (Ping timeout: 256 seconds) 21:47:06 --- join: reepca (~user@208.89.170.230) joined #forth 21:55:51 --- quit: dave9 (Quit: one love) 22:26:57 --- join: crc (sid2647@gateway/web/irccloud.com/x-yvsepfrfcdzujoym) joined #forth 22:31:20 --- join: comietek (sid134071@gateway/web/irccloud.com/x-xcwqxbdhjalxolqu) joined #forth 22:34:57 --- join: jhei (sid81469@gateway/web/irccloud.com/x-bhqatrexfrvamnym) joined #forth 22:40:12 --- join: impomatic (~digital_w@host81-136-104-94.range81-136.btcentralplus.com) joined #forth 22:41:02 --- join: ovf (sid19068@gateway/web/irccloud.com/x-nfpsztexqupjqiqd) joined #forth 22:41:07 --- join: pierpal (~pierpal@host45-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 22:54:15 --- join: rodarmor (sid210835@gateway/web/irccloud.com/x-upuudsmnongtnldq) joined #forth 22:56:54 --- quit: crc (Ping timeout: 256 seconds) 22:57:18 --- quit: ovf (Ping timeout: 265 seconds) 22:57:36 --- quit: comietek (Ping timeout: 276 seconds) 22:59:09 --- quit: rodarmor (Ping timeout: 255 seconds) 22:59:14 --- quit: jhei (Ping timeout: 265 seconds) 23:00:53 --- quit: Labu (Quit: WeeChat 2.0.1) 23:17:05 --- join: dave9 (~dave@207.213.dsl.syd.iprimus.net.au) joined #forth 23:20:02 --- join: rodarmor (sid210835@gateway/web/irccloud.com/x-nyevldfqfpusjuyc) joined #forth 23:20:06 --- quit: Keshl (Read error: Connection reset by peer) 23:20:21 --- join: Keshl (~Purple@24.115.185.149.res-cmts.gld.ptd.net) joined #forth 23:20:58 re 23:20:59 --- quit: rodarmor (Max SendQ exceeded) 23:21:44 --- join: rodarmor (sid210835@gateway/web/irccloud.com/x-hmxkdgcpcuxdkalo) joined #forth 23:22:30 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-jrmbmaoxepzieigb) joined #forth 23:23:02 --- quit: rodarmor (Max SendQ exceeded) 23:23:32 --- join: rodarmor (sid210835@gateway/web/irccloud.com/x-xfwebrleqflziklj) joined #forth 23:23:51 --- join: crc (sid2647@gateway/web/irccloud.com/x-jhjaqivrolyqwint) joined #forth 23:24:29 --- join: jhei (sid81469@gateway/web/irccloud.com/x-lmyanmhuxueuxvdm) joined #forth 23:25:30 --- join: ovf (sid19068@gateway/web/irccloud.com/x-cgqdwuudkxvftjqb) joined #forth 23:26:20 --- join: comietek (sid134071@gateway/web/irccloud.com/x-luocpnqcsrsliduz) joined #forth 23:41:18 --- join: ThirtyOne32nds (~rtmanpage@42.sub-174-204-0.myvzw.com) joined #forth 23:59:59 --- log: ended forth/18.06.19