Subsurface-4.6.1.4-x86_64.AppImage

Alessandro Volpi volpial at gmail.com
Fri Feb 17 14:26:29 PST 2017


I realized that the date 01/01/1900 was out of range only when Salva told
me that the "fake" dive was indeed present in the list, albeit not in the
expected order. As I have already explained to Salva the only reason for
having that "fake" dive was to use it as a template for new dives in
SmartTrak. The "template dive" has no meaning for subsurface. Salva wrote
me not to ditch SmartTrak, at least not to do that right now. The template
dive is handy for logging new dives in SmartTrak, since it provides default
data for suit and tanks in new dives. Therefore I do not want to delete it.

I have just changed its date to 01/01/1990 and it is now perfectly OK with
SmartTrak and with subsurface. The wrong ordering of dives for dates older
than 1970 (beginning of the UNIX epoch) is not IMHO to be considered as a
bug. Nobody was even thinking to an electronic dive log before 1970. In the
sixties and in the seventies I was using a paper logbook. i would like to
find it, but I have no idea about its physical location: I cannot find it
with recoll ...

As far as I am concerned changing the date of the "fake" dive is the
solution of the issue. I have always "suspected" that Linus Torvalds is a
perfectionist and I am therefore sure that the issue of dates older than
1970 will be soon fixed anyway. The question of signed and unsigned
integers has always been a major "bug generator". I remember of having once
put a BGT instruction ( Branch if Greater, for signed 16 bit integers) in
place of a BHI instruction (Branch if Higher, for unsigned 16 bit
integers). It was a piece of assembly code for a DEC PDP 11 of the Jurassic
age. The result was a powerful high frequency hydraulic actuator completely
out of control and a severe damage to the machinery. The mishap happened
after several years of flawless operations, when the addition of a
"nice-to-have" Fortran routine resulted in the upwards shift of a part of
an integer array beyond physical address 32767. The error in the position
of the "fake" dive in the list has been definitely LESS PAINFUL !

Very best regards.

Alessandro

On Fri, Feb 17, 2017 at 8:55 PM, Linus Torvalds <
torvalds at linux-foundation.org> wrote:

> On Fri, Feb 17, 2017 at 11:52 AM, Alessandro Volpi <volpial at gmail.com>
> wrote:
> > In my last message I said that the AppImage was working in Fedora 24,
> except
> > for some details related to font issues. That is not correct. In practice
> > the AppImage succeeds in producing good dive list and dive profile plots.
> > The problem is that the main menu lists are empty !  Clicking on the
> empty
> > space the required action is indeed executed.
>
> Ok, I can't help you with the UI parts (they are likely about some
> Appimage issue anyway). But:
>
> > I have also changed the date of the fake dive from 01/01/1900 to
> 01/01990.
> > Now the fake dive is the first of the list, as it should be .
>
> So we don't handle dates before 1904 correctly (why 1904? It's a
> leap-year issue: the year 1900 is "odd" and is *not* a leap-year
> despite the usual divisible-by-four, so our internal date handling is
> basically limited to 1904..2099 because it takes shortcuts).
>
> But to make matters worse, the divelist sorting was broken for
> anything before 1970 (which is our base "epoch"). It used an unsigned
> 64-bit comparison for sortng, it should be signed.
>
> I'll make a pull request for Dirk, because we *should* allow dives before
> 1970.
>
> But in the meantime, yeah, use 1970+ as a base date for testing.
>
>               Linus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170217/bf4193e7/attachment.html>


More information about the subsurface mailing list