great progress on dive site handling

[Dirk Hohndel]

On Mon, Jun 29, 2015 at 05:09:23PM +0800, Miika Turkia wrote:
> >> This sounds like sane logic to me. However, I do also see your concern
> >> about this if one only records the site name on that field. I still
> >> type the locations like "Indonesia - Lembeh Strait - Hairball" so I am
> >> not going to change a Blue Hole in Belize into a Blue Hole in Egypt
> >> (if there are no previous coordinates for the site).
> >
> > So once you have GPS data we will show the tags that you have chosen
> > (Country, State, whatever) in the UI. I'm not 100% clear how we should do
> > this when "autocompleting" but given the workflow that you and Linus
> > describe my guess is that we'd update those tags as well as we see and
> > find a awy to make sure that dive sites with identical names but different
> > GPS locations are handled in a somewhat sane manner... I can kind of
> > envision how this would look... Tomaz will love me for this...
> 
> I have actually never seen these tags to be added. Now I see that I
> need to enable it in the prefs...

This part isn't implemented, yet. So enabling doesn't do anything. I was
discussing how I think this will work once the implementation is complete.

> > So let's say you have three different GPS coordinates for Blue Hole. One
> > in Belize, two in Palau that are different anchoring spots. As you type
> > "Blue H" your autocompletion shows three lines of Blue Hole. As you use
> > cursor up and down to scroll through them the tags above the location
> > field change to "Belize" and "Palau", respectively, and the map jumps (not
> > flies, that's to slow) to the correct marker - this way you can even tell
> > the different anchor points appart even though you just entered the name.
> >
> > Which other possible workflow am I still missing with this?
> >
> >> Seems that I get an empty location field on first name edit, and
> >> second edit sticks.
> >
> > Can you explain the steps that got you to the empty location field?
> > I tried a few scenarios and can't reproduce that.
> 
> This time I was not able to edit the Location without restarting
> subsurface. Following steps:
> - Download from DC
> - Download from second DC
> - Sync GPS
> - Try to edit locations

So I tried this with two random DCs (both simulated in my case but that
shouldn't make a difference for Subsurface) and this works for me.

I hate it if I cannot reproduce what goes wrong for people. It makes
debugging so much harder.

> I guess I will have to try to remember your workflow, so things will
> be easier for me :D

Well yes, that would of course be the smart thing to do :-)

> >> (gdb) bt
> >> #0  Marble::StackedTile::pixel (this=0x0, x=36, y=30) at /home/mturkia/source/static/test/marble-source/src/lib/marble/StackedTile.cpp:85
> >
> > Hmm. this=0x0 - that would explain the crash when accessing a member of
> > this object. But how the heck did you get there?
> >
> >> #1  0x00007ffff654036c in Marble::ScanlineTextureMapperContext::pixelValueApprox (this=0x7fff748dbd50, lon=<optimized out>, lat=<optimized out>, scanLine=0x240b660, n=<optimized out>)
> >>     at /home/mturkia/source/static/test/marble-source/src/lib/marble/ScanlineTextureMapperContext.cpp:316
> >> #2  0x00007ffff654196d in Marble::SphericalScanlineTextureMapper::RenderJob::run (this=<optimized out>) at /home/mturkia/source/static/test/marble-source/src/lib/marble/SphericalScanlineTextureMapper.cpp:271
> >> #3  0x00007ffff2c25af0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> >> #4  0x00007ffff2c28b0e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> >> #5  0x00007ffff69676aa in start_thread (arg=0x7fff748dc700) at pthread_create.c:333
> >> #6  0x00007ffff2094eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> >
> > No clue. Obviously this worked for me (and I tried jumping around between
> > dive sites, etc).
> 
> Happens to me quite frequently. Once I have working Internet, I'll try
> to do full build.sh and see if that helps.

If I take this stack trace at face value it really doesn't make much
sense. It shouldn't be crashing where it claims to be crashing.
It "this" in StackedTile::pixel really was NULL it should crash in the
caller when trying to dereference the member function.

Thiago, any brilliant insights?

/D