Daily report(6/16/2022)

Work continues slowly on the configuration_hook_manager. I moved my installation over to an ssd, so now development is happening faster.

At some point I should look into running an lsp server from inside the irods builder, I might actually be able to get good completion and navigation.

I have moved the configuration update logic so that it reloads every loop from the main thread. This may need revision or further amendment in other main loops.

The next thing I need to do is writing tests for this, and then revising the existing tests to use this instead of .restart() when possible. There are three places I would like to see work, some basic delay server properties, and some agent server properties that are relevant.

I don't think a more comprehensive JSON differ would enhance the abilities to satisfy the needs of the server thus far. If something like that is necessary it shouldn't be too hard to adapt it.

The tests will require the usage of a rule to query the server_properties of the server. So I have written a microservice called msi_get_server_property which allows it to query it. With luck it will permit the tests to avoid all the timing issues reading the log is susceptible to.

The Sunlight

This place has no rain. Nothing to block the suns above it. Just a baked hot surface, scarred by the thermal stresses of the heaving that occurred prior to the falling of the system into this configuration.

Luckily, without an atmosphere, all I need is a wide, reflective parasol and more patience than our forebearers would ever muster. Black body radiation is a terribly slow way to cool down a planetary surface. Especially when you have to let the heat beneath percolate through the slow matrices of the stone and permit a sufficiently thick cool layer to develop.

I don't have all that much time here. In an awkwardly unwieldy number of cycles around its orbit, this place will be ripped apart in ways that will make the structural failures this rock has experienced seem so very insignificant.

There is a wide fiber optic channel that leads deep into the rock in a place of great geological and thermal stability. Further than I care to excavate at least. In the deep recesses I can see photocells, many of them still intact. There is a diode at the back that should be able to see me, and I can see it. Despite many wavelengths and powers, nothing gathers a response.

I wonder what they wanted from this? Did they think they would escape failure? Or did they just want more time?

That bunker down there isn't very big. There isn't much room for 'traditional' carbon based water solvated life, but thriftier substrates may have lasted a long time, thinking whatever thoughts they thought were important to carry out. But ultimately, this place won, the thermal noise probably destroyed it slowly at first and then very quickly. Or maybe they fried immediately. It's all a series of tradeoffs of risks and structure and cost. And here, they didn't seem to want to take much time evaluating this.

You can't make it into deeper time without replication. But they lacked either the time or the wherewithal to do that. Or maybe they chose to avoid it.

I don't feel like pulling it out of the ground. I know what I'll find, a dead computer in some state of repair. But computers are opaque. Their logic is imprinted on many levels, and the sophisticated stuff doesn't last without active maintenance.

A light turns on inside for a moment then flickers out. I think I'll just wire them a link to the relay just in case. I don't know if they're alive in there, but this doesn't cost me very much, the other bodies here were already quite enough for my purposes.

Ultimately, it's up to them to figure out what they want to do, and how that thing works. It's definitely possible that they will never figure it out. But it will keep on beckoning to them invitingly until this place is no more.

Maybe they'll find a friend. Or maybe I'm trying to email a corpse.

Daily Report(6/10/2022)

Today I have been investigating enhancing the reload() method with a list of difference objects. So far this has been relatively simple to implement.

Next week I plan to figure out the design of what will become the configuration_change_hook_manager facility, but let's go through some preliminary thoughts

  • The hook should be addressed by the configuration property's name.
  • The hook should have the new and old values passed to it.
  • The hook manager should be invoked on the list of changes to the configuration
  • configuration_hook should follow a builder pattern as the cron_manager's cron_task does
  • It should make noise about unhooked configuration changes in the log
    • This is important for debugging and properly informing admins about the potential issue not restarting their server might cause.
    • It might be worth adding a configuration option to make it error out when a configuration change isn't able to be handled.
  • I should talk to J about this since their work is likely to intersect it.

iRODS daily report(6/15/2022)

