Re: [Plplot-devel] Freeze and release dates now much better determined

[Alan W. Irwin]

On 2016-12-14 10:10-0500 Pedro Vicente wrote:

> Hi Alan
>
>>> spend an hour or so inserting write statments until I finally
>>> identify
>>> the Linux system call that is causing the long pause.
>
> debugging with write statements is for me the last option.
> it's ok for small bits of our own code, but in cases where you need to
> go deep into third
> party libraries's code it's no fun.

Hi Pedro:

I also normally prefer to use gdb (the Linux debugger that you are
also running from your Linux IDE) for debugging rather than
old-fashioned insertion of write statements to debug.  Nevertheless,
in this special case we likely have a time-dependent race condition
between two processes that are running (and just for the case when
they are running for the second time too close to when they ran
before).  So for this special case I believe the old-fashioned debug
methods are likely the best.

By the way, since putting off the const correctness topic until post
release, I feel much more on top of the release process, and I am
extremely curious about the cause of this "long pause" issue in case
there turns out to be a simple fix.  So if I don't hear from Phil by
later today that he is spent the required hour himself, I will likely
insert sufficient write statements in the -dev wxwidgets code and
wxPLViewer code to finally pin down the exact system call that is
causing the long pause.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Freeze and release dates now much better determined

[Pedro Vicente]

Hi Alan

>>spend an hour or so inserting write statments until I finally 
>> identify
>>the Linux system call that is causing the long pause.

debugging with write statements is for me the last option.
it's ok for small bits of our own code, but in cases where you need to 
go deep into third
party libraries's code it's no fun.

when I found the  linux wxwidgets bug I reported last week, I wrote
a Qt project that allows to debug PLplot and wxWidgets

it's here

https://github.com/pedro-vicente/plplot-wxwidgets/blob/master/wx_plplot/wx_plplot.qt.ubuntu.x86_64.pro

this project is hardcoded for Ubuntu 14.04 x86_64

to adapt to other linux and PLplot/wxWidgets installations, just 
replace these locations

dir_inc_plplot = /usr/local/include/plplot
  dir_lib_plplot = /usr/local/lib
  dir_inc_wx = /usr/include/wx-3.0
  dir_inc_wx_gtk = /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0
dir_lib_wx = /usr/local/lib

and then do

wx-config --cxxflags

the output is like this

-I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-pthread

so, replace here

DEFINES += _FILE_OFFSET_BITS=64
DEFINES += WXUSINGDLL

and the same for

wx-config --libs

on the LIBS part

then build all libraries with -g

-Pedro



On 2016-12-14 04:28, Alan W. Irwin wrote:
> Short story: freeze deadline now chiselled in stone as December 17th.
> But that is just for intrusive fixes, and small bug fixes and large
> or small documentation updates can continue through to the day
> of the release which might be only 5 days later, December 22nd (if
> our further
> comprehensive testing doesn't turn up any release critical issues) or
> 10 days later
> December 27th if there are some release-critical issues to address.
>
> Longer story with remarks relevant to Phil's current bug hunt at the 
> end:
>
> For quite some time I have been working (off and on) on a high impact
> topic branch where I am attempting to restore const correctness to 
> our
> PLplot code.  That topic branch is high impact because there will be 
> a
> backwards incompatibility introduced for most of our generic pointer
> use [which will effectively change from void * to const void *].
> Several days ago I finally realized it was hopeless to get this topic
> matured enough for the present release so I am putting off merging
> this topic to master until early in the next release cycle.  At the
> same time I managed to copy the updated include/plplot.h for this
> topic branch (which defines some additional useful self-documenting
> PLplot typedef additions) to the master branch with one typedef 
> change
> to retain backwards compatibility for now.  There were excellent
> results for that superficially intrusive change using unconstrained
> comprehensive testing with CMake-3.7.0.  Today I followed up with a
> similar excellent results for unconstrained comprehensive testing
> using CMake-3.0.2.  (See
> 
> 
> for the summary of these recent tests, and
>  for the ctest
> subset of these results for the CMake-3.0.2 test.
>
> So I now have nearly the total range of CMake versions that we accept
> for Linux covered by excellent comprehensive test results of our git
> master tip, and for non-Linux systems where the minimum version of
> CMake that we accept is 3.6.2, I am hoping for similar good results
> for Arjen on Cygwin (latest CMake version there is currently 3.6.2)
> and MinGW-w64/MSYS2 (latest CMake version there is currently 3.7.0). 
> I
> also hope that someone here with access to Mac OS X will try
> comprehensive testing on that platform with needed open-source
> libraries from one of Fink, MacPorts, or HomeBrew (all of whom 
> provide
> CMake-3.7.0 or 3.7.1) to make at least one of those platforms as well
> supported as Linux or the above two Windows platforms.
>
> But regardless of the response I get on my request for comprehensive
> testing I am already done with my own comprehensive testing.  Thus, I
> am in a mode where I plan to pick off just small bug issues and work
> on my topic branch consisting of a large update to our documentation
> that I plan to merge to master tip some time shortly before the
> release.
>
> So as far as I am concerned, because of the above decision to put off
> working on the const correctness topic, I am already in post-freeze
> mode (where only small bug fixes and/or large documentation updates
> are acceptable for merging to master) and even beyond comprehensive
> testing mode.  Of course, the formal date of the freeze still remains
> December 17th to accomodate Phil if he has any chance at all of
> tracking down and fixing the wxwidgets long pause issue by then.
>
> I wish him the best on that important bug hunt because it has large
> impact on my testing of wxwidgets, but I am not going to delay the
> release for that fix.  So if he doesn't