avarice-user

[AVaRICE-user] Bug in AVaRICE 2.13

[Marian B. <mar...@ov...>]

Hi,

the attached patch fixes an incorrect return statement: Apparently old GCC
versions implicitly casted "false" to "NULL", which no longer is the case. So
the "return false;" statement in jtagrw.cc:134 in function 

uchar *jtag1::jtagRead(unsigned long addr, unsigned int numBytes)

should be replaced by "return NULL;"

Also, there is a lot of inconsistent use of tabs and spaces for indent. Maybe
running astyle, uncrustify, or whatever of the code would be a good idea? ;-)

Kind regards,
Marian

-------------------------------------------------------------
M.Sc. Marian Buschsieweke
Dept. Communication and Networked Systems (ComSys)
Institute for Intelligent Cooperating Systems (IKS)
Otto-von-Guericke-University of Magdeburg
Universitätsplatz 2, Building 29, Room 314
39106 Magdeburg
Germany

http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html
Tel.: +49 - 391 - 67 - 52673
Fax:  +49 - 391 - 67 - 41161

Re: [AVaRICE-user] Bug in AVaRICE 2.13

[Joerg W. <j...@ur...>]

As Marian Buschsieweke wrote:

> the attached patch fixes an incorrect return statement: Apparently old GCC
> versions implicitly casted "false" to "NULL", which no longer is the case. So
> the "return false;" statement in jtagrw.cc:134 in function 
> 
> uchar *jtag1::jtagRead(unsigned long addr, unsigned int numBytes)
> 
> should be replaced by "return NULL;"

See bug report #24 (filed just recently)

> Also, there is a lot of inconsistent use of tabs and spaces for indent. Maybe
> running astyle, uncrustify, or whatever of the code would be a good idea? ;-)

Changing whitespace just for the purpose of changing it is generally
not a good idea.  It potentially obfuscates real code changes later on.

That doesn't mean maintaining a consistent style is a bad idea, but I
wouldn't want to commit changes just for that.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

Re: [AVaRICE-user] Bug in AVaRICE 2.13

[Marian B. <mar...@ov...>]

Dear Jörg Wunsch,

thanks for the quick reply.

> See bug report #24 (filed just recently)

Actually I had a look into the bug tracker and before writing the email and
couldn't find it. I also wanted to add a bug, but I really don't want to create
an account on SourceForge. Every time I click on something there a huge "we
value your privacy" banner is jumping in my face. And I only need to click on
"More Options" to see the provide that this is a lie...

My point is: SourceForge.net is a platform that really scares me away from an
open source project, no matter how cool it is. Other coders and potential
contributors may feel the same way about it. Maybe with teahub.io a good
alternative will (hopefully) emerge some day in the (hopefully) not too distant
future. Maybe that is worth for AVaRICE to look into, when it becomes available?

> Changing whitespace just for the purpose of changing it is generally
> not a good idea.  It potentially obfuscates real code changes later on.

(Sorry for writing a quite emotional rant about it, but inconsistent indent is
one of my pet peeves:)

I cannot disagree more on that. I see a VCS log as a tool to tweak the code -
not writing code as a tool to tweak the VCS log.

Inconsistent coding style makes reading and understanding the code harder. It
increases the barrier to get other people to contribute code and identifying
bugs harder. E.g. the CVE-2013-1266 (a.k.a. goto fail) [1] would most likely be
detected sooner when correct code indentation would have been used. This even
lead to the new "-Wmisleading-indentation" warning option in GCC [2]. So
getting code indentation consistent (no matter if you prefer tabs, spaces or
smart tabs) has a huge impact on code quality, even if this only changes white
space.

Kind regards,
Marian Buschsieweke

[1]: https://nvd.nist.gov/vuln/detail/CVE-2014-1266
[2]:
https://developers.redhat.com/blog/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail/

-------------------------------------------------------------
M.Sc. Marian Buschsieweke
Dept. Communication and Networked Systems (ComSys)
Institute for Intelligent Cooperating Systems (IKS)
Otto-von-Guericke-University of Magdeburg
Universitätsplatz 2, Building 29, Room 314
39106 Magdeburg
Germany

http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html
Tel.: +49 - 391 - 67 - 52673
Fax:  +49 - 391 - 67 - 41161

-------------------------------------------------------------

On Tue, 10 Jul 2018 12:21:58 +0200
Joerg Wunsch <j...@ur...> wrote:

