OTheB @OTheB@mastodon.technology

MOAR LOGGING

I am now a box that is in space.

BABY IN THE OFFICE OH GOD OH FUCK

As temperamental as these deployment tools are at times, I'm actually really enjoying deploying this environment at work. It's easily the most real work I've got done in a while, so I feel like I'm being very productive which is nice, and because there's a lot of waiting for a few minutes at a time as things copy over and install, I'm still able to chip away at my compiler project in the background.

Hopefully this feeling will continue through next week too.

Little tip for anyone that uses #vCentre (willingly or otherwise): here's some custom #CSS you can apply to the #WUI to give you a nice big obvious header to show you which environment you're in. Just adjust the background colour and content to your liking.

.main-nav:before {
display : block ;
width : 100% ;
background-color : red ;
content : "PRODUCTION" ;
font-weight : bold ;
color : black ;
text-align : center ;
font-size : 20px ;
padding : 5px ;
}

I wonder what the implications of offloading all SSL stuff onto the router would be? As in, all devices in a LAN just communicate plain and with http, and if you visit a website, the request the computer makes is http, but the router then acts as a proxy and encrypts the request.

Disadvantage is that a bad router can see *everything* and it's a single point of failure, *but* at the same time, you don't need to keep SSL stuff up to date on every device, so none of them fall out of date and become insecure.

It would be a lot of work to setup, but I'm honestly pretty interested to see how well it would work.

What I expect is likely to happen is that - because of the inheritance - basically every function would end up disallowing any parameters from having differing scopes, but because the assignment only goes one way, the objects can exist in different scopes if the lower is put in the higher. I'm intrigued, so I'm still going to try it, but I'm not as sure on committing to it yet.

If I wanted to carry on pursuing this idea, then what I'd need to do is have each function expose an array of "links", that being any 2 objects mentioned in the function where one is placed into the other. It would then inherit links from functions called in that function so that - from any function - I can know at compile time which sets of parameters into a function need to be in the right relative scopes to be memory safe and error at compile time.

So I realised my whole clever memory management idea is pretty fucked - or at least is going to be *waayyy* more convoluted than I originally thought.

Because with the current idea, it can be broken with an `addChild` method that takes 2 objects and puts one in the other, because it can't know where the objects came from, it can't realise they're from different scopes.

Solution architect fucked up the spec files (that all our deployment tools read for info on how to do everything) so it's basically tear it all down and start again. Oh well.

At least I'm getting plenty of experience deploying DB hosts lmao.

Colleague sat next to me, quietly singing "Sex on the beach" to himself with different lyrics:

"This, used to work. What the fuck has goooone wrong? This, used to work..."

How in the fuck is it only 10 past 11

ngl there's something pretty satisfying and amusing about constructing these really convoluted pretentious descriptions of what #D code is doing like "oh it's just a mixin inside a mixin inside a static foreach over variadic type arguments to dynamically construct an anonymous union at compile time", and you have to say it in this really arrogant stuck up voice.

eeeeeeeehhhhhh I was getting recursive template expansion using algebraic types so I tried to roll my own and got exactly the same problem so fuck guess I'm going to have to *manually* write out code like some kind of savage.

Silver lining is that I can implement algebraic types from scratch now though, so that's pretty neat.

Going to kill off type generalisations and instead let the user just check for compatibility with a regular type.

Has the cool implication that you can then use literally any type as an "interface".

Oh your program has a memory leak? That's cute, this one I'm using has a *storage* leak.

So this environment deployment is going terribly. MSSQL has such an abhorrently bloated cancerous install media that the deployment host is literally just running out of disk space and aborting.

Like this thing is 10s of GiB.

I need a better keyword for these things though. 'external' normally means something completely different. I'd go with 'persistent', but there isn't a good 3-letter abbreviation of it.

So with this system, the default behaviour is that memory is "managed" at compile-time by just freeing everything from a scope when the scope ends, which the GC won't need to even think about. *However*, to prevent placing the rather horrible limitations on the user, you have this 'ext' marker that exempts the object from that automatic memory management and allows it to persist afterwards. The caveat though is that I then need a GC to tidy up these extra bits.

Uuuhhh no wait ok. So *this* [1] would be allowed. Both the Person and string are reference types, so the function is thinking "these are references, so they must have been declared in a higher scope". What *wouldn't* be allowed is this [2], because we're trying to store the reference to an object in something that will continue to exist *after* the object is freed. We can fix this with [3], which marks 'new' as 'ext[ernal]'.

You can do what you like with it in that scope, you can pass it as a parameter to a function, and you can return it from a function. What you *can't* do is store that variable in an object in a higher scope, because when the scope ends, it will disappear.

With just these features, memory management becomes relatively simple, but comes with limitations in that it's impossible to write a function that modifies a parameter without also returning it.

I *think* I've got a *sort of* reasonable idea of how I want to approach memory management for this thing.

While it *would* be nice to not have a GC, with some of the things I want to be able to do, that's just not going to be feasible, *however*, I can do some things that can dramatically reduce the need for one.

So, by default, any variable you define exists *only* in the scope it was declared in.