[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Status of aghermann (Was: Bug#925629: aghermann: ftbfs with GCC-9)



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 <andreas@an3as.eu> 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
> > > Debian-med-packaging@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> >
> >
> > --
> > http://fam-tille.de
> 

-- 
http://fam-tille.de


Reply to: