subsurface Digest, Vol 40, Issue 104
Dileesha Rajapakse
dilee.dev at gmail.com
Tue Mar 24 07:22:22 PDT 2015
Hi, Iḿ Dileesha from Sri Lanka. Currently I´m an undergraduate majoring in
Software Engineering at Informatics Institute of Technology, Sri Lanka
(Affiliated with University of Westminster, London). I´m an enthusiastic
programmer having an eagerness to gain experience by involving in
industrial level projects. I have done some research in Subsurface and
decided to involve in it since I think that I have the necessary skills to
proceed further with the project.
On Mon, Mar 23, 2015 at 8:57 PM, <subsurface-request at subsurface-divelog.org>
wrote:
> Send subsurface mailing list submissions to
> subsurface at subsurface-divelog.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
> or, via email, send a message with subject or body 'help' to
> subsurface-request at subsurface-divelog.org
>
> You can reach the person managing the list at
> subsurface-owner at subsurface-divelog.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of subsurface digest..."
>
>
> Today's Topics:
>
> 1. Re: Coding Style - C++ constructor initialization list
> (Dirk Hohndel)
> 2. Re: Coding Style - C++ constructor initialization list
> (Dirk Hohndel)
> 3. Re: [PATCH] CodingStyle: add an extra line for the braces
> explaination (Lubomir I. Ivanov)
> 4. Re: Customizable Print Formats GSoC 2015 (Lubomir I. Ivanov)
> 5. Re: [PATCH] Fix some memory leaks (Lubomir I. Ivanov)
> 6. Re: [PATCH] fixed #404 Corrects volumes of cylinders
> (Anton Lundin)
> 7. Re: [PATCH] Fix some memory leaks (Lubomir I. Ivanov)
> 8. Re: [PATCH] initializing members (Lubomir I. Ivanov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Mar 2015 05:51:26 -0700
> From: Dirk Hohndel <dirk at hohndel.org>
> To: Marcos Cardinot <mcardinot at gmail.com>
> Cc: Subsurface Mailing List <subsurface at subsurface-divelog.org>
> Subject: Re: Coding Style - C++ constructor initialization list
> Message-ID: <20150323125126.GH1256 at rrmbp.gr8dns.org>
> Content-Type: text/plain; charset=utf-8
>
> On Mon, Mar 23, 2015 at 12:59:39AM -0300, Marcos Cardinot wrote:
> > Hello folks,
> >
> > It is just a naive discussion about coding style... =D
>
> Our favorite topic :-)
>
> > According to the CodingStyle.txt:
> >
> > *"- in a C++ constructor initialization list, the colon is on the same
> line
> > and*
> > * continuation lines are aligned as the rule above:*
> >
> > * ClassName::ClassName() : x(1), y(2),*
> > * z(3)*
> > * {*
> > * }"*
>
> Whitespace did you in here.
>
> Yes, it turns out that this is not quite what the we ended up with.
>
> > As you know, most of the classes does not follow this rule yet, but it's
> > fine, since it looks like a new rule =D
> >
> > However, in this format, the next lines would usually require some white
> > spaces (in order to do a correct alignment), but it might not be a good
> > idea, because the alignment would depends on the editor...
>
> Well, no. Tab is 8 spaces so this is not editor specific
>
> > In addition, writing many (more than one) members at the same line is
> less
> > readable than writing only one...
> >
> > My suggestion is that for this case, we should have a style in which we
> > would never need to use white spaces...
> > for example:
> > *ClassName::ClassName() :*
> > *x(1),*
> > *y(2),*
> > *z(3)*
> > *{*
> > *}*
>
> This isn't readable for me. Possibly a mail formating issue.
> What we really have and should have is
>
> ClassName::memberFunction() : x(1),
> y(2),
> z(3)
> {
> }
>
> So y and z are indented by exactly one tab.
>
> > *ClassName::ClassName()*
> > * : **x(1),*
>
> NO. I absolutely hate having the "connecting" character at the start of
> the next line.
>
> /D
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 23 Mar 2015 05:52:57 -0700
> From: Dirk Hohndel <dirk at hohndel.org>
> To: Boris Barbulovski <bbarbulovski at gmail.com>
> Cc: Subsurface Mailing List <subsurface at subsurface-divelog.org>
> Subject: Re: Coding Style - C++ constructor initialization list
> Message-ID: <20150323125257.GI1256 at rrmbp.gr8dns.org>
> Content-Type: text/plain; charset=utf-8
>
> On Mon, Mar 23, 2015 at 09:44:33AM +0100, Boris Barbulovski wrote:
> > or maybe like this:
> >
> > *ClassName::ClassName()*
> > * : **x(1)*
> > * , **y(2)*
> > * , **z(3)*
> > *{*
> > *}*
> >
> > Benefits:
> > * Members are aligned(easy to read)
> > * Eazyer for adding new members to the end of the list(no need to worry
> > about the comma to last entry)
>
> Downsides: UGLY and hard on my eyes.
>
> I know quite a few projects do this, I just don't like this. Sorry
>
> /D
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 23 Mar 2015 16:03:28 +0200
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> To: Subsurface Mailing List <subsurface at subsurface-divelog.org>
> Subject: Re: [PATCH] CodingStyle: add an extra line for the braces
> explaination
> Message-ID:
> <CAGDbWi8Kry4Og6CGwTWnHgGioec=pF=
> B3jrYrFhM_2QyPEQonw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> > 18 March 2015 at 02:22, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> > From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> >
> > The extra call "dosomethingelse()" is added with the
> > intention that user will not be confused to add braces
> > around single lined "if" conditions.
> >
> > Signed-off-by: Lubomir I. Ivanov <neolit123 at gmail.com>
> > ---
> > CodingStyle | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/CodingStyle b/CodingStyle
> > index 75aa1d4..ead24d0 100644
> > --- a/CodingStyle
> > +++ b/CodingStyle
> > @@ -42,6 +42,7 @@ Basic rules
> >
> > if (condition) {
> > dosomething();
> > + dosomethingelse();
> > }
> >
> > - both sides of an if / else clause either use or do not use curly
> braces:
>
> bump.
>
> lubomir
> --
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 23 Mar 2015 16:10:01 +0200
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> To: Gehad Elrobey <gehadelrobey at gmail.com>
> Cc: Subsurface Mailing List <subsurface at subsurface-divelog.org>
> Subject: Re: Customizable Print Formats GSoC 2015
> Message-ID:
> <CAGDbWi_sE4adU3dZuYPB3k=S1zNgbB+=
> oL+P0btviOPKSAxhpg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 22 March 2015 at 22:57, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
> > Hello,
> >
> > I have attached an updated version of my proposal.
> > I am glad to hear any remarks.
> >
>
> thanks for the update, Gehad.
> i have no more remarks ATM.
>
> if others are interested in the future printing capabilities of
> Subsurface, you can have a look.
>
> lubomir
> --
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 23 Mar 2015 16:55:09 +0200
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> To: Claudiu Olteanu <olteanu.vasilica.claudiu at gmail.com>, Salvador
> Cuñat <salvador.cunat at gmail.com>
> Cc: Subsurface Mailing List <subsurface at subsurface-divelog.org>
> Subject: Re: [PATCH] Fix some memory leaks
> Message-ID:
> <CAGDbWi9CHwVNoPjEVcK8LC62ZYWCg1+xGC=
> H1vL6H8pRRvgsgw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 22 March 2015 at 13:48, Claudiu Olteanu
> <olteanu.vasilica.claudiu at gmail.com> wrote:
> > Hello,
> >
> > This patch fixes some memory leaks from datatrak implementation.
> >
>
> it could clash with a change that the author / maintainer (Salvador)
> has recently sent.
> (the patch is not in master yet)
> [PATCH] [datatrak.c] Improve error management
>
> but the free() calls in your patch look appropriately placed.
>
> this:
> - free (fileheader);
> + free(fileheader);
>
> is a whitespace fix. still in the context of the memory leaks, but
> Dirk may not like it.
>
> lubomir
> --
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 23 Mar 2015 16:08:30 +0100
> From: Anton Lundin <glance at acc.umu.se>
> To: Harshal Jalan <harshal.jalan at gmail.com>
> Cc: subsurface at subsurface-divelog.org
> Subject: Re: [PATCH] fixed #404 Corrects volumes of cylinders
> Message-ID: <20150323150830.GB26336 at kennedy.acc.umu.se>
> Content-Type: text/plain; charset=utf-8
>
> On 22 March, 2015 - Harshal Jalan wrote:
>
> > The volumes of cylinders displayed in equipments tab was wrong. It was
> > corrected by changing data about the cylinders in the code.
> > Please have a look at the attached patch and suggest changes...
> >
> > Harshal Jalan
>
> > From f6adc09d5aa9d8a5a9f958c318e14d2dc62dd781 Mon Sep 17 00:00:00 2001
> > From: Harshal Jalan <harshal.jalan at gmail.com>
> > Date: Sun, 22 Mar 2015 22:30:07 +0530
> > Subject: [PATCH] [PATCH] Fixed #404 Corrects volumes of cylinders
> > The volumes of cylinders displayed in equipments tab was wrong.
> > It was corrected by changing data about the cylinders in the code.
> >
> > Signed-off-by: Harshal Jalan <harshal.jalan at gmail.com>
> > ---
> > equipment.c | 30 +++++++++++++++---------------
> > 1 file changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/equipment.c b/equipment.c
> > index aebac51..dfde924 100644
> > --- a/equipment.c
> > +++ b/equipment.c
> > @@ -141,28 +141,28 @@ struct tank_info_t tank_info[100] = {
> > { "11.1ℓ", .ml = 11100 },
> >
> > /* Most common AL cylinders */
> > - { "AL40", .cuft = 40, .psi = 3000 },
> > - { "AL50", .cuft = 50, .psi = 3000 },
> > - { "AL63", .cuft = 63, .psi = 3000 },
> > - { "AL72", .cuft = 72, .psi = 3000 },
> > - { "AL80", .cuft = 80, .psi = 3000 },
> > - { "AL100", .cuft = 100, .psi = 3300 },
> > + { "AL40", .ml = 5700, .bar = 207 },
> > + { "AL50", .ml = 6900, .bar = 207 },
> > + { "AL63", .ml = 9000, .bar = 207 },
> > + { "AL72", .ml = 6900, .bar = 207 },
> > + { "AL80", .ml = 11100, .bar = 207 },
> > + { "AL100", .ml = 13200, .bar = 228 },
>
> There's four spaces as indentation here. It should be one tab.
>
> //Anton
>
> --
> Anton Lundin +46702-161604
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 23 Mar 2015 17:20:34 +0200
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> To: Claudiu Olteanu <olteanu.vasilica.claudiu at gmail.com>
> Cc: Subsurface Mailing List <subsurface at subsurface-divelog.org>
> Subject: Re: [PATCH] Fix some memory leaks
> Message-ID:
> <CAGDbWi-5t7+8y9mFbiujYhd+O-o73dkf+Jy=
> yRk2Rrn7UbB3Kw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 22 March 2015 at 17:46, Claudiu Olteanu
> <olteanu.vasilica.claudiu at gmail.com> wrote:
> > I added more patches which will fix some memory leaks.
> > Regarding the uemis-downloader.c source I am not sure if
> > "iparam_buff" and "mbuf" variables should be freed too.
> >
> > I saw that one of the elements of "param_buff" is used as a result for
> the
> > "do_uemis_import" function, but I didn't saw where it is freed.
> >
>
> if you are not sure about a certain memory allocation don't fix it,
> because it can create bugs that are very difficult to debug and can
> only be tested fully on a specific device. :\
> i don't have the time to check "param_buff" ATM, leave it be for now,
> or once you find the answer, provide your train of though in the
> commit message on why it should be freed.
>
> 1) same as the first message
> 2) looks good, yet it will go with the process heap map (i.e. one time
> leak). still, to silence valgrind or similar tools the change is fine.
> 3) looks good to me. the string will be strdup-ed, and tmp can be freed.
> 4) also seems good
>
> lubomir
> --
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 23 Mar 2015 17:31:54 +0200
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> To: Marcos Cardinot <mcardinot at gmail.com>
> Cc: Subsurface Mailing List <subsurface at subsurface-divelog.org>
> Subject: Re: [PATCH] initializing members
> Message-ID:
> <
> CAGDbWi-ZhMCfpMgcxLz6pThE10-GCrHTKFfj82f_cJyOwKu6Nw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 23 March 2015 at 06:43, Marcos Cardinot <mcardinot at gmail.com> wrote:
>
> > Hi,
> >
> > The attached patches initialize some members in several classes of the
> > qt-ui package...
> >
> >
> hello,
>
> do these patches have the idea to solve compiler warnings (what GCC version
> and -W level) or potentially dangerous lack of initialization (according to
> you)?
> if no to both, perhaps we should leave these changes out.
>
> for instance about 008, the setup() is called in the constructor which will
> surely *not* leave the variable uninitialized.
>
> lubomir
> --
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150323/64415619/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
> ------------------------------
>
> End of subsurface Digest, Vol 40, Issue 104
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150324/a1d3f4e4/attachment-0001.html>
More information about the subsurface
mailing list