00:00:00 --- log: started forth/21.05.18 00:54:42 --- quit: proteus-guy (Remote host closed the connection) 00:56:02 --- join: proteus-guy joined #forth 03:12:47 --- quit: nitrix (Quit: Genius is one percent inspiration and ninety-nine percent perspiration) 03:17:41 --- join: nitrix joined #forth 04:00:17 --- join: f-a joined #forth 04:13:48 --- quit: f-a (Read error: Connection reset by peer) 04:16:09 --- join: f-a joined #forth 04:55:07 --- quit: Gromboli (Ping timeout: 260 seconds) 05:12:48 --- quit: f-a (Ping timeout: 260 seconds) 05:13:33 --- quit: Zarutian_HTC (Ping timeout: 240 seconds) 05:14:40 --- join: f-a joined #forth 05:21:19 --- quit: pbaille (Quit: Leaving...) 05:48:05 --- quit: dave0 (Quit: dave's not here) 05:50:02 --- join: tech_exorcist joined #forth 05:56:02 --- join: Gromboli joined #forth 06:24:28 --- quit: siraben (Ping timeout: 245 seconds) 06:31:13 --- quit: guan (Ping timeout: 250 seconds) 06:34:27 --- join: guan joined #forth 06:35:50 --- join: siraben joined #forth 06:59:10 --- join: boru` joined #forth 06:59:13 --- quit: boru (Disconnected by services) 06:59:15 --- nick: boru` -> boru 07:00:32 --- quit: joe9 (Ping timeout: 265 seconds) 07:01:52 --- join: mark4_ joined #forth 07:02:05 --- join: joe9 joined #forth 07:03:33 --- quit: mark4 (Ping timeout: 240 seconds) 07:04:33 --- quit: sts-q (Ping timeout: 240 seconds) 07:04:33 --- quit: APic (Ping timeout: 240 seconds) 07:09:33 --- quit: mark4_ (Ping timeout: 240 seconds) 07:10:50 --- join: sts-q joined #forth 07:11:36 --- join: mark4_ joined #forth 07:25:33 --- quit: gravicappa (Ping timeout: 240 seconds) 07:37:48 --- join: Zarutian_HTC joined #forth 07:42:17 --- join: gravicappa joined #forth 07:52:28 --- quit: gravicappa (Ping timeout: 240 seconds) 07:55:57 --- join: gravicappa joined #forth 07:59:37 --- quit: Zarutian_HTC (Remote host closed the connection) 08:04:04 --- join: APic joined #forth 08:09:34 --- nick: mark4_ -> mark4 08:09:37 --- mode: ChanServ set +v mark4 08:56:52 --- join: Zarutian_HTC joined #forth 09:13:58 --- quit: f-a (Ping timeout: 268 seconds) 09:15:11 --- join: f-a joined #forth 11:09:51 Ok, question for you all. I'm setting up my block/buffer system so that I use a hash to narrow down the list of buffers a block is able to reside in to two, then I can quickly check those two to see if one of them is the one I want. The question regards the case where both of the candidate buffers are occupied, but not by the block that I want. So I'm going to have to replace one of them. 11:10:31 I'm implementing a simple least-recently used system for that - I'll always replace the block that has sat there untouched for the longest time. 11:11:43 Here's the question: if the least recently used block has been written to, so I'd have to write it before replacing it, but the more recently used block has not been written (so I could just replace it), which do I do? Should dirty/clean override least recently used? 11:12:22 I lean toward yes, but I don't have a crystal clear argument as to why. 11:19:30 I have a nasty feeling that the answer to this question depends on the nature of my current traffic - i.e., it's application dependent. 12:48:22 --- quit: gravicappa (Ping timeout: 252 seconds) 13:11:43 hi, I am working through Moving Forth. I was just wondering if anybody had a particular preference for ICT, vs DCT and SCT? I found ICT as a model kind of appealing, though I can see some performance disadvantages 13:12:56 I have a strong preference for IDT. I think there are certain things (one is CREATE / DOES> ) that implement more cleanly in IDT. 13:13:03 lispmacs: depends on the $NEXT assembler macro 13:13:20 I'm sorry - ITC. 13:13:33 --- quit: f-a (Ping timeout: 240 seconds) 13:13:35 I will say right out, though, that many many people like STC. 13:13:51 I think it's just almost automatic to regard it as higher performance, but that really depends on the details of the architecture. 13:14:22 I think people think "Oh, the hardware supports STC, so surely it's best." 13:14:30 And I think they're likely right in many/most cases. 13:14:35 Just not in every single one. 13:14:40 I like STC on dual stack machines but DCT or ITC otherwise 13:15:36 I mostly do DTC, since imo it's nice that colon words are just a special case of code words 13:15:41 ITC is what I've become most thoroughly familiar with over the years, so my opinion should be considered somewhat biased. 13:15:43 --- join: f-a joined #forth 13:15:50 though yeah, I have worried about the branch predictor penalty vs STC 13:16:20 the subroutine call opcode often takes up one byte and the absolute address two, so you get lot of three byte instructions 13:16:39 heh, I live on aarch64, they're all 4-byte :) 13:16:40 remexre: That's an interesting point - I think I see what you mean. 13:17:30 on avr and others I prefer DTC 13:18:23 dave0's "NEXT == ret" approach has really impressed me - that's just slick as heck in my opinion. 13:18:24 KipIngram: re block: it also depends on how 'expensive' it is to write a block out 13:18:32 True. 13:18:49 I'm also thinking of including cuckoo hash at this level and dodging the whole question. 13:19:18 I.e., there would then be more than two buffers a block could live in. 13:19:27 There would be four - two from each hash method. 13:19:36 That mitigates the thrashing prospects quite a bit. 13:20:20 Best case access time wouldn't be impacted at all, but average access time would be lengthened. 13:20:48 I suspect writes to disk would be considerably less frequent in that scheme, which is probably enough to make it a win right there. 13:21:51 More work, though. 13:22:38 I do not recall where I read it, might been in Forth Dimensions, that one guy used tape as block storage. 13:22:46 I think with cuckoo, though, I would have fewer buffers. 13:22:53 Like instead of 256, it would be 240. 13:23:19 You'd need to eliminate the "diagonal" of the grid, so that no block got the same buffer # from both hashes. 13:23:49 but he had a modified casette 'drive' which could play the casette backwards 13:23:54 My very first Forth sort of did that - it had a 32 kB randisk and I loaded it from and to cassette. 13:23:55 I was wondering - author hinted that there were some advanced things that you could do with ITC since everything is an address - but he didn't go into details. I would imagine maybe writing a decompiler might be simpler...? or maybe it would be easier to modify/move-around code...? 13:23:59 That's not quite the same thing, though. 13:24:11 There the tape was just for offline storage. 13:24:42 Well, as I said, I've always found CREATE/DOES> easier and less klunky in ITC. 13:25:27 I think ITC is just the "closest to the origins" of Forth. 13:25:55 It really just stands to reason that an additional level of indirection would provide opportunities one could exploit, but I can't give you a full list right now. 13:26:31 and it had two sets of heads 13:26:53 Oh, INTERESTING. 13:27:03 If you ever run across that again point me at it. 13:27:10 I may look for that later, just for shoots and grins. 13:27:19 I like "clever." 13:27:27 re ITC: I am still somewhat facinated by opemfirmware fcode bytecode idea 13:27:49 I also find bytecode an interesting idea. 13:28:17 I don't think I'm interested in a pure bytecode system, but I keep wondering if it could be "integrated" into an ITC system in some useful way. 13:28:34 the idea was that pci devices had fcode drivers in accessible rom 13:29:05 lispmacs: My ITC system has a second pointer right there by the CFA pointer that points to the "parameter field" of each word. 13:29:23 no need to hunt down the driver from a disk or install it 13:29:32 So, definition points to called CFAs, the PFAs are right by the CFAs, the CFA points to code and the PFA points to the new definition. 13:29:42 And that structure makes me able to "revector" any word I want. 13:30:09 I can just change a words PFA pointer to point to a new definition, and that redefines EVERY INSTANCE of that word, everywhere. Even in already compiled definitions. 13:30:43 In fully traditional Forth systems you have to jump an extra hoop to get that revectoring capability, so you usually only do it with a subset of your words. 13:30:56 Of course, that's yet another level of indirection I have to thread through. 13:30:59 Every little bit costs. 13:31:08 The system still feels plenty snappy to me, though. 13:32:17 In a traditional ITC system the called definition list is right there immediately following the CFA, instead of there being another pointer involved. 13:32:17 i feel like from my perspective I wouldn't mind giving up some cycles to make a system more elegant and more hackable, though that might be a hard sell to others 13:32:28 re the tape drive: because each block on tape had lengthOfBlock, blockNr, blockData, lengthOfBlock it could seek backwards for the latest version of the block desired 13:32:43 So the only way you could redefine a word and affect prior usages would be to overwrite the definition with the new one. 13:32:46 And it might not fit. 13:33:21 KipIngram: that sounds appealing to me 13:33:31 It's very clean. 13:33:32 your approach, I mean 13:33:46 Well, if you're into elegance as you said, then you're somewhat like me. 13:33:53 So you might like the same sorts of things. 13:34:07 I'll show you what my next looks like. 13:34:27 next_c: geti rrW, rrIP ; Fetch next icell 13:34:29 radd rrW, rrHB ; Offset -> address 13:34:31 inci rrIP ; Bump instruction pointer 13:34:33 geti rrTMP, rrW ; Fetch CFA offset 13:34:35 radd rrTMP, rrBB ; Offset -> address 13:34:37 rjmp rrTMP ; Go there 13:34:40 Those are mostly macro names, but the comments tell you what's going on. 13:35:05 I have #defines to give Forth VM style register names. 13:35:44 My system is MacOS, which required those funky additions of rrBB and rrHB - you wouldn't need those steps in a Linux system. 13:36:14 You'd work with literal addresses, whereas everything stored in my system is offets. I have to add the base address of a region to each one to get the address. 13:36:21 So try to ignore that part. 13:36:26 tape drive: there was another guy that used a diffrent casette recorder and player that took these endless loop one way tapes 13:36:48 I think the same scheme in a Linux imp would just be missing both of the Offset --> address lines. 13:37:35 KipIngram: aside from those offset-related instructions, it looks pretty simple 13:37:39 :-) That's pretty fascinating. Seems like someone tries more or less everything eventually. 13:37:58 in that setup each block had servral locations evenly spaced around the tape 13:38:00 Yes. Compared to traditional FIG next it just has that one extra indirection. 13:38:21 Oh, but you don't see that here. 13:38:32 That extra level of indirection would be in the "docol" routine. 13:38:54 Sorry - so this is a completely traditional NEXT except for the Offset --> address lines. 13:39:01 And Apple force that on me. 13:39:25 so, each block had a version counter field in it 13:39:48 Yeah, I'm not fully grokking how these versions come into play yet. 13:40:11 Is there any trouble with "inlining" in a ITC system? 13:40:16 I used to wonder if you could do something like that endless one way tape with fiber optics. 13:40:31 Just have a repeater, that receives what comes out of the fiber and continually shoves it back in. 13:40:50 And however long the fiber was, if you wait a little while any piece of content will come by. 13:40:59 Just intercept what you need, replace what you want to replace. 13:41:21 I don't really see any immediate reason why that wouldn't work. 13:41:45 the tape the guy used was an hour long one but he could play it back at 4x speed 13:41:47 A km of fiber would spin every 3 us or so. 13:42:43 in extended memory he had a list of block nrs and their version 13:42:44 And say you worked with 5ns windows - that would store about 600 bits. So not much, I guess. That's probably the problem with it. 13:44:10 it meant that at power up he had to play the whole tape through for the system to discover which version nr was highest per block 13:44:25 Yeah. 13:45:35 but it meant that older versions of a block could be overwritten 13:45:48 Ah, I start to see now. 13:46:18 often with a diffrent block alltogether 13:46:20 That seems to bear some similarity to NAND flash strategies in data storage. 13:46:37 The write process there is sort of a continuous big loop through the physical storage. Over and over. 13:46:50 And you update logical to physical mapping however you need to as you go. 13:49:09 the neat thing regarding this recorder player was the read head was in front of the ereaser and write head 13:49:40 Because it was running backward? 13:50:15 nope this is the continous loop one 13:52:59 the guy figgured that he could record while playing back 13:54:47 so he built an decoder and encoder in hardware which meant that the stuff on tape was always being refreshed 13:54:50 Sure - why not? 13:55:34 I mean, two different spots on the tape - may as well do two different things. :-) 13:55:39 --- join: dave0 joined #forth 13:56:00 maw 13:56:36 hey dave0 13:56:45 You missed it - I was plugging your 13:56:48 Forth earlier 13:56:49 hey KipIngram 13:56:58 oh cool! 13:57:01 thanks guy :-) 13:59:37 KipIngram: so he experimented with overwriting obsoleted block versions with the block buffer that was least recently used 14:00:17 Ok. 14:00:59 worked suprisingly well 14:01:08 I think if I rig up this cuckoo-hash equipped block buffer system, then essentially I won't have to write any blocks out until the buffers get around 95% full. 14:02:02 Which really means that most of the time I'll probably write stuff out when I quit. 14:02:20 --- part: f-a left #forth 14:02:25 With how large memories are on computers I can easily have more buffers than I'd ever really use. 14:03:10 what I do not get was why there were diy papertape readers but no punches 14:04:23 Hmmm. Was there just no good cheap way to implement the punches? 14:04:44 I could easily imagine reading a paper tape on the fly as it's moving, but how would you punch it while it was in motion? 14:04:51 Just really really QUICKLY? 14:05:02 Before it had time to move any significant amount? 14:05:58 Maybe you could punch with a wheel. 14:06:21 As the wheel rotated (rolled along the paper) the punch heads would come down in well-contained spots. 14:06:43 If you could control a whole bunch of punch heads around the periphery of the wheel, maybe that could work. 14:07:29 That would be a lot of punches, though. 14:08:00 I'm having trouble thinking of anything other than advance/punch, advance/punch... that would be easy to home brew. 14:15:58 Ah man - got to caught up in this and missed a 4pm time for a phone call. 14:16:01 I've joined now, though. 14:16:10 It's too entertaining around here, man. 14:16:46 So, if I add this cuckoo hash stuff I'm still going to structure things the same at the top-most level: 14:17:15 : block (block) .0>; ...other stuff... ; 14:17:35 (block) will be written in assembly and it's job will be to implement the fast "already resident" path. 14:17:55 Which in this case will be all reads actually, until we start to get full. 14:18:07 So it will make good use of all the space I provide. 14:18:33 ...other stuff... will probably be written in Forth, because for whatever reason we're going to have to visit the disk now. 14:18:43 So not the same premium on speed. 14:58:23 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 14:58:26 --- join: Zarutian_HTC1 joined #forth 14:59:06 --- quit: tech_exorcist (Quit: tech_exorcist) 16:57:10 --- quit: dave0 (Quit: dave's not here) 17:01:27 --- join: rtdos joined #forth 17:01:27 --- join: proteanthread joined #forth 17:11:00 --- quit: rtdos (Ping timeout: 258 seconds) 17:11:00 --- quit: proteanthread (Ping timeout: 258 seconds) 17:14:27 --- join: rtdos joined #forth 17:14:27 --- join: proteanthread joined #forth 18:31:35 https://imgur.com/a/ifiUT0B 18:31:45 that is drawn in a 100% pure console text mode 18:31:54 rendered i should say 18:34:16 --- join: boru` joined #forth 18:34:20 --- quit: boru (Disconnected by services) 18:34:21 --- nick: boru` -> boru 18:44:23 --- quit: rtdos (Quit: Leaving.) 18:44:23 --- quit: proteanthread (Quit: Leaving.) 18:47:00 Nice. 18:48:21 :) 18:49:19 i have to get the bitmap raw data and somewhat rearrange the pixles :) 18:49:41 each character cell is 2 dots wide and 4 high 18:52:48 console based graphics is kind of fun. Do you know about sixels? 18:59:14 yes 18:59:19 used for printers 19:19:05 --- quit: sts-q (Ping timeout: 252 seconds) 19:19:47 I've found the whole idea of sixes interesting. 19:20:04 I like consoles, but it would be nice to be able to look at images and so forth when you wanted to. 19:20:13 Without having to pony up for the full GUI experience. 19:20:31 I've always felt like GUIs are overdone - graphics used where it's not really needed. 19:21:47 --- join: rtdos joined #forth 19:21:47 --- join: proteanthread joined #forth 19:29:03 --- join: sts-q joined #forth 19:31:50 Holy cow it's come up a blow. 19:32:03 Intense thunderstorms, tornadoes in the area, quarter-size hail, the works. 19:32:29 The easter edge of it all is just entering the area, and it sticks WAY off to the west in my weather app. 19:32:37 Looks like it's going to be quite a night. 19:37:19 where are you located? 19:41:24 --- quit: mark4 (Quit: Leaving) 19:42:15 --- quit: proteus-guy (Ping timeout: 260 seconds) 19:47:56 --- join: mark4 joined #forth 19:47:56 --- mode: ChanServ set +v mark4 19:50:23 Houston area. 19:50:28 Oh; I guess he quite. 19:54:35 --- join: proteus-guy joined #forth 20:02:19 im back :) 20:02:21 i had to reboot 20:08:00 mark4 - I'm in the area just slightly west of Houston, TX. 20:08:31 It's lightened up some now, but I think there's more to come in a little bit. 20:08:33 yea i was in north dallas till i moved here 20:14:38 --- quit: Zarutian_HTC1 (Ping timeout: 252 seconds) 20:16:25 My sister in law lived in Dallas for a while. 20:16:47 I spent a summer in Fort Worth, way back in 1982, doing an engineering internship with General Dynamics. 20:17:12 Man, I was as green as green gets - only had my freshman year under my belt. 20:19:09 heh 20:23:04 fucking getting annoyed with the GIMP. every fucking thing you do it anti aliases the fucking results and theres no fucking way to turn it off 20:24:30 mark4, what are you doing with it? 20:25:36 i have no graphics skills and got extremely annoyed at similar shenanigans then just wrote a python script to output svg 20:26:28 MrMobius: Way to go man - like how you roll. 20:27:17 im doing a 3d rotation transform about the z axis 20:27:29 and its fucking over by bluring the entire fucking image with anti aliasing 20:27:38 i fucking hate anti aliasing and you cant fucking disable 20:27:40 it 20:27:45 --- join: dave0 joined #forth 20:27:52 im not using svg 20:28:24 ya i made about half of a video game on windows once and anti aliasing always being on was annoying 20:28:27 i need to have one image not rotated. a copy of it rotated 5 degress + and 5 degrees minus then 10+ and 10+ ... all the way to 85+ and 85- 20:28:42 actually i could use reflections and get rid of the - side 20:32:53 mark4: What are you writing? 20:33:21 im going to do a ray cast thing in a console 20:33:23 text mode 20:34:25 what i need is a damned graphics editor that does not totally FUCK OVER everything i try do in it 20:34:36 and #gimp is 99.909999999999% unresponsive 20:34:48 they answer one question and then go away for a month 20:35:03 and sometimes their answer is "you cant stop it doing that" 20:44:17 I've used gimp quite a bit but I've never found it to very... graceful. 20:47:24 every time i need to use it its a nightmare of constant fighting it to NOT do something it thinks i must want 20:51:15 mark4, are you on windows? 20:52:51 you should be able to use GDI/GDI+ to rotate pretty easily and I think you might be able to disable anti aliasing 20:53:03 although opencv in python might let you do it too 20:53:33 There's also the ImageMagick library, but you have to code your tasks then. 20:56:09 linux 21:09:56 --- quit: dave0 (Quit: dave's not here) 21:18:07 --- join: gravicappa joined #forth 22:19:03 --- join: dave0 joined #forth 23:11:17 --- join: Zarutian_HTC joined #forth 23:19:08 --- quit: gravicappa (Ping timeout: 240 seconds) 23:58:13 --- join: mtsd joined #forth 23:59:59 --- log: ended forth/21.05.18