smtk2ssrf_test.AppImage: further testing

[Alessandro Volpi]

I have read your answer to my message sent on Fri, Feb 17, 2017 at
03:04:06PM +0000 .

My message contains an error: the record being differently read in
successive runs of smtk2ssrf is not dive #15, as I have written in the
mentioned message. It is dive #415, as I have correctly written in a
previous message ! This is for some mysterious reason the ONLY dive being
read in different ways running smtk2ssrf more than once on the same input
file. This happens randomly with Fedora 24 and with Ubuntu xenial. I cannot
find anything special in dive #415; perhaps the reason is simply in the
following identity 415=400+15  ...

I will check in the next week whether the smtk2ssrf behavior will somehow
be more predictable, after having changed the time of dive #15 to
01/01/1990.

As far as the issue of 12 h or 24 h time format I have seen that changing
the time format in the "Preferences" dialog is correctly setting the
formato in the dive list, but not in the "Notes" tab, which is always
reporting the 12 h AM/PM time format.

Also gmail does that, and I do not like it ... on the other hand I cannot
change the gmail default language to something different than En-US, since
most of my messages are written in American English.

Best regards.

Alessandro

On Fri, Feb 17, 2017 at 8:52 PM, Salvador Cuñat <salvador.cunat at gmail.com>
wrote:

> Good night Alessandro.
>
> On Fri, Feb 17, 2017 at 03:04:06PM +0000, Alessandro Volpi wrote:
> >
> > 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 !
> >
> I can see it there, in both your .xml files and mine.
> It's being readed as 1/1/2000 because libmdb returns localized strings
> for date and time. This wasn't a real problem for date, but actually
> was for some times representations (e.g. duration of the dive or
> surface time) because of that very big country using 12h and AM/PM
> instead of 24h time. So the program fix a "neutral" locale to work; I
> selected POSIX locale, but this has the drawback that has only two
> digits for the year. This way  1900 becomes 00 and 00 becomes 2000. I
> really never expected to find dates before 1969.
>
> > 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...
> >
> The segmentation fault was due to libmdb failing to identify a table
> in the .slg database. As I'm unable to reproduce the crash with your
> .slg or any other, I think it could be triggered by a bad interaction
> between libraries bundled in the appimage and the libraries in the
> host machine.
> As said above, dive #15 is in the xml files and it's imported as any
> other (with the 01/01/2000 issue). At first I didn't see it because I
> have the dive list in subsurface set to be date/time ordered, so it
> didn't show the first one. Setting the order to dive number shows it
> in first place. Subsurface xml format don't have this issues, so you
> can simply edit the #15 dive to be 1900 again.
>
> > 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 ...
> >
>
> It seems to be. But if Subsurface is running quite well and there are
> running appimages for such complex programs as Firefox and others, it
> shouldn't be that difficult to get this tiny tool to work. In fact,
> except glib2.0 and libmdb the rest of libraries are the same that
> those bundled in subsurface appimage.
>
> > 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.
>
> Don't worry about it, I was just curious.
>
> Best regards.
>
> Salva.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170217/a4030a2b/attachment-0001.html>