Re: [Plplot-general] PLplot+wxWidgets+MinGW+Windows10

[Tom Schoonjans via Plplot-general]

Hey David,

The error is coming out of C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp, 
so you will need to patch that file. I guess this fix should also go into the 
PLplot git repo.

Best,

Tom

> On 17 Oct 2019, at 20:41, David Bergman  wrote:
> 
> Tom, thanks for your input but I'm not even writing code yet.  This is a 
> build error and I'm using the out of the box make, cmake and other scripts so 
> I wouldn't know what file to put those lines of code in.  Any thoughts?
> 
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
> On Thu, Oct 17, 2019 at 2:46 PM, Tom Schoonjans via Plplot-general
>  wrote:
> ___
> Plplot-general mailing list
> Plplot-general@lists.sourceforge.net 
> <mailto:Plplot-general@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/plplot-general 
> <https://lists.sourceforge.net/lists/listinfo/plplot-general>
> 

___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] PLplot+wxWidgets+MinGW+Windows10

[Tom Schoonjans via Plplot-general]

Hi David,

To use rand_s you need to start your source file with:

#define _CRT_RAND_S
#include 


It is crucial that these lines precede all your other includes, because other 
headers may already have dragged in stdlib.h

Best,

Tom

> On 17 Oct 2019, at 19:03, David Bergman  wrote:
> 
> All,
> 
> I am in the process of trying to set up wxWidgets and plplot for development 
> using code::blocks with mingw on a Windows 10 machine.
> I previously had a configuration working on a Windows 8 machine with VS 2017 
> but that machine is deceased.
> wxWidgets installed fairly easily with no issues reported and everything 
> looks good (though I have not run any test examples yet).
> 
> The PLplot build ran and connected to wxWidgets (found it and finished 
> reporting it as being ON).  Running ming32-make at the command prompt I 
> eventually get a failure at 79% with the following error message (cut and 
> pasted at end of message).  I am using wxWidgets-3.1.2 and PLplot-5.15.0.  I 
> followed the commands for installing using mingw32-make that can be found on 
> the wiki for each product.
> 
> I have reached out to the plplot group but I'm also asking wxwidgets to look 
> at the output since the error message mentions files included from the 
> wxwidgets include dir.  So it is not clear, to me, if the error is related 
> solely to plplot or also to widgets.  Before building plplot I defined 
> WXWIN= and included the dll dir, <>\lib\gcc_dll, in 
> the PATH.  My assumption is that I have misunderstood something but I cannot 
> figure it out.  My new build/install in a new Windows 8 machine with VS 2017 
> seems to work but apps crash upon closing and that has not been easy to track 
> down either.  Thank you in advance for your help.
> 
> David
> 
> 
> [ 79%] Building CXX object 
> drivers/CMakeFiles/wxwidgets.dir/wxwidgets_dev.cpp.obj
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp: In constructor 
> 'Rand::Rand()':
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp:647:25: error: 'rand_s' 
> was not declared in this scope
>  rand_s( _seed );
>  ^
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp: In member function 'void 
> Font::createFont()':
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp:736:101: warning: 
> 'wxFont::wxFont(int, int, int, int, bool, const wxString&, wxFontEncoding)' 
> is deprecated: use wxFONT{FAMILY,STYLE,WEIGHT}_XXX constants ie: 
> wxFONTFAMILY_SWISS, wxFONTSTYLE_NORMAL, wxFONTWEIGHT_BOLD 
> [-Wdeprecated-declarations]
>  m_font = wxFont( pt, family, style, weight, m_underlined, wxEmptyString, 
> wxFONTENCODING_DEFAULT );
> ^
> In file included from C:/temp/src/wxWidgets-3.1.2/include/wx/font.h:652:0,
>  from C:/temp/src/wxWidgets-3.1.2/include/wx/window.h:23,
>  from C:/temp/src/wxWidgets-3.1.2/include/wx/wx.h:38,
>  from C:\temp\src\plplot-5.15.0\drivers\wxwidgets.h:32,
>  from C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp:44:
> C:/temp/src/wxWidgets-3.1.2/include/wx/msw/font.h:124:5: note: declared here
>  wxFont(int size,
>  ^
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp: In member function 
> 'virtual void wxPLDevice::FillPolygon(PLStream*)':
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp:1010:58: warning: 
> 'wxPen::wxPen(const wxColour&, int, int)' is deprecated: use wxPENSTYLE_XXX 
> constants [-Wdeprecated-declarations]
>  wxPen edgePen( m_brush.GetColour(), m_scale, wxSOLID );
>   ^
> In file included from C:/temp/src/wxWidgets-3.1.2/include/wx/pen.h:84:0,
>  from C:/temp/src/wxWidgets-3.1.2/include/wx/dc.h:25,
>  from C:/temp/src/wxWidgets-3.1.2/include/wx/wx.h:50,
>  from C:\temp\src\plplot-5.15.0\drivers\wxwidgets.h:32,
>  from C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp:44:
> C:/temp/src/wxWidgets-3.1.2/include/wx/msw/pen.h:59:5: note: declared here
>  wxPen(const wxColour& col, int width, int style);
>  ^
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp: In member function 
> 'virtual void wxPLDevice::SetWidth(PLStream*)':
> C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp:1046:53: warning: 
> 'wxPen::wxPen(const wxColour&, int, int)' is deprecated: use wxPENSTYLE_XXX 
> constants [-Wdeprecated-declarations]
>  pls->curcolor.a * 255 ), width, wxSOLID );
>  ^
> In file included from C:/temp/src/wxWidgets-3.1.2/include/wx/pen.h:84:0,
>  from C:/temp/src/wxWidgets-3.1.2/include/wx/dc.h:25,
>  from C:/temp/src/wxWidgets-3.1.2/include/wx/wx.h:50,
>  from C:\temp\src\plplot-5.15.0\drivers\wxwidgets.h:32,
>  from C:\temp\src\plplot-5.15.0\drivers\wxwidgets_dev.cpp:44:
> C:/temp/src/wxWidgets-3.1.2/include/wx/msw/pen.h:59:5: note: declared here
>  

