BulbCalculator Update

Here a really good news for BulbCalculator.

I finally solved the problem with the OpenGL library I am using (libQGLViewer) that make it unusable.
Actually the library still use the old QGLWidget instead of the the QOpenGLWidget, so once you use the libQGLViewer in a MDI subwindow, for some reason it lock all the MDI subwindows; the strange thing is that if you use the "tabbed" configuration for the MDI subwindow, everything work.

Anyway, after a bit of working, I finally succeeded in porting the libQGLWidet library to the new QOpenGLWidget, so all works again.

At this point, as soon as the upstream developer for the library answer, I will know if I need to maintain the library myself, I need to integrate in my source tree or whatever, but at least I can move forward and make a new interesting release.

Stay tuned...

A nightmare called Akonadi, part II

Well, after switching back to kmail and having it working for a couple or more years, kmail is again unusable,this time with the "Retriving messagefrom folder..." which make the program useless unless you stop and restart akonai some times just to read a message.

This time the problems seem to be db related, with akonadi that run too many queries on the db. Honestly this time I don't use too much time to understand how to workaround the problem, since in this case I lost my patience.

All I do this time is to look for a method to export the mails (hint: it's not here :-( ) to another software and look for the kmail substitute.

Now, despite the years passing, the status of the mail software under KDE is the same, there is only Kmail. So it is time for another switch, back to Claws Mail, which unluckily is Gtk based, but work really well.

It seems to me that the entire KDEPim project is way too complex or has way too few people working on it (or worse, the people that work on it does not care to release a working software) Anyhow, this is not a nice feeling for KDE.

Back to GitHub

After testing Gitlab for some time (both during the free time and working time) I decided that, at least from my usual places, Gitlab is really unusable, so I decided to return to GitHub.

The problem with the private repositories was solved buying a personal plan, which include unlimited private repositories (well, I just need a couples of them, for now).

I will continue to use GitLab for the projects that are hosted there (for now only BugsEverywhere) and my personal repo is still online, but basically all my repos are now on GitHub

New server (again)

So, after some more time and thinking, I changed my mind another time and this site is now hosted back where it was at the beginning, Linode.

Some new activity

Following an effort to minimize the systems I currently maintain (git, mail, www and so on) I am beginning to migrate some services from my own host to some hosted solution.

The first service to face a restructuration is git, with all my private repositories hosted on git.grys.it moved to GitLab, which offer free private repositories.
These private repositories are only the first ones moved, other will follow.

git.grys.it will not die anyway, some really personal repositories will stay on it, at least for some more time.

How to lose 5 year of life: 2° try...

The first try was when I applied a wrong configuration to grub and thereafter the laptop did not boot anymore (ok, it was some years ago...)
This time, after what seemed a normal update of my laptop, which is now running Archlinux, and a concurrent installation of cutegram, I found that I was unable do anything on the machine and I was basically locked out from my machine. Login from console give "login error" even before asking for the password and even with root. SSH did not work and also sudo or su did not work.

After a bit od digging, I was able to reboot to a shell rescue using systemd, I just needed to add the option systemd.unit=rescue.target to the kernel command line.

Once logged in, I begun to look for the problem. The first suspect was cutegram, but it turn out innocent.

After a bit of analisys of the log, I found this error:
Jun 17 23:35:05 galactica login[30384]: PAM adding faulty module: /usr/lib/security/pam_unix.so Jun 17 23:35:01 galactica login[30379]: PAM adding faulty module: /usr/lib/security/pam_access.so
which was followed by
PAM unable to dlopen(/usr/lib/security/pam_unix.so): /usr/lib/libtirpc.so.1: undefined symbol: __rpc_get_default_domain

The basic problem is that I was sure that I had not updated anything related to PAM or friends. The second error, anyway, directed me to the kernelof the problem: for some reason, the libtirpc library was the wrong version (also if I still don't know why).

The first try to solve the problem was to try to run pacman -S libtirpc, which oddly enough update the library: after that the system restarted to work properly.

I still don't know what happened and I am writing this to maybe help someone else. My impression was that it was an unfortunate update timing (since I use a mirror) which for some combination of factor completed my update but at the same time not all the packages in the mirror was at the correct version.

STL Export on Bulbcalculator

BulbCalculator (in HEAD) has now the export to STL file at least as Ascii. This follow a request from a user to be able to print a model with a 3D printer.
Using this request as starting point I added some features that are likely to be used to mill the model, so the STL can also be exported as half model.

There is, for now, a limitation in this since only one half of the model is saved to the STL file.
If you have a model perfectly symmetrical you just have to mill two times the object and you have a complete bulb. Conversely, if you have an asymmetric model (I presume on the vertical plane) this leads to a small amount of work on the CAD/CAM side since you have to generate a mirrored object.

This limitation will be eliminated in a next version, but for now you should keep it in mind if you plan to print (or mill) a bulb designed with BulbCalculator.

Two new features for BulbCalculator

Following a request from a BulbCalculator user, I started the work on implementing the export of the bulb into a STL model file, to be able to print a model with a 3D printer (or to be able to mill the bulb with a milling machine :-) ).

I also started to implemente the possibility to add a hole for the keel, which is somewhat tricky since for any material you remove, you should update the bulb dimension to take care of the difference.

When I started to work on these two features, I realized thatI needed to do some preliminary works that have, as a result, optimizede the code, especially the code that draw the 3D view of the model.

In the end I now have a more real wireframe view, while I added two other view modes: triangles and a real surface. The triangles view was a preliminary work to be able to create the STL file, the other one is just for fun ;-)

Bulbcalculator ported to QT5

After some work, Bulbcalculator is finally ported to QT5, with the future 2.2.0 version. While I am working on this, I also decided to implement some other features, firs of all a recent project list and the possibility to setup the page size, like some very well known CAD programs.

I have not a date to release the 2.2.0 version, since I have not so much time to work on it, but the work is slowly going on.

Working on stl-tools

Stl-tools get some work in the last couple of days which will be the basis for future development.

The main point I nailed out is to have a structure that can support commands that needs different number of parameters.

The old implementation needs to specify the axis for all the operations, but while adding the new operation stubs, I realize that not all of the operations I'd like to implement need the axis specification and, more important, not all of them refer to an axis.

With this in mind I removed the -x option and update the mirror operation to reflect this. The new method is based on a structure (technically a python dict) which hase a "name" , which is the operation itself, and a nested structure (another python dict) which contain all the couples option-value for the operation. This give the required liberty to implement every operation without the risk to touch every part of the code every time I will need to have another option for a new operation.

While working on this, I also corrected the mirror operation definition so now the it is defined to refer to a plane instead of an axis, which is way too more logical.

The last thing done is to move all the help related function to specific class. With this I hope to have a clearer code