I have continued to work on configuration_hook_manager. It is slowly coalescing into something that can truthfully said to compile. There are a few issues that I have to figure out, such as how to handle nested properties, and whether or not dispatching every event to every hook makes sense from a performance point of view(okay, fine it won't matter yet, but it might one day).

Another point in this design is that it does not currently measure changes to nested objects such as advanced_settings in a manner that I find satisfying, namely, anything inside it has to watch for changes on its own.

Much of today was spent trying to get the development/testing environment working 100% again. The build script now manages to clean up everything from previous invocations, and takes options to skip rebuilding irods or the number of tests you want to run at once(I can't run 16 at once, my harddrive is too slow for that, but 2 works).

But as I write this, I'm not sure this is the right action, I think it might not even need the configuration hook manager for the immediately desired outcome of this(making testing faster by eliminating reloads).

I have yet to attach the SIGHUP handler to the reload mechanism. And I still need to talk to J about their ideas for this.

Daily Report(6/7/2022)

Today has been marked by some progress in eliminating some dead ends in exploring fixing the bug. Changing the merge behavior in .capture() was successful in getting the main server to start yesterday, but it broke the agent server by somehow eliminating some of the information. But I had a thought, if I just make a new function, maybe .reload(), it could just behave differently than .capture()

Daily report(6/9/2022)

Today, with the help of the team I was able to resolve the issue with the server not being able to be stood up. The solution was to use docker-compose to tear down the previously created containers, as the database lingered without doing that and that caused errors in setup which resulted in a non-viable configuration.

With that working, adding a reload() method which merges the file's properties with the existing properties(permitting runtime properties to remain) is sufficient to permit tests to pass.

Daily report(6/6/2022)

Today has been slow because of being stuck with nothing more than my laptop. This has kept builds glacial and prevented most of the testing that I was hoping to do today. There is a simple explaination of the problems though, for whatever reason, when the capture() method is called on the server settings, it appears to have trouble acquiring most of the session variables.

I have managed to change where the crash happens by merging the configuration objects instead(replacing the old values with new values, but not getting rid of other old values), but that doesn't do a lot of good right now because now it seems that there is still something missing from the configuration object that the agent server gets.

This probably means that I broke something or other. 🙂

iRODS progress report 6/3/2022

What's been done

  • Development environment copied to laptop and working.
  • Using shared_mutex to synchronize access to the server_properties object
    • [x] Server compiles
    • [x] Server tests run successfully without adding regular calls to server_properties::capture
    • [ ] Server tests run successfully with calls to capture.
  • [ ] Integrate calls to capture back into the cron system

Problems run into so far

  • I didn't have vim installed on my laptop
  • The build script was set to use the 16 cores on my desktop
  • After adding the shared_mutex it still crashes when capture was called

What's next

  • use --leak-containers to keep the container up for long enough for me to muck around in when running the run_core_tests.sh script it and see what happens. Alternatively I could use stand_it_up.py to just stand up a server.
  • Investigate where the map() function is called on server_properties. It might be a good idea to do away with it if this is preventing thread safety.

iRODS progress report Day 2(6/2/2022)

Today I spent my time trying to get the configuration file to reload after I successfully ran the test suite.

The first approach that I tried was hooking it into the Cron system. This has failed thus far because reloading the configuration on the main server causes use-after-frees (I think) due to contention over the json objects across different threads.

Reloading the server_properties object from any thread causes the same issues.

The correct way to fix it, I believe, is to add a read-write mutex that guards against mutation in flight. This will require additional copying, but given that the reloading is going to be fairly rare it should not affect performance for long.

Once it is thread-safe the cron system should be able to be used to check for changes in the configuration file.

Tomorrow I will most likely be setting it up again on my laptop.

3D Printing

I am not new to 3d printers. In college I helped to run the 3d printing lab, fulfilling requests to make things for various classes(at the time, the most promising was how it could be used to demonstrate anatomy with relatively cheap modifiable parts). That was around 2017. At the time the printer lab consisted of a few Flashforges, a few Makerbots, and an Ultimaker that was not functioning at any point that I was working there. Before that I had a Da Vinci 3d printer that had DRM on the filament spools, which was not very welcome, so I have been using these things across the majority of the last decade.

When I was there, we used various software for slicing, including the makerbot software, Cura, and Silc3r(now prusaslicer), and Simplify3d, in order of quality(Cura is better, and I don't have a simplify3d license or a reason to use makerbot software thank god, prusaslicer has also improved a lot).

More recently, I got an Ender 3 Pro, which is relatively nice. It is a much better experience than the Da Vinci printer in all the ways I can think of, so there has been substantial progress on making this a pleasant process. However, I have not even had the printer for a full month and the board seems to be flaking out on me. Halting, juddering movement, frequent complete lockups where who knows what could happen to the thermal runaway protection.

That is to say, 3d printers are still haunted by the specter of low quality electronic components, or alternately, it was fried when a lighting bolt struck a nearby power line, causing a blackout. They claimed the PSU was higher quality on the Ender 3 pro, but I'm not sure that it has delivered completely. Either way, the new board is on the way for later today, and we'll see if we need another set of components or if we have finally shaken all the bugs out.

Recently I've been trying to design moving parts that can be manufactured by 3d printers. I've been having trouble with the bearing being impossible to dislodge without comprehensively damaging the object. My next attempt will involve using more infill and turning off the brim, so hopefully the meshes will not become entangled so strongly, but I suspect that the ultimate solution is to increase the amount of tolerance between the moving parts in the design.

In general, I'm quite happy with how things are going with the printers, one of my partners is talking about building a voron printer, which would be capable of being very fast and very accurate, and that sounds like a lot of fun.