Re: [Plplot-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Tom Schoonjans via Plplot-general]

You’re welcome.

The issue here is that pango should never have been updated to 1.43.0 in MSYS2 
since it’s an unstable development release, as are all GNOME releases with an 
odd minor version number. Linux distributions and macOS package managers would 
never have packaged this release.

Best,

Tom

> On 4 Jan 2019, at 13:30, Alan W. Irwin  wrote:
> 
> On 2019-01-04 11:47+0530 Tom Schoonjans wrote:
> 
>> Hi all,
>> 
>> 
>> I ran into the same problem a couple of weeks ago. It is in fact a bug in 
>> pango 1.43.0 which uses meson as buildsystem instead of autotools, and the 
>> pkg-config issue was introduced in the transition.
>> 
>> I reported this as a bug 
>> <https://gitlab.gnome.org/GNOME/pango/merge_requests/22#note_390137> and 
>> submitted a patch <https://gitlab.gnome.org/GNOME/pango/merge_requests/38>, 
>> which is now in master and should end up in 1.44 (or possibly in 1.43.1 if 
>> this ever gets released).
>> 
>> In the meantime, the problem can be fixed by executing:
>> 
>>  echo "Requires: gobject-2.0" >> /mingw64/lib/pkgconfig/pango.pc
>> 
>> followed by building plplot… The cairo backend should build fine then.
>> 
> 
> Thanks, Tom, for that really helpful comment about what appears to be a
> widespread issue with pango 1.43.0.  That's a heavily used free
> library.  So let's hope the upstream pango developers quickly release
> 1.43.1 with your fix and that quickly propagates to free software
> distributions for Linux (thousands of them), Mac OS X (fink, macports,
> and homebrew), and Windows (Cygwin and MinGW-w64/MSYS2).
> 
> @Günter:
> 
> So to summarize, it looks like my recent tests on Debian Testing have
> been fine because I have installed cairo 1.42.3, and that platform has
> not (yet) got around to packaging cairo-1.43.0.  Arjen's test was also
> a success because he has cairo 1.42.1 currently installed (and has not
> yet updated his system), but your recent test failed because you did
> do such an update which exposed you to the bad pango 1.43.0 version.
> So hopefully Tom's above echo command will sort out the issue for you
> until upstream developers fix the issue, and that fix propagates to
> MinGW-w64/MSYS2.
> 
> At the same time, I also stand by my advice to drop "MinGW Makefiles"
> and mingw32-make and use the "Unix Makefiles" or "MSYS Makefiles"
> generators and bash and make instead simply because if you ever run
> into PLplot trouble with the platform, the very much enhanced test
> capability (via bash scripts) you have access to with the latter
> method can be quite useful, e.g., the report tarball that can
> be generated for that case makes it much easier to
> understand your bug reports.
> 
> @Arjen: you will likely also be affected by the same bug and have to do the 
> same fix
> when you update your own MinGW-w64/MSYS2.
> 
> And I will likely be affected by the same bug if Debian Testing starts 
> packaging
> pango 1.43.0.
> 
> Alan
> __
> Alan W. Irwin
> 
> 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
> __



___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Tom Schoonjans via Plplot-general]

Hi all,


I ran into the same problem a couple of weeks ago. It is in fact a bug in pango 
1.43.0 which uses meson as buildsystem instead of autotools, and the pkg-config 
issue was introduced in the transition.

I reported this as a bug 
 and 
submitted a patch , 
which is now in master and should end up in 1.44 (or possibly in 1.43.1 if this 
ever gets released).

In the meantime, the problem can be fixed by executing:

echo "Requires: gobject-2.0" >> /mingw64/lib/pkgconfig/pango.pc

followed by building plplot… The cairo backend should build fine then.

Best regards,

Tom

> On 4 Jan 2019, at 06:30, Alan W. Irwin  wrote:
> 
> Hi Günter:
> 
> I have put my reply to your message on the plplot-general mailing list
> since your remarks and mine will be of interest to subscribers there.
> Therefore, if you have not already subscribed to that list you should do so
> now since that is where such support requests are normally addressed.
> 
> More below in context.
> 
> On 2019-01-03 19:29+0100 Günter Kanisch wrote:
> 
>> Dear Alan,
>> 
>> After a longer time having worked with the 32-bit version of plplot under 
>> Windows, I want to migrate now to the 64-bit executable of my 
>> Fortran/GTK/plplot program.  The fortran mathematics and the GTK gui are 
>> already running as an 64-bit executable. However, building now plplot-5.14.0 
>> fails with linking the cairo.dll (in the path .. 
>> drivers/CMakeFiles/cairo.dir) resulting in two error messages: unknown 
>> reference to 'g_object_unref' .
>> 
>> I am working with MSYS2 (installed under d:\msys64\mingw64 under Windows 
>> 10); it contains the 64-bitcompilers and GTK and so on, but also 
>> mingw32-make.exe.
>> 
>> I tried it for some days now - and could not solve the problem. At least, 
>> its seems that cmake finds all the correct 64-bit versions of exe and dll 
>> files.
>> 
>> I attach a text file containing the console output of the cmake and 
>> thereafter of the mingw32-make command(s), executed by a small bacth file. 
>> The cairo-related errors appears at the end of the file. I cannot exclude 
>> that the two commands (cmake and then mingw32-make) which I used are not 
>> sufficient for a complete build.
>> 
>> Can you recommend some changes in my build steps which I could try then here?
> 
> I have no direct knowledge of the MinGW-w64/MSYS2 platform, but I keep
> in close touch with the PLplot developer Arjen Markus (who will be
> reading this on the plplot-general mailing list) who has had great
> recent success with the 64-bit MinGW-w64/MSYS2 platform.  That is, you
> will see at 
> that Arjen has achieved almost perfect comprehensive test results with
> this platform in October.  So there is excellent hope you will be able
> to achieve that near-perfection as well with PLplot on this platform.
> :-)
> 
> I have just looked at the report from that test (which he shared with
> me), and it appears his pango, and cairo CMake find results were
> similar to the ones you have attached, i.e.,
> 
> irwin@merlin> grep -Ei 'cairo|pango' 
> Arjen.Markus/20181026/MSYS2/shared/noninteractive/output_tree/cmake.out
> -- Checking for module 'pango'
> --   Found pango, version 1.42.1
> -- Checking for module 'pangoft2'
> --   Found pangoft2, version 1.42.1
> -- Checking for module 'pangocairo'
> --   Found pangocairo, version 1.42.1
> -- WARNING: X windows not found. Setting xcairo driver to OFF.
> -- Checking for modules 'lasi;pango;pangoft2'
> -- WARNING: pango, pangoft2, or lasi not found with pkg-config.
> -- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 
> support
> -- Determine compile and link flags for ext-cairo-test
> -- Checking for module 'cairo'
> --   Found cairo, version 1.15.12
> DRIVERS_LIST: cairo;qt;mem;ntk;null;pdf;ps;svg;wingcc;xfig
> DEVICES_LIST: 
> memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;ntk;null;pdf;ps;psc;svg;wingcc;xfig
> 
> irwin@merlin> grep -Ei 'cairo|pango' Günter.Kanisch/20190103/MSYS2/text9.txt 
> -- Checking for module 'pango'
> --   Found pango, version 1.43.0
> -- Checking for module 'pangoft2'
> --   Found pangoft2, version 1.43.0
> -- Checking for module 'pangocairo'
> --   Found pangocairo, version 1.43.0
> -- WARNING: X windows not found. Setting xcairo driver to OFF.
> -- Checking for modules 'lasi;pango;pangoft2'
> -- WARNING: pango, pangoft2, or lasi not found with pkg-config.
> -- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 
> support
> -- Determine compile and link flags for ext-cairo-test
> -- Checking for module 'cairo'
> --   Found cairo, version 1.16.0
> DRIVERS_LIST: cairo;mem;ntk;null;pdf;ps;svg;wingcc;xfig
> DEVICES_LIST: 
> 

Re: [Plplot-general] setting PLPLOT_LIB by a function at the start of the program

[Tom Schoonjans]

Hi

I can confirm that Arjen is right as I use the putenv PLPLOT_LIB trick myself 
on macOS and Windows. 

On Linux this is generally not necessary assuming PLplot is installed using the 
distribution package manager. 

Best

Tom

On 12 Oct 2017, at 10:23, Frédéric  wrote:

>> There is no need to worry about such interference: the environment is
>> private to the process and is inherited from whatever process started it.
> 
> Is this true on all OS (Windows, OSX and Linux)?
> If so, I just call putenv at the beginning of my program, that's simple.
> 
> Thanks,
> 
> F
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Plplot-general mailing list
> Plplot-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-general

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

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Tom Schoonjans]

Hi Alan,


Many thanks for your quick fix! It works fine: the pkg-config files are working 
fine now.

I would like to renew my request for a PLplot bug fix release though. 
Currently, 3 patches need to be applied to get the 5.11.1 compiling and working 
properly with the latest CMake.

Also, this kind of bug would have been detected easily with a continuous 
integration setup: that’s how I discovered this particular bug in fact.

Best,

Tom




> On 20 Nov 2016, at 00:46, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
> On 2016-11-15 03:37-0800 Alan W. Irwin wrote:
> 
>> On 2016-11-15 09:38- Tom Schoonjans wrote:
>> 
>>> Hi all,
>>> 
>>> 
>>> I would like to report that the last official CMake release produces buggy 
>>> and therefore useless PLplot pkg-config files.
>>> 
>> 
>> Thanks, Tom, for your report of this issue.  Is this report for the
>> official release of PLplot-5.11.1 or for the much later git master
>> branch version which is about to released as PLplot-5.12.0?  The
>> reason I ask is it is possible whatever the problem is has been fixed
>> in the git version.  But if you report that is not the case, I promise
>> to take a look at the issue (although likely late this week after I
>> have dealt with some other PLplot issues that are currently on my
>> plate).
> 
> Hi Tom:
> 
> I have now dealt with this issue (see commit db396b9).  Please look at
> that commit message for the detailed explanation.  Bottom line though,
> is we rely on sharp-eyed users or developers to pay close attention
> whenever there is a CMP0054 related warning because it is normally a
> sure sign that our CMake code is no longer working correctly (e.g.,
> this case) because of a subtle name clash.  In this case the variable
> called "c" was defined by CMake-3.7.0, and that nameclashed with our
> previous logic
> 
> if(BINDING STREQUAL "c")
> 
> As soon as we adopt a minimum version of CMake that is not in the dark
> ages, CMP0054 will automatically take on the NEW behaviour (anything
> in quotes within an if statement will not be dereferenced) and these
> nasty and completely unexpected nameclashes will be a thing of the
> past!
> 
> 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
> __

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Tom Schoonjans]

