Frequent users of Golem may have noted a minorproblem with our app. Once you’ve exited, all the tasks disappear. They simply vanish.
As you have probably figured out, this issue needs to be resolved before our Brass launch. We have already implemented a task persistence system. Unfortunately, simply enabling has not been enough.
I had to rethink the directory structure for serializing the state of the tasks, since I encountered some conflicts here. As far as I see, task persistence works. But it still requires additional tests and reviews to be sure that it works in every case — says Marcin Mielniczuk, our software developer.
Moving forward to meet newer OpenSSL
Do you know about OpenSSL? It is the most common library for cryptographic primitives. First developed back in 1998, almost everything crypto uses it as its backend. And so do the Python cryptographical modules.
Unfortunately, the latest OpenSSL update, from 1.0 to 1.1 broke the API compatibility. This means that all libraries and programs taking advantage of the library cannot work with the new version without code modification. One of the affected libraries was a Python module called pyelliptic.
But, you might exclaim, Golem doesn’t use pyelliptic anywhere in it’s code. And you’d be right, we don’t. But pyelliptic is a transitive dependency, as the programmers call it. In other words, a dependency of a dependency.
Since deciding to migrate to pydevp2p, which does depend on pyelliptic, there were two possible solutions for us to choose from — either fix pyelliptic or modify pydevp2p to use a different library, in this case python-cryptography.
We decided to go with the second approach. A pull request to pydevp2p is awaiting the upstream developers’ review and hopefully it will be merged soon. As one of our developers, Wojciech Dubiel, describes the issue:
Why not [choose] the first solution? The problem with pyelliptic is that the module is completely unmaintained — i.e. there’s no developer actively working on it, unlike python-cryptography. If we had decided to go the pyelliptic route, it’s possible we’d have to fix something else in pyelliptic in a month or two again.
Developer mode in GUI
In tech news #4 we mentioned that our legacy, Qt-based GUI is to be removed. But if you ask developers, they’ll say they still use our legacy one. This is because our new GUI still lacks some developer features, namely — displaying detailed information about the tasks, subtasks and the connected nodes.
The missing features have just been added to our new, Electron-based GUI. This is a great leap forward to our goal of removing the legacy one entirely and we hope to do this in the near future.
As Muhammed Tanrıkulu, our frontend developer, comments: — As in the old GUI, the new developer mode will provide developers with what they’re looking for. In future we’ll have even more features. The good part is, the new GUI comes disabled so developers will be able to activate it whenever they need.
Bugfixes to task rendering preview
Some of our users have reported that the task rendering preview is displayed incorrectly. What does that mean exactly?
When requesting a Blender task, there’s a preview displaying the state of the rendering subtasks. You can click on every frame and check the preview of parts that were already rendered. But when you decide that you want to restart a specific subtask, ie. recompute part of the image, you don’t want to see the old result in preview anymore. This function was not working correctly for every use case and restarted subtasks were still visible if there were more subtasks than frames.
The fix is now awaiting review and will be merged soon.