lmi
[Top][All Lists]
Advanced

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

Re: [lmi] SHA1 for wx upgrade


From: Vadim Zeitlin
Subject: Re: [lmi] SHA1 for wx upgrade
Date: Thu, 23 Jul 2020 23:53:17 +0200

On Thu, 23 Jul 2020 20:42:33 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-07-21 23:31, Vadim Zeitlin wrote:
GC> > On Mon, 20 Jul 2020 22:36:20 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > 
GC> > GC> I'd like to be able to make the choice by around 10:00Z Wednesday,
GC> > GC> soon after the birds awaken me. Sooner than that is not preferable.
GC> > GC> A little later may be okay if an important regression is found.
GC> 
GC> We got distracted by business priorities, and haven't been able to
GC> begin our testing yet. I'd like to update on or before 16:00Z
GC> tomorrow, which means "by noon" in our local civil time. To what
GC> SHA1 should we update, though?

 FWIW the one I posted in my previous reply[1], i.e. 3c259eb56d (Document
change log update better in the release instructions, 2020-07-22) is still
perfectly fine.

[1]: https://lists.nongnu.org/archive/html/lmi/2020-07/msg00039.html

GC> One obvious candidate is
GC> 
GC> https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.4
GC> 
GC> which links to this:
GC> 
GC> 
https://github.com/wxWidgets/wxWidgets/commit/6cdaedd42ba59331b3dc4ead50e0bac76ae14c19

 However this one is not materially different from the commit above and you
could prefer to use this one just to use the official release tag (but
unfortunately you can't use the tag itself, i.e. just use "v3.1.4" as the
value of wx_commit_sha in install_wx.sh considering the way this script is
currently written).

GC> Looking through the fifteen commits since then, the only possibly
GC> relevant ones seem to be these two:
GC> 
GC> 
https://github.com/wxWidgets/wxWidgets/commit/8e126d2cd67479ad06536380da7453e3d1254d52
GC> 
GC>    Don't call RefreshRect() with negative size in wxGrid code
GC> 
GC>   Don't bother trying to refresh areas beyond the visible part of the
GC>   window: not only it's useless, but it also results in debug warnings
GC>   from Cairo/pixman due to the use of negative rectangle width/height.
GC> 
GC>   Closes #18848.
GC> 
GC> 
https://github.com/wxWidgets/wxWidgets/commit/0d18e12e797d96303cedf49c62fc9bcf404d2afb
GC> 
GC>    Avoid -Wconversion-null from MinGW-w64 in wxListBox code
GC> 
GC>   Explicitly cast the pointer to LPARAM instead of implicitly casting NULL
GC>   to it.
GC> 
GC>   No real changes.
GC> 
GC> We already know that the second one only causes an ignored warning
GC> in lmi's wx build, but it seems impossible for it to have any other
GC> effect on us. As for the first, I tried triggering it by resizing
GC> a census window many times--before, after, and during editing a
GC> cell, e.g.--but I couldn't see any diagnostic on my terminal.

 I think this one could be reproducible in lmi: it may happen if you call
SetColSize() or SetRowSize() on a column or row which is scrolled out of
view. Of course, it also only happens with wxGTK, so it can't affect the
lmi production build in any way and, even with wxGTK, the "BUG" warning
given on the console is not pretty but seems completely harmless. So I
don't think there is any real need to include this commit in lmi.

GC> Therefore, I don't imagine these commits change anything that lmi
GC> end users can possibly observe, or make any material difference to
GC> us developers, so I guess we should go with the official release,
GC> 6cdaedd42ba59331b3dc4ead50e0bac76ae14c19. Do you concur?

 Yes.

 I thought you had already begun testing with 3c259eb56d, but if not, using
this one looks like the most logical thing to do. Please let me know if you
find any (new) problems using it.

 Thanks in advance,
VZ

Attachment: pgp6HvGyRDxip.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]