Hi Alan,


This is occurring for both PLplot 5.11.1 and master.

Thanks for looking into this.

Best,

Tom

> On 15 Nov 2016, at 11:37, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
> On 2016-11-15 09:38- Tom Schoonjans wrote:
> 
>> Hi all,
>> 
>> 
>> I would like to report that the last official CMake release produces buggy 
>> and therefore useless PLplot pkg-config files.
>> 
> 
> Thanks, Tom, for your report of this issue.  Is this report for the
> official release of PLplot-5.11.1 or for the much later git master
> branch version which is about to released as PLplot-5.12.0?  The
> reason I ask is it is possible whatever the problem is has been fixed
> in the git version.  But if you report that is not the case, I promise
> to take a look at the issue (although likely late this week after I
> have dealt with some other PLplot issues that are currently on my
> plate).
> 
> 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
> __


--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] Nightly testing?

[Tom Schoonjans]

Hi Alan,


I am confident that CMake is a decent build system. I will give it a try at 
some point.

Please do keep me up to date about the outcome of the discussion among the core 
developers of whether or not you’ll be moving to Github.
If it is decided to do so, I will gladly help out with the continuous 
integration setup.

In the meantime, I hope you will still consider making the bug fix release, 
before making the release with the features that are currently being 
added/tested.

Best,

Tom



> On 23 Sep 2016, at 23:15, Alan W. Irwin  wrote:
> 
> On 2016-09-23 12:30-0700 Alan W. Irwin wrote:
> 
>> Note, a decade-old build system normally accumulates a lot of cruft
>> and PLplot is no exception in that regard.  So reducing that cruft and
>> also learning to take advantage of modern CMake facilities requires a
>> substantial amount of on-going maintenance.  But I am happy to do that
>> maintenance because the result is a build system that is much more
>> sophisticated and useful than what we created a decade ago which in
>> turn was already a bit more sophisticated than what we could achieve
>> with autotools at that time.
> 
> I want to correct a slightly wrong impression I gave there.  I am
> positive that with enough care and learning experience anything we do
> with CMake could also be replicated by autotools and vice versa so
> fundamentally there is no limit on the sophistication of build systems
> implemented with _either_ CMake or autotools.
> 
> However, that said, it is also fair to say that once someone uses
> CMake seriously for a short time (it was just a few hours for me and
> other PLplot developers who wanted to change the PLplot build system
> in some way have had similar quick-learning experiences), they will
> find most build-system and test-system components so easy to implement
> with CMake that they by far prefer to use CMake rather than autotools
> for that task from then on.  Which is why we dropped our
> autotools-based build system so quickly a decade ago.
> 
> In sum, we were pretty heavy autotools users, but we tried CMake and
> never looked back.  And I expect most autotools users that try CMake
> will also have similar positive experiences with it.
> 
> 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
> __


--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] Nightly testing?

[Tom Schoonjans]

Hello once again,

Travis-CI and Appveyor are not part of Github, but are separate companies in 
their own right. They are just (popular) examples of companies that make use of 
the webhook and integration possibilities that are offered by Github. A list of 
similar companies can be found here: https://github.com/integrations 
<https://github.com/integrations>

