On Wed, 1 May 2024 at 08:22, daniel Azuelos via subsurface
wrote:
>
> I am running Subsurface 6.0.5112 on macOS 11.7.8.
> I have .fit files I would like to import within subsurface.
To import fit files, you need to select "Import from dive computer"
and then pick FIT from the vendor choice (or
On Wed, 24 Apr 2024 at 11:13, Dirk Hohndel via subsurface
wrote:
>
> Those with better skills in interpreting error messages... what am I missing?
I think the line numbers are wrong, probably because of inlining etc.
The real issue is _probably_ on line 525:
snprintf(fl, 13,
On Mon, 8 Jan 2024 at 13:36, Berthold Stoeger
wrote:
>
> > here's the disassembled code and yes, it does call terminate...
>
> Does it? At least not directly as far as I can see. I reckon this is the
> exception handler?
Yeah, that branch to ___clang_call_terminate is not in the regular
code
On Mon, 8 Jan 2024 at 13:15, Dirk Hohndel wrote:
> >
> > So then you can - manually - use that relocation information to show
> > what the disassembly should have been.
>
> see below
Lovely. It doesn't even do the C++ demangling without using '-C'. Whatever.
> 5d60: 3468 cbz
On Mon, 8 Jan 2024 at 12:18, Dirk Hohndel via subsurface
wrote:
>
On Jan 8, 2024, at 11:15, Berthold Stoeger wrote:
> >
> > If all else fails, you could disassemble qmlmanager.ccc.o. as such:
> >
> > objdump -d
> > ./mobile-widgets/CMakeFiles/subsurface_mobile.dir/qmlmanager.cpp.o\
"objdump -d"
On Sun, 2 Jul 2023 at 12:23, Michael Keller via subsurface
wrote:
>
> After all, the fact that the hardware that they are selling can only be
> used in conjunction with software that many of their customers seem to
> perceive as limiting and not their first choice seems to be something
> that
On Sun, 2 Jul 2023 at 10:30, Matt Thompson via subsurface
wrote:
>
> Device GA002716 is the correct BT name for the DSX.
Yeah, that's the usual Oceanic / Pelagic pattern. "GA" is the
two-letter code (in libdivecomputer it's typically done as a 16-bit
hex value, but it's the same thing: "FQ" is
On Fri, Oct 28, 2022 at 1:57 PM Robert Helling via subsurface
wrote:
>
> just noticed: Current master crashes with memory violation when opening the
> planner on an empty log.
What platform and how do you open it?
I just did
valgrind ./subsurface empty.xml
where the 'empty.xml' file
On Mon, Aug 29, 2022 at 5:04 PM Moetaz Thabet wrote:
>
> this is the only comment that appeared in a red bar at the bottom of the
> window. Is there a way i can send you the error log file ?
Argh. We use "report_error()" and I *thought* we ended up with
multiple lines there, but maybe we only
On Mon, Aug 29, 2022 at 4:35 PM Moetaz Thabet via subsurface
wrote:
>
> Was updating my latest dives and when trying to save to the cloud the
> following error appeared "creating commit failed".
There should generally be errors before that "creating commit failed"
that talk about what went
On Sun, Jun 12, 2022 at 7:53 PM Dirk Hohndel wrote:
>
> /usr/bin/ld: cannot open linker script file
> /builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-qtbase-5.15.3-2.fc36.x86_64.ld:
> No such file or directory
>
> Hey Linus - is this something that you see, too?
Just
On Sat, Jun 4, 2022 at 6:24 AM Robert Helling via subsurface
wrote:
>
> I created a pull request that fixes this problem:
> https://github.com/subsurface/subsurface/pull/3462
Does it really make sense to show negative stop-times at all?
Wouldn't it make more sense to just make
On Thu, Apr 28, 2022 at 12:28 PM Dirk Hohndel wrote:
>
> The most likely users of this might be side-mount divers that are taking
> a deco stage on a dive. Ok, there might be someone with three tanks.
Yeah, I can see three tanks, if you do two alternating sidemounts and
the deco bottle.
*Maybe*
On Thu, Apr 28, 2022 at 12:26 PM Linus Torvalds
wrote:
>
> I think the newer Suuntos can actually give you up to 10 pressure
> readings per sample, but I guess nobody really ever used that.
.. actually, thinking more about it, I suspect it ends up doing the
same thing as Shearwater in
On Thu, Apr 28, 2022 at 12:15 PM Dirk Hohndel wrote:
>
> Are you going to send a PR, or do you want me to just make something up
> for you?
You might as well just apply that patch directly.
Linus
___
subsurface mailing list
On Thu, Apr 28, 2022 at 12:08 PM Dirk Hohndel wrote:
>
> Having looked at this a bit more I think there is one key reason why
> noone noticed or cared. There appears to be exactly one backend that
> can give you multiple pressure readings per sample (Shearwater)
I think the newer Suuntos can
On Thu, Apr 28, 2022 at 10:30 AM Linus Torvalds
wrote:
>
> In fact, we should probably fill in all the other 'index[]' entries
> too, but we never did, because [..]
Actually, the reason we never did is that we never expanded our sample
array past two sensors.
I thought we had, but we s
On Thu, Apr 28, 2022 at 10:34 AM Dirk Hohndel wrote:
>
> > On Apr 28, 2022, at 10:30 AM, Linus Torvalds
> > wrote:
> >
> > Can you send me the test-case so that I can follow along?
>
> Yep, will do off list.
Ok, so that makes *one* of the bugs very obvious.
On Thu, Apr 28, 2022 at 9:38 AM Dirk Hohndel wrote:
>
> except that's not what it does.
> If you have four cylinders, because that's what your dive computer provides
> in the download, then it sets index 0 to the cylinder that is in use, and
> index 1
> stays 1.
> Which then the code I mentioned
On Thu, Apr 28, 2022 at 9:25 AM Dirk Hohndel wrote:
>
> Yes, I get that part. And assuming we are looking at a CCR dive I can
> assign some resemblance of sense to it. But if this is an OC dive, this
> is all not at all useful,
But for an OC dive, all it does is
- set index 0 to 0 (or
On Wed, Apr 27, 2022 at 2:27 PM Dirk Hohndel wrote:
>
> Well, turns out that both in load-git.c and parse.c we have essentially this
> code:
>
> sample->sensor[0] = sanitize_sensor_id(state->active_dive,
> !state->o2pressure_sensor);
> sample->sensor[1] =
On Mon, Apr 25, 2022 at 12:55 PM Jason Bramwell via subsurface
wrote:
>
> If you want Subsurface-mobile connectivity then I’d personally limit the
> computers you are looking at to Bluetooth models. You can start with a list
> of computers that you’ve already found and then discard anything
On Sat, Apr 2, 2022 at 2:18 PM Dirk Hohndel via subsurface
wrote:
>
> I'd appreciate some other eyeballs on this :)
I have a suspicion.
Notable, the mobile side does:
importModel.recordDives()
from the qml code.
And look what the default flags are:
Q_INVOKABLE void
On Sun, Dec 5, 2021 at 2:03 PM Robert Helling via subsurface
wrote:
>
> depth * 1000.0 / 1000.0 which for a depth of 30m seemed to end up just a
> tiny bit below 30.
That implies that we (once again) didn't do proper rounding.
I suspect just short-circuiting it for zero helium hides the
On Fri, Dec 3, 2021 at 1:48 PM Alan Brown via subsurface
wrote:
> Thanks for looking into this. The test still fails but the number of
> lines in the diffs are fewer.
Still seems to be that EAD line if I count the columns right.
We do have a few places where we end up converting to an integer
On Wed, Dec 1, 2021 at 12:53 PM Alan Brown via subsurface
wrote:
>
> Scratch that, I hadn't chrooted into the build environment properly. The
> profiles in x86_64 built by TestProfile are identical to the reference
> files. Repeating the tests in the i686 environment does produce a lot of
>
On Sun, Nov 28, 2021 at 8:29 AM Alan Brown via subsurface
wrote:
>
> I am trying to package version 5.0.5 for void linux. The build seems to
> pass all of the tests for x86_64, aarch64, armv7l, armv6l but fails on
> i686 on the testprofile. Does anyone know why this might be happening
>
On Mon, Oct 25, 2021 at 2:11 PM Thiago Macieira via subsurface
wrote:
>
> Is this enough for Subsurface needs?
No. If anything, it's exactly the opposite of what Subsurface needs,
now that subsurface no longer does the GPS location tracking (because
of all the permission problems that involved).
On Mon, Oct 25, 2021 at 10:13 AM Jef Driesen wrote:
>
> What's the reason for ignoring the fingerprint if you don't have the
> corresponding dive anymore?
Simple: you successfully downloaded all the dives, but had some
problems, and never saved them.
Maybe just a "oops, screwed up editing" and
On Sun, Oct 10, 2021 at 6:24 AM Michael Andreen via subsurface
wrote:
>
> it would be nice to have some way of setting this bogus cylinder as not used.
So the problem is that it is marked as used by one of your dive
computers, and as a result subsurface refuses to delete it.
It would be easy to
On Fri, Oct 8, 2021 at 2:24 PM Attilla de Groot wrote:
>
> (have to use less air on my travel gas though, my SAC rate was a 1L higher
> than a dive to 70m yesterday).
Hmm. You have "AL40" as the type of all your cylinders except for the
main one. But then you've set the sizes to something else
On Fri, Oct 8, 2021 at 1:36 PM Attilla de Groot wrote:
>
> Is it possible to manually change this to how it should be
Sure. You can do it two ways: either manually by editing the dive data
in the xml file (or the git tree - it's a bit more hidden, and you
need to know enough git to do "git
On Fri, Oct 8, 2021 at 11:50 AM Attilla de Groot via subsurface
wrote:
>
> I’ll split up the issues between logging and planning:
I'll leave the planning thing for Robert Helling, who hopefully has
input on that one.
The logging one seems to be about downloading.
Strange.
> Logging:
> -
[ You replied to m er personally, which isn't very useful ]
It's not the gpx import, it's the integrated "subsurface uses the
phone gps" thing.
It requires gps permissions on the phone, which is part of the problem
(the other part is that neither me nor Dirk actually use it any more,
so it gets
On Sat, Sep 11, 2021 at 9:52 AM Dirk Hohndel via subsurface
wrote:
>
> Right now I'm wondering if I should just remove the code, or if I should
> compile it out and allow people who want to build their own and side-load it
> to still have that feature.
I suspect it should be removed, and hope
On Thu, Sep 9, 2021 at 10:26 AM Robert Helling via subsurface
wrote:
>
> The problem is that the code that interpolates the pressures between staring
> and ending pressure by assuming a constant SAC is, how can I put it, an
> interesting project to understand….
Yeah, the code should actually
On Mon, Jan 11, 2021 at 12:11 PM Markus Hinkelmann
wrote:
>
> I tried it in BLE mode. After same connection issue I get the same error (see
> log file).
Yes, that looks very similar, even if the exact point of failure is a
bit different. It starts out ok, we see the expected replies, and then
-
On Mon, Jan 11, 2021 at 11:37 AM Markus Hinkelmann via subsurface
wrote:
>
> I tried to import my dives from my Mares Quad Air using the Interface „Mares
> BLUELINK Pro“ to subsurface.
I'm afraid that the Mares BlueLink Pro has been the most problematic
piece of BLE hardware we have ever seen.
On Fri, Jan 8, 2021 at 12:31 PM Dirk Hohndel via subsurface
wrote:
>
> So we have working binaries for all platforms, but we have heard basically no
> feedback on the new statistics feature.
So I didn't test the pre-built binaries, but I did test my own.
I very much like the new statistics.
On Sun, Sep 27, 2020 at 4:48 AM Attilla de Groot wrote:
>
> I am wearing my Fitbit under my drysuit.
Yeah, that should be safe. It will still see the pressure changes, but
while that could cause some mechanical stress and also result in
failures (who knows how happy the regular atmospheric
On Thu, Sep 24, 2020 at 3:06 PM Fabio Rueda via subsurface
wrote:
>
> My suunto ambit works to 100m depth.
I don't think it does.
The whole "water resistance" in watches is an ugly ugly joke. The
water resistance thing is basically a (short) static pressure test,
not an actual "this is how
On Fri, Aug 14, 2020 at 11:11 PM Berthold Stoeger
wrote:
>
> On Freitag, 14. August 2020 22:27:00 CEST Linus Torvalds wrote:
>
> > Maybe something like the attached, but let's see what Berthold says.
>
> I like that patch - it's pragmatic. I would have added a clone_event
On Fri, Aug 14, 2020 at 1:55 PM Salvador Cuñat wrote:
>
> Dive num = 394 -- ev type = 11
> ev->gas,index = 1
> Dive num = 398 -- ev type = 11
> ev->gas,index = 1
> Dive num = 401 -- ev type = 25
> ev->gas,index = 0
> Dive num = 401 -- ev type = 6
> Dive num = 401 -- ev type = 3
> Dive num = 401
On Fri, Aug 14, 2020 at 12:34 PM Dirk Hohndel wrote:
>
> So we are merging dives and are renumbering cylinders, and then things go
> kaboom here:
>
> static void event_renumber(struct event *ev, const int mapping[])
> ...
> ev->gas.index = mapping[ev->gas.index];
>
> Line 2139 is that last
On Fri, Jun 12, 2020 at 1:01 PM Richard Houser via subsurface
wrote:
>
> Would this be a simple enough check?:
>
> IF (start/end pressure are BOTH within X% of an existing cylinder) THEN treat
> as the same, ELSE add as new?
We could change our heuristics, but part of it is that we very much
On Fri, Jun 12, 2020 at 11:57 AM John Smith via subsurface
wrote:
>
> I have two Shearwaters that can record gas pressure, so in theory can
> monitor four cylinders at the same time.
So as Dirk mentioned, the subsurface default assumption is that when
you have multiple dive computers with gas
On Thu, May 21, 2020 at 3:30 PM Till Schwab wrote:
>
> Till - has this worked before with that OSTC?
> This is my first OSTC and therefore the first time that I use the OSTC with
> subsurface.
Ahh, ok, then it does sound like it might be a "corrupt memory" issue,
possibly together with some
On Thu, May 21, 2020 at 1:30 PM Dirk Hohndel wrote:
>
> This looks like we are starting communication, but then all we get back from
> the OSTC Sport is 0x
>
> Any ideas?
The BLE side looks good and normal.
>> Service discovery initiated
>> Found service
On Sun, May 17, 2020 at 3:34 AM Willem Ferguson via subsurface
wrote:
>
> As a side note it is in principle possible for case (5) and (6) above
> to include a *continuous* 3rd variable e.g. a scatter plot of SAC
> versus dive depth where the colour of the dots indicate the water
> temperature of
On Tue, May 12, 2020 at 10:55 AM Linus Torvalds
wrote:
>
> I'll send Dirk a pull request to just remove the warning.
Done.
Dirk - holler if you want me to just merge trivial things like this
(after the tests pass, of course).
It's removing not just the warning, but the whole test for th
On Tue, May 12, 2020 at 4:04 AM Attilla de Groot via subsurface
wrote:
>
> Since the upgrade to 4.9.4 I get the message "git-load: string marker
> after running out of strings ('name’)” in a large red bar on the
> bottom of the window when starting Subsurface. It doesn’t seem to
> affect
Have you tried with the test picture?
Maybe the GPS data in your own picture has some other format that
subsurface doesn't then parse right?
Linus
On Fri, May 8, 2020, 14:05 Chirana Gheorghita Eugeniu Theodor via
subsurface wrote:
> and I use my own pic which has gos data
>
Ok, so I've just spent several hours re-synchronizing our subsurface
branch with Jef's upstream.
The most trivial part of that was to just pull the changes from Jef's
tree - they merged cleanly, nothing odd there.
But then I tried to basically re-base all our changes on top of Jef's
unmodified
On Sun, Apr 12, 2020 at 11:51 AM Berthold Stoeger via subsurface
wrote:
>
> If I do a "su" into the other user I get the garbled version.
>
> If I do a "su -" into the other user I get the sensible version.
I _think_ the main difference should be just your environment.
So you can do "printenv"
On Fri, Apr 3, 2020 at 2:37 PM Dirk Hohndel via subsurface
wrote:
>
> I need to spend more time staring at the code to try to figure out how
> it's possible that we find two new dives but then believe that the dive
> list is unchanged - as THAT is the underlying problem here. Which is
> different
On Fri, Mar 13, 2020, 15:00 Linus Torvalds
wrote:
>
> And again: I didn't look at the drive data itself, other than verifying
> that it looked sane in the list for dates and depths. The dives were from
> 4+ years ago...
>
Hmm. In order to look at the data, I decided to j
On Fri, Mar 13, 2020, 14:46 Linus Torvalds
wrote:
>
> I didn't try locking/unlocking by hand while downloading. I guess I should.
A short lock and then unlock again didn't break the download, but locking
and waiting ten seconds and then unlocking seemed to do so.
So I think the lock
So I just tried downloading from my old Suunto HelO2 on android
mobile, and it all seemed to work fine.
I did notice something: if I left my phone alone (because I did the
"force download all dives" and it took a while), the download seemed
to get truncated. I didn't really test a lot, but my
On Fri, Mar 6, 2020 at 4:54 PM Dirk Hohndel via subsurface
wrote:
>
> Ugh. Apparently wrong. Turns out that Mailman defaults to adding a Reply-To
> header now, so the net effect might be pretty much "no change".
This looks good to me. "Reply" does the right thing, and replies to
both the list
Hmm. It worked for me with top-of-tree as of a few days ago.
Did you try different keyboard focus points? That's what had broken for us
before (ie focus on the info window rather than the profile window or
whatever)
Linus
On Thu, Mar 5, 2020, 04:03 Miika Turkia wrote:
> Hello,
>
> Seems
On Tue, Feb 18, 2020 at 1:43 PM Linus Torvalds
wrote:
>
> There's two possibilities:
>
> (a) the Cressi protocol isn't the same on BLE as it is on a regular serial
> line
>
> (b) the Nordic UART service needs more setup for the other end (tell
> it baud-rate etc)
U
On Tue, Feb 18, 2020 at 1:36 PM Martin de Weger wrote:
>
> With the -v parameter, the logfile is as attached.
Yup, with that I see the version in the logs too. We'll try to
remember to ask people to do "-v" next time.
Linus
___
On Tue, Feb 18, 2020 at 1:33 PM Martin de Weger wrote:
>
> I gave it a number of tries (and checked the save logfile option).
Ok, I see the several tries, and I also see the lack of replies.
Oh well.
There's two possibilities:
(a) the Cressi protocol isn't the same on BLE as it is on a
On Tue, Feb 18, 2020 at 1:17 PM Martin de Weger wrote:
>
> The result looks the same in de UI.
.. but the log looks different.
Now you have
Using service "{6e41-b5a3-f393-e0a9-e50e24dcca9e}" as preferred service
which is the correct Nordic UART service.
So my patch did what it was
Good, that's the right one.
Let me know if that works now. And if it does, I'll just merge it into
mainline and we'll have a real build soon.
And if not, I'll take a new log-file and go back to the drawing board..
Linus
On Tue, Feb 18, 2020 at 1:15 PM Martin de Weger wrote:
>
On Tue, Feb 18, 2020 at 12:36 PM Linus Torvalds
wrote:
>
> For that test-build, the version string *should* be
>
> Subsurface 4.9.3-959-gaa80ecc77ee9
>
> and if it isn't, you're not testing with my Cressi hack in place.
Actually, I take that back. The build server did
On Tue, Feb 18, 2020 at 12:20 PM Martin de Weger wrote:
>
> I’ve downloaded the new version and retried to download the dives. The
> logfile is attached.
Damn. No change. It still tries the other service.
I wonder what went wrong. I see that
Found service
On Mon, Feb 17, 2020 at 1:09 PM Linus Torvalds
wrote:
>
> and once the OS X build has finished, you should be able to pick up
> the (unsigned) App from there (look for the "Mac / desktopBuild"
> thing, once it is complete and successful, you should find a download
On Mon, Feb 17, 2020 at 12:58 PM Martin de Weger wrote:
>
> I’m glad you can make sense out of this. ;)
Trust me, you don't want to understand BLE GATT protocol and the odd
service names etc. I've spent more time than is healthy on figuring it
out. I'd rather not know, but nobody else wanted to
On Mon, Feb 17, 2020 at 12:08 PM Martin de Weger wrote:
>
> It looks like it is not recognized as dive computer.
No, that part is ok. But the logs look a bit garbled, but that is just
an artifact of the asynchronous device discovery.
So there's a few random
Found new device: ""
On Sun, Feb 16, 2020 at 11:57 PM Robert Helling wrote:
>
> there were recent changes in the git parsing to fix a problem with bailout
> events.
> This seems to be earlier, already in the interaction with the git server.
Yes, this seems to be long before we actually get to the parsing
stage.
On Sun, Feb 16, 2020 at 1:33 PM Martin de Weger wrote:
>
> It does show the computer, but when I’m trying to download, it states
> “unsupported operation”
Ok, not entirely surprising. We've had good luck with our
"pseudo-generic serial service over BLE" code, but BLE serial really
isn't
On Sun, Feb 16, 2020 at 12:54 PM Dirk Hohndel wrote:
>
> The CI should create working Windows and Mac builds as well as an AppImage.
I think Martin wanted it for iOS, but hopefully he should be able to
at least do the "see if it works, or send us logs" on his Mac.
Where do the builds show up?
On Sun, Feb 16, 2020 at 7:20 AM Martin de Weger wrote:
>
> Were the screenshots for the bluetooth of any help?
So now that the basic downloading works, let's try bluetooth.
I've created a pull request for just adding the BLE names and the
knowledge that "yes, we can try a BLE connection" at
On Sat, Feb 15, 2020 at 11:15 AM Willem Ferguson
wrote:
>
> This hardly affects the utility of the software.
Yeah, no, but the "string marker after running out of strings" message
really means that we have some internal parsing consistency.
So I don't think it's a problem for actual users, but
On Sat, Feb 15, 2020 at 10:42 AM Linus Torvalds
wrote:
>
> On Sat, Feb 15, 2020 at 10:35 AM Willem Ferguson
> wrote:
> >
> > "git-load: string marker after running out of strings ('description')"
>
> Let me go stare at the description cases. Maybe there's so
On Sat, Feb 15, 2020 at 10:35 AM Willem Ferguson
wrote:
>
> I built the latest master and the translation of dive mode changes appeared
> perfect. There was a warning message
>
> "git-load: string marker after running out of strings ('description')"
>
> I saved the git dive log but on reopening
On Fri, Feb 14, 2020 at 1:48 PM Robert C. Helling wrote:
>
> But once more, I have to admit, a quick read through did not really reveal to
> me how it works when handling multiple strings.
The basic handling hasn't changed: the strings are still decoded into
the 'struct membuffer'
On Fri, Feb 14, 2020 at 11:17 AM Linus Torvalds
wrote:
>
> The string handling during parsing is just too fragile. I think I have
> a better model for this that actually allows for easier use of
> multiple strings.
>
> Let me test something out.
Ok, I made a pull request:
On Fri, Feb 14, 2020 at 10:28 AM Dirk Hohndel wrote:
>
> Another obvious case where I as the maintainer merged something
> that should have been fixed instead. Apologies.
Honestly, this case is such a special case that I'd likely have missed
it too. I knew of the limitation, but it's obscure and
On Fri, Feb 14, 2020 at 7:06 AM Robert Helling wrote:
>
> it almost does: It has an Obiwan error: when the stepping back finds a ‘\0’,
> it returns a pointer to the 0 rather than the next character. But that’s easy
> to fix.
Ok.
> I was wondering if a better patch might be in another
On Thu, Feb 13, 2020 at 1:25 PM Robert Helling wrote:
>
> Maybe somebody with a better understanding of the code (Linus?) can help me
> out with this.
Hmm. That
event 40:00 type=8 divemode="OC" name="modechange"
line actually violates the original git save format thing - each line
is
On Thu, Feb 13, 2020 at 10:45 AM Linus Torvalds
wrote:
>
> I started trying to generalize our "field cache" code (which includes
> the string interface code) so I'll try to finish that up first. But
> Jef's updates look simple to merge.
Ok, done, and pushed out.
I ca
On Thu, Feb 13, 2020 at 8:10 AM Dirk Hohndel wrote:
>
> Linus, would you please take a look and merge this into our branch?
Will do.
I started trying to generalize our "field cache" code (which includes
the string interface code) so I'll try to finish that up first. But
Jef's updates look
On Sun, Feb 9, 2020 at 11:56 AM Dirk Hohndel wrote:
>
> It's the speeeling. 'celcius' vs 'celsius'
Lol. I even wrote it correctly in my email, but was blind to the fact
that it was spelled incorrectly in the picture.
Duh.
Linus
___
On Sun, Feb 9, 2020 at 5:54 AM tormento wrote:
>
> There is a mistype in TestFlight:
I'm not seeing the problem.
Is it that you'd prefer "centigrade"? The name "Celsius" is actually
technically more correct and modern.
There's some historical confusion about the names, but celsius is
certainly
On Mon, Feb 3, 2020 at 6:57 PM Martin de Weger wrote:
>
> I’ve purchased a Cressi Cartesio with the (bluetooth enabled) interface. I’ve
> ran into a few issues with this setup on Subsurface:
>
> I’m unable to download the dives on my Mac and on my iPhone using Bluetooth
> with Subsurface. When
On Sat, Jan 25, 2020 at 3:43 PM Lutz Vieweg wrote:
>
> the successor to Aqualung's i450t, the i470tc, comes with a Bluetooth
> instead of a USB interface:
>
> http://www.aqualung.com/it/prodotti/computer/computer-per-immersioni-i470tc
>
> Does anybody know whether it is already or will be
On Thu, Nov 7, 2019 at 10:47 PM Willem Ferguson
wrote:
>
> I would like to see retaining the feature of selecting a relatively
> large number of dives for manipulation, many more than what is shown
> on-screen at the time.
Note that "visible" to the model doesn't imply visibility on *screen*.
On Thu, Nov 7, 2019 at 2:25 PM Dirk Hohndel wrote:
>
> > And it might be truly *lovely* for startup if we didn't populate the
> > whole model at all. For the git format, we could literally avoid even
> > parsing the dives that are in a collapsed trip and this not visible.
>
> So we'd have a
On Thu, Nov 7, 2019 at 12:14 PM Berthold Stoeger
wrote:
>
> It doesn't have to. Just like you defined a proxy model on top of the
> DiveListModel, one could implement a proxy model on top of the tree model that
> "linearizes" it.
Maybe we should do that in general, even for the desktop case.
I
On Thu, Nov 7, 2019 at 9:46 AM Dirk Hohndel wrote:
>
> I like the thinking here. Radically simple. It does, however, breaks a lot of
> assumptions in our code, but I'm willing to deal with that in favor of
> something that's logical and consistent.
Hmm. It shouldn't break any assumptions in
On Thu, Nov 7, 2019 at 9:17 AM Dirk Hohndel wrote:
>
> (4) ??? other ideas?
Stop thinking that dates have anything to do with dive trips.
A dive is in a trip. A trip is just a container. The date is
completely and utterly irrelevant, and has nothing to do with what
trip a dive is.
The *only*
On Sat, Nov 2, 2019 at 9:00 AM Pedro Neves wrote:
>
> After 2 months without diving I've started again this week. Now my
> Linux machine (Arch linux with kernel 5.3.7) does not recognize my
> Uwatec USB interface (dmesg shows nothing when I plug the thing) .
Even if you don't have a driver for
On Fri, Oct 18, 2019 at 9:03 AM Willem Ferguson
wrote:
>
> If I say git pull or git pull origin, I get "Already up to date".
> However when I do git log it does not show any updates after my last
> commit 2 months ago.
>
> Am I crazy?
If you don't mention an explicit branch, "git pull" (and "git
On Sat, Sep 7, 2019 at 12:21 PM Fabio Capriati wrote:
>
> If you have a Android version with new Beta version of libdivelog, I can
> test it on my Mares Smart DC.
Hmm. Travis successfully built the Android version at
https://travis-ci.org/Subsurface-divelog/subsurface/jobs/582100407
but I
On Sat, Sep 7, 2019 at 9:54 AM Linus Torvalds
wrote:
>
> I've done the merge, I'm doing a test build, and I'll make a pull
> request.
Travis is happy, things look ok.
For reference, this is the diffstat of the updates from Jef:
src/divesystem_idive_parse
On Sat, Sep 7, 2019 at 8:34 AM Dirk Hohndel wrote:
>
> Linus, is there anything in libdivecomputer we should pull?
I just checked Jef's branch, and merged it. It has a Mares BLE packet
caching fix that *might* explain that the Mares BLUELINK Pro
apparently doesn't work any more.
Since I don't
On Thu, Aug 29, 2019 at 4:14 PM Dirk Hohndel wrote:
> On Aug 29, 2019, at 3:32 PM, Linus Torvalds
> wrote:
> >
> > So there's a fix for the Deepblu Cosmiq+ gas import in
> > libdivecomputer. I wanted to also explore doing all the fingerprinting
> > and gett
On Thu, Aug 29, 2019 at 1:00 PM Dirk Hohndel wrote:
>
> So, since 4.9.2 was tagged already, let's regroup and try to get a 4.9.3 out.
> Which means we need to figure out what should be merged, what still needs to
> be fixed, and when we can release that...
So there's a fix for the Deepblu
1 - 100 of 881 matches
Mail list logo
