2023-11-09 03:43:59 Naa? 2023-11-09 03:44:01 Hm 2023-11-09 03:59:25 Ehm when did gforth add "normal" strings instead of s" ..."? 2023-11-09 04:00:02 Having 0.7.3 on my tablet 2023-11-09 04:01:25 Damn train wifi haha 2023-11-09 05:56:45 ollehar2: it's had "normal" strings since at least 2018 2023-11-09 08:12:52 Well, I harvested two new jobs last night and my deletion of data from the database in the afternoon didn't seem to help at all. The consumed space went up again anyway. 2023-11-09 08:13:42 This is suddenly a kind of urgent situation. But I did find myself wondering - this is a virtual system. Isn't one of the whole points of "virtual" that it makes it possible to adjust things like this on the fly? Shouldn't they be able to just make that storage space larger? 2023-11-09 09:02:06 Oh, good news - the IT guy tells me he can, in fact, grow that storage space. So hopefully this will just go away in a few hours. 2023-11-09 09:35:13 Makes me think consumed space might go up while doing a delete operation 2023-11-09 09:35:28 Which might make sense depending on how you're changing the table 2023-11-09 09:35:42 temporary tables and whatnot, especially if it don't fit in memory 2023-11-09 09:36:36 I'll admit this is fully outside my expertise 2023-11-09 10:05:13 Yeah, i had already confirmed that harvesting a typical job grew the db by about 75 MB. Last night I harvested two, but when I chedked this morning it had grown by considerably more that 150 MB. 2023-11-09 10:05:25 So it does look like deleting rows somehow TOOK space. 2023-11-09 10:22:51 Chances are the two jobs took up the 150MB of space I expected, using freed space, and the actual increase that shows at the os level was all due to the delete. So thinks may be fine - I *now* might show no increase if I continue harvesting. 2023-11-09 10:23:13 But since he's going to grow my space I'll just stand down until he's done with that. No pressing need to harvest anything right now anyway. 2023-11-09 10:23:37 I do have two jobs waiting for that, but they're not jobs anyone specifically asked for - they're just me staying on top of the latest firmware. 2023-11-09 10:37:08 I'm not sure I see why deletes would require space - that seems like a dangerous situation to allow to happen. But of course I have no idea how they have it set up. 2023-11-09 10:37:41 In my typical allocators, when I free a space I use a cell of that freed space to make it a member of the free list. No extra space is required to support that. 2023-11-09 10:38:24 Also, I bet my large delete yesterday failed because it was keeping temporary transaction information in the same storage space, and there wasn't enough room for the amount it needed. 2023-11-09 10:38:44 That was the nature of the error it through: not enough entries in a "lock table." 2023-11-09 10:39:13 but at any rate, people are going to fill up their drives from time to time - applications need to offer a way to "delete your way out" of that situation. 2023-11-09 10:39:51 yeah well someone ran their laptop HD 100% full for months and the NTFS developed filesystem loops 2023-11-09 10:40:26 Ick. :-) 2023-11-09 10:40:42 I try to never get close - this snuck up on me. 2023-11-09 10:40:54 so the nice windows admin tried to take a backup of the 500G disk and overran the network share (3T or whatever) 2023-11-09 10:40:56 I'll be adding instrumentation to keep tabs on it going forward. 2023-11-09 10:41:14 No reason I can't have my data harvest script just print out the remaining space situation each time I run it. 2023-11-09 10:41:30 In a way that makes extra sure I see it if I go over some threshold percentage. 2023-11-09 10:42:08 Also, this storage I keep this in is allegedly "backed up daily," but in my conversation with the IT guy yesterday he told me database backups don't always work. 2023-11-09 10:42:35 So it looks like I need to add some process steps to make sure I have a reliable backup that's at least within a few days of my current state. 2023-11-09 10:43:07 What he probably means, though, is that it's hard to make a good backup of a database that's actually in use constantly. 2023-11-09 10:43:25 I use this database very sporadically - only when I need to add new results to it or run a report. It's otherwise idle. 2023-11-09 10:44:02 My guess is that a backup made entirely while it was idle would probably be fine, but I suppose the only way tO be SURE is to actually shut the thing down, make a backup, and then re-start it. 2023-11-09 10:44:12 I can do that if he gives me a place to put the backup. 2023-11-09 10:44:26 I could set that up to run each weekend or something. 2023-11-09 10:45:59 When one of my jobs finishes, the results are sitting in a directory associated with the particular drive under test. "Harvesting" moves them from there to the database, and then I run a "clean" operation on the drive zone to empty out all the residue of that test. It's then ready to run a new test. 2023-11-09 10:46:34 So it would be inconvenient to have a test finish and then have to wait for a big backup to finish - I can't start the next job until I've harvested the results of the one that just finished. 2023-11-09 10:46:48 I guess I could establish a new "staging zone" to avoid that. 2023-11-09 10:47:13 What's "harvest" now would just copy the results to the staging area, and then an additional "harvest" from there would move things on to the database. 2023-11-09 10:47:57 You know, I actually am already doing that - it's just hidden from me. I rsync to another machine and then harvest from there. So i can decouple those steps pretty easily. 2023-11-09 10:48:30 I'll try to work that up as part of the general automation improvements I mentioned earlier. 2023-11-09 15:47:22 You know, I think I definitely prefer the cmForth way of handling compiler vs. interpreter words. The idea there is to place compiler words in a separate word list. The interpreter will only search the Forth vocabulary (and any others you've specified), but the compiler will search a separate vocabulary, COMPILER first, and then search the others. 2023-11-09 15:48:05 The very nice benefit of this is that you no longer have to mark headers are immediate. 2023-11-09 15:48:10 Saves a header bit. 2023-11-09 15:49:41 And also Liz Rather wrote that it makes cross compiling more streamlined. I think I kind of halfway see that, but not completely yet. 2023-11-09 15:56:24 Getting a bit out of the standard header layout seems pretty valuable to me, though. 2023-11-09 16:04:42 thrig: Did the network share get loops too and repeat process? 2023-11-09 16:11:44 no, the derp was only on the laptop drive 2023-11-09 21:26:10 Hey, question. If I have a move instruction that moves either direction between a register and a RAM cell, and then I follow that with a second instruction that does the same thing with another register and an *immediately adjacent* RAM cell, I'd expect that second one to be very low cost for cache reasons, right? 2023-11-09 21:26:46 I mean, it's clear that's the case for reads, but I guess it would also hold for writes, wouldn't it? 2023-11-09 21:32:06 A couple things I'm considering for the new system involve saving more than just the return address on the return stack. If I also save my partially shifted instruction cell, then I can return back to "within" a cell, rather than just to the start of the next cell. So I won't just waste the rest of a cell every time I make a call. 2023-11-09 21:32:55 But of course, that's an extra store on every call and an extra fetch on every return. But they're right next to one another, so most of the time they'll share a cache line. 2023-11-09 21:34:14 And the other thing I'm considering is implementing my "jump back to start of word" (the "me" words) by having that address in a register. So every time I call a new word that would have to be saved and updated for the new word. 2023-11-09 21:34:29 So that's three items I'm considering putting on the return stack. 2023-11-09 21:35:06 But it will eliminate having to fetch a jump offset out of the code stream; those "me" jumps will just become jmp . 2023-11-09 21:35:53 And for a loop I repeat a large number of times, that savings might add up. Although the jump offset, if it were there, would also get cached the first time around the loop. 2023-11-09 21:37:13 The neat thing about doing "me" words this way is that I can have an instruction that will, if I want to, "slide forward" the jump target. So I'll be able to jump back to anywhere in a word I choose. 2023-11-09 21:37:36 With the "default' being the beginning of the word. 2023-11-09 22:54:33 I'm also planning to have a "family" of call instructions that are standard size opcodes, but with each having a different call offset hard coded. All of thse features are oriented toward letting me call "nearby" helper words without having to discard residual parts of my cells. As much as possible will just be "opcodes." 2023-11-09 22:55:20 When I started planning this I was thinking in terms of six-bit opcodes, but I'm now looking at seven, or possibly even eight (maybe) to make room for that "family." 2023-11-09 22:56:00 I'll have a call instruction that can take an offset as well (like the F18A) to call things too far away to reach via the short call ops.