To the best of my knowledge, most of these companies operate under a financial 
model that includes free usage by open source projects, but paid services for 
closed source projects (usually these are private repositories on Github, but 
private hosting is also possible). Either way, their usage is completely 
optional, though highly recommended. Even if one of these continuous 
integration providers would go broke or cease to provide free services for open 
source projects, there are alternative providers available, or they can just be 
turned off and other testing options could be found.

I have to admit that my knowledge of CMake, CTest and CDash is next to nothing 
(I am more of autotools kind of guy myself), but it looks promising. If you 
would get such a server up and running, I am sure there are ways to have a 
webhook following a commit trigger a build.

Best,

Tom

> On 22 Sep 2016, at 20:06, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
> Hi Tom:
> 
> On 2016-09-22 13:54+0100 Tom Schoonjans wrote:
> 
>> 
> [Hazen said]
>>> I am not familiar with Travis-CI or AppVeyor but they sound interesting.
>> 
>> Nowadays Continuous Integration is a standard tool for automated testing and 
>> building nightly releases. With Travis-CI and AppVeyor you can easily 
>> configure that each commit sets of a number of builds on Linux, Mac OS X and 
>> Windows using any combination of options and compilers you want. Plus it’s 
>> completely free for open-source projects!
>> 
>> It is also possible to require PRs to successfully build and survive testing 
>> on Travis-CI and AppVeyor as a precondition for being merged in.
>> 
>> For an example of Travis-CI and AppVeyor, have a look at for example 
>> https://github.com/tschoonj/easyRNG <https://github.com/tschoonj/easyRNG>, 
>> scroll to the end of the page and click on the green badges.
> 
> Even if we move to github I would advise whoever is in charge of such
> a move to not rely on semi-proprietary or proprietary products this
> way since "free of cost" can change to "costly" with one corporate
> decision at github.
> 
> I do agree that nightly testing of PLplot would be worthwhile.  In
> fact, we are already almost completely set up to do that with ctest,
> and very little more is required for anybody interested to publish
> their nightly PLplot ctest results in cdash client mode. So all that
> is essentially required is a cdash (see ) server to
> collect and display those results in convenient form on a website.
> KitWare already provides such a free service (see
> <http://my.cdash.org/>), but I recall there are some limitations
> (e.g., only a limited number of clients are allowed for a given
> project such as PLplot). But note that cdash is a completely
> open-source product so it should be straightforward to download that
> source and build a cdash server. So ultimately if the my.cdash.org
> limitations became an issue we would need to find a volunteer
> (presumably someone who is already running their own website) who is
> willing to build and host a cdash server for PLplot.
> 
> 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
> __

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] New release?

[Tom Schoonjans]

Hi Alan,


Releasing regularly new versions of the package is always good: it instills 
confidence in users that they are using a software package that is being 
actively developed and maintained.

However, I do think that the approach of having bug-fix branches is essential 
when making regular releases (3-6 months). Implementing new features (like the 
new Fortran bindings you mentioned) can take a long time, and it is difficult 
to predict when a new feature is ready to ship. After all, I am assuming none 
of the core developers are working full-time on PLplot right? This way of 
working unfortunately leads to large gaps between releases, which has led to 
the current situation where PLplot cannot be compiled with the latest version 
of CMake. Having a bug fix branch, and making releases off it, would ensure 
that PLplot can quickly address incompatible changes in its dependencies, or 
just fix important bugs, while relieving the developers from the pressure of 
having to produce a new release that will be a mixture of (hopefully properly 
working) new features and bug fixes.

Best,

Tom