> As Marian Buschsieweke wrote:
> 
> > the attached patch fixes an incorrect return statement: Apparently old GCC
> > versions implicitly casted "false" to "NULL", which no longer is the case. So
> > the "return false;" statement in jtagrw.cc:134 in function 
> > 
> > uchar *jtag1::jtagRead(unsigned long addr, unsigned int numBytes)
> > 
> > should be replaced by "return NULL;"  
> 
> See bug report #24 (filed just recently)
> 
> > Also, there is a lot of inconsistent use of tabs and spaces for indent. Maybe
> > running astyle, uncrustify, or whatever of the code would be a good idea? ;-)  
> 
> Changing whitespace just for the purpose of changing it is generally
> not a good idea.  It potentially obfuscates real code changes later on.
> 
> That doesn't mean maintaining a consistent style is a bad idea, but I
> wouldn't want to commit changes just for that.

Re: [AVaRICE-user] Bug in AVaRICE 2.13

[Joerg W. <j...@ur...>]

As Marian Buschsieweke wrote:

> My point is: SourceForge.net is a platform that really scares me away from an
> open source project, no matter how cool it is. Other coders and potential
> contributors may feel the same way about it. Maybe with teahub.io a good
> alternative will (hopefully) emerge some day in the (hopefully) not too distant
> future. Maybe that is worth for AVaRICE to look into, when it becomes available?

Seriously, AVaRICE has bigger problems but its hosting platform or
indentation style (or VCS, in case anyone's asking for Git now ...).
Sourceforge hasn't been my decision, I merely inherited the project
that way, but for just distributing the software, it doesn't matter
much anyway which platform it is lying on.

So far, there are *zero* active developers, plus a number of things
that require a rewrite of larger portions of the code.  Namely, the
entire handling of the AtmelICE (and JTAGICE-3 in HID mode, as well as
all the embedded debuggers of the various Xplained boards) is just
alpha quality, and could be considered flakey at best.  This is way
more important than stylistic things (as important as they might be to
you personally), because it affects the core functionality of the tool
for the only existing current Atmel debugging hardware.

I don't have the time to do anything on it, sorry.  I can probably
merge the current patch (which is a trivial one), and I could also be
willing to just roll out a new release if needed, but that's it.

If there's anyone going to jump in, who wants to *seriously* (and
long-term) maintain AVaRICE, it would be their decision where to host
the project (or just keep it on SF.net).  They are then also free to
migrate to the VCS they feel most comfortable with, and to fix
stylistic issues.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

Re: [AVaRICE-user] Bug in AVaRICE 2.13

[Marian B. <mar...@ov...>]

Dear Jörg Wunsch,

first: Thank you for your contribution to AVaRICE and maintaining it. It seems
you took offense in my previous email, which was never my intention. I'm sorry
for that.

A new release would be greatly appreciated. The one-liner patch I posted does
not apply to the current SVN head and the bug is already fixed there. So a new
release would solve that issue and other issues and I would be really grateful
for that.

I still believe I have a point in both suggestions (Fixing indentation by
running astyle/uncrustify/clang-format/... and moving AVaRICE to a different
code hosting platform). Let me elaborate on why the code hosting platform is
more relevant than it seems:

As you said, AVaRICE would greatly profit from attracting new contributors. In
order to increase the chance that other contribute the choice of a hosting
platform (and also VCS, as you brought that up) can have a huge impact. E.g.
let's assume AVaRICE would move to GitHub:

- About 6.5 times more coders already have an account there [1], so it's
  more likely that they stumble upon AVaRICE by chance and end up using it and
  hopefully contributing to it
- Most of the computer science students that attend one of our courses already
  have experience in using git, but few have experience using subversion
- The effort to contribute is quite low on platforms like GitHub, GitLab, ...
- Also, the effort to maintain is quite low on those platforms and the burden
  of maintenance can be distributed

Summing up: The project would be more public and visible, so that more people
get the chance to contribute. Also, the bar to contribute would be
significantly lowered, as potential contributors are more likely to already
know the tools and the process of contribution is more streamlined there. So
while changing the code hosting platform does not address any of the actual
issues, it might lead to others contributing important improvements.

Regarding the search of a new maintainer of AVaRICE you mentioned: Maybe the
OpenOCD guys are willing to adopt AVaRICE? They would have the expertise
required to maintain it. Also maybe integrating the code of AVaRICE into
OpenOCD could be an interesting long term goal, which would solve the problem
of too few active contributors, as OpenOCD seem to have an active community.
(And OpenOCD is hosted on SourceForge, so no code migration would be required.)

Another suggestion regarding the maintainer is to ask big users of AVaRICE.
E.g. RIOT OS is using it to debug the Arduino Mega 2560. They might not have
the same expertise regarding debuggers as OpenOCD (as their main competence is
writing an IoT operating system), but they certainly have the infrastructure
and expertise required for maintaining open source projects. And for users of
AVaRICE (RIOT OS or others) have a natural interest in keeping AVaRICE running.

