I'm going to delay this - I need to enhance my understanding of C++
namespaces as I'd like to offer the correct solution to these warnings,
rather than a dodgy hack :)
Steve
On Wed, 10 May 2017 at 17:42 Steve Davies <davies...@gmail.com> wrote:
> Yes, I can do that.
> Cheers,
> Steve
>
> On Tue, 9 May 2017 at 23:57 Petr Kovar <pk...@volny.cz> wrote:
>
>> On Wed, 26 Apr 2017 09:57:18 +0000
>> Steve Davies <davies...@gmail.com> wrote:
>>
>> > Bugzilla - That would have been the best answer - particularly as I
>> already
>> > have an account now you mention it! :)
>> >
>> > While I am here - the following is from memory, I'm away from my pan dev
>> > environment.
>> >
>> > I notice that COMPRESS_GZIP and ENABLE_COMPRESS_GZIP are defined in
>> > compress.h, which is #included in many places, but both values are used
>> > only once each in nntp.c - On my version of g++ this causes many
>> "defined
>> > but not used" compile warnings. Would it be better to move those 2 lines
>> > into nntp.c? Or replace them with #defines?
>>
>> I think moving them to nntp.cc would be a nice fix, yes, though I don't
>> really know that code so it would need some testing, too.
>>
>> Could you submit a patch? I think people following pan master could be
>> able
>> to test it.
>>
>> Thanks,
>> pk
>>
>>
>> > On Tue, 25 Apr 2017 at 23:51 Petr Kovar <pk...@volny.cz> wrote:
>> >
>> > > On Tue, 25 Apr 2017 20:31:22 +0100
>> > > Steve Davies <davies...@gmail.com> wrote:
>> > >
>> > > > On 25/04/2017 20:23, Petr Kovar wrote:
>> > > > >
>> > > > >> Yes, happens to me too (I had not noticed!) on Windows 10.
>> > > > >>
>> > > > >> I'll try and update everything I can and re-build. It is not a
>> > > > >> fundamental date formatting issue because the article pane shows
>> the
>> > > > >> date just fine...
>> > > > > Was just wondering, do you build Pan with GTK+ 2 or 3? I wouldn't
>> be
>> > > > > surprised if this was a problem in older versions of GTK+.
>> > > > >
>> > > > > pk
>> > > > >
>> > > > GTK+3 is not yet usable on Windows builds as far as I can tell, but
>> I
>> > > > did find the issue - Not sure how to submit the following, so here
>> is a
>> > > > "patch" for you to check and merge if you like it.
>> > >
>> > > Thanks, Steve, for a quick fix! :)
>> > >
>> > > > commit cfbf70be8e083b8a35fc94fad5d5c902c024a223
>> > > > Author: Steve Davies <davies...@gmail.com>
>> > > > Date: Tue Apr 25 20:13:33 2017 +0100
>> > > >
>> > > > Fix the strftime test for mingw64
>> > > >
>> > > > mingw64's strftime returns an empty string when the %l and %h
>> > > > tokens are not understood.
>> > > >
>> > > > diff --git a/configure.ac b/configure.ac
>> > > > index 4caae04..cce6c24 100644
>> > > > --- a/configure.ac
>> > > > +++ b/configure.ac
>> > > > @@ -240,13 +240,14 @@ dnl Check to see if strftime supports the use
>> of
>> > > > %l and %k
>> > > > AC_MSG_CHECKING(for %l and %k support in strftime)
>> > > > AC_RUN_IFELSE([AC_LANG_SOURCE([[
>> > > > #include <string.h>
>> > > > +#include <stdlib.h>
>> > > > #include <time.h>
>> > > > int main(int argc, char **argv) {
>> > > > char buf[10];
>> > > > time_t rawtime = time(0);
>> > > > struct tm *timeinfo = localtime (&rawtime);
>> > > > strftime(buf, 10, "%l %k", timeinfo);
>> > > > - exit (strstr(buf, "l") || strstr(buf, "k") || !strcmp(buf," "));
>> > > > + exit (strstr(buf, "l") || strstr(buf, "k") || !strcmp(buf," ") ||
>> > > > !strlen(buf));
>> > > > }]])],[
>> > > > AC_DEFINE(HAVE_LKSTRFTIME, 1, [strftime supports use of l and k])
>> > > > ac_cv_lkstrftime=yes
>> > > >
>> > > >
>> > > > The above will probably be destroyed in-transit :(
>> > > > Steve
>> > >
>> > > Yeah, the line breaks didn't survive it, so I recreated it manually. I
>> > > think it's better to send it as an attachment, since git format-patch
>> > > creates a patch in a mail format. Or, pan is mirrored on GitHub if
>> you're
>> > > there. Or, Bugzilla...
>> > >
>> > > Cheers,
>> > > pk
>> > >
>>
>
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
