Re: [GSoC] Week 6 (Native Bluetooth support)
On Monday 06 July 2015 22:03:52 Dirk Hohndel wrote: > I tried testing on Ubuntu, also in a VM on the same Mac. But I can't seem > to figure out which package to install to get the QtBluetooth stuff. Any > suggestion on the right package names? This needs to be added to the > INSTALL file, too... It should be libqt5bluetooth5, according to packages.ubuntu.com. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
On Mon, Jul 06, 2015 at 10:03:52PM -0700, Dirk Hohndel wrote: > On Mon, Jul 06, 2015 at 11:00:08PM +0300, Claudiu Olteanu wrote: > > Hi, > > > > I wanted to let you know that after I did the firmware upgrade everything > > works fine. I tested both devices on all three environments > > (OpenSuse, Fedora, ArchLinux) and I didn't encounter any problem. > > > > Now we just have to figure out why Dirk's devices don't work. > > Dirk, do you have other environment on which you can run the tests? > > Latest firmware on both my OSTC 2N and the OSTC Sport. No luck with Arch > running in a VM inside of a Mac. I'll assume for now that this is because > of the VM. > > I tried testing on Ubuntu, also in a VM on the same Mac. But I can't seem > to figure out which package to install to get the QtBluetooth stuff. Any > suggestion on the right package names? This needs to be added to the > INSTALL file, too... I also tested with Qt5.5 on Arch (patch to make things compile will be pushed shortly). Similar results to 5.4: qt.bluetooth.bluez: Bluez 5 detected. qt.bluetooth.bluez: Creating QtBluezDiscoveryManager qt.bluetooth.bluez: Discovered: "00:12:6F:2A:0E:E0" "OSTCs 0321" Num UUIDs 1 total device 0 cached RSSI 0 Class 7936 Now I can pick that device and click download The OSTC Sport switches into Download mode enabled and nothing happens. Shortly thereafter I get qt.bluetooth.bluez: void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Connection reset by peer" And when I check with bluez the divecomputer is no longer listed as connected. My guess is that this is because I'm in a VM. Once I figure out the Ubuntu situation I'll use a different computer that is running Ubuntu directly. I don't consider being able to run inside a VM critical... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
On Mon, Jul 06, 2015 at 11:00:08PM +0300, Claudiu Olteanu wrote: > Hi, > > I wanted to let you know that after I did the firmware upgrade everything > works fine. I tested both devices on all three environments > (OpenSuse, Fedora, ArchLinux) and I didn't encounter any problem. > > Now we just have to figure out why Dirk's devices don't work. > Dirk, do you have other environment on which you can run the tests? Latest firmware on both my OSTC 2N and the OSTC Sport. No luck with Arch running in a VM inside of a Mac. I'll assume for now that this is because of the VM. I tried testing on Ubuntu, also in a VM on the same Mac. But I can't seem to figure out which package to install to get the QtBluetooth stuff. Any suggestion on the right package names? This needs to be added to the INSTALL file, too... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
On Mon, Jul 06, 2015 at 02:02:54PM -0700, Thiago Macieira wrote: > On Monday 06 July 2015 23:19:58 Claudiu Olteanu wrote: > > > + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff); > > > > That's slightly weird :-) > > > > I know that this is weird but there is no HostPoweredOn enum :-). It can be > > either off, connectable, discoverable or discoverable limited inquiry. > > Therefore I choose to use !(mode == QBluetoothLocalDevice::HostPoweredOff)) > > instead of (mode == QBluetoothLocalDevice::HostDiscoverable || mode == > > QBluetoothLocalDevice::HostConnectable || ..) > > I meant doing > > bool on = !(x == y); > > instead of > > bool on = x != y; I'd much prefer bool on = (x != y); The parenthesis may be optional but they make this much easier to read. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
Oh yeah :). I don't know what was in my mind when I did that :)). On Tue, Jul 7, 2015 at 12:02 AM, Thiago Macieira wrote: > On Monday 06 July 2015 23:19:58 Claudiu Olteanu wrote: > > > + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff); > > > > That's slightly weird :-) > > > > I know that this is weird but there is no HostPoweredOn enum :-). It can > be > > either off, connectable, discoverable or discoverable limited inquiry. > > Therefore I choose to use !(mode == > QBluetoothLocalDevice::HostPoweredOff)) > > instead of (mode == QBluetoothLocalDevice::HostDiscoverable || mode == > > QBluetoothLocalDevice::HostConnectable || ..) > > I meant doing > > bool on = !(x == y); > > instead of > > bool on = x != y; > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
On Monday 06 July 2015 23:19:58 Claudiu Olteanu wrote: > > + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff); > > That's slightly weird :-) > > I know that this is weird but there is no HostPoweredOn enum :-). It can be > either off, connectable, discoverable or discoverable limited inquiry. > Therefore I choose to use !(mode == QBluetoothLocalDevice::HostPoweredOff)) > instead of (mode == QBluetoothLocalDevice::HostDiscoverable || mode == > QBluetoothLocalDevice::HostConnectable || ..) I meant doing bool on = !(x == y); instead of bool on = x != y; -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
Sorry, my mistake! Somehow I deleted the qtserialbluetooth.cpp source from SUBSURFACE_CORE_LIB_SRCS list :-). I managed to compile the project with Qt5.5.0. I saw that Bluetooth connectivity doesn't work for the moment with this version. I will investigate it tomorrow. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
Hi Thiago, > + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff); > > That's slightly weird :-) I know that this is weird but there is no HostPoweredOn enum :-). It can be either off, connectable, discoverable or discoverable limited inquiry. Therefore I choose to use !(mode == QBluetoothLocalDevice::HostPoweredOff)) instead of (mode == QBluetoothLocalDevice::HostDiscoverable || mode == QBluetoothLocalDevice::HostConnectable || ..) > Hint: QString has a "multiarg" arg that works on QStrings and is slightly > faster. If you remember, please use it next time. > > Hint: please use the Qt API for the containers. I had to look up to see if > the > empty() function was a getter of the emptiness state or whether it emptied > the > container. Thanks for your feedback! I will keep in mind what you said. This is the first time I work with Qt framework and obviously I have a lot to learn. Cheers, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
On Mon, Jul 06, 2015 at 11:00:08PM +0300, Claudiu Olteanu wrote: > Hi, > > I wanted to let you know that after I did the firmware upgrade everything > works fine. I tested both devices on all three environments > (OpenSuse, Fedora, ArchLinux) and I didn't encounter any problem. > > Now we just have to figure out why Dirk's devices don't work. > Dirk, do you have other environment on which you can run the tests? I will test under Ubuntu tonight. > > Thiago, do you have a dive computer with Bluetooth support? Do you > believe that you can help me with some tests? I can give Thiago such a dive computer, no problem. (Thiago is one of our surprisingly large number of key contributors who aren't actually divers...) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PATCH] OSTCTools - Add unsigned char variable
In commit 22bfc49 an explicit cast to (char *) was introduced to silence some compiler warnings, but an (unsigned char *) is needed if related values are expected to be greater than 127 or we will get the usual weirdnesses. Just introduce such variable and use it where needed. Signed-off-by: Salvador Cuñat --- ostctools.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/ostctools.c b/ostctools.c index 84af67d..45a21e9 100644 --- a/ostctools.c +++ b/ostctools.c @@ -67,7 +67,7 @@ void ostctools_import(const char *file, struct dive_table *divetable) FILE *archive; device_data_t *devdata = calloc(1, sizeof(device_data_t)); dc_family_t dc_fam; - unsigned char *buffer = calloc(65536, 1); + unsigned char *buffer = calloc(65536, 1), *uc_tmp; char *tmp; struct dive *ostcdive = alloc_dive(); dc_status_t rc = 0; @@ -85,18 +85,18 @@ void ostctools_import(const char *file, struct dive_table *divetable) } // Read dive number from the log - tmp = calloc(2,1); + uc_tmp = calloc(2, 1); fseek(archive, 258, 0); - fread(tmp, 1, 2, archive); - ostcdive->number = tmp[0] + (tmp[1] << 8); - free(tmp); + fread(uc_tmp, 1, 2, archive); + ostcdive->number = uc_tmp[0] + (uc_tmp[1] << 8); + free(uc_tmp); // Read device's serial number - tmp = calloc(2, 1); + uc_tmp = calloc(2, 1); fseek(archive, 265, 0); - fread(tmp, 1, 2, archive); - serial = tmp[0] + (tmp[1] << 8); - free(tmp); + fread(uc_tmp, 1, 2, archive); + serial = uc_tmp[0] + (uc_tmp[1] << 8); + free(uc_tmp); // Read dive's raw data, header + profile fseek(archive, 456, 0); -- 2.1.4 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
On Monday 06 July 2015 23:00:08 Claudiu Olteanu wrote: > Thiago, do you have a dive computer with Bluetooth support? Do you > believe that you can help me with some tests? No, I don't have one. I could probably borrow one from Dirk, but please don't expect a lot of availability to do debugging... /me goes back to reviewing IPv6 support for the IoT software -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
Hi, I wanted to let you know that after I did the firmware upgrade everything works fine. I tested both devices on all three environments (OpenSuse, Fedora, ArchLinux) and I didn't encounter any problem. Now we just have to figure out why Dirk's devices don't work. Dirk, do you have other environment on which you can run the tests? Thiago, do you have a dive computer with Bluetooth support? Do you believe that you can help me with some tests? Thanks, Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
On Monday 06 July 2015 17:42:00 Claudiu Olteanu wrote:
[mostly cut]
Hello Claudiiu
The patches look good. They do what we had discussed previously.
My comments are only nitpicks and suggestions for coding style in the future.
There's no need to change anything now.
> + bool on = !(mode == QBluetoothLocalDevice::HostPoweredOff);
That's slightly weird :-)
I can see how this can grow from having a !(x || y) and then you remove part
of the conditional.
> + QString deviceLable = QString("%1
> (%2)").arg(remoteDeviceInfo.name()).arg(remoteDeviceInfo.address().toString
> ());
Hint: QString has a "multiarg" arg that works on QStrings and is slightly
faster. If you remember, please use it next time.
QString("%1 (%2)").arg(emoteDeviceInfo.name(),
remoteDeviceInfo.address().toString());
The variable name is misspelt.
> +
> + // Check if the remote device is already in the list
> + if (itemsWithSameSignature.empty()) {
Hint: please use the Qt API for the containers. I had to look up to see if the
empty() function was a getter of the emptiness state or whether it emptied the
container.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
On Monday 06 July 2015 21:41:37 Claudiu Olteanu wrote: > libsubsurface_corelib.a(libdivecomputer.c.o): In function > `do_libdivecomputer_import': > /home/claudiu/gsoc/subsurface/libdivecomputer.c:930: undefined reference to > `dc_serial_qt_open' > > The method is declared as external "C" and is implemented in > qtserialbluetooth.cpp source. I don't know what changed from Qt 5.4.1 > version to Qt 5.5.0 because it worked before the Qt update. nm -C qtserialbluetooth.o Does it appear? Does it appear with () at the end? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
remove unused icons
So, I just send a bunch of icons for luisa so she can take a look at them
and save us
I found out those old icons laying around.
From 611a7d28f9b7647437e585036e2dba5949a11c93 Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava
Date: Mon, 6 Jul 2015 16:28:08 -0300
Subject: [PATCH] Removed unused icons
While looking for the icons so luisa could create svg
versions of them, I found out a few things that are not
used anymore.
Signed-off-by: Tomaz Canabrava
---
icons/planner/arrow_down.png | Bin 363 -> 0 bytes
icons/planner/arrow_up.png | Bin 471 -> 0 bytes
icons/planner/icon_depth.png | Bin 2022 -> 0 bytes
icons/planner/icon_time.png | Bin 1661 -> 0 bytes
icons/planner/left_wing.png | Bin 1965 -> 0 bytes
icons/planner/minus.png | Bin 262 -> 0 bytes
icons/planner/plus.png | Bin 301 -> 0 bytes
icons/planner/right_wing.png | Bin 1873 -> 0 bytes
icons/planner/round_base.png | Bin 2817 -> 0 bytes
subsurface.qrc | 9 -
10 files changed, 9 deletions(-)
delete mode 100644 icons/planner/arrow_down.png
delete mode 100644 icons/planner/arrow_up.png
delete mode 100644 icons/planner/icon_depth.png
delete mode 100644 icons/planner/icon_time.png
delete mode 100644 icons/planner/left_wing.png
delete mode 100644 icons/planner/minus.png
delete mode 100644 icons/planner/plus.png
delete mode 100644 icons/planner/right_wing.png
delete mode 100644 icons/planner/round_base.png
diff --git a/icons/planner/arrow_down.png b/icons/planner/arrow_down.png
deleted file mode 100644
index 462d7291a0518d264fb177f9adb19f12cc39f5d7..
GIT binary patch
literal 0
HcmV?d1
literal 363
zcmeAS@N?(olHy`uVBq!ia0vp^DL|aS!3-qttW_@nQY`6?zK#qG8~eHcB(ehe3dtTp
zz6=aistgPb%?u1b{{!il3=E|P3=FRl7#OT(FffScPl`Y422|@5;1lBd|Ns9vU@&dw
zYzPA@sg%|(lF+K0-jUxi#iF3Qeew+P#MY3S2|(?Kf4qGIG>xYu$S;^-i{f{shDMHi
zKK0&78>R;U#Tk>l-CYEalYaqsQL>%0vH
z0xTB~tF>?D{CnMNgA1!p{AVeNwbyuns(|4Cif7@f-7PzQC?Ab7UwTq?QgrO$U3Gh<
zv+r{%o8|2Oy^r_Qv9Et0*1d?+ckD?D;+j&$kcUva;y3_Ii5!AATz#OamCY|7F-
QNeRUFboFyt=akR{06HIp+W-In
diff --git a/icons/planner/arrow_up.png b/icons/planner/arrow_up.png
deleted file mode 100644
index d1da042000bab42332c231b239b0e7a554a9f292..
GIT binary patch
literal 0
HcmV?d1
literal 471
zcmeAS@N?(olHy`uVBq!ia0vp^DL|aS!3-qttW_@nQY`6?zK#qG8~eHcB(ehe3dtTp
zz6=aistgPb%?u1b{{!il3=E|P3=FRl7#OT(FffScPl`Y422?vCz$e7@|NsAUP{C|e
z?u=Qpr_VwW>zg*KXX;E;RZt$Xy8MnQx$RTbGCEY!J0j~RiX^l~)J>2|Zj(%Eb1m(4
zD(S83pDvovTHQCzAg4<|rweEV&@r`tSYh7ML)4P}_9j-bwTEAS
zt*uNcu;9Det6($NJ-IMt(#)s9xyrL*&#e30y6K@FclOkeUJ{Y_SA{RxrM~N!TJ4SK
mxp}D*?|#l+AI%6h=|>}5-Vu%h1<`x6L3~eFKbLh*2~7Yxp}l1Q
diff --git a/icons/planner/icon_depth.png b/icons/planner/icon_depth.png
deleted file mode 100644
index 08df4343cca955da1ecb4b43428c3e524e463d33..
GIT binary patch
literal 0
HcmV?d1
literal 2022
zcmZWo3pCVQ7yl#0)LpmL&D+H2wJO|iNEE&rW;BR=Dvu=3OTHq-aFgWyxEYa1-e08g
z9Ip_QA(6ZZVdR}@gFT6Mgs&9UNbv)k+iwFDG~VMpQ4*su?7A+v9gCfFB$kkJ+`#>%L0V(
z*7=~f#@8htN=A{bz(Y}m9>vYDlncono##5`y+vJ8LA0@XE=raS&K3M+p)?ef38sMo
z8bIkF8l*!5!GJxP!))-Pu0v5psLPJlfFh_1GD0}LcN{=S_iIc^>iZ!;5}O8qKz#ZN
z@;-Stkn(;IPTD&86=?gy^42&0ti?XJVQpihZE{vQx)_%7p?Pr){a|FYvd*P5jM8d~
zd&g>X#@sT4vWlF*oSV?#0dEx>nd^m0g$LJqn_eP!U|y1>nj$AH*=VMj{v%`pgh)5(~Zv`tma=6
z>Ej%4{J~Z0Q&}BTI1y3Z9j|JR@k2!`l
zy136R>XR5=(7HtQoyOaKgrk?j#hn-!Gm^YVa7#k={^UGb;(u%va{_a<7=8vCNp4e0
z(~`fNWw{hy$+l>h{n_3@^%p#y8bO)qS(Y1Tc%((p+*Lb^3nJRqEN1OOZTdQiy2fr~
z5uH-OOF@{YM_NpH=`K0eJ1R|%^;yY>YUs8&&~LD(XK#D*gHm5lXO+tp!k1s(sK;Vw
zMSB=B$u0QH+PZH0^9sw1wJkLV^!$gfuwH3ZN*JXat|)x2IM*H2g2if6=AYg5p>T$C
zj}3EzDf)MhkbReSm$}kkytdA$J(Yb^VPwILo-WLJIBy;+WG*4ma^^*(xDEcP2So%ugWt7_uX1nH)f5uqRv7k!GK_F*xStYkq{
z_VrURwUJJ=HY8YG^f5dBqvcY5kjC|oMM4&IoAUo6LDn1SupRnz_jbkW^<@RE;?1#+Mbv5B*R2DZ5U-
zI_b028rQJ6t0^W!>(0#5Q)ZmH>-jVt-z)R2pH`FTk<^;ZZt>&?w@Owdy$qMH|Cj%H
z!Lq!{Po=(1d3@;7HM&1@A3Z{9{%!VDo1Er_z{e??BL@#3oZ-+zf+#bEtkVI*wF%Wd
hX9S$1TVvBUKzJHs@2Rv4FA0wjF(jE1i}dV+{|^y_LvR29
diff --git a/icons/planner/icon_time.png b/icons/planner/icon_time.png
deleted file mode 100644
index 618cb6cf9f06683488cbaeca693d96044b4a065e..
GIT binary patch
literal 0
HcmV?d1
literal 1661
zcmah|c{J2p9RE>HFr
z2roq8Wy>zhShCDw7{eG_GYm5CYR>8X`R@7M@A|pl?cN^&HTJp-@P*IsgBkt-&6~)=)&jDbW&4jB<#Nw%II^I)gy~feJSi
zshsq`X!ge68f$?{b1+#gFA{l0>DKH2W?Z$}Vo*27DKw-JFp6MHnMpuct9c77K&CsH
zZ4Q6gJ7{aTNg0^+#{hYoHOusJ;-n^kAb`@*=G@#&fCqHBC`S|@&>1We6aXws&r+G5
zP7DlUwQR2jZgv`|P4IPOW1yGrYz~k#Q7}$9o&Adys`v;J7nEEvm1f7ixPKWG7*+L~o7kyF^QAz+4}Y;YHQUBeBT-p*^)WxTc~#x?72
z4K-lYpni~OW1xqdlg@pf&LI(a?Vng7J|IPncT7BZV%d1Kqca2@a7=5S-%%y4NGEOU
zPa!vZAA305;-$ebse%fXM~vN|)LqPXAEki&x==b!OR%lLuHJIa!>;94Y1T5?>+^#5
z^0i5_D6RDmiNSXHEZ@K%lphFeHR}zDg7-%OYfJ|4)6h?
zu^4HFzMulRy@A>6O>qpIB5Ws-RvbY^g=%NSL6u@&cD7bfqJ#<@C{jUiw@?U@KDxKX
zpzIt42-+uwurj~mH@!q=d)PZEd|oaqeHA@g5IxjPf*nz}Ye(nHsjHLZo!*uBQ8mk&
zx}Xf0XL3
Re: [GSoC] Week 6 (Native Bluetooth support)
Sorry for the late response but I decided to try again to compile the Subsurface project with Qt 5.5.0. After I read carefully the log messages I find out what caused the problem. Apparently the headers from two libraries were missing (mesa-libGL-devel and libdrm-devel). Now I receive an undefined reference to my "dc_serial_qt_open" method: libsubsurface_corelib.a(libdivecomputer.c.o): In function `do_libdivecomputer_import': /home/claudiu/gsoc/subsurface/libdivecomputer.c:930: undefined reference to `dc_serial_qt_open' The method is declared as external "C" and is implemented in qtserialbluetooth.cpp source. I don't know what changed from Qt 5.4.1 version to Qt 5.5.0 because it worked before the Qt update. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On Tue, Jul 07, 2015 at 03:53:35AM +1000, Rick Walsh wrote: > Our local sea conditions change rapidly. Frequently, the scheduled dive > site is altered an hour before the boat leaves. Or a boat is cancelled > because not enough people booked onto it. Either way, much of the time we > end up diving a different site than what we planned when we left home. Now > our original plan isn't valid anymore. > > So, it would be a killer app feature from my point of view too. In fact, > I've been considering paying for a commercial app that does this. Cool. Thanks for the input. So yes, we'll add that. Save you some money. You can make up for it by testing and contributing and reviewing :-) > > Excellent. That's why I said "I simply don't know" :-) > > Thanks for the concrete examples. So let's figure out how a UI for that > > should look. > > > > > I would just love a simple planner. > > > > > > For me it could be as simple as: > > > > > > Depth, time, gas, deco-gasses, and it just does drop-stone-mode and > > > gives me whatever is in the "Dive plan details" view. > > This is all I'd want most of the time. Quick and easy to use and copy to > wet notes. Excellent. That should be doable. > > > ( I even might wire it up myself, now when i think about it =) > > > > That's of course always a good idea. The more people figure out how to > > work on the QML interfaces, the better. > > > > But if I may share my personal list of priorities (and even if you don't > > want me to, how would you stop me?): > > > > Anton: > > > > 1) get us back to be be able to build an APK > > 2) do some testing of what we have for VPM / planner - any red flags? > > 3) anything else > > > > Grace: > > > > 1) profile support > > 2) download dialog using BT > > 3) more gestures for a more natural UI > > 4) testing on Android > > 5) anything else > > I assume it wasn't part of the original intended GSOC scope, and extra > mid-way feature requests are a great way to get off track. It would be > great if someone can implement it. And thanks Anton for volunteering. But > I agree the focus should be getting a working and tested Subsurface app > first. Yes, I don't want Grace to get distracted by this - much as I love the vocal tech divers... we have more than 5k users and my guess is we'll get quite a few more for an Android app. And dive planning may not be the #1 feature they are looking for. So yes, I definitely support adding this and given the infrastructure that we have it shouldn't be too hard to do so. But one thing at a time. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On 7 Jul 2015 1:55 am, "Dirk Hohndel" wrote: > > On Mon, Jul 06, 2015 at 05:27:45PM +0200, Anton Lundin wrote: > > > > Also a simple ui for the planner would be on my wishlist =) > > > > > > Not so sure about this one. There are so many options plus the smaller > > > screen size. And you can't print. Would people REALLY use that instead of > > > doing this on a real computer? Or would this be more something that one > > > looked at once, said "cool" but then never actually used? > > > > > > I simply don't know. I find it hard to imagine that a serious tech dive > > > would plan a dive on their phone and then copy it from there to their > > > slate or something. But then, I'm not a serious tech diver, so I could be > > > completely wrong and that would be the killer app everyone wants. > > > > > > > Me and my dive team do it all the time. > > > > We quite frequently run numbers on different gases, depth, time, deco > > gas, whatever on our cell's just to figure out what we can/should do for > > sort of dive. > > > > Eg, We do a 55m dive on 21/35, can we deco 50% or will it take to long > > time in the cold water so we need to bring the o2 along. > > > > Will my 100 bar AL80 with 50% do, or do i need more gas? Our local sea conditions change rapidly. Frequently, the scheduled dive site is altered an hour before the boat leaves. Or a boat is cancelled because not enough people booked onto it. Either way, much of the time we end up diving a different site than what we planned when we left home. Now our original plan isn't valid anymore. So, it would be a killer app feature from my point of view too. In fact, I've been considering paying for a commercial app that does this. > > Excellent. That's why I said "I simply don't know" :-) > Thanks for the concrete examples. So let's figure out how a UI for that > should look. > > > I would just love a simple planner. > > > > For me it could be as simple as: > > > > Depth, time, gas, deco-gasses, and it just does drop-stone-mode and > > gives me whatever is in the "Dive plan details" view. This is all I'd want most of the time. Quick and easy to use and copy to wet notes. > > > > ( I even might wire it up myself, now when i think about it =) > > That's of course always a good idea. The more people figure out how to > work on the QML interfaces, the better. > > But if I may share my personal list of priorities (and even if you don't > want me to, how would you stop me?): > > Anton: > > 1) get us back to be be able to build an APK > 2) do some testing of what we have for VPM / planner - any red flags? > 3) anything else > > Grace: > > 1) profile support > 2) download dialog using BT > 3) more gestures for a more natural UI > 4) testing on Android > 5) anything else I assume it wasn't part of the original intended GSOC scope, and extra mid-way feature requests are a great way to get off track. It would be great if someone can implement it. And thanks Anton for volunteering. But I agree the focus should be getting a working and tested Subsurface app first. Cheers, Rick ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] libdivecomputer - Subsurface-testing branch
On Monday 06 July 2015 08:20:19 Dirk Hohndel wrote: > Pull requests have advantages for GSoC purposes as they make it much > easier for me to ask the mentor to go through them, sign off on the > patches and then I can pull them. But as Lubomir said, that's optional. And I've just reviewed, but the patches don't have the Signed-off-by. If Dirk wants, I can merge them to my tree with my sign-off and then send the pull request. Same question to Jef. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
GSoC Status - Week 6 (VPM-B)
Hi! This week I spent mostly on testing and refactoring my commits. I also started the promised article and checked how the Boyle's law compensation should work. I still haven't discovered where some of the result differences come from, I want to finish it this week but it's hard to predict how much time it will take. I will also implement Boyle's law compensation and finish the algorithm's description. Then the great testing will come but it will probably the next week. -- Jan Darowski ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
> > Actually, here's one. The fake open function for the OSTC 2N. That could > have been its own commit, added before the next commit that adds all the > qtserialbluetooth stuff. That's a simple example, but maybe it illustrates > what I mean. > It is funny that in the beginning I did an isolated commit for that. In the end I thought that it would be better to separate the patches in three groups: - changes on the current UI - implementation of the selection dialog - implementation of our custom serial communication I know that some of them contain too many lines of code but I thought that it would be easier to group them by their main scope. > I won't ask you to refactor the commits because I don't think there's > anything wrong in what you did. Just something to look into for the > future. > > I will try to use a high degree of granularity for the commits in the future. Thanks for your feedback! Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On Mon, Jul 06, 2015 at 05:27:45PM +0200, Anton Lundin wrote: > > > Also a simple ui for the planner would be on my wishlist =) > > > > Not so sure about this one. There are so many options plus the smaller > > screen size. And you can't print. Would people REALLY use that instead of > > doing this on a real computer? Or would this be more something that one > > looked at once, said "cool" but then never actually used? > > > > I simply don't know. I find it hard to imagine that a serious tech dive > > would plan a dive on their phone and then copy it from there to their > > slate or something. But then, I'm not a serious tech diver, so I could be > > completely wrong and that would be the killer app everyone wants. > > > > Me and my dive team do it all the time. > > We quite frequently run numbers on different gases, depth, time, deco > gas, whatever on our cell's just to figure out what we can/should do for > sort of dive. > > Eg, We do a 55m dive on 21/35, can we deco 50% or will it take to long > time in the cold water so we need to bring the o2 along. > > Will my 100 bar AL80 with 50% do, or do i need more gas? Excellent. That's why I said "I simply don't know" :-) Thanks for the concrete examples. So let's figure out how a UI for that should look. > I would just love a simple planner. > > For me it could be as simple as: > > Depth, time, gas, deco-gasses, and it just does drop-stone-mode and > gives me whatever is in the "Dive plan details" view. > > ( I even might wire it up myself, now when i think about it =) That's of course always a good idea. The more people figure out how to work on the QML interfaces, the better. But if I may share my personal list of priorities (and even if you don't want me to, how would you stop me?): Anton: 1) get us back to be be able to build an APK 2) do some testing of what we have for VPM / planner - any red flags? 3) anything else Grace: 1) profile support 2) download dialog using BT 3) more gestures for a more natural UI 4) testing on Android 5) anything else Obviously this is an open source project so you can work on what you would like to work on. Please don't take this the wrong way. I'm just trying to make sure we get the pieces we need in place :-) Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
Hi CLaudiu On Mon, Jul 06, 2015 at 05:42:00PM +0300, Claudiu Olteanu wrote: > Hi there, > > I attached you some patches which add the QtBluetooth serial implementation. > The Bluetooth download mode is accessible from the DownloadFromDiveComputer > widget. > > In order to connect to a Bluetooth device I decided to remove the SDP > discovery because > it doesn't work for all devices. For the moment I try to connect to the > device using the RFCOMM > channel 1 because this is the default channel of the SPP service for most > devices. > If this doesn't work I try again on RFCOMM channel number 5 (for Petrel2 > devices). Thanks for sending a strong set of patches. There is always this question of "what level of granularity is right for commits". It's good not to show all steps of development. So don't add things just to delete them in the next commit, etc. But it's also good to try to make the commits fairly small so they are easy to read, they ideally do just one thing and are incremental. I have no simple rule and no simple tool that will tell you the right way to do this (and different maintainers actually have different preferences). To me a couple of your patches felt a little big, adding quite a few things at once. I could have seen ways to split them into smaller, self contained parts. But it's really hard for me to come up with a concrete example that says "look, here, this is how it should be done". Actually, here's one. The fake open function for the OSTC 2N. That could have been its own commit, added before the next commit that adds all the qtserialbluetooth stuff. That's a simple example, but maybe it illustrates what I mean. I won't ask you to refactor the commits because I don't think there's anything wrong in what you did. Just something to look into for the future. > The last patch is not mandatory. It adds some extra logs which can be > useful for > debugging. I took the last patch as well as I hope that others here on the list with BT devices will help test the implementation and I'm guessing that we will always want the more verbose output. We can remove these later when we have it all working as expected. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] libdivecomputer - Subsurface-testing branch
On Mon, Jul 06, 2015 at 05:33:00PM +0300, Claudiu Olteanu wrote: > Hi, > > These patches create a generic way to represent any type of serial > communication. They are used to create a custom serial implementation > for HW_OSTC3 and SHEARWATER families. This looks good to me. I'll add these to our Subsurface-testing branch Thanks for your great work on this! /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On 06 July, 2015 - Dirk Hohndel wrote: > On Mon, Jul 06, 2015 at 09:47:42AM +0200, Anton Lundin wrote: > > > Also a simple ui for the planner would be on my wishlist =) > > Not so sure about this one. There are so many options plus the smaller > screen size. And you can't print. Would people REALLY use that instead of > doing this on a real computer? Or would this be more something that one > looked at once, said "cool" but then never actually used? > > I simply don't know. I find it hard to imagine that a serious tech dive > would plan a dive on their phone and then copy it from there to their > slate or something. But then, I'm not a serious tech diver, so I could be > completely wrong and that would be the killer app everyone wants. > Me and my dive team do it all the time. We quite frequently run numbers on different gases, depth, time, deco gas, whatever on our cell's just to figure out what we can/should do for sort of dive. Eg, We do a 55m dive on 21/35, can we deco 50% or will it take to long time in the cold water so we need to bring the o2 along. Will my 100 bar AL80 with 50% do, or do i need more gas? Our plans change all the time, and we always iterate our plans in the team and just try to figure out what works today. I've used multideco on android quite a bit, and sometimes the planner on my OSTC 3. Right now the OSTC 3 is getting support for calculating gas usage which is quite important, but its still a bit clumsy to iterate different plans on. A whole touch screen is better input than a two-button-interface. I would just love a simple planner. For me it could be as simple as: Depth, time, gas, deco-gasses, and it just does drop-stone-mode and gives me whatever is in the "Dive plan details" view. ( I even might wire it up myself, now when i think about it =) //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] libdivecomputer - Subsurface-testing branch
On Mon, Jul 06, 2015 at 06:17:02PM +0300, Claudiu Olteanu wrote: > Hi Lubomir, > > Thanks for the info! > > Yeah, probably I shouldn't named the thread "PULL REQUEST". > > Since these are the differences between my repository > and the Subsurface' one, I thought that the process is similar > with a pull request. > > Also I knew that Dirk prefers patches instead of pull requests. :-) In general that is correct. In the normal flow of Subsurface development I tend to prefer patches... but as I said, there is a very nice way to use pull requests (and Gehand and Lubomir are using that for their GSoC student / mentor collaboration). So in summary: either is fine. Usually I gravitate towards patches, but especially for GSoC having pull requests go through the mentors tree is fine as well. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] libdivecomputer - Subsurface-testing branch
On Mon, Jul 06, 2015 at 06:07:02PM +0300, Lubomir I. Ivanov wrote: > On 6 July 2015 at 17:33, Claudiu Olteanu > wrote: > > Hi, > > > > These patches create a generic way to represent any type of serial > > communication. They are used to create a custom serial implementation > > for HW_OSTC3 and SHEARWATER families. > > > > hey, Claudiu. > > just to point out that if you attach the patches in the email, it's > not a git pull-request. but AFAIK, pull-requests are not mandatory for > GSoC. Both true. I prefer emails with patches to have [PATCH] in their subject because that makes it much easier for me to find them. Pull requests have advantages for GSoC purposes as they make it much easier for me to ask the mentor to go through them, sign off on the patches and then I can pull them. But as Lubomir said, that's optional. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] libdivecomputer - Subsurface-testing branch
Hi Lubomir, Thanks for the info! Yeah, probably I shouldn't named the thread "PULL REQUEST". Since these are the differences between my repository and the Subsurface' one, I thought that the process is similar with a pull request. Also I knew that Dirk prefers patches instead of pull requests. Claudiu ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PULL REQUEST] libdivecomputer - Subsurface-testing branch
On 6 July 2015 at 17:33, Claudiu Olteanu wrote: > Hi, > > These patches create a generic way to represent any type of serial > communication. They are used to create a custom serial implementation > for HW_OSTC3 and SHEARWATER families. > hey, Claudiu. just to point out that if you attach the patches in the email, it's not a git pull-request. but AFAIK, pull-requests are not mandatory for GSoC. a pull-request means that you have a repository somewhere (e.g. github) and you want to notify the maintainers to review the code and pull: http://git-scm.com/docs/git-request-pull lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
[PULL REQUEST] Subsurface branch - QtBluetooth serial implementation
Hi there,
I attached you some patches which add the QtBluetooth serial implementation.
The Bluetooth download mode is accessible from the DownloadFromDiveComputer
widget.
In order to connect to a Bluetooth device I decided to remove the SDP
discovery because
it doesn't work for all devices. For the moment I try to connect to the
device using the RFCOMM
channel 1 because this is the default channel of the SPP service for most
devices.
If this doesn't work I try again on RFCOMM channel number 5 (for Petrel2
devices).
The last patch is not mandatory. It adds some extra logs which can be
useful for
debugging.
Claudiu
From 031f1ffaff034b725253994bf0fe5b4c3c296c08 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu
Date: Mon, 6 Jul 2015 16:18:06 +0300
Subject: [PATCH 1/4] Add a checkbox and a button for Bluetooth download mode
The checkbox will be used to enable the Bluetooth
downloading mode. The button will be used to create
a dialog selection where the user will be able to
scan and select remote devices.
Signed-off-by: Claudiu Olteanu
---
qt-ui/downloadfromdivecomputer.cpp | 19 +++
qt-ui/downloadfromdivecomputer.h | 2 ++
qt-ui/downloadfromdivecomputer.ui | 17 +
3 files changed, 38 insertions(+)
diff --git a/qt-ui/downloadfromdivecomputer.cpp b/qt-ui/downloadfromdivecomputer.cpp
index c5d57e6..f1bb058 100644
--- a/qt-ui/downloadfromdivecomputer.cpp
+++ b/qt-ui/downloadfromdivecomputer.cpp
@@ -99,6 +99,9 @@ DownloadFromDCWidget::DownloadFromDCWidget(QWidget *parent, Qt::WindowFlags f) :
ui.ok->setEnabled(false);
ui.downloadCancelRetryButton->setEnabled(true);
ui.downloadCancelRetryButton->setText(tr("Download"));
+ ui.chooseBluetoothDevice->setEnabled(ui.bluetoothMode->isChecked());
+ connect(ui.bluetoothMode, SIGNAL(stateChanged(int)), this, SLOT(enableBluetoothMode(int)));
+ connect(ui.chooseBluetoothDevice, SIGNAL(clicked()), this, SLOT(selectRemoteBluetoothDevice()));
}
void DownloadFromDCWidget::updateProgressBar()
@@ -493,6 +496,8 @@ void DownloadFromDCWidget::markChildrenAsDisabled()
ui.chooseDumpFile->setEnabled(false);
ui.selectAllButton->setEnabled(false);
ui.unselectAllButton->setEnabled(false);
+ ui.bluetoothMode->setEnabled(false);
+ ui.chooseBluetoothDevice->setEnabled(false);
}
void DownloadFromDCWidget::markChildrenAsEnabled()
@@ -512,6 +517,20 @@ void DownloadFromDCWidget::markChildrenAsEnabled()
ui.chooseDumpFile->setEnabled(true);
ui.selectAllButton->setEnabled(true);
ui.unselectAllButton->setEnabled(true);
+ ui.bluetoothMode->setEnabled(true);
+ ui.chooseBluetoothDevice->setEnabled(true);
+}
+
+void DownloadFromDCWidget::selectRemoteBluetoothDevice()
+{
+ //TODO add implementation
+}
+
+void DownloadFromDCWidget::enableBluetoothMode(int state)
+{
+ ui.chooseBluetoothDevice->setEnabled(state == Qt::Checked);
+ if (state == Qt::Checked)
+ selectRemoteBluetoothDevice();
}
static void fillDeviceList(const char *name, void *data)
diff --git a/qt-ui/downloadfromdivecomputer.h b/qt-ui/downloadfromdivecomputer.h
index 92db09d..0b63d28 100644
--- a/qt-ui/downloadfromdivecomputer.h
+++ b/qt-ui/downloadfromdivecomputer.h
@@ -77,8 +77,10 @@ slots:
void updateProgressBar();
void checkLogFile(int state);
void checkDumpFile(int state);
+ void enableBluetoothMode(int state);
void pickDumpFile();
void pickLogFile();
+ void selectRemoteBluetoothDevice();
private:
void markChildrenAsDisabled();
diff --git a/qt-ui/downloadfromdivecomputer.ui b/qt-ui/downloadfromdivecomputer.ui
index ff80935..f232967 100644
--- a/qt-ui/downloadfromdivecomputer.ui
+++ b/qt-ui/downloadfromdivecomputer.ui
@@ -116,6 +116,23 @@
+
+
+
+Choose Bluetooth Download mode
+
+
+
+
+
+
+Select a remote Bluetooth device.
+
+
+...
+
+
+
--
2.1.4
From 87b3607918d1c21be650c7cad1ba4c740bd537ef Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu
Date: Mon, 6 Jul 2015 16:35:13 +0300
Subject: [PATCH 2/4] Add a dialog for remote Bluetooth devices selection
Implement a dialog which can be used for remote Bluetooth devices
selection and to control the local Bluetooth device.
Functionalities of the widget:
- expose information about the local BT device
- scan for remote BT devices
- pair/unpair with a remote BT device
- turn on/off the local BT device
- logging
- save the selected BT device
The selection dialog is created when the bluetoothMode checkbox
is enabled.
Signed-off-by: Claudiu Olteanu
---
CMakeLists.txt | 5 +-
libdivecomputer.h | 1 +
qt-ui/btdeviceselectiondialog.cpp | 261 +
qt-ui/btdeviceselectiondialog.h| 46 +++
qt-ui/btdeviceselectiondialog.ui | 214 ++
qt-ui/downloadfromdivecomp
[PULL REQUEST] libdivecomputer - Subsurface-testing branch
Hi,
These patches create a generic way to represent any type of serial
communication. They are used to create a custom serial implementation
for HW_OSTC3 and SHEARWATER families.
Claudiu
From 05d830371f2bce35820bebb7419ed27946b3a658 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu
Date: Sat, 27 Jun 2015 15:11:15 +0300
Subject: [PATCH 1/7] Extend the transport enum descriptor for serial
communication
Add a new transport type which can be used to identify
Bluetooth serial communication.
Signed-off-by Claudiu Oleanu
---
include/libdivecomputer/descriptor.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/libdivecomputer/descriptor.h b/include/libdivecomputer/descriptor.h
index 6f9735d..f1c815d 100644
--- a/include/libdivecomputer/descriptor.h
+++ b/include/libdivecomputer/descriptor.h
@@ -33,7 +33,8 @@ typedef enum dc_transport_t {
DC_TRANSPORT_NONE,
DC_TRANSPORT_SERIAL,
DC_TRANSPORT_USB,
- DC_TRANSPORT_IRDA
+ DC_TRANSPORT_IRDA,
+ DC_TRANSPORT_BLUETOOTH
} dc_transport_t;
typedef struct dc_descriptor_t dc_descriptor_t;
--
2.1.4
From b4092f3b4b04f9b31097f6c79b2e1cdafcaf5a06 Mon Sep 17 00:00:00 2001
From: Claudiu Olteanu
Date: Sat, 27 Jun 2015 15:14:16 +0300
Subject: [PATCH 2/7] Create a generic way to represent any type of serial
communication
Add a structure which holds references to basic operations
on a serial communication. This can be used to pass a set
of function pointer callbacks in order to create a custom
implementation for serial communication.
Add a generic structure to represent the needed information
for a serial communication.
Implement the initialization method where the user can
pass a set of function pointer callbacks and set some
custom data for the serial device.
Create open method for the native serial implementation.
Signed-off-by: Claudiu Olteanu
---
include/libdivecomputer/Makefile.am | 3 +-
include/libdivecomputer/custom_serial.h | 63 ++
src/Makefile.am | 3 +-
src/custom_serial.c | 79 +
4 files changed, 146 insertions(+), 2 deletions(-)
create mode 100644 include/libdivecomputer/custom_serial.h
create mode 100644 src/custom_serial.c
diff --git a/include/libdivecomputer/Makefile.am b/include/libdivecomputer/Makefile.am
index 71887d5..a0ed196 100644
--- a/include/libdivecomputer/Makefile.am
+++ b/include/libdivecomputer/Makefile.am
@@ -53,4 +53,5 @@ libdivecomputer_HEADERS = \
citizen.h \
citizen_aqualand.h \
divesystem.h \
- divesystem_idive.h
+ divesystem_idive.h \
+ custom_serial.h
diff --git a/include/libdivecomputer/custom_serial.h b/include/libdivecomputer/custom_serial.h
new file mode 100644
index 000..a52d49b
--- /dev/null
+++ b/include/libdivecomputer/custom_serial.h
@@ -0,0 +1,63 @@
+/*
+ * libdivecomputer
+ *
+ * Copyright (C) 2015 Claudiu Olteanu
+ * base on code that is Copyright (C) 2008 Jef Driesen
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef CUSTOM_SERIAL_H
+#define CUSTOM_SERIAL_H
+
+#include
+#include
+
+#include "context.h"
+#include "descriptor.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+typedef struct serial_t serial_t;
+
+typedef struct dc_serial_operations_t
+{
+ int (*open) (serial_t **device, dc_context_t *context, const char *name);
+ int (*close) (serial_t *device);
+ int (*read) (serial_t *device, void* data, unsigned int size);
+ int (*write) (serial_t *device, const void* data, unsigned int size);
+ int (*flush) (serial_t *device, int queue);
+ int (*get_received) (serial_t *device);
+ int (*get_transmitted) (serial_t *device);
+} dc_serial_operations_t;
+
+typedef struct dc_serial_t {
+ serial_t *port;//serial device port
+ dc_transport_t type; //the type of the transport (USB, SERIAL, IRDA, BLUETOOTH)
+ void *data;//specific data for serial device
+ const dc_serial_operations_t *ops; //reference to a custom set of operations
+} dc_serial_t;
+
+void dc_serial_init(dc_serial_t *device, void *data, const dc_serial_operations_t *ops);
+
+dc_status_t dc_serial_native_open(dc_serial_t **serial, dc_context_t *context, const char *devname);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+#endif /* CUSTOM_SERIAL_H */
diff --git a/sr
Re: dive plan test
> On 06 Jul 2015, at 15:51, Dirk Hohndel wrote:
>
> On Mon, Jul 06, 2015 at 06:36:58AM -0700, Dirk Hohndel wrote:
>>
>> I seem to get 107 with the latest build. 9/9/9/3 m/min for ascent.
>> GF 100/100
>> last stop at 6
>> drop down to depth and 30 minutes at 79m
>> 0 min minimum switch duration
>>
>> depth duration runtime gas
>> 79m 3min 3min (15/45)
>> 79m 27min 30min
>> 33m 5min 35min EAN38
>
I have to look again at your numbers, but for the number in this patch I get
agreement with the dives I compute in the UI (as attached).
Best
Robert
From 49b27d7f113155679bd46cb152656f54d695c29f Mon Sep 17 00:00:00 2001
From: "Robert C. Helling"
Date: Mon, 6 Jul 2015 15:44:05 +0200
Subject: [PATCH] Fix typo in test and some numbers
With these values I reproduce the runtimes from the UI.
Signed-off-by: Robert C. Helling
---
tests/testplan.cpp | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/testplan.cpp b/tests/testplan.cpp
index 8fa0921..88f1366 100644
--- a/tests/testplan.cpp
+++ b/tests/testplan.cpp
@@ -4,6 +4,8 @@
#include "units.h"
#include
+#define DEBUG 1
+
// testing the dive plan algorithm
extern bool plan(struct diveplan *diveplan, char **cached_datap, bool
is_planner, bool show_disclaimer);
@@ -15,12 +17,11 @@ void setupPrefs()
prefs.ascratestops = prefs.ascrate50;
prefs.ascratelast6m = feet_to_mm(10) / 60;
prefs.last_stop = true;
-
}
void setupPlan(struct diveplan *dp)
{
- dp->salinity = 10030;
+ dp->salinity = 10300;
dp->surface_pressure = 1013;
dp->gfhigh = 100;
dp->gflow = 100;
@@ -77,7 +78,7 @@ void TestPlan::testMetric()
QCOMPARE(ev->value, 100);
QCOMPARE(get_depth_at_time(&displayed_dive.dc, ev->time.seconds), 6000);
// check expected run time of 105 minutes
- QCOMPARE(displayed_dive.dc.duration.seconds, 104u * 60u);
+ QCOMPARE(displayed_dive.dc.duration.seconds, 108u * 60u);
}
void TestPlan::testImperial()
@@ -113,7 +114,7 @@ void TestPlan::testImperial()
QCOMPARE(ev->value, 100);
QCOMPARE(get_depth_at_time(&displayed_dive.dc, ev->time.seconds), 6096);
// check expected run time of 105 minutes
- QCOMPARE(displayed_dive.dc.duration.seconds, 105u * 60u);
+ QCOMPARE(displayed_dive.dc.duration.seconds, 110u * 60u - 2u);
}
QTEST_MAIN(TestPlan)
--
1.9.5 (Apple Git-50.3)
testdiveimperial2.xml
Description: XML document
testdivemetric2.xml
Description: XML document
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: dive plan test
On Mon, Jul 06, 2015 at 06:36:58AM -0700, Dirk Hohndel wrote: > > I seem to get 107 with the latest build. 9/9/9/3 m/min for ascent. > GF 100/100 > last stop at 6 > drop down to depth and 30 minutes at 79m > 0 min minimum switch duration > > depth duration runtime gas > 79m 3min 3min (15/45) > 79m 27min 30min > 33m 5min 35min EAN38 Grr, did EAN38 again. Stupid fingers. imperial with 30/30/30/10/75 ft/min GF 100/100 last stop at 20 0 min min switch depth duration runtime gas 260ft 3min 3min (15/45) 260ft 27min 30min 110ft 6min 36min EAN36 90ft 2min 37min 80ft 2min 39min 70ft 3min 42min 60ft 4min 46min 50ft 6min 52min 40ft 8min 60min 30ft 13min 73min 20ft 35min 108min oxygen 0ft 2min 110min CNS: 109% OTU: 164 and then this is with 9/9/9/3/23 m/min GF 100/100 last stop at 6m 0 min min depth duration runtime gas 79m 3min 3min (15/45) 79m 27min 30min 33m 5min 35min EAN36 27m 2min 37min 24m 2min 39min 21m 3min 42min 18m 4min 46min 15m 5min 51min 12m 8min 59min 9m 12min 71min 6m 35min 106min oxygen 0m 2min 108min CNS: 109% OTU: 162 I think this might need a little bit more work to understand what causes the tiny fluctuations from the UI. My bet is that if we save those dives and look at the exact times for the different samples we'll see the small changes as the UI possibly shows rounded values somewhere... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MOD of oxygen at pO2 of 1.6 is 20ft
On Mon, Jul 06, 2015 at 09:56:20AM -0300, Rodrigo Severo wrote: > On Mon, Jul 6, 2015 at 4:24 AM, Henrik Brautaset Aronsen > wrote: > > > > On Sun, Jul 5, 2015 at 11:03 PM, Rick Walsh wrote: > >> > >> Serious question: does anyone switch to 50% at 22m? > > > > > > For tank MOD markings around me usually round to the nearest 3 (meters). > > So 21 meters (not 22) for 50% and 6 meters (not 5) for o2. Etc. Also to > > the nearest 10ft. > > I dive metric, my stops are all multiple of 3 m and my tanks have the > real MODs, not rounded ones, as I understand MODs as maximum operation > depth, not mandatory other-gas depth ;) But obviously I understand > that having the MOD equal to some deco stop might seems less > confusing. Thanks for the data points. > Truncating sounds more conservative but actually I bet that if your > dive plan gets unsafe because of half a meter on a deco stop or worst > half a foot you have other problems not rounding related so rounding > seems to me as the right thing to do. I completely agree. And as I said, the important reason to switch to rounding was to get Oxygen at 20ft - I think we can all agree that that's the common practice. I don't know of any tech diver who thinks that they can't switch to O₂ at 20ft. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: dive plan test
On Mon, Jul 06, 2015 at 01:00:54PM +0200, Robert C. Helling wrote: > Dirk, > > > On 05 Jul 2015, at 20:47, Dirk Hohndel wrote: > > > > Thank you. Much appreciated. I'm reasonably certain that I'm just missing > > some setting that gets set up in the full app but does not get set up in > > TestPlanner. > > I found three things: > > 1) I think most important: you have a typo in the salinity: > > - dp->salinity = 10030; > + dp->salinity = 10300; :facepalm: > 2) What is your descent rate? It seems to be 23m/min but you don’t set this. > > + prefs.descrate = 23000/60; I don't use the descent rate at all. I manually set the first point if you look at the setup function. > 3) What is the value you are aiming for? The UI version of subsurface seems > to come up with a 108min dive, doesn’t it. So I would say > > - QCOMPARE(displayed_dive.dc.duration.seconds, 104u * 60u); > + QCOMPARE(displayed_dive.dc.duration.seconds, 108u * 60u); I seem to get 107 with the latest build. 9/9/9/3 m/min for ascent. GF 100/100 last stop at 6 drop down to depth and 30 minutes at 79m 0 min minimum switch duration depth duration runtime gas 79m 3min 3min (15/45) 79m 27min 30min 33m 5min 35min EAN38 27m 2min 37min 24m 2min 39min 21m 3min 42min 18m 4min 46min 15m 5min 51min 12m 7min 58min 9m 12min 70min 6m 35min 105min oxygen 0m 2min 107min But I get 108 in imperial :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On Mon, Jul 06, 2015 at 11:55:38AM +0300, Grace Karanja wrote: > On Mon, Jul 6, 2015 at 1:51 AM, Dirk Hohndel wrote: > > Things looks nice, great progress. Styling is a bit off on my display (text > > seems to be too close to the bottom of the surrounding box) but it's quite > > usable already. It's just so cool when you add your credentials and it > > simply shows all your dives... > > Thanks. I am working on improving the UI issues. Once I have a dive profile > in place, I should be able to implement some swipe gestures. Good. > > That will be cool. I am really happy how close to useful this is already - > > and we only at about half time of the project! > > > > > and > > > - Spend time on improving Android compilation. As the app has only been > > tested > > > on desktop, we will need to run it on Android for better testing. > > > > Definitely. Please keep asking Anton(glance) to help you there. Worst case > > I can try and dig into what I can find... I don't consider fixing the > > cmake problem part of your GSoC tasks and don't want you to have to waste > > too much time on this. > > > > > All of the work done so far is on my GitHub repository. > > > > I pulled from there to play with things. I'm not quite ready to pull this > > into master because there seems to be too much redundant code movements. > > One patch moves code here, the next patch moves it there. > > One patch comments out code, the next patch remove the comment. > > Several patches have incremental changes to the same file. > > > > I know that you have used git rebase -i in the past. I'd really like to > > see you combine some of these commits so the series of patches becomes > > more structured and goes reasonably straight to the end result. > > > > From a commit message point of view I think you are doing well. One thing > > that would be nice would be a "tag" in the commit title. For example if > > all of the commits that deal with the QML UI started with "QML UI:" and > > continued in lower case. Something like > > > > QML UI: implement saving dives in the cloud > > Thanks...I will redo the commits in this format :) Thank you. I look forward to a fresh pull request. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On Mon, Jul 06, 2015 at 09:47:42AM +0200, Anton Lundin wrote: > ... > > > and > > > - Spend time on improving Android compilation. As the app has only been > > > tested > > > on desktop, we will need to run it on Android for better testing. > > > > Definitely. Please keep asking Anton(glance) to help you there. Worst case > > I can try and dig into what I can find... I don't consider fixing the > > cmake problem part of your GSoC tasks and don't want you to have to waste > > too much time on this. > > > > After my last patch series, subsurface builds again against the Android > NDK and Qt 5.4.2. It can't produce a working APK yet, but things > compile. > > I'm testing qt 5.5.0 right now. > > > My current plans for Cmake / Android support are picking ideas from > https://github.com/calincru/QML-Android-Demo to hook things up to be > able to generate a apk. > > Btw. Do anyone know if there are any plans for cmake / Android support > "natively" in Qt? Most of the questions about this seem to end up pointing to this at some point: https://github.com/LaurentGomila/qt-android-cmake > ps. > Another thing i would love if Grace took a look at is wiring up a > download from divecomputer dialog in qml. That would be great for the > Qt-bluetooth tingie on android. Yes > Also a simple ui for the planner would be on my wishlist =) Not so sure about this one. There are so many options plus the smaller screen size. And you can't print. Would people REALLY use that instead of doing this on a real computer? Or would this be more something that one looked at once, said "cool" but then never actually used? I simply don't know. I find it hard to imagine that a serious tech dive would plan a dive on their phone and then copy it from there to their slate or something. But then, I'm not a serious tech diver, so I could be completely wrong and that would be the killer app everyone wants. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
When I manage to connect to the OSTC 2 device and to initiate the data transfer I get the same result. It gets stuck somewhere in the middle. The libdivecomputer back-end initiate a read request for a 1024 buffer and can read only 923 bytes from device's buffer. I will let you know if the new firmware fixes this problem. That is definitely we need to work on with Matthias. I got sidetracked (I simply work on too many things - I need more areas where others take over and I don't need to worry about them) and never spent the time to really figure out what was broken. That's a known issue of the 1.80. Update to 1.81 and this will be fixed automatically. Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MOD of oxygen at pO2 of 1.6 is 20ft
On Mon, Jul 6, 2015 at 4:24 AM, Henrik Brautaset Aronsen wrote: > > On Sun, Jul 5, 2015 at 11:03 PM, Rick Walsh wrote: >> >> Serious question: does anyone switch to 50% at 22m? > > > For tank MOD markings around me usually round to the nearest 3 (meters). So > 21 meters (not 22) for 50% and 6 meters (not 5) for o2. Etc. Also to the > nearest 10ft. I dive metric, my stops are all multiple of 3 m and my tanks have the real MODs, not rounded ones, as I understand MODs as maximum operation depth, not mandatory other-gas depth ;) But obviously I understand that having the MOD equal to some deco stop might seems less confusing. Truncating sounds more conservative but actually I bet that if your dive plan gets unsafe because of half a meter on a deco stop or worst half a foot you have other problems not rounding related so rounding seems to me as the right thing to do. Rodrigo Severo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: dive plan test
Dirk, > On 05 Jul 2015, at 20:47, Dirk Hohndel wrote: > > Thank you. Much appreciated. I'm reasonably certain that I'm just missing > some setting that gets set up in the full app but does not get set up in > TestPlanner. I found three things: 1) I think most important: you have a typo in the salinity: - dp->salinity = 10030; + dp->salinity = 10300; 2) What is your descent rate? It seems to be 23m/min but you don’t set this. + prefs.descrate = 23000/60; 3) What is the value you are aiming for? The UI version of subsurface seems to come up with a 108min dive, doesn’t it. So I would say - QCOMPARE(displayed_dive.dc.duration.seconds, 104u * 60u); + QCOMPARE(displayed_dive.dc.duration.seconds, 108u * 60u); What do you think? Best Robert signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On Mon, Jul 6, 2015 at 1:51 AM, Dirk Hohndel wrote: > Hi Grace > > On Sun, Jul 05, 2015 at 11:00:31PM +0300, Grace Karanja wrote: > > > > This week, I managed the following:- > > > > - Adding a preferences dialog for the user to store cloud credentials. > > - Loading dives/Saving them to the cloud. > > - Displaying the dive profile in QML. > > Things looks nice, great progress. Styling is a bit off on my display (text > seems to be too close to the bottom of the surrounding box) but it's quite > usable already. It's just so cool when you add your credentials and it > simply shows all your dives... > Thanks. I am working on improving the UI issues. Once I have a dive profile in place, I should be able to implement some swipe gestures. > > That will be cool. I am really happy how close to useful this is already - > and we only at about half time of the project! > > > and > > - Spend time on improving Android compilation. As the app has only been > tested > > on desktop, we will need to run it on Android for better testing. > > Definitely. Please keep asking Anton(glance) to help you there. Worst case > I can try and dig into what I can find... I don't consider fixing the > cmake problem part of your GSoC tasks and don't want you to have to waste > too much time on this. > > > All of the work done so far is on my GitHub repository. > > I pulled from there to play with things. I'm not quite ready to pull this > into master because there seems to be too much redundant code movements. > One patch moves code here, the next patch moves it there. > One patch comments out code, the next patch remove the comment. > Several patches have incremental changes to the same file. > > I know that you have used git rebase -i in the past. I'd really like to > see you combine some of these commits so the series of patches becomes > more structured and goes reasonably straight to the end result. > > From a commit message point of view I think you are doing well. One thing > that would be nice would be a "tag" in the commit title. For example if > all of the commits that deal with the QML UI started with "QML UI:" and > continued in lower case. Something like > > QML UI: implement saving dives in the cloud > Thanks...I will redo the commits in this format :) > > I know, this is nit picking, but the goal here is to turn you into a > strong contributor :-) > > Thanks for your hard work. > > /D > -- -- Grace K ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Week 6 GSoC Progress Update (Android Port)
On 05 July, 2015 - Dirk Hohndel wrote: > Hi Grace > > On Sun, Jul 05, 2015 at 11:00:31PM +0300, Grace Karanja wrote: ... > > and > > - Spend time on improving Android compilation. As the app has only been > > tested > > on desktop, we will need to run it on Android for better testing. > > Definitely. Please keep asking Anton(glance) to help you there. Worst case > I can try and dig into what I can find... I don't consider fixing the > cmake problem part of your GSoC tasks and don't want you to have to waste > too much time on this. > After my last patch series, subsurface builds again against the Android NDK and Qt 5.4.2. It can't produce a working APK yet, but things compile. I'm testing qt 5.5.0 right now. My current plans for Cmake / Android support are picking ideas from https://github.com/calincru/QML-Android-Demo to hook things up to be able to generate a apk. Btw. Do anyone know if there are any plans for cmake / Android support "natively" in Qt? //Anton ps. Another thing i would love if Grace took a look at is wiring up a download from divecomputer dialog in qml. That would be great for the Qt-bluetooth tingie on android. Also a simple ui for the planner would be on my wishlist =) -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MOD of oxygen at pO2 of 1.6 is 20ft
On Sun, Jul 5, 2015 at 11:03 PM, Rick Walsh wrote: > Serious question: does anyone switch to 50% at 22m? > For tank MOD markings around me usually round to the nearest 3 (meters). So 21 meters (not 22) for 50% and 6 meters (not 5) for o2. Etc. Also to the nearest 10ft. Henrik ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MOD of oxygen at pO2 of 1.6 is 20ft
On 06 July, 2015 - Robert C. Helling wrote:
>
> > On 05 Jul 2015, at 21:31, Dirk Hohndel wrote:
> >
> > On Sun, Jul 05, 2015 at 12:11:15PM -0700, Linus Torvalds wrote:
> >> On Sun, Jul 5, 2015 at 11:56 AM, Dirk Hohndel wrote:
> >>> static inline depth_t gas_mod(struct gasmix *mix, pressure_t po2_limit,
> >>> int roundto) {
> >>>depth_t depth;
> >>>depth.mm = ((po2_limit.mbar * 1000 / get_o2(mix) * 10 - 1) /
> >>> roundto) * roundto;
> >>>return depth;
> >>> }
> >>>
> >>> So all we need to do is adjust this function to add (roundto - 1) to the
> >>> enumerator before deviding by roundto, correct?
> >>
> >> Ugh. I think it would be better to write it more readably first.
> >> That's a particularly unreadable line of noise.
> >
> > Well, Robert wrote it, now he can fix it.
>
> I couldn’t remember but git blame says so. But I only added the rounding, the
> poor man’s pressure to depth conversion was there before.
I abstracted it out to a separate helper, but you wrote the math to
begin with back in 9ddef367 =)
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