I'm really interested in having an open source tool for OCD of AVR MCUs. Sadly,
I neither have the expertise regarding debuggers nor the time to provide
significant contributions. However, I am willing to contribute any bugfix and
improvement that I program in order to keep AVaRICE running for the OCD of the
platforms I'm working with. Maybe, if others do the same those minor
contributions add up.

Kind regards,
Marian

[1]:
https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Popularity

-------------------------------------------------------------
M.Sc. Marian Buschsieweke
Dept. Communication and Networked Systems (ComSys)
Institute for Intelligent Cooperating Systems (IKS)
Otto-von-Guericke-University of Magdeburg
Universitätsplatz 2, Building 29, Room 314
39106 Magdeburg
Germany

http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html
Tel.: +49 - 391 - 67 - 52673
Fax:  +49 - 391 - 67 - 41161

-------------------------------------------------------------

On Tue, 10 Jul 2018 22:08:46 +0200
Joerg Wunsch <j...@ur...> wrote:

> As Marian Buschsieweke wrote:
> 
> > My point is: SourceForge.net is a platform that really scares me away from
> > an open source project, no matter how cool it is. Other coders and potential
> > contributors may feel the same way about it. Maybe with teahub.io a good
> > alternative will (hopefully) emerge some day in the (hopefully) not too
> > distant future. Maybe that is worth for AVaRICE to look into, when it
> > becomes available?  
> 
> Seriously, AVaRICE has bigger problems but its hosting platform or
> indentation style (or VCS, in case anyone's asking for Git now ...).
> Sourceforge hasn't been my decision, I merely inherited the project
> that way, but for just distributing the software, it doesn't matter
> much anyway which platform it is lying on.
> 
> So far, there are *zero* active developers, plus a number of things
> that require a rewrite of larger portions of the code.  Namely, the
> entire handling of the AtmelICE (and JTAGICE-3 in HID mode, as well as
> all the embedded debuggers of the various Xplained boards) is just
> alpha quality, and could be considered flakey at best.  This is way
> more important than stylistic things (as important as they might be to
> you personally), because it affects the core functionality of the tool
> for the only existing current Atmel debugging hardware.
> 
> I don't have the time to do anything on it, sorry.  I can probably
> merge the current patch (which is a trivial one), and I could also be
> willing to just roll out a new release if needed, but that's it.
> 
> If there's anyone going to jump in, who wants to *seriously* (and
> long-term) maintain AVaRICE, it would be their decision where to host
> the project (or just keep it on SF.net).  They are then also free to
> migrate to the VCS they feel most comfortable with, and to fix
> stylistic issues.

Re: [AVaRICE-user] Bug in AVaRICE 2.13

[Joerg W. <j...@ur...>]

As Marian Buschsieweke wrote:

> first: Thank you for your contribution to AVaRICE and maintaining it. It seems
> you took offense in my previous email, which was never my intention. I'm sorry
> for that.

No offense taken, not at all.

> As you said, AVaRICE would greatly profit from attracting new contributors. In
> order to increase the chance that other contribute the choice of a hosting
> platform (and also VCS, as you brought that up) can have a huge impact.

According to > 25 years of opensource contributions by myself, I don't
think just changing the environment would get anyone to step forward.
People only come by if 1) they really need any particular feature in a
certain software, and 2) they have the time and skills to do so.

Once someone is there who really wants to dedicate the required time
for maintenance, migrating to some different environment could
certainly be arranged.

> Regarding the search of a new maintainer of AVaRICE you mentioned: Maybe the
> OpenOCD guys are willing to adopt AVaRICE?

As someone who contributed minor additions to OpenOCD as well: I don't
think there's anyone around in the OpenOCD community interested and
knowledgable about AVRs.  It would certainly be interesting to migrate
the AVR debugging part there, as they've got a good and versatile
framework for many different platforms.  I already contemplated to at
least handle the AtmelICE + EDBG part there (as these tools are
already working well on OpenOCD for ARM targets, so the part that is
currently not working well in AVaRICE is already available there), and
then just keep AVaRICE as it is for the historic JTAGICE, JTAGICEmkII,
AVR Dragon, and JTAGICE3 (early firmware) where it works well enough.
However, see my previous mail: I lack the time for it (and partly now
also the motivation).

> However, I am willing to contribute any bugfix and
> improvement that I program in order to keep AVaRICE running for the OCD of the
> platforms I'm working with. Maybe, if others do the same those minor
> contributions add up.

Surely, minor contributions like that are always welcome, but they do
not solve the major headache I currently have about handling the
AtmelICE & co.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)