Re: [CCR PATCH] Import ad store sensor and setpoint values from xml [WITH attachment]
On Sat, Oct 11, 2014 at 10:05:33AM +0200, Willem Ferguson wrote:
CCR patch: Import and store oxygen sensor data
Thanks for this one. Instead of sitting on it forever or a back and forth
about the minor changes that I want I simply applied the changes and
committed it. Here's my diff on top of yours... you'll see some small
algorithm cleanup (you put that value in o2val, so use o2val instead of
getting the structure member again), whitespace, debug printout...
/D
diff --git a/dive.c b/dive.c
index ea1ff03afbbc..d20a64cc1cc1 100644
--- a/dive.c
+++ b/dive.c
@@ -1113,10 +1113,10 @@ static void fixup_dive_dc(struct dive *dive, struct
divecomputer *dc)
for (j = 0; j dc-no_o2sensors; j++) { // for CCR oxygen
sensor data:
o2val = sample-o2sensor[j].mbar;
if (o2val) {
- if (lasto2val[j] == sample-o2sensor[j].mbar)
+ if (lasto2val[j] == o2val)
sample-o2sensor[j].mbar = 0;
else
- lasto2val[j] = sample-o2sensor[j].mbar;
+ lasto2val[j] = o2val;
}
}
@@ -1134,7 +1134,7 @@ static void fixup_dive_dc(struct dive *dive, struct
divecomputer *dc)
depthtime += (time - lasttime) * (lastdepth + depth) / 2;
lastdepth = depth;
lasttime = time;
- if (sample-cns dive-maxcns)
+ if (sample-cns dive-maxcns)
dive-maxcns = sample-cns;
}
diff --git a/parse-xml.c b/parse-xml.c
index b07505c2d8f4..6e74e8aaf449 100644
--- a/parse-xml.c
+++ b/parse-xml.c
@@ -815,8 +815,8 @@ static void try_to_fill_dc(struct divecomputer *dc, const
char *name, char *buf)
return;
if (MATCH(diveid, hex_value, dc-diveid))
return;
- if (MATCH(dctype, get_dc_type, dc-dctype)) { printf(TYPE\n);
- return; }
+ if (MATCH(dctype, get_dc_type, dc-dctype))
+ return;
if (MATCH(no_o2sensors, get_sensor, dc-no_o2sensors))
return;
if (match_dc_data_fields(dc, name, buf))
--- a/profile.c 2014-10-11 07:05:54.047560980 -0400
+++ b/profile.c 2014-10-11 07:09:59.319146178 -0400
@@ -551,7 +551,7 @@
entry-in_deco = sample-in_deco;
entry-cns = sample-cns;
entry-pressures.o2 = sample-po2.mbar / 1000.0;
- entry-o2setpoint = sample-o2setpoint.mbar / 1000.0; // for
rebreathers
+ entry-o2setpoint = sample-o2setpoint.mbar / 1000.0; // for
rebreathers
entry-o2sensor[0] = sample-o2sensor[0].mbar / 1000.0; // for
up to three rebreather O2 sensors
entry-o2sensor[1] = sample-o2sensor[1].mbar / 1000.0;
entry-o2sensor[2] = sample-o2sensor[2].mbar / 1000.0;
@@ -844,10 +846,10 @@
entry-end = (entry-depth + 1) * (1000 - fhe) / 1000.0 -
1;
entry-ead = (entry-depth + 1) * (1000 - fo2 - fhe) /
(double)N2_IN_AIR - 1;
entry-eadd = (entry-depth + 1) *
- (entry-pressures.o2 / amb_pressure *
O2_DENSITY +
-entry-pressures.n2 / amb_pressure *
N2_DENSITY +
-entry-pressures.he / amb_pressure *
HE_DENSITY) /
- (O2_IN_AIR * O2_DENSITY + N2_IN_AIR *
N2_DENSITY) * 1000 - 1;
+ (entry-pressures.o2 / amb_pressure *
O2_DENSITY +
+ entry-pressures.n2 / amb_pressure *
N2_DENSITY +
+ entry-pressures.he / amb_pressure *
HE_DENSITY) /
+ (O2_IN_AIR * O2_DENSITY + N2_IN_AIR *
N2_DENSITY) * 1000 - 1;
if (entry-mod 0)
entry-mod = 0;
if (entry-ead 0)
@@ -914,9 +916,9 @@
setup_gas_sensor_pressure(dive, dc, pi); /* Try to
populate our gas pressure knowledge */
populate_pressure_information(dive, dc, pi, NONDILUENT); /* ..
calculate missing pressure entries for all gasses except diluent */
if (dc-dctype == CCR) { /* For CCR
dives.. */
- printf(CCR DIVE: %s (%d O2 sensors)\n,
dc-model,dc-no_o2sensors);
+ printf(CCR DIVE: %s (%d O2 sensors)\n, dc-model,
dc-no_o2sensors);
populate_pressure_information(dive, dc, pi, DILUENT); /* ..
calculate missing diluent gas pressure entries */
// fill_o2_values(dc, pi); /* .. and
insert the O2 sensor data having 0 values. */
}
calculate_sac(dive, pi); /* Calculate sac */
calculate_deco_information(dive, dc, pi, false);
Re: [PATCH 6/7] This adds a ui for Suunto Vyper settings
On Sun, Oct 12, 2014 at 04:55:00PM +0200, Anton Lundin wrote: On 12 October, 2014 - Anton Lundin wrote: This builds up a ui to use for all the settings for the Suunto Vyper family devices. Some of the fields are pure information, eg, max depth and number of dives, so they are marked read-only. I would love if someone with a better knowledge about qt could answer this: Can you re-use common fields between the two different tab widgets, eg Serial number, Custom Text and so on between the OSTC3 and the Suunto Vyper configuration panels? Tomaz? Thiago? In this patch i just add another set of the same ones. Is that the right way to do it? I don't know a different way. This is a cool patch series. Thanks. I'm doing test builds right now and expect to push it in a minute. Sadly I don't have access to one of those older devices (Tomaz has my Mosquito, Linus' Gekko got lost... the other Suuntos I have access to are the newer ones like Linus' Vyper Air and HelO₂), so I can't test it. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: DiveShare patch
On Sun, Oct 12, 2014 at 07:41:41PM +0200, Salvo Tomaselli wrote:
Greetings,
I made this patch that adds a new export option, to diveshare.
Nice
Dives can still be anonymous, but users can click a button and
go on a page where they have a secret string that they can paste
so that dives go to their account directly.
Let me know if this can be merged or needs some fixes.
I'd like to see a few changes... see below
Feel free to test it, but make sure that you don't test it with
any data that you wouldn't want to be public.
I have NOT tested this, just read the code...
diff --git a/qt-ui/diveshareexportdialog.cpp b/qt-ui/diveshareexportdialog.cpp
new file mode 100644
index 000..a44c2ee
--- /dev/null
+++ b/qt-ui/diveshareexportdialog.cpp
[...]
+void DiveShareExportDialog::finishedSlot(QNetworkReply* reply) {
+ this-ui-progressBar-setVisible(false);
+ if (reply-error() != 0) {
+ const char* error;
+ switch (reply-error()) {
+ case QNetworkReply::ConnectionRefusedError:
+ error = the remote server refused the connection (the
server is not accepting requests);
+ break;
+ case QNetworkReply::RemoteHostClosedError:
+ error =the remote server closed the connection
prematurely, before the entire reply was received and processed;
+ break;
+ case QNetworkReply::HostNotFoundError:
+ error =the remote host name was not found (invalid
hostname);
+ break;
+ case QNetworkReply::TimeoutError:
+ error =the connection to the remote server timed out;
+ break;
and lots and lots more...
do we need all these errors? I.e., can they all happen?
please mark all the texts for translation since they are user facing.
+ case QNetworkReply::TemporaryNetworkFailureError:
+ error =the connection was broken due to disconnection
from the network, however the system has initiated roaming to another access
point. The request should be resubmitted and will be processed as soon as the
connection is re-established.;
While we have no hard line length limit, this one seems a bit excessive...
+void DiveShareExportDialog::doUpload() {
[...]
+
+ //generate json
+ struct membuffer buf = { 0 };
+ export_list(buf, /tmp, this-exportSelected, false);
A path like this will work on Linux and Mac, but not on Windows
This is what jumped out at me after casually reading through the code.
I'll have to spend more time with some of the protocol stuff (or get
Thiago to review that part).
The reason I didn't pull it and said let's fix it in future commits is
that I worry that this is completely untested under Windows and I want to
make sure that we continue to have working daily builds on that
platform...
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [CCR PATCH] reorganise po2 calculations
Robert, I took the patch with tiny cleanups as it looked sane to me, but I think I the last couple of days have shown that you are much better than me in spotting issues in that code :-) Would you please take a look? Willem is leaving tonight and I want to make sure we get this figured out in the next 12 hours or so. Thanks /D On Mon, Oct 13, 2014 at 10:24:36PM +0200, Willem Ferguson wrote: CCR patch. Reorganise the oxygen partial pressure calculations. This patch responds to the side effects that the CCR code has had with respect to ceilings in OC dives and dive plans. Dive ceilings are now calculated apparently correctly. The following were performed: 1) remove the oxygen sensor and setpoint fields from the gas_pressures structure. 2) Re-insert setpoint and oxygen sensor fields in the plot_data structure. 3) Remove the algorithm that reads the o2 sensor data and calculates the pressures.po2 value from function fill_pressures() in dive.c and save it as a separate function calc_ccr_po2() in profile.c. 4) Activate calc_ccr_po2 from function fill_pressures() in profile.c. 5) Move the relative position of the call to fill_pressures() within the function create_polt_info_new() in profile.c. Signed-off-by: willem ferguson willemfergu...@zoology.up.ac.za ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: DiveShare patch
This is missing a Signed-Off-By: line
and it doesn't compile (toAscii() doesn't exist... did you mean toUtf8()?)
/D
On Tue, Oct 14, 2014 at 09:41:36AM +0200, Salvo Tomaselli wrote:
From 441da7c4e1b8fd41709919e29fb79944999d1209 Mon Sep 17 00:00:00 2001
From: Salvo 'LtWorf' Tomaselli tipos...@tiscali.it
Signed-off-by: Salvo 'LtWorf' Tomaselli tipos...@tiscali.it
Date: Sun, 21 Sep 2014 16:11:58 +0200
Subject: [PATCH] Export to DiveShare
Adds the possibility of exporting dives to DiveShare.
---
qt-ui/divelogexportdialog.cpp | 5 +
qt-ui/divelogexportdialog.ui| 10 ++
qt-ui/diveshareexportdialog.cpp | 142 +
qt-ui/diveshareexportdialog.h | 34 +
qt-ui/diveshareexportdialog.ui | 268
save-html.c | 3 +-
save-html.h | 2 +
subsurface.pro | 9 +-
8 files changed, 469 insertions(+), 4 deletions(-)
create mode 100644 qt-ui/diveshareexportdialog.cpp
create mode 100644 qt-ui/diveshareexportdialog.h
create mode 100644 qt-ui/diveshareexportdialog.ui
diff --git a/qt-ui/divelogexportdialog.cpp b/qt-ui/divelogexportdialog.cpp
index 67803ee..6c50c75 100644
--- a/qt-ui/divelogexportdialog.cpp
+++ b/qt-ui/divelogexportdialog.cpp
@@ -9,6 +9,7 @@
#include mainwindow.h
#include divelogexportdialog.h
+#include diveshareexportdialog.h
#include ui_divelogexportdialog.h
#include subsurfacewebservices.h
#include worldmap-save.h
@@ -70,6 +71,8 @@ void DiveLogExportDialog::showExplanation()
ui-description-setText(tr(Comma separated values that
include the most relevant information of the dive profile.));
} else if (ui-exportDivelogs-isChecked()) {
ui-description-setText(tr(Send the dive data to divelogs.de
website.));
+ } else if (ui-exportDiveshare-isChecked()) {
+ ui-description-setText(tr(Send the dive data to
dive-share.appspot.com website));
} else if (ui-exportWorldMap-isChecked()) {
ui-description-setText(tr(HTML export of the dive locations,
visualized on a world map.));
} else if (ui-exportSubsurfaceXML-isChecked()) {
@@ -243,6 +246,8 @@ void DiveLogExportDialog::on_buttonBox_accepted()
tr(CSV files
(*.csv *.CSV)));
} else if (ui-exportDivelogs-isChecked()) {
DivelogsDeWebServices::instance()-prepareDivesForUpload(ui-exportSelected-isChecked());
+ } else if (ui-exportDiveshare-isChecked()) {
+
DiveShareExportDialog::instance()-prepareDivesForUpload(ui-exportSelected-isChecked());
} else if (ui-exportWorldMap-isChecked()) {
filename = QFileDialog::getSaveFileName(this,
tr(Export world map), lastDir,
tr(HTML files
(*.html)));
diff --git a/qt-ui/divelogexportdialog.ui b/qt-ui/divelogexportdialog.ui
index 9510b5f..8e37196 100644
--- a/qt-ui/divelogexportdialog.ui
+++ b/qt-ui/divelogexportdialog.ui
@@ -84,6 +84,16 @@
/widget
/item
item
+ widget class=QRadioButton name=exportDiveshare
+property name=text
+ stringDiveShare/string
+/property
+attribute name=buttonGroup
+ string notr=trueexportGroup/string
+/attribute
+ /widget
+ /item
+ item
widget class=QRadioButton name=exportCSV
property name=text
stringCSV/string
diff --git a/qt-ui/diveshareexportdialog.cpp b/qt-ui/diveshareexportdialog.cpp
new file mode 100644
index 000..165df5e
--- /dev/null
+++ b/qt-ui/diveshareexportdialog.cpp
@@ -0,0 +1,142 @@
+#include diveshareexportdialog.h
+#include ui_diveshareexportdialog.h
+#include mainwindow.h
+#include save-html.h
+#include qt-ui/usersurvey.h
+#include qt-ui/subsurfacewebservices.h
+
+#include QDesktopServices
+#include QUrl
+#include QSettings
+
+DiveShareExportDialog::DiveShareExportDialog(QWidget *parent) :
+ QDialog(parent),
+ ui(new Ui::DiveShareExportDialog),
+ reply(NULL)
+{
+ ui-setupUi(this);
+}
+
+DiveShareExportDialog::~DiveShareExportDialog()
+{
+ delete ui;
+ delete reply;
+}
+
+void DiveShareExportDialog::UIDFromBrowser()
+{
+ QDesktopServices::openUrl(QUrl(DIVESHARE_BASE_URI /secret));
+}
+
+DiveShareExportDialog *DiveShareExportDialog::instance()
+{
+ static DiveShareExportDialog *self = new
DiveShareExportDialog(MainWindow::instance());
+ self-setAttribute(Qt::WA_QuitOnClose, false);
+ self-ui-txtResult-setHtml();
+ self-ui-buttonBox-setStandardButtons(QDialogButtonBox::Cancel);
+ return self;
+}
+
+void DiveShareExportDialog::prepareDivesForUpload(bool selected)
+{
+ exportSelected =
Re: Make planner work again for CCR dives
On Thu, Oct 16, 2014 at 05:28:42PM +0200, Robert Helling wrote: Hi, the latest CCR patches had rendered the planner not usable for CCR dives. This patch corrects this (and reenables the CCR set point column for segments). The problem was that a new member setpoint of struct divepoint had been introduced, but there was already po2 which had the same meaning. This patch merges the two and renames them setpoint to prevent future confusion. I'm a bit nervous that it doesn't apply to latest master. Do you have other code in your tree that isn't upstream? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: I guess we should make a release again... 4.3
On Tue, Oct 21, 2014 at 05:24:30PM +0200, Robert Helling wrote: On 20.10.2014, at 20:46, Paul-Erik Törrönen pol...@777-team.org wrote: I noticed that the fixed setpoint p02 (for OSTC3) is not working as earlier. In 'Subsurface v4.2, built with libdivecomputer v0.4.2' it showed the selected setpoints correctly (see screenshot), while in the latest version from git 'Subsurface v4.2-274-g839bcaaf70b7, built with libdivecomputer v0.4.2' this is no longer the case for the attached log. I think this patch fixes this. Please test. Others: I do not really understand our xml-parsing logic. So I inserted a loop through all samples to look for a set point to determine CCR dives right before a parsed dive gets added to the dive list. I am not sure this is the best place to do this. The way things work is that we iteratively build the dive as we read things. So all you'd have to do is add the flag to the cur_dive in try_to_fill_sample() once you see the setpoint (I haven't checked closely... we have some special case handling for Shearwater samples there, you might need to address it there as well) The way you did it would be rather alien to the way the algorithm is designed to work :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: I guess we should make a release again... 4.3
On Tue, Oct 21, 2014 at 08:32:40PM +0200, Robert Helling wrote: On 21 Oct 2014, at 18:52, Dirk Hohndel d...@hohndel.org wrote: Dirk, The way things work is that we iteratively build the dive as we read things. So all you'd have to do is add the flag to the cur_dive in try_to_fill_sample() once you see the setpoint (I haven't checked closely... we have some special case handling for Shearwater samples there, you might need to address it there as well) I hope this is what you intended. It would be, if it wasn't so horribly whitespace damaged :-( /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: I guess we should make a release again... 4.3
On Wed, Oct 22, 2014 at 11:37:28AM +0200, Robert Helling wrote: stupid me. I shouldn’t have started with some semi-failed attempt to fix the CCR planning but from origin/master. Rather than repairing the old, here is a brand new patch. This time based on master and with eight position TABs instead of four spaces. Applied and pushed. I guess I am a bit tired. I often feel that way, Robert. Thanks for the fix. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: I guess we should make a release again... 4.3
On Wed, Oct 22, 2014 at 03:13:13PM +0200, Davide DB wrote: On Mon, Oct 20, 2014 at 7:05 PM, Dirk Hohndel d...@hohndel.org wrote: - cut'n paste for dive data http://trac.subsurface-divelog.org/ticket/737 Have you considered looking at the code and fixing the problem? Maybe it's really easy (I haven't looked). The more people are willing and able to look at bugs and fix them, the more of the core developers have time to finish / implement bigger changes. I know, not everyone is a developer, but I felt it worth it to send out this little reminder... it's a lot of fun and I really try to make it easy for people. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Any problem with the mail server ?
Umm… why is this on the Google group that is supposed to be for our users? On Oct 26, 2014, at 2:59 PM, Tomaz Canabrava tcanabr...@kde.org wrote: Em 26/10/2014 18:44, Salvador Cuñat salvador.cu...@gmail.com escreveu: It's pretty strange to be 4 days without a single post in the mailing list, the last I received was in Oct, 22. Last commit in git is also from Oct, 22. I know it sounds crazy, but I don’t actually work on Subsurface 24x7. It only feels that way. So yes, the last few days I have been really busy at my actual job and then Linus and I traveled to San Jose where we had the pleasure to be the surprise speakers at the GSOC mentor reunion - and got to hang out with Miika and Anton. Which mean that the two of them had been traveling this week. All of which conspired to reduce the mail traffic over here... Im on hold again, again. My dad is having some serious issues and im again without time. Ugh. Ugh indeed. This has been a tough tough time for you. I’m so sorry. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
Good morning... On Mon, Oct 27, 2014 at 08:42:12AM +0100, Robert Helling wrote: Robert appears to have stepped up to help our Willem to get this right, but the more people work on this and help figure out what's the right way to do things, the better. indeed, more people needed here. I cannot say I have any sort of overview about the recently added CCR functionality. I have only only spent some time on debugging to make sure features that worked before got unbroken again. And of course, I don’t dive rebreathers myself (currently I am not diving anything unfortunately, stupid flu!) so all my knowledge is from hearsay anyway. So who are the rebreather divers besides Willem who are helping to get this right and are especially testing this as thoroughly as possible. I'd hate to release 4.3 and announve rebreather support and then have to say never mind... Re the compression thing: I agree it should not be in memory, only when saving files. And then repeated values should be omitted rather than set to zero as zero has a special meaning: Zero set point indicates that we are on OC and shortcuts all CCR calculations. Exactly. I need to go through the recent patches again and figure out where this was added. I was definitely too relaxed accepting rebreather changes, but I figured this was the best way to get stuff in and get people to start testing, given the challenges we had to get patches to work in the first place. BTW, another thing that need some looking after (for which I did not have time, yet) is when we calculate SAC rates: For the PSCR code, that I submitted on Friday, the steady state value of pO2 depends (amongst other things) on the current SAC. But often enough (at least when I was testing) it had not yet been calculated so the pO2 calculation has to resort to the default value (see the first if() in the code). My impression is that in many cases, there should be enough data to have a SAC but we only calculate it later in the code path. This is particularly bad, since we have two different default values for SAC, one for bottom time and one for deco, except that for real dives (those downloaded from dive computers) this distinction does not make sense. I'm still unclear how we are calculating the SAC in the PSCR case. So I can't quite tell you where this should be done. I repeat my question from above - who else on this list dives rebreather, understands the logic behind all this and can help get this right? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
On Mon, Oct 27, 2014 at 03:23:11PM +, Paul Sargent wrote: So who are the rebreather divers besides Willem who are helping to get this right and are especially testing this as thoroughly as possible. I'd hate to release 4.3 and announve rebreather support and then have to say never mind... I'm certainly happy to look over as much as I can, but it's limited by what I can exercise from my dive data. As far as I can tell a number of the patches recently deal with utilising ppO2 data from the sensors, and the only unit we can import ppO2 data from is a MkVI. I don't dive a MkVI, so whilst I can test planning CCR dives, or imported constant ppO2 CCR dives from an OSTC, I can't exercise everything. And that's fine. Let me know what you'd like me to attack ;-) Everything that you CAN use. So for the dives that you import, do the things that we show make sense? Is there a way they could (should?) make more sense? Does the planning seem right? Pieces missing? I simply notice that almost every time I do something that I usually don't play much with, I quickly find little bugs. And I worry that that's the experience for a lot of our users as well. And especially since tech divers appear to be a reasonably big part of our user base, I want to make sure we get this right :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
On Mon, Oct 27, 2014 at 11:26:52AM -0400, William Perry wrote: I can probably get my instructor to run a download against a bunch of shearwaters or Nitek Qs with the 4th cell monitoring if we need test data for subsurface or libdivecomputer. I'll leave this to the experts to ask for the data that would help them. I simply don't know. Usually my response is the more test data, the better, but I don't even know what to ask for :-/ Maybe I can convince my wife that I need to buy the rebreather a bit earlier than planned so I can help… :) That seems totally reasonable to me... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Mon, Oct 27, 2014 at 11:29:47AM -0400, William Perry wrote: I just finished by CCR training down in Bonaire last week so I don’t have a lot of experience, but I did find that minor depth changes did not impact the loop volume enough for me to feel the need to add diluent. My inhale was cut very slightly short (I was diving with the auto-diluent-valve off after the initial big descent). This would be equivalent to the occasional mask clear at depth. If you are doing a ton of 10 meter ascents/descents in a cave system as it winds around then those will add up quickly, but 1-2 footers is noise. I agree: 1/2 foot is noise, 10 m is significant. What value do you think we should use as limit? I just proposed 1 m on my previous email to Robert but I'm not sure if this value is big enough. What do you think? Maybe start tracking it if they stay at the new depth for more than a certain # of samples? If I just drop down quickly to look at something I’m not going to mind a short breath or two but if I am following the contour of the reef and stay at that depth for 5-10 minutes I will probably squirt in some diluent. I’m generally not a fan of heuristics like that though. With the benefit of absolutely know subject matter expertize, I think what would make sense is to smooth out the depth graph. Something like a gliding average across one minute - that should remove jitter and the quick pop down to look at things that you describe, at the same time it should be reasonably close to what I would call the perceived depth during a dive - and I think that's what people will tend to base their change to the counter lung content on... Again, just running my mouth (errr, fingers) and making things up here :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
towards 4.3
A few notes... - I would like to have a first beta released no later than Nov 10. - I have fixed the script that created the daily builds. It was still uploading them to the old site. :facepalm: - I will make a go/no-go decision on some of the features in a week or so; what that means is that some things that are not in a reasonable state may end up getting disabled for 4.3, to be continued once 4.3 is out Translations: I will push the latest strings in the next hour or two Documentation / User Manual / Manual Translations: let's wait for Willem to be back (I think he said he'd be back on the 28th, but I may be making this up) and figure out how we want to do that. With Tomaz out I assume the multi-filter will be delayed to 4.4. The current filters are marginally useful, I'll have to play with them some more to understand if I want to keep them or if the things I hate about them are beyond my ability to fix. Can you guys get the CCR stuff into a reasonably clean state in the next couple of weeks? Or should we disable this? What other things are partly done and likely / unlikely to be finished in the next two weeks? Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: towards 4.3
On Mon, Oct 27, 2014 at 01:34:37PM -0400, John Van Ostrand wrote: What other things are partly done and likely / unlikely to be finished in the next two weeks? Any chance the Cochran import can make it in? That's more a libdivecomputer question. Or are there Subsurface patches as well that I have ignored? I have been chatting with Jef a bit and he has been crazy busy the last few weeks and while he is thrilled that people are contributing (I did the A300CS, you did Cochran, Linus did the Suunto Eon Steel) that has only added to the workload. I know, this sounds backwards, but I know exactly how Jef feels. Working with contributors takes time. In the big picture it saves time if more people continue to contribute, but initially there is this extra effort... From a Subsurface point of view, I'll wait to see what Jef thinks is reasonable. In the past he has done heroic efforts to get things integrated in time for our releases. If Jef says sorry guys, I won't be able to get any of this integrated in the next two weeks (which is always possible, life comes first) I might be talked into doing a custom built (i.e., a temporary fork) in order to add support for those three dive computers to Subsurface 4.3 (actually, I think it's more than three - how many different devices do your patches cover? two? three?), but I really would prefer not to have to do so. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 3/6] Change the OSTC3 macros to have a ; in the end
On Mon, Oct 27, 2014 at 02:13:54PM -0700, Linus Torvalds wrote:
On Mon, Oct 27, 2014 at 12:37 PM, Anton Lundin gla...@acc.umu.se wrote:
-#define READ_SETTING(_OSTC3_SETTING, _DEVICE_DETAIL) \
+#define READ_SETTING(_OSTC3_SETTING, _DEVICE_DETAIL); \
That extra ';' as the first token in the macro definition seems entirely
broken.
rc = hw_ostc3_device_config_read(m_data-device,
_OSTC3_SETTING, uData, sizeof(uData)); \
if (rc == DC_STATUS_SUCCESS) \
m_deviceDetails-_DEVICE_DETAIL(uData[0]);
I'd also suggest enclosing it all in a do { } while (0) (*without* a
semicolon at the end - the final semicolon should come from the user),
because otherwise
if (x)
READ_SETTING(..)
else
READ_SETTING(..);
ends up parsing cleanly by the compiler, but doing completely bogus
crap (the else ends up pairing with the if inside the macro,
instead of the if in the code).
Needless to say, I agree with both statements. What the heck is that first
semicolon for, Anton?
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC Configuration
On Mon, Oct 27, 2014 at 10:04:57PM +0100, Anton Lundin wrote: On 27 October, 2014 - Anton Lundin wrote: Here is the results of my last little project. This stack of patches adds support for reading and writing the config blocks of the OSTC devices. All this bit magic was a bit tricky to get right so i wrote some simulator code for tis to actually be able to test read/write. There are some blocks in this code that ain't pretty. I kinda ran out of ideas to try to make it less ugly, so please, if anyone have some suggestion of sane pattern we could use I'm all ears(eyes?). There is also some cases where we should care about errors from libdivecomputer and show them propperly, but thats actually needed for all the config parts, so i thought i send out these ones and attack that later. And yes, if anyone wonders, the code is tested against a real device. All and every corner isn't tested that thoroughly, but it looks like i actually got it right =) I'll need to get my OSTC 2N and my OSTC 3 out and do a - backup - write random settings - restore - backup cycle and check that the two backups are identical... I am obviously rather nervous about this code. A prior instantiation ended up getting my OSTC3 into a state (with earlier firmware, thanks to Matthias this couldn't happen anymore with the latest version) where it no longer calculated any deco / ndl... which is kinda the point of a dive computer. And of course, what's still missing is the firmware update :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Create delegates for Config gas tables
On Mon, Oct 27, 2014 at 10:12:44PM +0100, Anton Lundin wrote: These patches was as far as i manage to get in my delegate handling. These ones looks ok, but the ComboBox one would be better if it saved the string value instead of the numeric value after you clicked on it, and you managed to translate that to the numeric value somehow in the populateDeviceDetails-methods. Yeah, this looks funny. Maybe one of the Qt experts can tell us what's missing to always show the string representation in the table. Oh, and I still think the way the tables are laid out is kinda goofy... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Mon, Oct 27, 2014 at 08:14:44PM +0100, Anton Lundin wrote: On 27 October, 2014 - Gaetan Bisson wrote: [2014-10-24 16:48:34 +0200] Robert Helling: what happened to Gaetan’s attempts at coming up with a UI implementation? I wanted to do something basic and Anton convinced me that would be a shame and something much better should be done instead. Since GUIs are the complete opposite to my area of expertise, I just stopped thinking about this. Something is always better then nothing. Give it a try! +1 -- if we have something then we can talk about what should be differently and make that happen. If we have nothing it's really hard for the UI experts to start working. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Removed dependence on not yet released libdivecomputer code.
BTW, did you check git master…? :-) /D On Oct 27, 2014, at 7:02 PM, John Van Ostrand j...@vanostrand.com wrote: Signed-off-by: John Van Ostrand j...@vanosrand.com --- cochran.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cochran.c b/cochran.c index 9e31f55..b3ba7b4 100644 --- a/cochran.c +++ b/cochran.c @@ -351,11 +351,13 @@ int cochran_dive_event(struct divecomputer *dc, const unsigned char *s, SAMPLE_FLAGS_BEGIN, 0, QT_TRANSLATE_NOOP(gettextFromC, ascent)); break; +#ifdef SAMPLE_EVENT_BATTERY case 0xC2: // Low battery warning add_event(dc, seconds, SAMPLE_EVENT_BATTERY, SAMPLE_FLAGS_NONE, 0, QT_TRANSLATE_NOOP(gettextFromC, battery)); break; +#endif case 0xC3: // CNS warning add_event(dc, seconds, SAMPLE_EVENT_OLF, SAMPLE_FLAGS_BEGIN, 0, -- 1.8.3.1 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: cochran_emc.h: packed structs
On October 28, 2014 8:05:20 AM Lubomir I. Ivanov neolit...@gmail.com wrote: On 28 October 2014 16:28, Dirk Hohndel d...@hohndel.org wrote: On Tue, Oct 28, 2014 at 01:28:47PM +0200, Lubomir I. Ivanov wrote: } __attribute__((packed)); is unreliable with MINGW 4.6 up until 4.8.2 - the one i have bundled with the Qt 5.3. Yes, Jef pointed that out (with less detail) on the libdivecomputer mailing list. padding is added regardless and there is high potential for the code to break. one solution would be to branch / use #pragma pack() which is an MSVC thing but recent MINGW supports it. i'm CCing John Van Ostrand as the author, and posting this message so that everyone knows. perhaps there is a need for a SUBSURFACE_PACK_STRUCT(x) macro of sorts. Is there a reliable way to do packed structures with mingw, msvc and gcc? If yes then I would love to have such a macro (or however this would be done). Being able to do this would make code so much more readable. We might even convince Jef to allow use of such a construct (after it's sufficiently tested) in libdivecomputer which would do wonders for my sanity :-) here is a solution (found online) that uses 'gcc_struct'. the attribute itself exists since 3.4.x. by coupling with 'packed' it respects the forced packing - tested on mingw 4.8.2! 'packed' not working in general still remains a bug... something to note - in the manual, they do not mention if it exists for GCC-ARM, but i would assume it does. also i have no idea if clang has it. I can test clang. What about msvc? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: cochran_emc.h: packed structs
On Tue, Oct 28, 2014 at 08:54:26AM -0700, Thiago Macieira wrote:
On Tuesday 28 October 2014 17:39:27 Lubomir I. Ivanov wrote:
__declspec(packed)
i don't have that in MSVC 2003; perhaps it's a newer feature.
Yeah, I was wrong, it's not there.
http://msdn.microsoft.com/en-us/library/dabb5z75.aspx
That's probably why the GCC attribute is disabled in MinGW for MS struct
compatibility. So it's not a bug, it's a feature.
The suggestion is to not require packing of structs. Reorder the members so
you don't need packing, if you can, or try to use different types if you
really
need the members in that order due to data storage or protocol.
Hm :-(
The reason so many people reverse engineering want packed structures is
that it makes it so much easier to write readable code.
A typical 8 byte sample might look like this:
struct sample {
unsigned char temp; // in F
unsigned int16_t depth; // in 1/16 ft
unsigned int16_t deco : 1;
unsigned int16_t tank_idx : 2;
unsigned int16_t marker : 1;
unsigned int16_t ascend_warn : 1;
unsigned int16_t compass : 9;
unsigned int16_t pressure; // in psi
unsigned char flags;
}
I made this up - it's much simpler than some real structures actually are.
The goal is to allow me to say
if (sample-deco) { ... }
instead of
if (data[3] 0x01) { ... }
and
show_direction(sample.compass)
instead of
show_direction((array_16_le(data + 3) 5) 0x1f)
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: cochran_emc.h: packed structs
On Tue, Oct 28, 2014 at 11:29:48AM -0700, Thiago Macieira wrote:
On Tuesday 28 October 2014 09:34:33 Dirk Hohndel wrote:
On Tue, Oct 28, 2014 at 09:28:31AM -0700, Thiago Macieira wrote:
Are we sure of the sample size? It's an odd number of bytes...
We have dive computers with non-constant sample sizes. And pretty much any
random number you can think of. Yes, 8 is common, as are 12 or 16.
8, 12, 16, 24, 32, 64 are fine.
I meant it when I said any random number. Yes, we USUALLY see multiples
of 4, but there are others. Like 37 (0x25).
uemis_sample_t is 37 (0x25) bytes in size with the packing and is used like
this:
/* first byte of divelog data is at offset 0x123 */
i = 0x123;
u_sample = (uemis_sample_t *)(data + i);
while ((i datalen) (u_sample-dive_time)) {
[...]
i += 0x25;
u_sample++;
}
Given the i += 0x25, it seems that the size is as intended.
It certainly is. If there is anything insane, broken or stupid that could
be done in a data protocol, chances are good that it has been done in the
Uemis protocol. Including an offset of 0x123 for the divelog data. Of
course, 3 x 97. And then 37 byte samples on top of that. What could
possibly go wrong?
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Translation question
On Tue, Oct 28, 2014 at 04:41:59PM -0400, John Van Ostrand wrote: I've modified a string that are being translated, specifically the string below that contains file extensions as well as labels: QStringList fileNames = QFileDialog::getOpenFileNames(this, tr(Open dive log file), lastUsedDir(), tr(Dive log files (*.xml *.uddf *.udcf *.csv *.jlb *.dld *.sde *.db *.can);; XML files (*.xml);;UDDF/UDCF files(*.uddf *.udcf);;JDiveLog files(*.jlb);; Suunto Files(*.sde *.db);;CSV Files(*.csv);;MkVI Files(*.txt);;All Files(*))); Do I need to modify all the /translations/*.ts files or will it be handled by some other process? This will be handled by the translators (using the transifex web site). Also, should this be changed since file extensions are not usually translated. Maybe a sprintf to build a string using translations of labels only? What gets translated are the texts in the middle. And you don't know if all languages have the same order, so is it XML files or whatever XML? So manually assembling this will increase the likelihood of issues with the translations. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
messing with the gas / tank handling
Hey Linus, Usually whenever I touch this code I break it. And then you have to fix it later when you notice that I messed with things. So this time I'll alert you directly. Danger, danger, Dirk touched the gas / tank handling code!!! Bug #742 shows that we got things pretty badly wrong for the Cobalt if the primary gas used on a dive (or in the case of his sample data, the only gas used on a dive) was not tank 0. We showed that ugly gas change, we showed that two gases were used during the dive, we associated the pressure from the samples with the wrong tank, etc. I just pushed out a commit that pretends to fix this. And it makes sense to me. But I'd really appreciate if you (or anyone else for that matter) would take a look and double check that this is ok. My biggest concern is the logic I added to fixup_dive_dc(). Because I don't know if sample-sensor == 0 means we explicitly switched to sensor 0 or we don't know which sensor we are using (i.e., which tank the sensor is connected to). The code there worked for all dives that I could find (I have a bunch of Cobalt dives from a couple of years ago when I got a Cobalt as a loaner for one of the tech classes we did). And it works with all my other multitank dives. Still - there is too much black magic in the way we handle gases / tanks. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 02:58:50PM -0700, Linus Torvalds wrote: On Tue, Oct 28, 2014 at 2:13 PM, Dirk Hohndel d...@hohndel.org wrote: Bug #742 shows that we got things pretty badly wrong for the Cobalt if the primary gas used on a dive (or in the case of his sample data, the only gas used on a dive) was not tank 0. We showed that ugly gas change, we showed that two gases were used during the dive, we associated the pressure from the samples with the wrong tank, etc. I just pushed out a commit that pretends to fix this. And it makes sense to me. But I'd really appreciate if you (or anyone else for that matter) would take a look and double check that this is ok. It looks fine, but the whole = 30s and first sample thing looks a bit confused. Do you really need *both*? From reading the Cobalt code we don't need the = 30s code anymore - it's ALWAYS on the first sample. I wondered if there was another dive computer that did something similar where we might still need it. I can't think of one, though. Maybe I should just remove it and see if something breaks :-) Also, that whole /* if we have an explicit first cylinder */ if (sample-sensor == 0 first_cylinder != 0) sample-sensor = first_cylinder; looks a bit iffy. I guess we're stuck with it, but my gut feel is that it's actually an Atomic Cobalt back-end bug, and that the Cobalt should just have reported the right sensor, rather than reporting sensor 0. I was wondering about that as well. The backend clearly has code there to try to report this data - but without access to a Cobalt this is hard to figure out... the Cobalt is another one of the dive computers where we can't just do a memory dump. Jef - I think you were working on a tool to dump the raw data for a dive? That might be helpful here... Or I could just send the user a hacked version of Subsurface that dumps the raw data to a file. He is responsive on trac... The reason it's iffy is that another dive computer that does this *right* might be impacted. And that's exactly why I wanted to show this to you... But right now, I guess only the Cobalt has this whole first_cylinder issue, so maybe worry about that possibility later.. And quite frankly, we'll need to eventually fix the fact that we can only have one cylinder pressure per sample, so this code will end up needing changes in more fundamental ways eventually. So the whole this might break in the future is not a very strong objection. The code is pretty much *guaranteed* to break in the future for other reasons anyway. Lovely. See my comment above :-/ Thanks for taking a look. I'll remove the = 30s checks and leave it as is otherwise. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 04:00:05PM -0700, Linus Torvalds wrote: On Tue, Oct 28, 2014 at 3:38 PM, Anton Lundin gla...@acc.umu.se wrote: Multiple sensor support feels way better than the current separate diluent-sensor code we currently carry for the Mk6. I think Dirk has another EON Steel with pressure sensor coming once they are public, so then we can finally test the whole two independent and concurrent pressure sensors from a dive computer that supports it. We have two other combinations that we can test. We have two Uemis sensors and we have two Icon HD sensors. Once my EON Steel arrives we'll need to drive up to Hoodsport and do some data collection... :-) They've been around before, but we haven't had access to any real data. And even some that are around don't seem to really report multiple pressures (ie they'll switch on gas switch events, or they support showing buddy pressures, but don't log them). I know we tested this with the Uemis and that simply switched between sensors in the samples. I can't remember what the Mares did, though. It's possible the EON Steel does the switch on gas switch events thing too, but judging by the encoding, I *think* it will actually log pressures from all the cylinders in parallel. We'll have to wait and see. It's going to be somewhat painful. Going to *two* sensors wouldn't be an issue: it doesn't take much more room than our current sensor index + pressure for our single sensor model, and in fact if we re-use one of the cylinders for diluent, we'd actually be shrinking our data structures. But our MAX_CYLINDERS value is currently 8, and it feels a bit wrong to make cylinderpressure an array of eight. How many tank sensors does the EON Steel support? The Uemis supports up to three. But I suspect that's what we'll have to do. Anything more complicated would not just increase confusion, but on 64-bit machines even just carrying a pointer to sensor data around takes up the space of two of the pressures, so it's hard to make it much denser with extra indirection or something. I guess 32 bytes per sample just for sensor data isn't really all that excessive in the end. It's not like people are likely to run this on really old machines. Do we really need 4 bytes for pressure data? Yes, we do when saving in mbar... we could switch to storing things in cbar - unsigned int16 gives us up to 650 bar... I'll admit, I'm not really serious. I'm not worried about 16 bytes more per sample and just staying with sane types. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 04:47:31PM -0700, Linus Torvalds wrote: I can't remember what the Mares did, though. Did we even have multiple sensors? I could have sworn that we had two. I even remember talking to the Mares guys about it. But I can only find one. Does anyone have a spare Mares Icon HD transmitter that they wouldn't mind borrowing us for a while? Or does anyone here have an Icon HD with two transmitters from which we could get raw data? How many tank sensors does the EON Steel support? The Uemis supports up to three. I think the docs said up to ten. Wow. We need to increase MAX_CYLINDERS :-) Do we really need 4 bytes for pressure data? Yes, we do when saving in mbar... we could switch to storing things in cbar - unsigned int16 gives us up to 650 bar... Hmm. Looking at the sample pressures I have, none of them have higher resolution than centibar anyway. So we could do that for cylinderpressure. But I only have a few pressure sensors and sources of data: the Uemis, and two different versions of the Suunto one. I did a quick look through libdivecomputer sources. I cannot find any device that appears to devote more than 16 bits to this. And I actually find several that appear to do this in 8 bits (i.e., 2 bar resolution). The surface pressures and cylinder working pressures are actually saved in mbar, though, so we'd have to use a separate type for cylinderpressure. Might not be a bad idea, though. I'm really torn. Do we really care that much? This would be our third pressure type. We have pressure_t which is 32bit mbar, we have o2pressure_t which is 16bit mbar. And then we'd have cylpressure_t which is 16bit and cbar. so at least *one* divecomputer clearly thinks it's sufficient. As far as I can tell ALL divecomputers think that's sufficient. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
bug reports on trac
As always, as we get ready for a release, I'm going back through trac bug reports. It's pretty sad how many are sitting there and no one cares. If it's really just Jef and me who are taking care of this then we as a community are failing our users. There are quite a few tickets where there are obvious requests for more data that should be asked. Or where someone even with limited understanding of our sources could sit down and try to reproduce the bug and add more data or maybe even look at the code and see if something stands out that seems bogus. It's fun. And it will improve the experience for our users. Lubomir, any chance you could look at #740. We clearly are messing up with wchar and Windows path names, again. Anyone with a tiny bit of understanding of our source could fix 739. 732 and 738 might be a bit harder, but not much. My bet is that's a change of fewer than 5 lines. 726 is also something that I bet would be really easy to figure out. 731 is something that someone could try to reproduce - I don't see this. Etc. Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: bug reports on trac
On Wed, Oct 29, 2014 at 07:12:23AM +0100, Robert C. Helling wrote: On 29 Oct 2014, at 04:52, Dirk Hohndel d...@hohndel.org wrote: Dirk, If it's really just Jef and me who are taking care of this then we as a community are failing our users. how do I subscribe to the mailing list where new tickets are announced? It's simply another mailing list... http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface-trac /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: New trial at EON Steel support - with DC_FIELD_STRING
Hey Linus, I like where this is going. Sadly I don't have my EON Steel, yet, so I can't really test it. One small comment, you forgot to add the fix for the broken headers on some Windows builds. We need something like this: #ifdef HAVE_LIBUSB #ifdef _WIN32 #define NOGDI #endif #include libusb-1.0/libusb.h With that applied (and a reasonably recent libusb - you're using a couple of interfaces that are somewhat new, they were added early last year and on one of my cross build setup I still had an older one...) it cross builds fine for Windows for me. There are a few warnings about pointers targets differing in signedness (you pass char * to a send_receive which expects const unsigned char *, and then the other way around with alloc_dirent(); finally strcpy doesn't like unsigned char *, either). But in all these cases a quick glance at the function shows that these are not a problem. On Wed, Oct 29, 2014 at 09:20:57AM -0700, Linus Torvalds wrote: Also, to show how DC_FIELD_STRING allows other things, I added Deco algorithm, Battery before dive and Battery after dive parsing to the EON Steel backend, although right now my subsurface patch just simply ignores that extra data. We'll need a way to show it, or at least save/restore it sanely, so that will take a bit of effort. Neat. I'll implement a simplistic way to show these soon. I'll wait for Jef's feedback on the DC_FIELD_STRING ;-) Whatever. The subsurface patch is still pretty small and straightforward, although to save/show generic strings will definitely take more effort. But battery information is apparently something people have been asking for, so I think it's all good. Yes, this is awesome. I could have done inter-diffs from the previous version, but with the big renames of eon_steel to eonsteel, that diff wouldn't really have been very useful anyway, and it's not like the previous version was applied, so this is an all-new series. Three patches for libdivecomputer, and one patch for subsurface. Not speaking for Jef, I prefer new patches in situations like this. No point to add the previous version to the git history. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Globe missing
On Wed, Oct 29, 2014 at 12:58:23PM -0400, John Van Ostrand wrote: Thanks. Boy does that makes me feel stupid. The full window view also had the same issue. I find this actually super annoying... Tomaz, can we enforce a minimum width for the Marble window? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Globe missing
On Wed, Oct 29, 2014 at 03:08:37PM -0200, Tomaz Canabrava wrote: Yes, we can make it unshirinkable. I actually liked the hability to hide, but I can remove it. Maybe we can keep it but make sure that Ctrl-1 always gives it at least 50px width? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: help understanding a Windows crash report
On Wed, Oct 29, 2014 at 06:46:12PM -0200, Tomaz Canabrava wrote: On Wed, Oct 29, 2014 at 6:38 PM, Dirk Hohndel d...@hohndel.org wrote: Running my latest daily build (not on the server, yet, for obvious reasons) I get the following crash. And I have no clue how to read those... Problem signature: Problem Event Name: APPCRASH Application Name:subsurface.exe Application Version: 4.2.0.349 Application Timestamp: 545147c1 Fault Module Name: Qt5Core.dll Fault Module Version:5.3.2.0 Fault Module Timestamp: 541cda2f Exception Code: c005 Exception Offset:00094d90 OS Version: 6.1.7601.2.1.0.256.4 Locale ID: 1033 Additional Information 1:70c7 Additional Information 2: 70c70372fad2f93bb2b69b6202626cb6 Additional Information 3:dfe1 Additional Information 4: dfe1b677b69a5298073538898968a3dd It looks like it's crashing in Qt5Core.dll - but how do I figure out what the rest means? There's an offset but no function name??? Dirk, Can you build the app in debug mode? Qt libraries have them build in debug mode to help that kind of stuff. I remember this rat hole. My Qt libraries come from Fedora (cross built for Win64). A debug build of Marble alone is several hundred megabytes and takes roughly forever... and I have yet to be able to build a single installer that actually works as debug build. Literally. That's why I gave up trying to get Qt5 work in 32bit. Sooo frustrating. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: help understanding a Windows crash report
On Wed, Oct 29, 2014 at 01:52:07PM -0700, Dirk Hohndel wrote: I remember this rat hole. My Qt libraries come from Fedora (cross built for Win64). A debug build of Marble alone is several hundred megabytes and takes roughly forever... and I have yet to be able to build a single installer that actually works as debug build. Literally. That's why I gave up trying to get Qt5 work in 32bit. Brilliant. Apparently a Fedora update broke things. If I replace the current Qt DLLs with the ones from a built a few months ago everything works. So now I need to undo those updates to mingw64-qt5-qtbase and friends. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: help understanding a Windows crash report
On Oct 30, 2014, at 3:15 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 30 October 2014 00:07, Dirk Hohndel d...@hohndel.org wrote: Please test http://subsurface-divelog.org/downloads/daily/subsurface-4.2-349-g2b8043b82b99.exe if you have a chance to make sure that it's not just my system where this works again... This one also implements the long missing don't install 64bit binaries on a 32bit system feature... quickly tested the installer and there are no crashes. Good. Thanks. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
divelist and units
So someone suggested this idea the other day (sorry, forgot who it was) when we were discussing the space issues and alignment issues with the header of the divelist. Don't show the units in the header at all, show them only in a tooltip. So I figured how hard can that be? and tried to implement it this morning. Surprisingly, it was ridiculously easy. This Qt thing might be working out for us after all... :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: divelist and units
On Thu, Oct 30, 2014 at 11:25:25AM -0400, John Van Ostrand wrote: On Thu, Oct 30, 2014 at 11:10 AM, Dirk Hohndel d...@hohndel.org wrote: So someone suggested this idea the other day (sorry, forgot who it was) It was in trac where I made the suggestion. I'm glad it worked out, since I really don't know what I'm doing.. Thanks for the idea... John Van Ostrand At large on sabbatical Oh, so you have time to learn Qt and contribute even more! Awesome :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: help understanding a Windows crash report
On Wed, Oct 29, 2014 at 09:19:22PM -0700, Dirk Hohndel wrote: On Oct 29, 2014, at 6:50 PM, Thiago Macieira thi...@macieira.org wrote: I'm fairly certain it's not a Qt bug now. This is a binary incompatibility issue between QtGui and QtWidgets due either a bug in Dirk's packaging or in Fedora's packaging. Dirk: verify that the DLLs you gave me are exactly the ones that Fedora shipped. If they are, the bug is in Fedora's build, somehow. It looks like a stale Qt5Gui.dll got packaged instead of the right one. I am 99% certain that the package I gave you had the correct DLLs from the Fedora packages. I’ll need to hunt down the md5 values for those DLLs to be 100% sure. I am now certain that I am packaging the Qt DLLs as delivered by Fedora 20. I uninstalled the corresponding packages, reinstalled them from the server and compared md5 fingerprints of all the Qt DLLs with the ones from the DLLs that were in the package that crashed... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Divelist: make the column headers for units left aligned
Just FYI, I had this applied yesterday and then reverted it today because
I think with my change to move the units to the tooltip I think this isn't
needed and things actually look better without it.
I know you implemented what I suggested. Thanks for that. It's just that
John's suggestion was better than mine :-)
/D
On Wed, Oct 29, 2014 at 06:23:25PM +0200, Lubomir I. Ivanov wrote:
From: Lubomir I. Ivanov neolit...@gmail.com
Fixes #739
Signed-off-by: Lubomir I. Ivanov neolit...@gmail.com
---
qt-ui/models.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
index ef76e7e..f548d37 100644
--- a/qt-ui/models.cpp
+++ b/qt-ui/models.cpp
@@ -1081,7 +1081,7 @@ static int nitrox_sort_value(struct dive *dive)
return he * 1000 + o2;
}
-static QVariant dive_table_alignment(int column)
+static QVariant dive_table_alignment(int column, bool isHeader)
{
QVariant retVal;
switch (column) {
@@ -1093,7 +1093,7 @@ static QVariant dive_table_alignment(int column)
case DiveTripModel::OTU:
case DiveTripModel::MAXCNS:
// Right align numeric columns
- retVal = int(Qt::AlignRight | Qt::AlignVCenter);
+ retVal = int((isHeader ? Qt::AlignLeft : Qt::AlignRight) |
Qt::AlignVCenter);
break;
// NR needs to be left aligned becase its the indent marker for trips
too
case DiveTripModel::NR:
@@ -1116,7 +1116,7 @@ QVariant DiveItem::data(int column, int role) const
switch (role) {
case Qt::TextAlignmentRole:
- retVal = dive_table_alignment(column);
+ retVal = dive_table_alignment(column, false);
break;
case DiveTripModel::SORT_ROLE:
Q_ASSERT(dive != NULL);
@@ -1353,7 +1353,7 @@ QVariant DiveTripModel::headerData(int section,
Qt::Orientation orientation, int
switch (role) {
case Qt::TextAlignmentRole:
- ret = dive_table_alignment(section);
+ ret = dive_table_alignment(section, true);
break;
case Qt::FontRole:
ret = defaultModelFont();
--
1.7.11.msysgit.0
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Correct bug: setpoint handling of Poseidon CCR dive logs
Linus, much of this is code that you wrote (the original when do we zero thing, when don't we). I clearly mis-remembered some of this. Would you chime in to get to the right resolution here, please? On Thu, Oct 30, 2014 at 08:29:18AM +0200, Willem Ferguson wrote: Ok, so here is how I understand the code as it is at present. It all happens in fixup_dive_dc() in dive.c and in fill_o2_values in profile.c. fixup_dive_dc(): While a particular cylinder is being used (i.e. while the index of the cylinder *remains the same*), the duplicate gas pressure values are zeroed out. This is pre-existing code, i.e it was there before any CCR code was developed. I only added the zeroing out for diluent gas pressures as well. [~line 1138 in dive.c]. I think I remember now. The logic was that many tank sensors don't give a reading in every sample. And somehow, somewhere this got converted into samples with no pressure reading ending up with the previous pressure reading which gave rather step function looking plots. The pre-existing code also zeroed out duplicate temperature values [~line 1169]. You can see there that the style of the commenting for that particular operation is different from my style of commenting. Same logic I believe. Immediately below the temperature value manipulation I added code that zeroes out the oxygen-related data. (o2 sensors and o2 setpoint). And at least for O2 setpoint that's problematic, given that we use this to distinguish CCR and OC. Maybe that's wrong and we need to fix THAT elsewhere, but right now that's what we do. Now where do all the zeroed data values get re-instated for profile calculations? As follows: 1) Gas pressures: In gaspressures.c the zeroed gas pressure values effectively get replaced. This is code that originally comes from profile.c and that code does *much* more than just re-instating the zeroed values. But, amongst others, interpolated values (using raw data from structures of sample) replace zeroed values in the appropriate places in structures of plotdata. Yes, it does smart interpolation (depth based, attempting constant SAC rate) and removes linear interpolation (some dive log programs did that and filled in these completely ridiculous linear interpolations... we detect that and rip it out). 2) Temperature values: The temperature values are re-instated in populate_plot_entries() in profile.c (~line 591). This is pre-existing code. 3) Oxygen values: In function fill_o2_values() in profile.c the zeroed sensor data and setpoint data are re-instated for plotting. As with the pressure calculations mentioned above, this function does more than re-instating zeroed oxygen values. It also triggers calculation of po2 values that are stored in pressures.o2 contained within each structure of plotdata. This is the code I'm less familiar with - that's partly yours (Willem), partly Robert's, I think. Towards a plan of action: In the underlying data structures the memory space requirements are the same, regardless of whether a zero is stored in a location or a measured data value. My suggestion is that we do not touch the pressure values in fixup_dive_dc but that we remove code that zeroes the oxygen-related values. Similarly, fill_o2_values() in profile.c is reduced to a loop that steps through the structures of plotdata, which corrects zero values (that might have originated either from the insertion of events along the dive profile or from glitches in the logging or download process) and which triggers po2 calculation for each structure of plotdata (i.e. each point on the dive profile). That sounds sane. I am not sure what to do about the zeroing and re-instatement of temperature data but if we were consistent, the zeroing of temperature data should also be removed. Why? Can you explain why the tank pressure handling would stay, but the temperature handling would change? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Changed tissue icon on profile graph.
On Thu, Oct 30, 2014 at 01:51:06PM -0400, John Van Ostrand wrote: The previous icon was of a bird that didn't seem to make sense. This icon looks like the tissue graph and should be more intuitive. Yes. BTW, I think the bird is an inside joke. The idea for the graph was inspired by the Shearwater Petrel... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [RFC] Don't display deleted tags after dive edit
On Thu, Oct 30, 2014 at 10:31:16PM +0300, Joseph W. Joshua wrote: The attached patch fixes issue #732 on trac. Please check, I hope my approach is right. Nope, doesn't seem to do it for me... Of course trying to figure out WHY this didn't work made me dig in and so I fixed it instead :-/ /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Correct bug: setpoint handling of Poseidon CCR dive logs
On Fri, Oct 31, 2014 at 08:30:14AM +0200, Willem Ferguson wrote: For this reason neither the temperature data nor the oxygen-related data need to be zeroed since the resolution of all these variables is more than sufficient and is highly unlikely to cause a blocky type of graph on the profile as long as these variable are logged fairly regularly. With the present code there is no possibility of interpolation of these data anyway. As an aside, temperature data from my Uwatec dive computer is blocky but this is because of the lack of temperature resolution of the DC. My Mares DC has better temperature resolution and a smooth temperature profile. Therefore, would it be sensible if I removed the zeroing out of oxygen-related and temperature data, more or less as described in the plan of action above? Yes, I think so. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Setting location coordinates while editing a dive
On Fri, Oct 31, 2014 at 02:51:39PM +0100, Davide DB wrote: On Thu, Oct 30, 2014 at 9:22 PM, John Van Ostrand j...@vanostrand.com wrote: So, do we track that in the edit session and update it on a name change or revert it on cancel? Or do we inform the user, on a double click, that they need to save first? Good question. Actually I always found the editing/saving process very inconsistent. Why I get dive is being edited alert just on the dive notes tab but I can change tanks, I can add events on the profile without any alert? Just to be precise, you cannot modify equipment without triggering the edit mode. But you can add a gas change. Yes, our handling of edits is extremely inconsistent. It has bugged me for a long time. I absolutely want a way to say never mind when editing things. I usually need that in the context of edits to the info page, so that's where it got implemented. But then there are several other ways to edit things where we don't have that. People have suggested an undo/redo feature but that would be an even more complex layer to add. Today you can make changes in these places (I hope I didn't forget any) 1) Dive notes tab (date, time, location, divemaster, buddy, tags, notes) (and once you entered edit mode, on a manually added dive, you can change the profile in the profile, but you can only start this process if you actually change some other field first - that's completely broken) Equipment tab (tanks and weights). The moment you edit things in Dive notes or Equipment tab, this triggers edit mode and the save / discard functionality. 2) Right click on the profile (changing/adding/removing events, gas changes, order of dive computers, delete dive computer All of these take immediate effect 3) Double click on the globe window Also takes immediate effect 4) Dive list (mostly changes to trip status, but also delete dives or shift their times) All of these take immediate effect I think it would be fairly simple to switch to edit mode when making changes in the second and third case above. Not sure this can be reasonably done in the last one. Or we could do what other software does and not have this edit mode. So basically the moment you tab away from a field that edit is permanent. Only if you use ESC is an edit reverted. I'll admit that I'd hate that, so I'd be more inclined to got with adding edit mode to 2) and 3) above. Comments? Preferences? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Setting location coordinates while editing a dive
On Thu, Oct 30, 2014 at 04:22:03PM -0400, John Van Ostrand wrote: I was getting very frustrated adding a dive location to an existing dive. I was expecting to be able to add a location then select the coordinates from the globe and have the coordinates updated and the location name and coordinates associated. Neither happens. The flag is planted without text and the flag disappears when I save. That's not how it's supposed to work :-( I thought that commit 9ead871d6456f8f19f6f0fe2413513ef4449253d was the culprit except reverting it seemingly made no difference. (qt-ui/globe.cpp:135 is the effective area of that commit.) So I added a dive to see what functionality that commit was supposed to correct. By double clicking, the coordinates are associated with the location of the highlighted dive in the dive list. I can see why that's bad. Then restoring the commit gave me the same add-dive bug, odd but I'll forget about that right now. You lost me. So I'm looking for ideas on proper behaviour. There are several circumstances I can think of: 1. User is adding a dive.. Associate the location with the edit location name of the dive. 2. User is editing an existing dive. Associate the location with the edit location name of the dive. I don't know what you mean by edit location name of the dive in both of these cases. 3. User is not editing a dive. Associate the location with the recorded location name of the dive. Yep. The problem arises that if the user changes the location while editing, or cancels the edit that needs to change the location-coordinate mapping. Sorry, your language is just too confusing for me. There are three things that we need to treat separately: - location name - coordinates - flag placement on the globe Can you rephrase your three cases and your issue using these terms? Then we can determine which scenario isn't working right and hopefully fix it... So, do we track that in the edit session and update it on a name change or revert it on cancel? Or do we inform the user, on a double click, that they need to save first? So this is the one part I did understand. And I responded to THAT in my previous email. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Proxy bug [was Re: Setting location coordinates while editing a dive]
On Fri, Oct 31, 2014 at 03:50:04PM +0100, Davide DB wrote: I'm just editing my last dives and I found a bug on Proxy: - Proxy password has expired - You try to download GPS point and you get authentication error - You update the password and save new setting but the new password is not used by the GPS download feature but it was correctly saved. - Restart the application, everything works. I'll file a bug on trac Please do. I guess I can think of a reason for this... it's possible that we only get the password when the Object is created and don't refresh it from the preferences when we try again. I'll look into that. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Fri, Oct 31, 2014 at 05:08:54PM +0100, Davide DB wrote: If I correctly understand this topic, its' about the same old rant about cylinder management... I hope this could be solved in 4.4 at least. I'm editing multiple technical dives after a week of training and it's a nightmare between bugs and missing functionalities. While testing bugs 753 and 754 I realized that some dives have the current cylinder in use PITA on all of them. Actually I do not understand why in a row of six imported dives just a couple of them have this problem on all cylinders. Sorry - as far as bug reports go... this one isn't really helping me understand what's going wrong. - I never touched profiles - I played with copy paste on multiple tanks and god knows what happened. I understood that you were referring to download tank data from your DC but I use only a stupid BT and I would like to be in full control of my cylinder data. Yes. So tell us in small words and short sentences ( :-) ) what it is that you would like and what the various bugs and missing features are. Ideally one at a time. I'm not trying to be funny - but it's really really hard to debug this / write the code when you don't quite understand what's wrong. For the developers usually the way we use things work. Otherwise we'd fix it :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Setting location coordinates while editing a dive
On Fri, Oct 31, 2014 at 09:40:29AM -0700, Dirk Hohndel wrote: I've been able to make changes so the ui.coordinates field is updated but placing flags on the globe is more challenging. Since the edited location name and coordinates only exist in the ui.location and ui.coordinates variables the globe::repopulateLabels() function can't place a flag on the globe, repopulateLabels() uses the dive list for coordinates and labels. Adding code so it also checks isEditing() and places a flag based on the edited fields would add that functionality. It should use the data from displayed_dive in addition to the dive list. Then all you need to do is make sure things are tracked correctly in displayed_dive (and they should, if not, that's yet another bug). Oh, and in case this wasn't obvious... my sentence implied the suggestion that you should implement that. So I won't tackle this and focus on the other three dozen bugs that I'm aware of. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Setting location coordinates while editing a dive
On Fri, Oct 31, 2014 at 04:36:29PM -0400, John Van Ostrand wrote:
In other words when manually adding a dive an empty dive would be added to
the dive list with fields added to the dive in as they are entered in the
form.
Hmm. I find that somewhat awkward. But I'm not categorically rejecting it.
This would have a few benefits
1. We eliminate the This dive is being edited indicator and all the
code
referencing isEditing().
So this is easy to write in text, but once you deal with the widgets it
gets a little tricky.
Example. You edit something (let's say a tag), your cursor is still in
that field, and then click on a different dive in the dive list. What
happens? You have a drop down open (date, cylinder type) and you change to
a different dive...
What I'm trying to say is that the definition of I'm editing something
is very intuitive, until you try to implement the finer details.
I figured we could use a change signal of some kind so we can react to
changes. It looks like some widgets are already enabled. Others may need
some modification.
That's part of the 'how'. But the question in many instances is when do
you issue that signal. E.g., when changing a text field, do you issue
this with every key press? If not, then when DO you do it? We have learned
the hard way that it's not always simple to figure out when focus has
moved...
2. We don't have anything funny to do with placemarks on the map.
3. Oops, like accidental double clicks can be backed out.
4. Eliminate non-intuitive location/placemark functionality.
5. Any for_each_dive will automatically include the dive being edited so
UI
updates like placemarks don't need special cases.
That last one doesn't make sense to me. Can you elaborate.
The repopulateLabels function in globe.cpp uses the dive list to create
flags. It would be cleaner if the data being editing was being updated into
the dive list as each field was changed. That way functions like
repopulateLabels wouldn't have to retrieve data from the form to place a
flag.
Ah, OK. That's what I suggested with adding the displayed_dive there.
But please DO NOT break the logic that the displayed_dive is distinct and
different from the corresponding dive on the divelist...
There would be a few challenges:
1. Single dive edits would be easy but multi-dive edits would more
complicated. They should be associated as one undo.
OK
2. Trips would be another undo case.
What does that mean? You mean trip changes to the divelist?
Uhhh, I want to see the data structure in which you do that :-)
We may want to undo a trip grouping or undo edits to a trip. We need to set
up different types of undos. A TRIP_GROUP undo might be one type and
TRIP_EDIT undo might be another. The undo stack would have a struct that
contains a type and a pointer to a blob of data, and undo action would send
that blob to the function that handles that specific undo type. The blob
would be used by that function to perform the undo. This provides a
framework for allowing a wide range of different undos.
Wow. Oops. Err. Yeah. That sounds easy...
A example might be this (imagine expanding struct undo_dive_edit to hold a
list of dives.)
struct undo_item {
enum undo_type type;
void *data;
};
struct undo_dive_edit {
int divenr;
struct dive *dive;
};
struct undo_item undo_stack[16];
int undo_stack_head = 0;
int undo_stack_tail = 0;
// called when date field is updated
void MainTab::updateDate(const QDateTime )
{
undo_dive_create(); // create and undo for this change
update dive in dive list with new date
}
void undo_dive_edit_create()
{
struct undo_item undo = undo_get_current(); // Get most recent undo
struct undo_dive_edit *ude = undo-undo_data;
// Only create an undo if this change affects a different set of dives
than the current undo.
if (undo.type != UNDO_DIVE_EDIT || ude-dive == selected_dive) {
// Create undo item.
struct undo_dive_edit *new_undo = malloc(sizeof(struct
undo_dive_edit));
new_undo-divenr = selected_dive;
new_undo-dive = copy of dive structure
undo_push(UNDO_DIVE_EDIT, (void *) new_undo);
}
}
// Dive Edit Undo
void undo_dive_edit(void *undo_data)
{
struct undo_dive_edit *undo = undo-undo_data;
copy saved dive over current version
}
void undo_pop()
{
if (undo_stack_head == undo_stack_tail)
return; // nothing to undo
struct undo_item undo = undo_stack[undo_stack_head--];
switch (undo.type) {
case UNDO_DIVE_EDIT:
undo_dive_edit(undo-data);
break;
case UNDO_DIVE_DELETE:
...
}
}
That looks like an interesting start. And hellishly fragile.
I'd be very careful to make sure we understand how to create atomic
transactions here - i.e. how to make sure that we can move
Re: better 'person' filter.
Thanks, Tomaz, this is much better! /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Fix inconsistent search result in HTML export
On Sat, Nov 01, 2014 at 09:54:19PM +0200, Gehad Elrobey wrote: Dirk, I think you have missed this patch, this patch fixes ticket #723 on the trac. Sorry about that. Applied /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: new daily builds and preparing for Beta 1
On Sat, Nov 01, 2014 at 07:18:26AM +0100, Robert C. Helling wrote: The CCR / PSCR code clearly needs more work. What's the status of the planner? Sorry I have been so silent recently but some real world issues required my attention more urgently. I will tell you what I tell everyone. Life comes first. Don't worry about it. But I should have a few hours in the next week for subsurface. Do here is what I expect: CCR logging (as far as ceilings go) should work with gas consumption disabled beyond anything that is dillutant use at depth independent rate. CCR planning should work as well but still without much UI support for bailout variants except from here bailout OC). PSCR will not be exposed to users (except maybe as Easter egg like have pscr keyword to turn on pscr ceiling calculations for testing). That is my plan which is hopefully realistic. That sounds like a good goal. Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: new daily builds and preparing for Beta 1: User manual
On Sat, Nov 01, 2014 at 09:15:24AM +0200, Willem Ferguson wrote: On 01/11/2014 01:12, Dirk Hohndel wrote: Willem, I assume you will continue to drive the user manual (which of course also drives its own translation team). Yup. I was waiting for some of the new UI developments to stabilise before writing English text. Understood. I'm still waiting to hear from Tomaz if he wants to tackle the alternative UI design for the multi filter that I proposed or if he wants to keep it as is for 4.3. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: trying to figure out the filter code
On Mon, Nov 03, 2014 at 10:47:56PM -0200, Tomaz Canabrava wrote:
On Mon, Nov 3, 2014 at 10:21 PM, Dirk Hohndel d...@hohndel.org wrote:
So I'm trying to understand how this all hooks together and it's clear
that there's some Qt magic in the background that I'm missing...
There is a bit of black magic, yes.
Beginning to shine a light on it :-)
but if you wanna check if something happened just *after* the filter was
due,
you need to implement something inside of the
void MultiFilterSortModel::myInvalidate()
{
invalidate();
// HERE.
}
The 'invalidate()' method is internal to Qt and all it does is mark the
model as dirty and filter everything again based on the filterAcceptsRow.
Excellent. I just did that and I think I managed to clean up part of the
issues with the selection. I pushed two changes that did that.
Another question. In the regular model code for the dive list - we have
lots of selection modification code there. That needs to become aware of
filter data so that selecting a trip in the filtered view only selects the
dives inside this trip that are visible under the filter - and similarly,
the trip row in the view needs to show the number of visible dives in that
trip, not the number of total dives in that trip.
Very hard to do with our current setup:
The state of the DiveModel is unchanged, we are applying a filter on top
of it.
so it doesn't know about the filter at all.
To illustrate:
I have a trip with 12 dives
I filter for dives with Buddy Tomaz
Then only the 6 dives with Tomaz are shown, but similarly the trip summary
row should read
Dive trip (6 dives)
instead of (12 dives)
So when I'm in TripItem::data() member, how can I figure out how many of
the dives in that trip are visible with the current filter?
*right now* we cant. simple as that ( unless we do something really ugly to
the code. )
so, Options:
1 - We hack around that, but the code will be easy to break and hard to
maintain, for now.
2 - We hm
okay, some light came, maybe we can.
the MultiFilterProxyModel acts as 'proxy' so we can use it's own data()
method to retrieve information about
the filtered trip - but I'm not really sure it works, I need to test and
see, the setup should be as this:
1 - Implement the data() method for MultiFilterProxyModel,
if the current index is a dive, call the default implementation
if the current index is a trip, verify the number of children it has in the
proxy model, not in the real model.
return the correct string.
I got stuck there - didn't manage to figure out how to do that. :-(
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Fwd: Two more rebreather patches
On Tue, Nov 04, 2014 at 10:01:05AM +0100, Robert Helling wrote: I think these two patches have not yet been applied. Sorry about that. I like the first one, the second one is marginal but it should have no negative impact, so I took it. It didn't apply but was easy to fix. Still, please double check. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Poseidon CCR dives: Nitrogen loading
On Wed, Nov 05, 2014 at 06:34:38PM +0100, Robert C. Helling wrote: On 05 Nov 2014, at 17:37, Willem Ferguson willemfergu...@zoology.up.ac.za wrote: Willem, 1) This patch has an unintended consequence: The ending cylinder pressure for the diluent cylinder (as seen on the equipment tab) is changed to reflect that of the ending pressure of the oxygen cylinder. The diluent cylinder index for the Poseidon diluent is the dreaded and infamous 1. We hardcode the cylinder IDs here while reading in the dive log because it is very specific to the Poseidon. In addition, even though these specific two cylinders have already been assigned to enum values of oxygen and diluent respectively, we are in the process of setting up the cylinders, so we cannot already use the functions that use these enum values. So: dive-cylinder[1].sample_end.mbar for this sample dive has a value of 141, that of the oxygen cylinder. The correct ending value for this variable is 137. I have carefully looked around the code around line 600 in file.c but cannot see the cause of this problem. Run the code with and without your patch and see the difference. This is weird. For some reason the pressures for the O2 cylinder are shown even when the gas name is “Air”. Have to investigate this further. The code that handles what's the current gas is rather dumb. I wouldn't be surprised if there were assumptions somewhere that whatever gas you have the sensor pressure for is also the gas that you are breathing. That's the first place I would look. 2) A question just to improve my understanding of the code. If the explicit_first_cylinder() result is diluent, does this mean that the deco requirements are calculated for the gas in the diluent cylinder? In this case the diluent is air, but the displayed ceilings do not (at first sight) appear to be shallower than that for air dives to the quivalent depths. For instance, if I simulate the sample dive as an air dive using the planner, the dive extended to 70 min for sufficient deco. So if the ceilings reflect the pn2 values at the various depths as actually calculated at each point on the profile, why does it matter whether one starts with cylinder 0 or cylinder 1? It means that air is handed to fill_pressures as gasmix (for which then the inert gas pressures are adopted according to the set point). So it should do the correct thing. If you gave it O2 then the gas output would always be pure O2 (and thus no deco obligation). No deco obligation and one heck of a CNS/OTU value I'd guess :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Don't add space between buddy tags
I don't understand the commit message. Can you elaborat? What does this fix? Your commit message seems to imply that things were better WITHOUT your commit... /D On Wed, Nov 05, 2014 at 10:54:33PM +0100, Anton Lundin wrote: The second buddy tag will then contain a space, due to that the internal splitter is the comma, and not the ,space. It actually looked better in the ui with ,space. Signed-off-by: Anton Lundin gla...@acc.umu.se --- qt-ui/maintab.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/qt-ui/maintab.cpp b/qt-ui/maintab.cpp index 545632f..b5cde40 100644 --- a/qt-ui/maintab.cpp +++ b/qt-ui/maintab.cpp @@ -923,7 +923,7 @@ void MainTab::on_buddy_textChanged() QStringList text_list = ui.buddy-toPlainText().split(,, QString::SkipEmptyParts); for (int i = 0; i text_list.size(); i++) text_list[i] = text_list[i].trimmed(); - QString text = text_list.join(, ); + QString text = text_list.join(,); free(displayed_dive.buddy); displayed_dive.buddy = strdup(text.toUtf8().data()); markChangedWidget(ui.buddy); @@ -936,7 +936,7 @@ void MainTab::on_divemaster_textChanged() QStringList text_list = ui.divemaster-toPlainText().split(,, QString::SkipEmptyParts); for (int i = 0; i text_list.size(); i++) text_list[i] = text_list[i].trimmed(); - QString text = text_list.join(, ); + QString text = text_list.join(,); free(displayed_dive.divemaster); displayed_dive.divemaster = strdup(text.toUtf8().data()); markChangedWidget(ui.divemaster); -- 1.9.1 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Cleaned up file list in open and import dialogs
On Nov 7, 2014, at 1:14 PM, Dirk Hohndel d...@hohndel.org wrote: Does not apply to master... Never mind. I needed to apply the LVD patch first. I had considered holding that back based on Henrik’s comments but decided to have you fix those issues in tree instead /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: extra data display
On Nov 7, 2014, at 2:05 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
Whatever we can extract from the dive computer and that is semi useful.
Please take a look at the implementation and especially the visualization.
Ok, this is an updated patch to use the DC_FIELD_STRING model, now using your
add_extra_data() interface.
Looks like it's working fine:
Extra-data.png
although I wouldn't call the visualization exactly beautiful. But the data
is there, and in a useful form.
Are you saying that I am not ${DEITY}’s gift to user interface design?
I thought the use of a model/view interface to visualize those string pairs is
extremely inspired.
AND it shows of the brilliance of having the key/value pair approach to
presenting information.
So byte your tongue. Or even “bite” it…
:-)
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: FTBFS libgit2
On Nov 9, 2014, at 9:10 AM, Salvo Tomaselli tipos...@tiscali.it wrote: Is there anything new about libgit2 in the qmake file? I get this Project ERROR: Package libgit2 not found I have the dev files installed, and I tried to have a look but it seems like a straightforward directive so I don't know where the problem is. Using master from git. This hasn’t changed in several months and is working fine for people on other distributions. I assume you are on some flavor of Debian? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ERROR: Package libgit2 not found
On Nov 9, 2014, at 6:07 AM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: Answer to myself: $ pkg-config --print-errors --exists libgit2 Package libssh2 was not found in the pkg-config search path. Perhaps you should add the directory containing `libssh2.pc' to the PKG_CONFIG_PATH environment variable Package 'libssh2', required by 'libgit2', not found I needed to install package libssh2-1-dev. Patch attached. INSTALL needs to be updated too. I don’t see Subsurface requiring libssh2. A quick git grep shows no mention. Is it possible that this is an issue with libgit2 packaging on Debian? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 4/6] Add support for libdivecomputer DC_FIELD_DIVEMODE
On Sun, Nov 09, 2014 at 11:11:44AM +0100, Jef Driesen wrote: OK, I ended up just implementing this… it’s pushed to master. In a broken commit that I pushed earlier and then a fix once I realized that this didn’t compile with older versions of libdivecomputer - but since it had been in the public tree for a while it seemed wrong to force push a fixed commit, so my stupidity will stay visible for the world… Please test. I did a quick test using a Cobalt 2, and I think there are some issues. (Note that there was a bug in libdivecomputer too, for which I just pushed a fix.) That obviously isn't included in the Windows binaries in case anyone is using those. I attached the raw data for one such dive. It has 5 tanks configured. Four metric and one imperial (in CUFT@BAR mode). Only one of the metric tanks is used. See the libdivecomputer xml output below. When downloading this dive into subsurface, this looks wrong: * None of the tanks has volume or working pressure. That sucks, so my code is wrong. That's always a pain to debug when you don't have access to the hardware * The O2 percentage for air is missing. I'm not sure if this is by design or not, but I expected to see 21% here. That's by design. Air is special. No gasmix info means you are using air, not 0% O₂ and 0% He (i.e., pure N₂). So whenever Subsurface deals with Air we do so with a gasmix of all zero. Note that this problem is not specific to the Cobalt. I see exactly the same with the Mares Darwin Air (and Airlab). That might help for debugging the problem, because with the darwin backend you can use the simulator. If you disable the 50 ms delay in mares_darwin_device_open, it runs faster :-) OK, good. That should allow me to test the Subsurface side of things. Not sure if I'll have the time today because of some family issues, though. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ERROR: Package libgit2 not found
On November 9, 2014 12:07:14 PM Tomaz Canabrava tcanabr...@kde.org wrote: On Sun, Nov 9, 2014 at 3:43 PM, Dirk Hohndel d...@hohndel.org wrote: On Nov 9, 2014, at 6:07 AM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: Answer to myself: $ pkg-config --print-errors --exists libgit2 Package libssh2 was not found in the pkg-config search path. Perhaps you should add the directory containing `libssh2.pc' to the PKG_CONFIG_PATH environment variable Package 'libssh2', required by 'libgit2', not found I needed to install package libssh2-1-dev. Patch attached. INSTALL needs to be updated too. I don’t see Subsurface requiring libssh2. A quick git grep shows no mention. Is it possible that this is an issue with libgit2 packaging on Debian? Looks so. But if some compile libgit with ssh and others don't, it's not safer to require both? I'd prefer to understand what's going on. To me it seems packaging is broken for that package if it requires another package but doesn't have a dependency /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: ERROR: Package libgit2 not found
On November 9, 2014 3:21:11 PM Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: On Mon, 10 Nov 2014, Salvo Tomaselli wrote: In data domenica 9 novembre 2014 09:43:12, Dirk Hohndel ha scritto: I don’t see Subsurface requiring libssh2. A quick git grep shows no mention. Is it possible that this is an issue with libgit2 packaging on Debian? Subsurface in debian doesn't use libgit2, I wrote a patch to take it away because of the poor status of libgit2, otherwise Subsurface wouldn't have been in the upcoming stable release of debian. Yes. Thanks. Unfortunately, there's still a problem when building subsurface from source :( It seems reasonable to at least document this on our web page. I'll try to do this today /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Help with translation Typos
Seriously. This is NOT a user forum type question, right? Please let’s use the developer mailing list for developer content, the user forum for user content. On Nov 10, 2014, at 12:54 PM, Davide DB dbdav...@gmail.com wrote: On Sun, Nov 2, 2014 at 9:00 PM, Davide DB dbdav...@gmail.com mailto:dbdav...@gmail.com wrote: String 352 is a piece of HTML doc??? Yes, it comes from the diveshareexportdialog.ui file. I’m trying to figure out how to mark it so it doesn’t get included in the source strings APNOE in ../qt-ui/configuredivecomputerdialog.ui:1940 Maybe apnea? Should be apnoea, I believe /D___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 1) Robert's patch; 2) the filter panel
On Nov 11, 2014, at 12:38 AM, Davide DB dbdav...@gmail.com wrote: On Tue, Nov 11, 2014 at 7:36 AM, Miika Turkia miika.tur...@gmail.com mailto:miika.tur...@gmail.com wrote: My intuition would add buttons for selecting all and clearing all filters. And possibly one for hiding the filter dialog as well. But do GUI people might think differently? You are correct. This was a sketch where everything started. There is a button: to clear applied filters; to close and clear everything; to minimize the search panel; to open the stats page giving info on the filtered dives. Besides control buttons, IMHO two features would be nice having: A string recalling how many dives where filtered A count number (nn) near every item. come to think of it, with these two info further searches became worthless (in some case): you open the filter panel and you already knows that you dove 100 times on reef and 51 times shooting photos. Maybe you dove 67 times to Catalina Reef... And just making some selection you already know how many dives you selected (e.g. Dirk Hohndel Yolanda reef). Is it difficult to count every item while populating the list boxes? I think it’s a great idea. Main problem? Most of the time no one but Tomaz is working on things like this. I occasionally dabble in Qt code, many of you fix things here or there, Anton worked on the config UI, but we really need another developer or three who dare to do bigger things like this… I talked to Tomaz yesterday and he said he had updated patches for the filter that got them closer to your design and was still debugging them. Once he sends that I can try and add the counts. Doing that now is likely to cause conflicting changes. And it’s almost 2am and I may not be in the best mental state to write code. Or heck, maybe that slight delirium IS the best time to write code. Let me consider… /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 1) Robert's patch; 2) the filter panel
On Nov 11, 2014, at 1:10 AM, Willem Ferguson willemfergu...@zoology.up.ac.za wrote: We need to remain focused. Let us, for the moment, not talk about what we would like in general and what version 5.0 might have. Let's talk specifically about what version 4.3 should have so that we can get the immediate done while putting the least possible pressure on Tomaz. Hehe. Agreed to some extend. But as I mentioned, I know that he is trying to finish this code - real life has thrown him a lot of problems in the last three months and real life always comes first. Once we have decided that 4.3 is going with the present filter panel, that gives me the information to generate documentation for the manual and I know what to do. Then, the only info I need is the complete information for the present operation of the filter panel (key shortcuts, etc) :-) My suggestion would be that you wait documenting this for a couple of days so we see how much can sanely be implemented in 4.3 and what should be pushed to 5.0. Worst case I once again adjust my release time line. I really agree with Davide that the buttons to show / clear / hide the filters are important and a must have for 4.3. The counts are a really cool idea so I want to at least look into how hard those would be to implement (and how confusing they would be to the user… you could have 30 boat dives and 200 photo dives, yet selecting both boat and photo you get 210 dives shown (because some, but not all boat dives are also photo dives)… I think this makes a lot of sense, but I’ll need to see it in action. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Poseidon information from Notes to Extra Data tab
On Tue, Nov 11, 2014 at 05:52:55PM +0800, Miika Turkia wrote: On Tue, Nov 11, 2014 at 5:30 PM, Willem Ferguson willemfergu...@zoology.up.ac.za wrote: Looks excellent Miika, Small bug. At the end of each item in the second column of the Extra data tab there is a small unprintable character showing up as a square. I suspect that should not be? I am shooting in the dark but would this patch fix the issue? Why would the string be terminated by '\n' or '\r'? I must be missing something (need to look at that code in the larger context). Shouldn't we just strip all whitespace (like \r and \n)? I had a bug earlier in my code where the second string did not get NUL terminated and that caused odd things to be shown, but I thought I fixed that. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On Tue, Nov 11, 2014 at 06:42:34PM +0200, Lubomir I. Ivanov wrote: On 11 November 2014 17:23, Lubomir I. Ivanov neolit...@gmail.com wrote: but i think i found another one: - start new divelog - import dives/test0.xml-test38.xml - select first dive in the trip - select second dive in the trip (dive #35?) it enters an infinite loop allocating 3MB per second while frozen. i'm a bit confused about this one... created ticked: http://trac.subsurface-divelog.org/ticket/759#ticket ticket text: -- Qt 5.3.0, win7 64bit, SHA1: d06cc2c68e10bb3 start subsurface load ./dives/test35.xml Above you say open all of them, here you say just load that one. the dctype='CCR' attribute in test35.xml is causing an infinite loop. if i put this line: This doesn't happen for me - I can open test35.xml just fine (latest master, Linux). /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
for those with scubaboard.com accounts
I’m trying to get them to establish a Dive Software forum at scubaboard.com - apparently the rules say that I need 25 people to voice their support. So if you happen to have an account there it would be nice if you could spend a minute and post a +1 or something like that in this thread: http://www.scubaboard.com/forums/suggestions/495505-request-new-dive-software-sub-forum.html http://www.scubaboard.com/forums/suggestions/495505-request-new-dive-software-sub-forum.html Thanks /D___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: outdated informations in the translations of the website
On Tue, Nov 11, 2014 at 10:20:54PM +0100, Salvo Tomaselli wrote: Hello, I've just updated the italian build page to mention the debian problem with libgit2. It occurred to me to check the other translations and basically no other language has any mention of libgit2 (not even in the dependencies). I believe that having outdated translations is much worse than having no translations at all, because you end up with missing information and you might not think to change the language of your browser in the settings, to obtain the information that you're looking for. I don't know how this would work with wordpress, but it'd be best if the translation of a page was automatically removed after the English version has been modified, and then the translator can manually check the differences and enable the translated page again. But anyway, I believe that something needs to be done, either keep the translations very up to date or just give up and localize just the executable. Yes, we need dedicated owners of the translations on the web site. I own the English and German text Lutz also helps keep my German honest Salvo and Davide own Italian Krzysztof owns Polish Pierre and Jean-Noël own French Salvador and Rodrigo own Spanish (???) I don't know who owns Portuguese Let me know if I need to make changes to this list. Also, are all of you on the subsurface-website mailing list? That one was intended for the people helping me translate the site... It would be great if people could do the following a) all of you: read the English text and point out issues. We definitely need to tweak the Subsurface page and update screenshots... b) each of the translators: please get the text in sync with what we have in English right now - that should make it much easier to make the small changes that we need when releasing 4.3 Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
4.2.1
No that anyone here is likely to care... I just updated the Windows installers. They are now officially version 4.2.1 The reason behind this is too embarrassing for words. I had built the libdivecomputer used for the 4.2 Windows binaries without libusb support by mistake. And then of course trying to re-create 4.2 installers against the fixed libdivecomputer I ran into the problem with the broken Qt5.3.2 cross build binaries under Fedora. And fixing that of course caused our version magic (and my build strings) to no longer show this as a 'release binary' which broke the update backend... So I threw up my hands in despair and simply created a 4.2.1 tag and corresponding binaries for Windows. Besides fixing my own stupidity there's nothing new there. Which reminds me, I guess I should push that branch... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Shows an error about wrong permissions
On Thu, Nov 13, 2014 at 11:36:24AM -0800, Thiago Macieira wrote: macos.c won't compile, there's an extra ( that isn't closed. Yeah, I'll fix that when applying. No big deal. Thanks for the report. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Shows an error about wrong permissions
On Thu, Nov 13, 2014 at 09:50:19PM +0200, Lubomir I. Ivanov wrote: On 13 November 2014 21:36, Thiago Macieira thi...@macieira.org wrote: On Thursday 13 November 2014 21:12:03 Lubomir I. Ivanov wrote: 2014-11-13 1:27 GMT+02:00 Salvo Tomaselli tipos...@tiscali.it: + } else if (access(data-devname, R_OK | W_OK) != 0) Hm. Now that I think of it. I don't know if this works on Windows… access() is part of the Win32 C library, but it needs UTF-16 to work for non-ASCII paths (_waccess()). we already do this for a set of functions such as fopen(), rename() etc, so a new wrapper function subsurface_access() has to be added. two patches are attached. (the second one is just some cleanup) another solution would be to not use access(). Hi Lubomir macos.c won't compile, there's an extra ( that isn't closed. Sorry, I can't include the patch code inline because your email listed them as application/octet-stream... my bad, There's also no io.h on Linux or Mac ;-) access() is in unistd.h /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
translations -- or how the times are changing
Completely random post... But traditionally and for many releases in a row, the languages that were the first to be fully translated and had the most complete translations were always German (I do horrible translations for that - and oh btw, I need help with some of the terms... what the heck is compass gain in German... Kompass Gewinn???), plus the three languages that are the most critically important to our user base (as I kept joking): Norwegian, Swedish and Finnish. Yet, as I'm preparing for the first beta of 4.3 I notice that all three of these languages are between 78 and 81% completed. Bulgarian, Italian, Dutch, Polish, English(UK), Spanish, Portuguese, French, Slovak, even Danish are ahead of them, Russian, Chinese, Estonian, Latvian and Brazilian Portuguese are pretty much on par with those three Skandinavian languages. I'll admit that I'm shocked... /D PS: yes, I'm of course just poking fun at you guys... ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Export CCR dive log to xml
On Sat, Nov 15, 2014 at 06:37:21PM +0200, Willem Ferguson wrote:
This is a second version of a similar patch submitted a few days ago.
That may be. It also is (with all due respect) CRAP.
This patch removes code that was added a few days ago to fix a crash. Plus
other unrelated things that undo recent changes.
I worry about the state of your git tree, Willem.
I'm about to cut the first beta and things like this shouldn't happen,
especially not now.
This version preserves the present convention of storing the CCR setpoint
information in xml using a PO2 attribute. It also reads the setpoint info
from
a xml PO2 attribute.
Three lines are marked as belonging to patches that were formulated by
Rober Helling and by Miika Turkia, respectively. So their equivalent patches
need to be pushed before this one. But this patch is buggy without those
two patches.
I'm trying to figure out which ones those might be...
but first look at these parts of your patch below
diff --git a/dive.c b/dive.c
index 0c0e649..ae99951 100644
--- a/dive.c
+++ b/dive.c
@@ -434,10 +434,6 @@ void clear_dive(struct dive *d)
taglist_free(d-tag_list);
STRUCTURED_LIST_FREE(struct divecomputer, d-dc.next, free_dc);
STRUCTURED_LIST_FREE(struct picture, d-picture_list, free_pic);
- for (int i = 0; i MAX_CYLINDERS; i++)
- free((void *)d-cylinder[i].type.description);
- for (int i = 0; i MAX_WEIGHTSYSTEMS; i++)
- free((void *)d-weightsystem[i].description);
memset(d, 0, sizeof(struct dive));
}
@@ -456,10 +452,6 @@ void copy_dive(struct dive *s, struct dive *d)
d-location = copy_string(s-location);
d-notes = copy_string(s-notes);
d-suit = copy_string(s-suit);
- for (int i = 0; i MAX_CYLINDERS; i++)
- d-cylinder[i].type.description =
copy_string(s-cylinder[i].type.description);
- for (int i = 0; i MAX_WEIGHTSYSTEMS; i++)
- d-weightsystem[i].description =
copy_string(s-weightsystem[i].description);
STRUCTURED_LIST_COPY(struct picture, s-picture_list, d-picture_list,
copy_pl);
STRUCTURED_LIST_COPY(struct tag_entry, s-tag_list, d-tag_list,
copy_tl);
STRUCTURED_LIST_COPY(struct divecomputer, s-dc.next, d-dc.next,
copy_dc);
WTF Why is that in here? How did you create this patch?
@@ -2515,13 +2507,8 @@ int count_dives_with_tag(const char *tag)
struct dive *d;
for_each_dive (i, d) {
- if (same_string(tag, )) {
- // count dives with no tags
- if (d-tag_list == NULL)
- counter++;
- } else if (taglist_contains(d-tag_list, tag)) {
+ if (taglist_contains(d-tag_list, tag))
counter++;
- }
}
return counter;
ditto
}
@@ -2535,13 +2522,8 @@ int count_dives_with_person(const char *person)
struct dive *d;
for_each_dive (i, d) {
- if (same_string(person, )) {
- // solo dive
- if (same_string(d-buddy, )
same_string(d-divemaster, ))
- counter++;
- } else if (string_sequence_contains(d-buddy, person) ||
string_sequence_contains(d-divemaster, person)) {
+ if (string_sequence_contains(d-buddy, person) ||
string_sequence_contains(d-divemaster, person))
counter++;
- }
}
return counter;
}
ditto
@@ -2559,20 +2541,6 @@ int count_dives_with_location(const char *location)
return counter;
}
-// count the dives with exactly the suit
-int count_dives_with_suit(const char *suit)
-{
- int i, counter = 0;
- struct dive *d;
-
- for_each_dive (i, d) {
- if (same_string(d-suit, suit))
- counter++;
- }
- return counter;
-}
-
-
struct dive *merge_dives(struct dive *a, struct dive *b, int offset, bool
prefer_downloaded)
{
struct dive *res = alloc_dive();
ditto
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 727 fixed
On Sun, Nov 16, 2014 at 11:28:48PM -0200, Tomaz Canabrava wrote: From 3db4a422485374801ca2f6233ec23b8671a8656d Mon Sep 17 00:00:00 2001 From: Tomaz Canabrava tomaz.canabr...@intel.com Date: Sun, 16 Nov 2014 23:22:58 -0200 Subject: [PATCH] fix 727 - position correctly the popup. When the user entered a tag and that made the message box display the popup with the possible choices was still in the old position hidding the line edit. You're a genius. This was one of those subtle little bugs that drove me nuts... Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
INSTALL file
Could some of you who build from source on various flavors of Linux and Mac check the INSTALL file and make sure it's still accurate / send updates? Thanks, that would really help me. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] User manual: Filter panel
I'll take this - but we REALLY, REALLY need different icons for Reset / Hide / Close in the filter panel. The ones we have are completely meaningless. /D On Mon, Nov 17, 2014 at 09:01:51AM +0200, Willem Ferguson wrote: Subject: User manual: text to explain filter panel Few smaller changes to text dealing with tissue pressures graph Signed-off-by: willem ferguson willemfergu...@zoology.up.ac.za From 694fa04f5bd872788b6d7c094cede4d3276ba1bd Mon Sep 17 00:00:00 2001 From: willem ferguson willemfergu...@zoology.up.ac.za Date: Mon, 17 Nov 2014 08:56:34 +0200 Subject: [PATCH 2/2] User manual: text to explain filter panel Few smaller changes to text dealing with tissue pressures graph Signed-off-by: willem ferguson willemfergu...@zoology.up.ac.za ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] User manual: Filter panel
On Mon, Nov 17, 2014 at 07:22:22AM +, Dirk Hohndel wrote: I'll take this - but we REALLY, REALLY need different icons for Reset / Hide / Close in the filter panel. The ones we have are completely meaningless. Oh, I also modified your filter text a little bit. Please check what I just pushed. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: bugs in daily build 4.2-549
On Mon, Nov 17, 2014 at 10:05:13AM +0100, Salvador Cuñat wrote: In Windows 7, 64b, while doing copy/paste of data from a preexisting dive to a new one (manually creating it), tanks and weight strings get corrupted, probably the same problem solved some days ago with the tanks names. Which strings? The descriptions? BTW, there is a crash when discarding the changes on the manually added dive. :-( BTW, BTW, some button tags aren't translated, I've realized save, discard, and cancel. That's odd - those look like they should be default strings that are translated through the Qt translations. Which language did you use? Where did those strings show up. On linux git-549 only seems to be affected the weight strings, even without copy/paste, after saving the dive, no crash while discarding, button tags translated. I can't quite parse that sentence... something only happens to the weight strings? What does even without copy/paste mean in this context? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: bugs in daily build 4.2-549
On Mon, Nov 17, 2014 at 02:06:27PM +0100, Salvador Cuñat wrote: 2014-11-17 10:19 GMT+01:00 Dirk Hohndel d...@hohndel.org: On Mon, Nov 17, 2014 at 10:05:13AM +0100, Salvador Cuñat wrote: In Windows 7, 64b, while doing copy/paste of data from a preexisting dive to a new one (manually creating it), tanks and weight strings get corrupted, probably the same problem solved some days ago with the tanks names. Which strings? The descriptions? Yes, the descriptors. That should be fixed. BTW, BTW, some button tags aren't translated, I've realized save, discard, and cancel. That's odd - those look like they should be default strings that are translated through the Qt translations. Which language did you use? Where did those strings show up. It is. Only affects Win, in linux are perfectly translated. I'm on spanish. Those are the strings showed on the warning pop ups when quitting without saving in both, the editor and the complete program (if there are changes unsaved to the log). This sounds like there are translations missing in the Windows installer. Odd. Everything else is translated correctly? On linux git-549 only seems to be affected the weight strings, even without copy/paste, after saving the dive, no crash while discarding, button tags translated. I can't quite parse that sentence... something only happens to the weight strings? What does even without copy/paste mean in this context? I apologize for my bad english (specially when I'm in a hurry). I initially thought that the strings thing was only when copy/pasting in Win, but realized it happened in linux also, both with or without copy/paste (when saying copy/paste I mean the subsurface recent feature, not the usual desktop feature). The other thing I meant was there were no crash or untranslated buttons in linux. Don't worry about English - I am perfectly happy to ask for clarification if I'm lost. Your English is orders of magnitudes better than my Spanish :-) Anyway, Linux is much more resillient to memory errors - Windows crashes much more aggressively. But I think the crash / corruption should be fixed (famous last words). The translation thing baffles me. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Patches
On Mon, Nov 17, 2014 at 03:40:52PM +0100, Davide DB wrote: Tomaz, I have no words to better describe it but... the filter panel is simply amazing!!! It's the best invention since Cousteau-Gagnan diving regulator :) It's just an implementation of your design, so while Tomaz deserves the credit for writing the code (and I helped a little), the glory goes to you for coming up with the design for it. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: bugs in daily build 4.2-549
On Mon, Nov 17, 2014 at 04:39:01PM +0200, Lubomir I. Ivanov wrote: On 17 November 2014 16:30, Davide DB dbdav...@gmail.com wrote: I forgot: if I discard those changes the app crashes... I this this is useless but... just in case: Nome evento problema: APPCRASH Nome applicazione: subsurface.exe Versione applicazione: 4.2.0.549 that's on an older installer version, but we can assume that the current git master has it fixed. I'm tethering over my phone right now. I'll make fresh binaries in a couple of hours... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
some changes to the stats tab
Since the stats tab apparently caused confusion (especially with only one dive selected), I made a few changes and added more tooltips. I think this is much clearer now, but unfortunately this added a few new strings that need to be translated. I don't worry so much about Beta 1, but just keep this in mind if you are one of the people helping to get things translated for the 4.3 release. I just kicked of a new set of Windows builds which should be on the server shortly (-569). Assuming I don't stumble into anything really annoying over the next hour or two I hope this can finally become the long delayed Beta 1. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Undo some broken CCR features
A few questions...
a - why are there two different commit messages?
On Mon, Nov 17, 2014 at 09:19:20PM +0200, Willem Ferguson wrote:
Undo some features that were broken in Robert's patch 0d7c192e:
1) Calculate correct partial pressure of oxygen to be plotted on
dive profile, taking into account the oxygen sensor data.
Currently, erroneously, OC PO2 values are shown, due to an
erroneous calling parameter to fill_pressures().
2) Read start and end cylinder pressured correctly. In Robert's
patch, some wrong assignments were done in file.c. This is
now corrected and the correct cylinder pressures are shown in
the equipment tab.
3) Write correct cylinder pressures to XML. Currently the data for
the two cylinder are written to XML the wrong way round
(diluent pressures = oxygen and vice versa).
Expand XML output:
1) Write oxygen sensor data to XML
2) Write no_of_02sensors to XML
Signed-off-by: willem ferguson willemfergu...@zoology.up.ac.za
From 8a4121607a4259fc5a2651eb815a340fd81d5034 Mon Sep 17 00:00:00 2001
From: willem ferguson willemfergu...@zoology.up.ac.za
Date: Mon, 17 Nov 2014 21:04:36 +0200
Subject: [PATCH] Undo some features that were broken in Robert's patch
0d7c192e:
1) Calculate correct partial pressure of oxygen to be plotted on
dive profile, taking into account the oxygen sensor data.
Currently, erroneously, OC PO2 values are shown, due to an
erroneous calling parameter to fill_pressures().
2) Read start and end cylinder pressured correctly. In Robert's
patch, some wrong assignments wer done in file.c. This is
now corrected and the correct cylinder pressures are shown in
the equipment tab.
Expand XML output:
1) Write oxygen sensor data to XML
2) Write no_of_02sensors to XML
Signed-off-by: willem ferguson willemfergu...@zoology.up.ac.za
The first one is what you wrote in the email, the second one is the commit
message that you gave when committing the patch. Why do you do that twice
instead of just sending the commit?
diff --git a/file.c b/file.c
index 97095fd..4fe4d35 100644
--- a/file.c
+++ b/file.c
@@ -597,7 +597,7 @@ int parse_txt_file(const char *filename, const char *csv)
case 13:
add_sample_data(sample,
POSEIDON_O2CYLINDER, value);
if (!o2cylinder_pressure) {
-
dive-cylinder[1].sample_start.mbar = value * 1000;
+
dive-cylinder[0].sample_start.mbar = value * 1000;
o2cylinder_pressure =
value;
} else
o2cylinder_pressure =
value;
BTW: I wanted to comment on this one before. This is SO UGLY.
if you have braces on one side of the else, have them on both sides.
diff --git a/profile.c b/profile.c
index 63023b5..8e43c21 100644
--- a/profile.c
+++ b/profile.c
@@ -905,7 +905,7 @@ static void calculate_gas_information_new(struct dive
*dive, struct plot_info *p
amb_pressure = depth_to_mbar(entry-depth, dive) / 1000.0;
- fill_pressures(entry-pressures, amb_pressure,
dive-cylinder[cylinderindex].gasmix, entry-pressures.o2, dive-dc.dctype,
entry-sac);
+ fill_pressures(entry-pressures, amb_pressure,
dive-cylinder[cylinderindex].gasmix, entry-o2pressure, dive-dc.dctype,
entry-sac);
fn2 = (int) (1000.0 * entry-pressures.n2 / amb_pressure);
fhe = (int) (1000.0 * entry-pressures.he / amb_pressure);
hmm, so what IS the difference between entry-pressures.o2 and
enry-o2pressure?
diff --git a/save-xml.c b/save-xml.c
index 52582db..cf7ccfe 100644
--- a/save-xml.c
+++ b/save-xml.c
@@ -254,6 +254,21 @@ static void save_sample(struct membuffer *b, struct
sample *sample, struct sampl
old-cns = sample-cns;
}
+ if ((sample-o2sensor[0].mbar) (sample-o2sensor[0].mbar !=
old-o2sensor[0].mbar)) {
+ put_milli(b, sensor1=', sample-o2sensor[0].mbar, bar');
+ old-o2sensor[0] = sample-o2sensor[0];
+ }
+
+ if ((sample-o2sensor[1].mbar) (sample-o2sensor[1].mbar !=
old-o2sensor[1].mbar)) {
+ put_milli(b, sensor2=', sample-o2sensor[1].mbar, bar');
+ old-o2sensor[1] = sample-o2sensor[1];
+ }
+
+ if ((sample-o2sensor[2].mbar) (sample-o2sensor[2].mbar !=
old-o2sensor[2].mbar)) {
+ put_milli(b, sensor3=', sample-o2sensor[2].mbar, bar');
+ old-o2sensor[2] = sample-o2sensor[2];
+ }
+
if (sample-setpoint.mbar != old-setpoint.mbar) {
put_milli(b, po2=', sample-setpoint.mbar, bar');
old-setpoint = sample-setpoint;
So this stores the three sensors in XML -
Re: [PATCH] Ruler: fix weird behaviour near x = 0
Nice catch. Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Patches
On Mon, Nov 17, 2014 at 03:59:52PM +0100, Davide DB wrote: I would have a smaaalll improvement if it is not difficult nor too late: Populating the tag list ONLY with the tag effectively used :) Are you trying to say don't list tags with a count of 0 ? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Patches
On Mon, Nov 17, 2014 at 10:08:29PM +0100, Davide DB wrote: Yes. Exactly Done. Just to keep our Chief User Experience Designer happy :-) /D Il 17/nov/2014 22:06 Dirk Hohndel d...@hohndel.org ha scritto: On Mon, Nov 17, 2014 at 03:59:52PM +0100, Davide DB wrote: I would have a smaaalll improvement if it is not difficult nor too late: Populating the tag list ONLY with the tag effectively used :) Are you trying to say don't list tags with a count of 0 ? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
4.3 Beta 1
Windows installers are on the serer in the download area (not daily, the real download area). Patches and tag are pushed. I will post announcements soon. Unfortunately for certain reasons (don't ask) I can't create a Mac DMG right now, so until that's fixed this is Windows only (and Linux from source). Major thanks goes to... Tomaz - for implementing the 4.3 killer feature Davide - for designing said feature and being persistent enough that it actually ended up being implemented as he envisioned things Anton Joshua - for the work on the dive computer configuration (and much more) Gehad - for the HTML exporter Miika, Robert, Willem, Lubomir everyone else for all the hard work you put into making this project fun and exciting. And of course for Linus, for getting this all started and for still hanging around and sending the occasional patch... I'm sure I forgot a ton of things. In the ReleaseNotes. In the README. Everywhere. Hey, just found the first oops. The ReleaseNotes still say Experimental CCR and PSCR support: (someone explain what does and does not work, please) But hey, it's only Beta 1. It's not supposed to be perfect. Send patches :-) /D git shortlog -s -n v4.2.. 178 Dirk Hohndel (bogus number, contains translations and random other stuff) 86 Tomaz Canabrava 80 Anton Lundin 34 Gehad Elrobey 34 Joshua Wambua 29 Miika Turkia 24 Robert Helling 24 Willem Ferguson 21 Lubomir I. Ivanov 14 Giuseppe Bilotta 14 John Van Ostrand 9 Tim Wootton 8 Linus Torvalds 7 Salvo 'LtWorf' Tomaselli 5 Thiago Macieira 4 Salvador Cuñat 1 Florian Klink 1 Gaetan Bisson 1 Joakim Bygdell 1 Karina Mochetti ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.3 Beta 1
On Mon, Nov 17, 2014 at 11:41:12PM +, Dirk Hohndel wrote: Windows installers are on the serer in the download area (not daily, the real download area). Patches and tag are pushed. I will post announcements soon. Unfortunately for certain reasons (don't ask) I can't create a Mac DMG right now, so until that's fixed this is Windows only (and Linux from source). And now the Mac DMG is in the Dowloads area as well. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
git save requires existing repository
Linus, can you remind me of the rationale why you did this? I obviously didn't get around writing a better UI for git saves (huge surprise), but when I just looked through the code to help Miika figure out how to test it, I realized that I thought we talked about Subsurface simply creating a new repository if there isn't onw - but then I can't remember why we aren't doing that. Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Undo some broken CCR features
On Tue, Nov 18, 2014 at 08:19:43AM +0200, Willem Ferguson wrote: The first one is what you wrote in the email, the second one is the commit message that you gave when committing the patch. Why do you do that twice instead of just sending the commit? In future I will just send the commit. Thanks BTW: I wanted to comment on this one before. This is SO UGLY. if you have braces on one side of the else, have them on both sides. This is not my code Interesting. Let's look at git blame to find out who I need to yell at :-) Miika! That's just terrible... diff --git a/profile.c b/profile.c index 63023b5..8e43c21 100644 --- a/profile.c +++ b/profile.c @@ -905,7 +905,7 @@ static void calculate_gas_information_new(struct dive *dive, struct plot_info *p amb_pressure = depth_to_mbar(entry-depth, dive) / 1000.0; - fill_pressures(entry-pressures, amb_pressure, dive-cylinder[cylinderindex].gasmix, entry-pressures.o2, dive-dc.dctype, entry-sac); + fill_pressures(entry-pressures, amb_pressure, dive-cylinder[cylinderindex].gasmix, entry-o2pressure, dive-dc.dctype, entry-sac); fn2 = (int) (1000.0 * entry-pressures.n2 / amb_pressure); fhe = (int) (1000.0 * entry-pressures.he / amb_pressure); hmm, so what IS the difference between entry-pressures.o2 and enry-o2pressure? entry-o2pressure holds the consensus PO2 after considering the data from the different oxygen sensors. OK It is the variable that is used for plotting in the dive profile. entry-o2pressure is calculated before pressures.o2. And what, may I ask, is pressures.o2? The call above to fill_pressures() is the one that actually computes pressures.o2. I assume one should not use pressures.o2 as a parameter in a call to a function that calculates pressures.o2?? Valid point. The XML import/export is not perfect yet. The export removes the cylinder start and end values supplied by the DC because cylinder-sample_start and cylinder-sample_end are zeroed somewhere beforehand, so they are not written. The import also has some problems with cylinder pressures and figuring out start/end pressures. My suggestion is let's get the XML side working reliably, then it is a simple matter to transfer to the git back end. Does this make sense? Sure. We're running out of time for 4.3, though I am actively working at improving the XML import/export. Excellent. So I assume this patch is not acceptable? Would you like me to re-draft the patch in line with you comments? No, I wanted to see your comments to understand what's going on. I still want to understand what pressures.o2 does... I'll take the patch and hope that you'll send patches on top of it to get CCR closer to ready for Beta 2 /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Undo some broken CCR features
On Tue, Nov 18, 2014 at 08:41:26AM +, Dirk Hohndel wrote: So I assume this patch is not acceptable? Would you like me to re-draft the patch in line with you comments? No, I wanted to see your comments to understand what's going on. I still want to understand what pressures.o2 does... I'll take the patch and hope that you'll send patches on top of it to get CCR closer to ready for Beta 2 BTW, as a general rule. If I look at the patch, it does four things. While this may seem silly, I would have MUCH preferred four patches that each do one thing. Each with their own commit message. Etc. But as I said, I took what you sent (but I rewrote the commit message to be less... personal). /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Question about cylinder start pressure variables
On Tue, Nov 18, 2014 at 02:25:47PM +0200, Willem Ferguson wrote: Does anyone know what are the purposes of the cylinder-start and cylinder-sample_start variables? How do these two members interact? cylinder-start is the start pressure manually entered by the user in the equipment menu. It could also show up when importing from other sources or (I think this is theoretical at this point in time) from a dive computer that doesn't store pressures in the samples but does somehow know about beginning and end pressure. cylinder-sample_start is a convenience variable that tells you the first pressure that is found in one of the samples. If we have that we tend to consider it more reliable then -start /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
mail interruption
Since today clearly wasn't my day, after the MySQL server died and took the database with it (thankfully I had a current backup for the Subsurface website - a couple other of my websites weren't that lucky), the mail server was acting up as well and had to be completely re-done. I have a backup MX server so I thought all would stay sane, but of course I didn't take Murphy's law into account. A permission error (caused by a setgid bit that somehow got lost) made mailman bounce emails for a short while. Perfect. JUST perfect. Please check that mails that you sent to the mailing list actually made it back to you (or are in the archives)... and if I ignored a personal email from you in the past eight hours it might not hurt to just resend it. Maybe tomorrow will be smoother for me. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 3/6] Create events from mouthpiece position
Oh the translators will LOVE this. What the HECK is NC and UN?
/D
On Wed, Nov 19, 2014 at 10:14:21PM +0100, Anton Lundin wrote:
This is based on the great work done by Søren Reinke's on his MKVI Logfile
Analyzer.
Signed-off-by: Anton Lundin gla...@acc.umu.se
---
file.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/file.c b/file.c
index e793152..8541427 100644
--- a/file.c
+++ b/file.c
@@ -592,6 +592,27 @@ int parse_txt_file(const char *filename, const char *csv)
switch (i) {
case 3:
switch (type) {
+ case 0:
+ //MouthPiece position event:
0=OC, 1=CC, 2=UN, 3=NC
+ switch (value) {
+ case 0:
+ add_event(dc,
cur_sampletime, 0, 0, 0,
+
QT_TRANSLATE_NOOP(gettextFromC, MouthPiece position OC));
+ break;
+ case 1:
+ add_event(dc,
cur_sampletime, 0, 0, 0,
+
QT_TRANSLATE_NOOP(gettextFromC, MouthPiece position CC));
+ break;
+ case 2:
+ add_event(dc,
cur_sampletime, 0, 0, 0,
+
QT_TRANSLATE_NOOP(gettextFromC, MouthPiece position UN));
+ break;
+ case 3:
+ add_event(dc,
cur_sampletime, 0, 0, 0,
+
QT_TRANSLATE_NOOP(gettextFromC, MouthPiece position NC));
+ break;
+ }
+ break;
case 6:
add_sample_data(sample,
POSEIDON_SENSOR1, value);
break;
--
1.9.1
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
