Dear Salva, I agree that the question of my dive #15 has a bit of "woodo rite" flavor; nevertheless the explanation is quite simple. I have resumed my diving activity in 1998, after a 20 years pause. My previous deep diving practice was based on the type of equipment available in the seventies, namely 4 mm thick suits, double tanks without SPG and NO BC. So I decided to attend a course for learning to use the new stuff. I obtained a two stars Certificate, including rescue procedures, after 15 dives. That's why my logbook begins with dive #16. When I began to rely on the UWATEC software for logging my dives, I elected to insert a "fake dive" #15 in order to get a "template dive" with default values for tanks and suits to be applied to the new dives being inserted in the log. The advantage of having a fake dive (formally carried out on 1/1/1900) was simply to be free to change the defaults for new dives, without being forced to modify the data of a true dive. The data in dive #15 include the suit type ( Two pc. wet suit ) an the tank system ( 2 x 8.5 liter sidemount set ).
I have observed that smtk2ssrf does not consider the template dive to be a true dive (it is actually fake) and does not export it to the .xml file. I guess that 1/1/1900 is not a good date; if I have well understood your program reads it as 1/1/2000 , exactly one century later ! Coming back to the issue of the .AppImage executables I point out that, theoretically, a computer program should ALWAYS BEHAVE THE SAME WAY with the same input data, unless the program gets entropy from a source like /dev/urandom . I mean that a program which is crashing once with a <SEGMENTATION FAULT> SHOULD ALWAYS CRASH WITH THE INSTRUCTION POINTER VALUE ALWAYS POINTING TO THE SAME INSTRUCTION. Moreover the program should always read the SAME stuff ( right or wrong) in all records, including record #15. I do not understand why this record seems not to be as good as any other... Apparently IT IS NOT ... and I cannot imagine how this could happen. I am not familiar with AppImage building procedures and I read on your message that you are not also completely at ease with that. Btw I have yesterday tried to run a Subsurface AppImage on Fedora 24. The program was working in spite of some complains about wrong libraries and in spite of some problem probably related to the application fonts. I fully agree with you that the AppImage approach is somehow tricky. I guess that the question is much more complicated than simply including stand-alone instances of some shared libraries in the executable ... As far as the test of subsurface build scripts on Ubuntu xenial, is concerned, I must admit that I was not able to carry it out as promised. This has been a busy week for me and I was forced to lend my laptop with xenial to a friend of mine. She is complaining since I have not yet finished to install Linux on her new PC and she needs a working computer right now. I hope to be able to complete the job next week, so that I can get back my laptop ... Best regards. Alessandro On Thu, Feb 16, 2017 at 11:47 PM, Salvador Cuñat <[email protected]> wrote: > Good night Alessandro, thank you very much for such a detailed testing. > > On Wed, Feb 15, 2017 at 11:14:08PM +0000, Alessandro Volpi wrote: > > I have tested two versions of the AppImage on Fedora 24 (64bit) > > > > > > 1. [~/bin]$file smtk2ssrf_test.AppImage :: smtk2ssrf_test.AppImage: > ELF > > 64-bit LSB executable, x86-64, version 1, dynamically linked, > interpreter > > /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, > > BuildID[sha1]=30434935ca0d1a94a0eb2853b71390dfe2e9017f, stripped > > 2. [~/myfiles/downloads]$file smtk2ssrf_test.AppImage :: > > smtk2ssrf_test.AppImage: ELF 64-bit LSB executable, x86-64, version 1, > > dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for > GNU/Linux > > 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, > stripped > > > > The two .AppImage file will be briefly indicated as "old" (1.) and "new" > > (2.) in the following text. > > > > First trial: > > > > The old AppImage was launched from a terminal, relying on the GUI. The > > resulting files are: > > smtk2_old_gui_out.txt, containing the output on the terminal > > smtk2_old_gui_log.txt , containing the program's output on the GUI > window. > > smtk2_old_gui.xml , the input file for subsurface > > > > Second trial : > > > > The old AppImage was launched from the terminal indicating input and > output > > file as command arguments. The resulting files are: > > smtk2_old_out.txt, containing the output on the terminal > > smtk2_old.xml , the input file for subsurface > > > > Third trial : > > > > The new AppImage was launched from the terminal indicating input and > output > > file as command arguments. The resulting files are: > > smtk2_new_out.txt, containing the output on the terminal > > smtk2_new.xml , the input file for subsurface > > > > Fourth trial : > > > > The new AppImage was launched from a terminal, relying on the GUI. The > > resulting files are: > > smtk2_new_gui_out.txt, containing the output on the terminal > > smtk2_new_gui_log.txt , containing the program's output on the GUI > window. > > smtk2_new_gui.xml , the input file for subsurface > > > > After examining the four .xml files I found out that three of them are > > identical. The different file is smtk2_old. The only different record is > > dive 415, where the notes were not correctly read. It is worth while to > > point out that dive 415 was manually inserted in SmartTrak, since no > UWATEC > > dive computer was used for the dive. On the other hand this is not the > only > > dive manually inserted; it is simply the only dive where an error has > been > > ascertained. > I can see the difference between both xml files, but I don't really > understand the reason for it. I've runned 7 different versions > (appimages and builds from sources) on your slg file and #415's notes > are always readed. > > > > Another unexpected behavior is that the new AppImage, when launched in > GUI > > mode complains about missing libGL components. On the other hand dnf says > > that required packages are installed and latest version. This might be > > related to the nvidia proprietary drivers. In spite of the allegedly > > missing components the program seems to run flawlessly. Moreover I do not > > understand why libGL should be required for a 2D graphic application such > > as smtk2ssrf . > > > I don't think this is appimage related, I'd put my money on Qt. > > > Another even more surprising event was a SEGMENTATION FAULT crash when i > > tried to launch the new AppImage as command line application (see file > > smtk2_new_out.txt). I tried to do that a second time and the program ran > > flawlessly. > > > This seems libmdb related. Never saw it before, not in my old 32b > laptop nor my 64b one. > > > I do not know anything about the behavior of .AppImage executables, but > is > > was apparent that, running 2 times with same input file may result in > > different output file; moreover I was not sure that the different result > > was actually dependent on the sunning condition, command line or GUI. > > > > I have thus run once again the "Second trial"; surprisingly the resulting > > file smtk2_old_2.xml is not equal to smtk2_old.xml but is identical to > the > > .xml files obtained in trials 1, 3 , 4 ; the question of the GUI is not > in > > my opinion relevant. > > > > I have also tested the new AppImage on my laptop, with a freshly > installed > > Ubuntu xenial OS. > > > > I have not saved the files, but I can tell you that, also with xenial I > > have got different .xml files running the AppImage more than once. > > > > My conclusion is that, SOMEHOW, RUNNING THE APPLICATION WITH THE SAME > INPUT > > MAY RESULT IN DIFFERENT .XML FILES, DEPENDING ON SOME EXTERNAL > DISTURBANCE. > > THE ERROR IS ALWAYS IN THE NOTES OF DIVE 415 ! > > i CANNOT IMAGINE HOW THAT COULD HAPPEN ... I begin doubting about > AppImage > > "relocatability" ... > > > I can't agree with you on this. I'm actually using suburface 4.6.0 > appimage without any issue. This problems seems to be more related to > my own inability to produce a stable appimage. > I love it's philosophy, but libraries management through different > distros is a true pain. > > BTW, I'm seeing in all produced divelogs (also in slg file) a dive > numbered #15, which seems to lack of date and time (well it claims to > be 01-01-2000 at 00:00:00) and any other info but the suit. Is it > correct or some kind of weird artifact from the Access database? > > And finally, have you tried to build from sources on Xenial? > > Again, thanks for your heavy testing. > > Best regards. > > Salva. >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
