Re: [lmi] Saving and restoring window geometry

[Vadim Zeitlin]

On Wed, 2 May 2018 16:35:12 +0000 Greg Chicares <address@hidden> wrote:

GC> I wish git-fetch had a '--progress=summary' option that would show how
GC> long it took and the number of bytes transferred.

 I don't know how would you do something like this. I thought of setting
GIT_SSH to a custom script, but I realized I don't even know how to get
this information from ssh itself. For the "how long" part, such a script
could definitely output this, however. Or you could also set
GIT_TRACE_PERFORMANCE=true to get information about not only this step, but
all the others as well.


GC> For the record, I did exactly this:
GC>   /opt/lmi/src/lmi[0]$./install_wx.sh >../wx_log 2>&1
GC>   /opt/lmi/src/lmi[0]$make $coefficiency --output-sync=recurse -f 
install_wxpdfdoc.make
GC>   /opt/lmi/src/lmi[0]$make $coefficiency install check_physical_closure 
2>&1 |less -S
GC> and everything seems to work as expected...except that, with 'wine',
GC> if I
GC>   unmaximize
GC>   resize and move
GC>   maximize
GC>   exit
GC>   reload
GC>   unmaximize
GC> then only the size is restored, not the position (it's moved to the upper
GC> right corner).

 Yes, this is exactly https://bugs.winehq.org/show_bug.cgi?id=45099 -- i.e.
it's a Wine bug as the same sequence works as expected under native MSW.


GC> Later I did:
GC>   /opt/lmi/src/lmi[0]$./nychthemeral_test.sh 2>&1 | tee /tmp/lmi/logs/log | 
sed -f errors.sed
GC>   /opt/lmi/bin[0]$wine ./wx_test --ash_nazg --data_path=/opt/lmi/data 
--pyx=only_new_pdf
GC> and that revealed a dll-export problem, but that has nothing to do with
GC> this wx upgrade--it just means I should have run that test before pushing
GC> my preceding change...but that doesn't affect the production system.
GC> 
GC> It seems curious that libtiff notices lzma but not zlib:
GC> 
GC>  Support for external codecs:
GC>   ZLIB support:                       no
GC>   ...
GC>   LZMA2 support:                      yes
GC> 
GC> but I don't actually care about that.

 Hmm, I don't see this here:

----------------------------------------------------------------------------
Libtiff is now configured for i686-w64-mingw32

  Installation directory:             /opt/lmi/local
  Documentation directory:            ${prefix}/share/doc/tiff-4.0.9
  C compiler:                         i686-w64-mingw32-gcc 
-fno-omit-frame-pointer -Wall -W
  C++ compiler:                       i686-w64-mingw32-g++ 
-fno-omit-frame-pointer
  Enable runtime linker paths:        no
  Enable linker symbol versioning:    no
  Support Microsoft Document Imaging: yes
  Use win32 IO:                       yes

 Support for internal codecs:
  CCITT Group 3 & 4 algorithms:       yes
  Macintosh PackBits algorithm:       yes
  LZW algorithm:                      yes
  ThunderScan 4-bit RLE algorithm:    yes
  NeXT 2-bit RLE algorithm:           yes
  LogLuv high dynamic range encoding: yes

 Support for external codecs:
  ZLIB support:                       yes
  Pixar log-format algorithm:         yes
  JPEG support:                       no
  Old JPEG support:                   no
  JPEG 8/12 bit dual mode:            no
  ISO JBIG support:                   no
  LZMA2 support:                      yes
----------------------------------------------------------------------------

 As you say, this isn't really important, but if you're curious, you could
have a look at config.log created by libtiff configure and search it to
find out why did zlib test fail.

 Regards,
VZ