> On 22 Sep 2016, at 20:01, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
> Hi Tom:
> 
> On 2016-09-22 13:54+0100 Tom Schoonjans wrote:
> 
>> In the scenario I am suggesting, you would just end up with a new
> branch that starts at a tag and will contain bug fixes only. It will
> never need to be merged into master as it will consist of commits that
> were cherrypicked from master.
> 
>> This kind of workflow is used for example by all GNOME projects such
> as glib and gtk+: development occurs on master, when a new major
> release is ready, a tag is created (e.g. 3.22.0), as well as a new
> branch with the name of that major release (gtk-3-22), which will then
> receive bug fixes that were cherrypicked from master, but not its new
> features! Every now and then maintenance releases will be created off
> this branch like 3.22.1, 3.22.2 etc.
> 
> This is certainly a possible approach, but in my view an even better
> (and simpler) approach would be to get out our releases (whether
> maintenance releases or otherwise) in a timely manner, i.e., every 3-6
> months.  I have obviously fallen short of that goal for this release,
> but I also hope to do a lot better moving forward!
> 
> 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
> __


--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] Possible move to github?

[Tom Schoonjans]

Hi Alan,



 A move to Github would certainly be advantageous for a number of reasons:

- It would make receiving contributions and patches a lot easier (git-patch is 
not that cool). The fork-pullrequest system is phenomenally good.
- Github provides a more pleasant user experience on its website: no one is 
confronted with annoying ads when downloading tarballs
- Github is a more stable and reliable host: it has a very impressive uptime, 
and I think we all remember SF’s week long outage last year… As another 
example, it took me yesterday three attempts before I could successfully clone 
the PLplot repository.
- Github is considerably less evil than SF 
https://en.wikipedia.org/wiki/SourceForge#Controversies 
<https://en.wikipedia.org/wiki/SourceForge#Controversies>

Moving the git repository to Github itself would be trivial. Just use 
https://github.com/new/import <https://github.com/new/import>, but I do 
recommend using the PLplot organization as owner. Just add yourself to it first 
and get sufficient privileges. Hazen I think you would be able to help out here 
since you seem to be in charge of this organization.

The git history would be identical to the current one as it is a direct copy. 
Afterwards you can enforce whatever workflow you are comfortable with regarding 
contributions/patches.

The website you host at plplot.sourceforge.net <http://plplot.sourceforge.net/> 
is another matter. Github does allow you to host websites (e.g. 
plplot.github.io), but they have to be static: no PHP! However there is nothing 
from switching the git repo to github while keeping the website where it is 
right now. This is actually pretty common.

Same for downloads: either they can stay where they are or they can be moved to 
github.

On to the next email!

Tom


> On 22 Sep 2016, at 19:50, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
> Hi Tom:
> 
> On 2016-09-22 13:54+0100 Tom Schoonjans wrote:
> 
>> Hello again,
>> 
> [Hazen asked]
>>> We have been trying to maintain a linear history with git following
> the process explained in the README.developers file. I think that the
> fork and pull-request system would break this?
> 
>> Not necessarily, you can ask people submitting a PR that they rebase
> against master. You can even enforce as a required check before
> merging that new branches are up to date with the latest changes in
> master.
> 
> @Tom:
> 
> Keeping both a github and SF repository adds quite a bit of work so I
> think what we are really discussing is whether we want to move
> completely to github.  But that move is a lot of work as well. I (as
> current de facto maintainer of our official git repository at
> SourceForge) would not want to do such work.  However, if someone else
> wanted to take up the responsibility of maintaining our official git
> repository, I would be happy to hand over that responsibility. Furthermore, 
> if they decided it would be a good idea to move to
> github, I would not get in the way of such a move so long as such a
> move did not dictate our git workflow and our git history (currently
> stretching back to the early 90's) was preserved.  More later about our 
> workflow
> under a different subject line
> 
> 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
> __

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] New release?

[Tom Schoonjans]

Hello again,

> We have been trying to maintain a linear history with git following the 
> process explained in the README.developers file. I think that the fork and 
> pull-request system would break this?

Not necessarily, you can ask people submitting a PR that they rebase against 
master. You can even enforce as a required check before merging that new 
branches are up to date with the latest changes in master.

In the scenario I am suggesting, you would just end up with a new branch that 
starts at a tag and will contain bug fixes only. It will never need to be 
merged into master as it will consist of commits that were cherrypicked from 
master.
This kind of workflow is used for example by all GNOME projects such as glib 
and gtk+: development occurs on master, when a new major release is ready, a 
tag is created (e.g. 3.22.0), as well as a new branch with the name of that 
major release (gtk-3-22), which will then receive bug fixes that were 
cherrypicked from master, but not its new features! Every now and then 
maintenance releases will be created off this branch like 3.22.1, 3.22.2 etc.

