Delta Time - part 2 (basic intro?)

So, what am I doing?

I've ... gotten high while immersing myself into code. Checking things here and there - and trying to follow up what I was doing in reference to what I want to be doing. Thereby I encountered various instances along the way that bugged me - going through it one by one ... while making some adjustments here and there. Mainly to how the Meta is being set up. Thereby I stumbled upon a flaw in how ~the Meta~ ~is~ being set up; And while looking around for how to solve it, I finally navigated to the place where it would fit. The first available space for the particular fix in question. But how the fix should work out, that is now a relatively important question and basically has like ... vast consequences on what is to come.


And hence it is practically a good place to 'start'. For here now the thing would take its final shape, in as far as this little project here is concerned - to say:


Obviously setting up access units through M is silly. Well, one might be tempted to setup the Source by argument, but the intention is clearly for this to not be the case. While the statement has been that we're cheating M access into Lumberjack, it should be even more so prudent then, to understand what the rule would be. Clearly M isn't supposed to be accessible and the implications thereof have to be properly realized.

So, moving to m_CORE right beneath the "ion gates" ... there ought to be a function to be called instead of calling REGISTER_XS_UNIT directly. Within we access m through zero - where now the question becomes how restrictive we want to be about Access Units.
I should say very. But ... user output and online sharing demand a safe way to integrate foreign code into the own codebase; And as I continue I should continue to urge a code-based safety web. So, principally using macros to obscure critical functions and undef the macros once leaving the designated scope.


The REGISTER_XS_UNIT function thus needs an interface that allows us to initialize XS Units in any given environment; And here we then check for what permissions are being set. And to properly understand what's going on, we move to the first primary collective instance of this project. CrystalsMeta.h, here in __Meta__INITIALIZE__, we need to settle on what the System can give us - and from there we move through different layers to exit the function in the state that the System is supposed to be in, according to what we can specify in the Meta. Everything outside of that is userland.

Sortof. In there are isolated cores, each with specific functionality and interactions - and to properly map that out, we now come back to where we were before. m_CORE.cpp.
Or, on another note we get into Crystals_MAIN.h.cpp - specifically M_CORE::INITIALIZE in that it encapsulates what's going on in __Meta__INITIALIZE__. So, from a process flow perspective.

To put this back into perspective, we move back to CrystalsMeta.h - and make sure that Crystals_MAIN.h.cpp is included therein, rather than Lumberjack. And also as first thing. This will allow us to make cleanup simple. As to also understand where that line is. You might then copy the SYSLOG functions into there, after including Crystals_MAIN.h.cpp, as __META__::LOG(_OK/ERROR), and define _metalog as __META__::LOG. And we set the default to 1 - initializing a depth of maybe ... 5. And so, assuming _metalog is defined right after the __META__ namespace, there's ... some blank space there. And this is possibly where we first want to include Lumberjack.cpp - and I suppose there somewhere we can also place a separator.


In __Meta__INITIALIZE__ then, the first critical function is INITIALIZE_META_VOLUME. And here ... well. We produce the Meta - and ... well. Within the compiler settings, I changed rbx to reg__Zeta, r14 to reg__Meta and r15 to reg__Option.
Regarding reg__Source and reg__Dest, I labeled them as 'system imposed' - reg__Meta and reg__Option as Meta specific.


And this would then be ... the basic ... setup. So - in a way, intentionally not available as a package. You have to settle your own way in. Or you take the next one, where these things ... well, we'll see when we get there.

And so, for now, reg__Meta is meta. But ultimately - in its final form - that's not the case. So - reg__Meta doesn't say Meta, we need something else for that. And why are we doing that? Well. System Levels. We can't do much about that here - or I can't. Since the structure is designed as to be an operating system, there are different layers of system access. Some are critical internally, others are critical functionally. So, there are different priorities.

The System Core is supposed to be the functional backbone of the system. So, that's the stuff that's ultimately relevant and used - preferrably at utmost efficiency by whatever metric. So - in term of user access there has to be a permanent "gate" untowards end-user access; And that is realized in the T Core. Supposedly.

So, anything that needs to be globally accessible. It's also ... a logical bridge. A tool of convenience.


So - with that being said, say ... you started with five, followed this guide; But it's 10 years later and whatever is possible - so, how does one get from here to there?




