cantstanya has quit [Remote host closed the connection]
cantstanya has joined #forth
Zarutian_HTC has quit [Ping timeout: 260 seconds]
Zarutian_HTC has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
wineroots has joined #forth
<KipIngram>
veltas - that was an interesting idea earlier - that a typical hierarchical file system approximates a self-balancing tree. Not exactly, of course, but I suspect you're right in most cases.
sts-q has quit [Ping timeout: 268 seconds]
sts-q has joined #forth
mtsd has joined #forth
phadthai_ is now known as phadthai
<proteus-guy>
KipIngram, are your stack frames effectively offering a C-call ABI to forth words?
<KipIngram>
Possibly. Tell me a little more about what that means.
<KipIngram>
{ saves the existing frame register on the return stack and mirrors the stack pointer into the frame register.
<KipIngram>
At that point references off of either of them would be the same.
<KipIngram>
But nothing else changes the frame register, so even as the stck wiggles back and forth it provides a stable reference. } retrieves the frame register from the return stack and does a final adjustment on the data stack.
sts-q has quit [Quit: ]
sts-q has joined #forth
mtsd has quit [Quit: Leaving]
mtsd has joined #forth
<KipIngram>
:* how clever?
<KipIngram>
Ooops.
<KipIngram>
Sorry.
jedb_ has quit [Quit: Leaving]
jedb_ has joined #forth
jedb_ is now known as jedb
<proteus-guy>
KipIngram, what happens if your word starts with { but exits early without calling }?
andrei-n has joined #forth
andrei_n has joined #forth
andrei_n has quit [Client Quit]
jedb has quit [Quit: Leaving]
jedb has joined #forth
gravicappa has joined #forth
hosewiejacke has joined #forth
<KipIngram>
Don't do that. They have to balance. { covers up the return address.
<KipIngram>
As well.
<KipIngram>
You can see how I used them in my FIND here:
<KipIngram>
Anyway, there's precedent for that; you get into trouble if you >r without r> as well.
<KipIngram>
And of course you can't issue either one from the interpreter; they're in-definition only.
<KipIngram>
And I don't protect against that, though I suppose it wouldn't be terribly hard to add.
<KipIngram>
But one of the things I like about Forth is that it will let you shoot your foot off.
<KipIngram>
That paste shows two modes of usage. In vocs and words I nenver actually use the frame variables - the primary purpose of { ... } is to effect stack cleanup, regardless of how lower code left the stack. But the usage in chars, in addition to doing that, makes the stack variables available for the lower code to use.
<KipIngram>
I was quite pleased with that code - just 13 short little definitions, but it handles the whole dictionary search. Walks the vocabularies, walks the word lists, iterates over the words' characters.
<KipIngram>
Much more concise than in my previous attempts.
<KipIngram>
I feel that's it's the stack framing and the conditional (sometimes double) returns that made that happen.
<veltas>
KipIngram: At one point I thought that's why filesystems were in trees, but now I think it's more to do with namespacing and structure than anything else
<veltas>
But yes they do naturally balance in a lot of cases
<veltas>
If I wrote a filesystem then it would be one big B-tree with the paths as keys, directories would be stored as files with a list of paths or block numbers solely to speed up enumerating a directory
<veltas>
And files would store a B-tree of actual block ranges (block range is the key)
<veltas>
I would not be surprised if an existing filesystem does something like this
<KipIngram>
Yeah, it's hard these days to be the first to think of something. But it's still nice to think of it independently.
<KipIngram>
Interesting that block *range* is key - I think I have a gut sense of how that could be, but I'd have to think through it to be sure.
<KipIngram>
In a lot of cases it seems like there would be a gradual evolution away from having many ranges, as you frag up the file system. But in something like flash-based storage where you move stuff around every time you re-write it anyway, you could perhaps put some natural recovery from that in.
<KipIngram>
Well, maybe. Not sure. Just woke up a few minutes ago - need coffee...
<KipIngram>
I'd already thought about how a b-tree could store a file without using ranges; I haven't pondered it with the range option yet.
<KipIngram>
I take it the b-tree sort would be on start of range? Or is there something more clever going on?
<KipIngram>
So, those thoughts I was having about storing comments - I realized I was thinking about just one layer. Source, attached comments, and that's it. But there would be no reason not to have source, comments on source, detailed comments on comments, etc. - it's really a whole wiki scheme. B-tree really seems to handle that well; you could implement an arbitrary "linkage network" amongst spots in the storage
<KipIngram>
array.
<KipIngram>
And that would be a very compact b-tree; I decided you could get about 200+ links in each 4k block.
<KipIngram>
If I do that I'll probably put the links in in both directions, but with an indication of whether each one is a forward link or a backward link.
<KipIngram>
Logically, I mean.
<KipIngram>
So it would wind up that the source code just contained entry points to a documentation tree.
<KipIngram>
documentation wiki, rather.
<veltas>
KipIngram: Block range would be key in file B-tree because you would store ranges of contiguous blocks
<veltas>
And because the key can be hashed easily and has a well defined ordering
<veltas>
A lot of modern filesystems have a lot of unnecessary crap to do with hard drive geometry that's now redundant on SSDs
<KipIngram>
Yes. We design flash-based storage at work, so I'm fairly well exposed to the differences between managing hard drives vs. flash.
<KipIngram>
While it would have been a lot of fun figuring out all those spinning disk optimizations, it's really nice that the need for that stuff is fading.
<KipIngram>
But let's say you define a new file, and it's all nice and contiguous. Then you make a small change to it - that re-writes one block and now you have two contiguous ranges with one odd man out (range of 1). Update another block, and one of those ranges gets split. Don't you eventually wind up with very few ranges?
<KipIngram>
And lots of odd men out?
<KipIngram>
It seems like unless you periodically go clean up that's the direction it would go.
<veltas>
This small change hasn't changed the size?
<KipIngram>
Might not, but ok - if you have to re-write everything after that then that would eliminate the odd guys out I guess.
<veltas>
It would just update the block "in place" (not really in flash but that's a different level of abstraction)
<veltas>
And if it changed size it would update the block and all later blocks in place, maybe adding some extra blocks elsewhere as a tail
<KipIngram>
Oh, ok - you're still assuming a logical to physical management layer that's separate.
<KipIngram>
Ok, but that would still split the original range?
<veltas>
Yes that's worth doing because flash has such strange behaviour and there's little or no disadvantage to layering that
<KipIngram>
Well, and it's almost always going to be part of what you buy with the SSD anyway.
<veltas>
I'm not sure how modern SSDs do it but I think they abstract this stuff out themselves
<KipIngram>
Unless you're actually building your own system from raw flash, you don't really have control over the L-to-P stuff.
<veltas>
If you bought NAND chips yourself then you can do hardware or software stuff to track logical blocks
<KipIngram>
Right - that's the level we work at at work.
<veltas>
I am familiar with NAND/NOR flash
<KipIngram>
These days I know NAND better.
<KipIngram>
Haven't worked with NOR in a long time.
<veltas>
NAND fits a block abstraction better
<veltas>
With NOR more complicated abstractions or lower level algorithms become more productive
<veltas>
Because the programming granularity is much lower
<KipIngram>
Makes sense. Anyway, I'm not arguing with you here. I believe you've thought it through. Just trying to follow your reasoning.
<veltas>
Well if you have a reasonable number of contiguous regions then it yields a smaller tree to track the file
<KipIngram>
Yes.
<veltas>
That's the advantage, on SSD there is no other real advantage to having contiguous blocks of course
<KipIngram>
Right.
<veltas>
So that's why I'm storing ranges
<KipIngram>
Ok; it makes sense. As long as the range length didn't go all the way to one there would still be an advantage.
<KipIngram>
And it seems reasonable to me that it might not (go to 1) in a randomly accessed system. That there would be some equilibrium.
<KipIngram>
proteus-guy: Thanks! Good morning entertainment!
<KipIngram>
Yee ha!
<proteus-guy>
Flying now!
<KipIngram>
That's just awesome.
<KipIngram>
The things we can do...
<KipIngram>
I watched the first Falcon Heavy launch. When those two side thrusters just set themselves down pretty as you please on their pads, it almost brought tears. That kind of thing was just science fiction to me before that day.
<proteus-guy>
Yeah that was freaking amazing. I call it "lawn darts for billionaires"! :-)
<KipIngram>
lmao
<KipIngram>
Right on.
<KipIngram>
Wow - see that little rock or something float by?
<KipIngram>
Just after separation. Maybe it was a piece of gear.
<KipIngram>
I do hate to think of all the junk we're accumulating up there.
<proteus-guy>
haha there's all kinds of bits of stuff that get shook loose.
<proteus-guy>
it's all low orbit - it falls down pretty quickly.
<KipIngram>
That's good. :-)
<KipIngram>
That was great.
<proteus-guy>
they can't see outside until nose cone is off.
mjl has quit [Ping timeout: 258 seconds]
mjl has joined #forth
<KipIngram>
Ah, so they weren't actually enjoying those views when they mentioned it.
<KipIngram>
So, how is Musk's whole Mars plan going? Is he still generally on track?
<proteus-guy>
Up to getting Starship flying but the new generation vehicles are up next and I think they'll be flying and landing multiple times soon.
<KipIngram>
Groovy. That's an aggressive name, by the way - "Starship."
<KipIngram>
That actually has a cultural meaning, and... it isn't.
<proteus-guy>
Well do you know what its original name was?
<KipIngram>
But they were already playing thta game when they named the first shuttle Enterprise.
<KipIngram>
No, I don't the name history.
<proteus-guy>
BFS were the initials.... care to guess? :-)
<KipIngram>
:-) Well, big f***ing <something> comes to mind.
<KipIngram>
But that wouldn't do for a public name.
<proteus-guy>
Particularly embarassing when Enterprise was never gonna fly into space. Just an outrageously expensive glider.
<proteus-guy>
Big Fucking Spaceship. :-)
<KipIngram>
Yes.
<KipIngram>
I remember being vastly disappointed by that.
<KipIngram>
Honestly, though, the fact we were able to do anything at all in space before the modern microelectronics era is pretty amazing.
<KipIngram>
That stuff was so damn crude compared to what we can do now.
<proteus-guy>
Yeah a good chunk of the Star Trek original cast was there when it was unveiled with the name and I was just like... grr.... idiots!
<KipIngram>
Yeah, I remember.
<KipIngram>
I'm old enough for that. :-)
<veltas>
That's like calling a boat an inter-planetary transport
<KipIngram>
Right?
<proteus-guy>
indeed
<veltas>
Columbus was an astronaut
<KipIngram>
;-)
<proteus-guy>
Well to be honest, Apollo invented the modern microelectronics era. First ICs were the guidance and flight computers on Saturn/Apollo.
<proteus-guy>
Howdy crc ! See the launch?
<KipIngram>
Well, that's actually very easy to believe. Even the early gens of chips would have made so much more possible.
<proteus-guy>
KipIngram, yeah Apollo radically pushed the limits. And then the landing computer on Eagle was overwhelmed with data from the ground radar and kept resetting. They had not tested the two together... yikes! So truly pushing the boundaries to the extreme.
<KipIngram>
Ah, man. That could have been disastrous.
<proteus-guy>
nearly was.
<KipIngram>
I remember sitting up late one night with my mom when I was just six to watch Armstrong climb down onto the moon.
<proteus-guy>
But the computer guy saw what was going on and understood it immediately and called the ok to land. That call decided whether the mission would be scrubbed or not in less than 3 seconds. Those guys knew their stuff and were cool under fire.
<KipIngram>
Indeed - it was a great time for NASA.
<proteus-guy>
I was younger. I do remember one night launch, likely Apollo 15, and I was super exited about it (less than 6 years old) all day long. Finally it went up and then I was so pissed when Cronkite said it'll be a couple of days until they land on the moon. I stayed up all night to see them walk on the moon that day! haha I didn't realize they wouldn't just get straight there.
hosewiejacke has quit [Ping timeout: 240 seconds]
hosewiejacke has joined #forth
<KipIngram>
:-) The innocence of childhood...
<KipIngram>
Ok, cordics are really interesting.
hosewiejacke has quit [Ping timeout: 240 seconds]
f-a has joined #forth
<mark4_>
my father worked for NASA going round the world working on tracking stations
<mark4_>
when i was 3 i was in madagasgar because nasa had a station there
<mark4_>
i have a nasa patch for tananarive madagasgar
<KipIngram>
Cool.
<proteus-guy>
that's pretty rad.
hosewiejacke has joined #forth
f-a has quit [Ping timeout: 268 seconds]
f-a has joined #forth
f-a has quit [Ping timeout: 240 seconds]
f-a has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
tabemann has quit [Remote host closed the connection]
<KipIngram>
Ok, so my usual desire in a digital system (to be able to feel explicitly aware of what every little bit of it is doing) just isn't really going to work with a monster like that, is it?
<KipIngram>
HOLY COW. 20 PB/sec memory bandwidth.
<veltas>
That desire hasn't worked since like the early 90's
<veltas>
Perhaps even earlier
<veltas>
And frankly if you expand the scope of what you understand you've never been alive in a situation like that
<KipIngram>
That was around when I moved from design only to management.
<KipIngram>
I was still able to fake it for a while, but you're really right.
<veltas>
Even just the CPU was so ridiculously complicated by the Pentium Pro
<KipIngram>
Sure. I don't understand all the quantum events underlying everything I do. :-)
<KipIngram>
Or even all of the analog behavior.
<KipIngram>
But digital network design provides a pretty stark "dividing line."
<veltas>
Something like spectre and meltdown required nobody to really understand how the Intel CPUs work from top to bottom
<KipIngram>
What I"m referring to is the level of designing an FPGA image by drawing a schematic.
<veltas>
Yes
<lispmacs[work]>
KipIngram: I should think that a chip like that would be a lot of blocks of something repeated many times
<lispmacs[work]>
maybe not hard to grasp the fundamental block
f-a has quit [Ping timeout: 260 seconds]
f-a has joined #forth
boru has joined #forth
<KipIngram>
Very true; it says in the article that it spreads the resources out over the various layers for neural network training. And those training algorithms are pretty easy to express using matrices and so forth.
hosewiejacke has quit [Ping timeout: 268 seconds]
andrei-n has quit [Read error: Connection reset by peer]
andrei-n has joined #forth
dave0 has quit [Quit: dave's not here]
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Ping timeout: 265 seconds]
gravicappa has quit [Ping timeout: 260 seconds]
<siraben>
KipIngram: compositional design helps immensely with complex systems, if something is comprised of reusable parts with clear semantics/behavior, IME it becomes drastically easier to reason about the whole
<siraben>
depends on the domain of course but outside embedded it's often infeasible to get to the bottom of everything
<f-a>
↑
<f-a>
tho siraben , some $haskell_firm solved a problem by hiring a ghc lad
<siraben>
f-a: oh, elaborate
<f-a>
as only he knew the internals and could insta pinpoint the performance problem
<f-a>
I wish I could, lore from #haskell
<f-a>
or was it discourse.haskell.org
hosewiejacke has joined #forth
<f-a>
I was happy for the new hire but felt «betrayed» too :P
<siraben>
amazing how Haskell stdlib source is very readable but the whole is insanely complex
<siraben>
various list functions come to mind, implemented like textbook versions heh
* f-a
nos
<f-a>
+d
<siraben>
ah i see
<siraben>
I tried peering into C++ internals before and oh boy
<f-a>
hehe
<siraben>
bbl
hosewiejacke has quit [Remote host closed the connection]
mtsd has joined #forth
shmorgle has quit [Quit: [TalkSoup] via NEXTSPACE]
<KipIngram>
This book looks like it's doing it's best to be a full coverage computer science textbook.
<KipIngram>
Like, from scratch.
<KipIngram>
But the "review" I read of it (https://twobithistory.org/2018/10/14/lisp.html) makes it sound like it also has a weird mix of philosophy and humanism in it. Just sounded too strange for me not to track it down and take a look.
<KipIngram>
I'm doing a fairly rapid perusal of it now, and it's going through all of the basic number theory stuff and really laying down the low-level foundations.
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
phadthai has quit [Remote host closed the connection]