> I am not familiar with Travis-CI or AppVeyor but they sound interesting.

Nowadays Continuous Integration is a standard tool for automated testing and 
building nightly releases. With Travis-CI and AppVeyor you can easily configure 
that each commit sets of a number of builds on Linux, Mac OS X and Windows 
using any combination of options and compilers you want. Plus it’s completely 
free for open-source projects!

It is also possible to require PRs to successfully build and survive testing on 
Travis-CI and AppVeyor as a precondition for being merged in.

For an example of Travis-CI and AppVeyor, have a look at for example 
https://github.com/tschoonj/easyRNG <https://github.com/tschoonj/easyRNG>, 
scroll to the end of the page and click on the green badges.


Best,

Tom

> On 22 Sep 2016, at 13:29, Hazen Babcock <hbabc...@mac.com> wrote:
> 
> On 09/22/2016 04:58 AM, Tom Schoonjans wrote:
>> 
>> Thanks for the fast reply.
>> 
>> I appreciate that you want to make sure that all newly implemented features 
>> have been properly tested before making the next release. Surely we can all 
>> benefit from that.
>> 
>> However, since a new release is at least a month from now, I still would 
>> like to urge you to release a maintenance release (5.11.2) in the meantime, 
>> which branches off the commit tagged as ‘plplot-5.11.1’ and cherrypicks the 
>> two commits (and possibly other bugfixes) from master to ensure it builds 
>> properly with CMake 3.6.
>> 
>> On a side note, I am also wondering if it would be possible to set up a 
>> mirror of the repository on GitHub? The fork and pull-request system is 
>> extremely good for collaboration. Also, it would be trivial to implement 
>> continuous integration support with e.g. Travis-CI and AppVeyor, which 
>> should really make testing a lot easier. I would gladly help out with that.
>> 
>> Best regards,
>> 
>> Tom
> 
> We have been trying to maintain a linear history with git following the 
> process explained in the README.developers file. I think that the fork and 
> pull-request system would break this?
> 
> Also, I have been maintaining an unofficial mirror here:
> https://github.com/HazenBabcock/PLplot
> 
> And we do have a PLplot organization on github, though we've not done much 
> with it:
> https://github.com/PLplot
> 
> I am not familiar with Travis-CI or AppVeyor but they sound interesting.
> 
> best,
> -Hazen
> 

--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

[Plplot-general] New release?

[Tom Schoonjans]

Hi all,


I was wondering if a new release of PLplot could be made soon, as the current 
release does not build with CMake 3.6.x? The fix for it is currently in master.

Many thanks in advance and best regards,

Tom Schoonjans
--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general

[Plplot-general] Announcing Gtkmm-PLplot 1.0

[Tom Schoonjans]

Hi all,


It is my great pleasure to announce the first release of Gtkmm-PLplot, a 
library providing scientific plotting support for Gtkmm, built entirely around 
PLplot.

I started this project as I found that there were no plotting libraries around 
that were supporting Gtkmm-3 and I was badly in need for one.

I discovered that it’s really easy to combine Gtkmm and PLplot using a 
Gtk::DrawingArea and the extcairo plot device and decided to create an entire 
library around it.

Currently I am supporting two dimensional plots (including polar), contour 
plots with/without shades and three-dimensional plots of line data. Where 
appropriate, I have also added support for zooming by dragging selection boxes.

More features will follow in future releases.

I invite everybody to check out the library and have a look at the 
documentation (including screenshots) I am hosting at 
http://github.com/tschoonj/gtkmm-plplot 
<http://github.com/tschoonj/gtkmm-plplot> and 
http://tschoonj.github.io/gtkmm-plplot <http://tschoonj.github.io/gtkmm-plplot>.

Best regards,

Tom Schoonjans--
___
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general