<div dir="ltr">Dear Salva,<div><br><div>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.</div></div><div>The data in dive #15 include the suit type ( Two pc. wet suit ) an the tank system ( 2 x 8.5 liter sidemount set ).</div><div><br></div><div>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 !</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>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 ...</div><div><br></div><div>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 ...</div><div><br></div><div>Best regards.</div><div><br></div><div>Alessandro</div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 16, 2017 at 11:47 PM, Salvador Cuñat <span dir="ltr"><<a href="mailto:salvador.cunat@gmail.com" target="_blank">salvador.cunat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good night Alessandro, thank you very much for such a detailed testing.<br>
<br>
On Wed, Feb 15, 2017 at 11:14:08PM +0000, Alessandro Volpi wrote:<br>
> I have tested two versions of the AppImage on Fedora 24 (64bit)<br>
><br>
><br>
>    1. [~/bin]$file smtk2ssrf_test.AppImage :: smtk2ssrf_test.AppImage: ELF<br>
>    64-bit LSB executable, x86-64, version 1, dynamically linked, interpreter<br>
>    /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18,<br>
>    BuildID[sha1]=30434935ca0d1a94<wbr>a0eb2853b71390dfe2e9017f, stripped<br>
>    2. [~/myfiles/downloads]$file smtk2ssrf_test.AppImage ::<br>
>    smtk2ssrf_test.AppImage: ELF 64-bit LSB executable, x86-64, version 1,<br>
>    dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux<br>
>    2.6.18, BuildID[sha1]=d629f6099d2344ad<wbr>82818172add1d38c5e11bc6d, stripped<br>
><br>
> The two .AppImage file will be briefly indicated as "old" (1.)  and "new"<br>
> (2.) in the following text.<br>
><br>
> First trial:<br>
><br>
> The old AppImage was launched from a terminal, relying on the GUI. The<br>
> resulting files are:<br>
> smtk2_old_gui_out.txt, containing the output on the terminal<br>
> smtk2_old_gui_log.txt , containing the program's output on the GUI window.<br>
> smtk2_old_gui.xml , the input file for subsurface<br>
><br>
> Second trial :<br>
><br>
> The old AppImage was launched from the terminal indicating input and output<br>
> file as command arguments. The resulting files are:<br>
> smtk2_old_out.txt, containing the output on the terminal<br>
> smtk2_old.xml , the input file for subsurface<br>
><br>
> Third trial :<br>
><br>
> The new AppImage was launched from the terminal indicating input and output<br>
> file as command arguments. The resulting files are:<br>
> smtk2_new_out.txt, containing the output on the terminal<br>
> smtk2_new.xml , the input file for subsurface<br>
><br>
> Fourth trial :<br>
><br>
> The new AppImage was launched from a terminal, relying on the GUI. The<br>
> resulting files are:<br>
> smtk2_new_gui_out.txt, containing the output on the terminal<br>
> smtk2_new_gui_log.txt , containing the program's output on the GUI window.<br>
> smtk2_new_gui.xml , the input file for subsurface<br>
><br>
> After examining the four .xml files I found out that three of them are<br>
> identical. The different file is smtk2_old. The only different record is<br>
> dive 415, where the notes were not correctly read. It is worth while to<br>
> point out that dive 415 was manually inserted in SmartTrak, since no UWATEC<br>
> dive computer was used for the dive. On the other hand this is not the only<br>
> dive manually inserted; it is simply the only dive where an error has been<br>
> ascertained.<br>
I can see the difference between both xml files, but I don't really<br>
understand the reason for it. I've runned 7 different versions<br>
(appimages and builds from sources) on your slg file and #415's notes<br>
are always readed.<br>
><br>
> Another unexpected behavior is that the new AppImage, when launched in GUI<br>
> mode complains about missing libGL components. On the other hand dnf says<br>
> that required packages are installed and latest version. This might be<br>
> related to the nvidia proprietary drivers. In spite of the allegedly<br>
> missing components the program seems to run flawlessly. Moreover I do not<br>
> understand why libGL should be required for a 2D graphic application such<br>
> as smtk2ssrf .<br>
><br>
I don't think this is appimage related, I'd put my money on Qt.<br>
<br>
> Another even more surprising event was a SEGMENTATION FAULT crash when i<br>
> tried to launch the new AppImage as  command line application (see file<br>
> smtk2_new_out.txt). I tried to do that a second time and the program ran<br>
> flawlessly.<br>
><br>
This seems libmdb related. Never saw it before, not in my old 32b<br>
laptop nor my 64b one.<br>
<br>
> I do not know anything about the behavior of .AppImage executables, but is<br>
> was apparent that, running 2 times with same input file may result in<br>
> different output file; moreover I was not sure that the different result<br>
> was actually dependent on the sunning condition, command line or GUI.<br>
><br>
> I have thus run once again the "Second trial"; surprisingly the resulting<br>
> file smtk2_old_2.xml is not equal to smtk2_old.xml but is identical to the<br>
> .xml files obtained in trials 1, 3 , 4 ; the question of the GUI is not in<br>
> my opinion relevant.<br>
><br>
> I have also tested the new AppImage on my laptop, with a freshly installed<br>
> Ubuntu xenial OS.<br>
><br>
> I have not saved the files, but I can tell you that, also with xenial I<br>
> have got different .xml files running the AppImage more than once.<br>
><br>
> My conclusion is that, SOMEHOW, RUNNING THE APPLICATION WITH THE SAME INPUT<br>
> MAY RESULT IN DIFFERENT .XML FILES, DEPENDING ON SOME EXTERNAL DISTURBANCE.<br>
> THE ERROR IS ALWAYS IN THE NOTES OF DIVE 415 !<br>
> i CANNOT IMAGINE HOW THAT COULD HAPPEN ... I begin doubting about AppImage<br>
> "relocatability" ...<br>
><br>
I can't agree with you on this. I'm actually using suburface 4.6.0<br>
appimage without any issue. This problems seems to be more related to<br>
my own inability to produce a stable appimage.<br>
I love it's philosophy, but libraries management through different<br>
distros is a true pain.<br>
<br>
BTW, I'm seeing in all produced divelogs (also in slg file) a dive<br>
numbered #15, which seems to lack of date and time (well it claims to<br>
be 01-01-2000 at 00:00:00) and any other info but the suit.  Is it<br>
correct or some kind of weird artifact from the Access database?<br>
<br>
And finally, have you tried to build from sources on Xenial?<br>
<br>
Again, thanks for your heavy testing.<br>
<br>
Best regards.<br>
<br>
Salva.<br>
</blockquote></div><br></div></div>