So - as for Lumberjack, I think I found fertile ground for some of my ideas. And to keep it really simple for now ... we need a full screen - so if you only have one you should kick the Metabar, unless you find some workaround for it. So ... simple jack. First I moved the class and the primary function into a separate file, included from within CrystalsMeta.h, right after the Control Frame. Then, between jack.PRIME_SETUP and jack.FINALIZE I have the screen init - but now the question is ... what goes where?

Lumberjack is here its own thing. That's the solid part that wouldn't or shouldn't change. Or the main thing, while simple jack ... well, that's where we are at the beating heart of the system.

Like, if we were displeased by the overhead of the Unit Cue, we could wire in a signal to M. That is, if we have access to M. In that regard, there now are two options: Option One: There is no (active) Access Unit that has access to M; And option two: There is at least one active Access Unit that has access to M. Further: By controlling the priority of each Access Unit, we can create scopes regarding Meta and Option. So - setting Meta to a specific value while leaving it there, allows us to append Units that can utilize that particular setup.

So - going into __Meta__INITIALIZE__ we expect to have M, initialize the units that may have it, and then ... would clear it to whatever need be. This is finally then the first logical user gate. To say, here M is definitely inaccessible because the user gate itself takes the spot where M would otherwise be. Is that really safe? Well, presumably the -whatever takes its spot- would first have to be mistaken for M - to then be probed in a way as though it were M. So, where does that happen?
M, for all intents and purposes, is userland. To that extent access to M is the primary thing we want from Crystals_MAIN; And from here we can now control the main loop and other things.
So, by defining __M we define how to address the M_CORE as within our code. Say, rename M_CORE into gobbldygook - so, once __M is undefined, access to your version of the M_CORE is no longer feasible. Well, by conventional means.

Do the same with the m_core, and now in order to access the critical functions embedded within it, critical guesswork would have to be done to actually "by accident" become vulnerable. And so, however you want to solve this; And whatever shared terms we would agree on; That's ... whatever.
Poof.

What remains is now: that by convention "user" is on Source and T on dest.
And Meta - as a useful link - would be something other than the Metacore itself - as we have it at first. Or, I. So, that's the question. After creating the Volume, Meta is on Meta so that M can be Source. Next we need something else on Meta, to mirror itself. And so at some point Meta has to also be on Source. Logically. We can think of this as a setup on the scope where we simply use two different Initialization functions - sort of initializing the Meta twice - but more to the point does it matter for the code in that we have to somehow juggle the two definitions. So, if we ever want to use certain functions in both scopes, we need some switch into a meta specific environment.

So we can determine:

ALPHA SCOPE
The main loop initializes reg__Source according to the Access Shell per setup to M and the EXEC PRIME function is being called. We set reg__Meta from M and now have first access to Meta. So - easy handle: while Meta is accessible through reg__Meta, there is 'first' access where reg__Source is M.

From here Meta ought to be copied to reg__Source; Thus entering

PRIMARY SCOPE

The way Lumberjack is set up, the "jack" is entitled to set the function to this scope. So, it does make sense to include simple jack within the control frame, possibly right above the separator.


Uhm, rewind. Idea: use _metalog as a separate line utilizing reg__Meta to interact with the Core.

But so, what is it then, that now goes to Meta? Uhm ... Delta Core. ???
So that finally we come to

DELTA SCOPE
Alias ... what the Meta can do - or what options the system might hold apart from what's at the core of it all.


So - what is user space?

Well. Good question. For once, the idea is that we do here now run a second loop. So, through instances that are now registered as such. Crystals. And so - finally the fog in my head ... oh my ... oh Lord. This is where the input belongs. So - we use the transition from alpha to delta scope to carry certain things into delta scope. So - through M we can set m to give us access to zero. Then we close zero back down - where we can now substitute or otherwise implement ... the input hook. Or whatchamacallit.

Well ... hmm. ... . Anyway.

Lumberjack is here our friend - though, which ... what does ...

Alpha side meta ... or let's say 'lower case' ... or 'system side' (M access) - and Primary Meta, so, upper case Meta. So, what can the Delta Core do for us? Other than just sitting there ... staring at me ... menacingly?


And that's my wrap for today.

---

I have Dwarf Fortress on itch.io by the way. It works out of the "box". No installation required.