Hi,
@Andrei: Thank you for your status update
@List-Readers: I'd like to forward this status mail from Andrei to
the list. I've also added it to debian/README.Debian to make sure
the information is at hand once it might be needed.
I personally see no need for any action since aghermann is now free
of any known bugs in Debian. I do not have any spare time cycles to
package the suggested alternative.
Kind regards
Andreas.
On Tue, Jan 14, 2020 at 04:35:47AM +0200, andrei zavada wrote:
> Gentlemen,
>
> This is the original author of aghermann. First of all, thanks for
> take good care of it. My circumstances have changed quite a bit since
> I did my last release -- an age ago. In professional capacity, in 2010
> I have turned to Erlang and, since around 2014, my proficiency in C++
> has been in steady decline. These days, even as I am looking at this
> 40k LOC of my own code with a faint sense of some grand achievement, I
> find myself totally incapable of carrying on with it. Please consider
> this as a letter of retirement.
>
> The other day I wanted to cherry-pick Andreas's changes
> (https://salsa.debian.org/med-team/aghermann/commit/3cf06970a18219a327fc79a3580d94959ffd7a9a)
> into my repo, but it being a mix of useful gtk3 deprecations and a lot
> more, along with massive move/rename, I gave up. But all of them were
> good.
>
> I am aware of at least one recent paper where the slow-wave sleep
> model as used in aghermann is revived and applied in very much the
> same way: https://dx.doi.org/10.1093%2Fsleep%2Fzsy079. (It comes from
> the lab of Vlad Viazovsky, who happens to be my old acquaintance, even
> though we don't keep in touch.) This has largely vindicated my effort,
> and it is my hope it can make your maintainership of it in Debian
> worth your time.
>
> Again, thanks a lot, and cheers!
> Andrei
>
> On Mon, 13 Jan 2020 at 18:35, Andreas Tille <[email protected]> wrote:
> >
> > Thanks a lot for the very helpful comments, Andreas.
> >
> > On Mon, Jan 13, 2020 at 07:20:24AM -0800, Matthew Fernandez wrote:
> > > > I need to admit that I understand so less from all the gcc issues you
> > > > tried to explain - I do not even have any idea what C++ attributes are.
> > > > I simply cared for that Debian bug since nobody else did. :-(
> > > > So I feel really incompetent to discuss this with gcc maintainers but
> > > > I'd welcome if you bring it up there.
> > >
> > > GCC attributes like the __attribute__ example here are a mechanism for
> > > annotating C/C++ code with things not covered by the ISO standards, but
> > > supported by compiler extensions. Attributes can be applied to many
> > > things including variables and functions, and the function attributes are
> > > documented at https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
> > > <https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. These days
> > > Clang also understands many of the GCC attributes.
> > >
> > > The particular one in question here is telling the compiler that the
> > > lambda function being defined has similar behavior to the libc printf
> > > function. The integer parameters say a printf format string appears as
> > > the second argument and the first varargs parameter is the third
> > > argument. This looks off by one, but I think the captured local (&L)
> > > counts as the first parameter. The only thing the compiler uses this
> > > attribute for is to detect calls to this lambda with incorrect arguments
> > > and emit warnings for them.
> > >
> > > The C++11 standard brought in a more commonly supported way of declaring
> > > attributes using square brackets. Unfortunately the standard does not
> > > support many common attributes and you still need to use a “gnu::” prefix
> > > to access the GCC-specific attributes. Hence, “[[gnu::format(printf, 2,
> > > 3)]]” being the C++11 equivalent of this.
> > >
> > > >> If you need to bypass this urgently, I would recommend deleting the
> > > >> attribute as that particular one is only used to aid the compiler in
> > > >> creating warnings.
> > > >
> > > > Hmmm, as I said my patch[1] works and I just have the gut feeling (as I
> > > > said I have no competence!) that this might be better than to delete the
> > > > attribute. If not would you mind sending an alternative patch which is
> > > > better in your opinion?
> > >
> > > Lambda functions, which are already being used in this code, are a C++11
> > > feature as are this style of attributes. So I imagine it would be
> > > acceptable to upstream to take your patch. Having said that, when I did
> > > this in my experiment code above the compiler warned that it was ignoring
> > > this attribute as it thought it was being applied to the trailing “int”.
> > >
> > > I re-read the GCC issue and realized I’d misread Jonathan Wakely’s
> > > comments. The issue is actually still open and Jonathan was just noting
> > > that r265787 introduced the bug, not fixed it. So I think what we’re
> > > seeing is consistent with the GCC maintainers’ view.
> > >
> > > I would suggest proposing your patch upstream. Although its primary
> > > purpose is working around a compiler bug, it’s also an objective
> > > improvement in modernizing the code base.
> > >
> > > > Thanks again
> > > >
> > > > Andreas.
> > > >
> > > >
> > > >> [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333
> > > >> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333>
> > > >
> > > > [1]
> > > > https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch
> > > >
> > > > <https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch>
> > > >
> > > > --
> > > > http://fam-tille.de <http://fam-tille.de/>
> >
> > > _______________________________________________
> > > Debian-med-packaging mailing list
> > > [email protected]
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> >
> >
> > --
> > http://fam-tille.de
>
--
http://fam-tille.de
