Re: [Plplot-devel] PLplot should be ready for comprehensive testing on modern software stacks

[Orion P. <or...@nw...>]

On 4/24/26 14:15, Alan W. Irwin wrote:
> Hi Orion:
> 
> It was good to hear from you, and I am glad you are taking a look at 
> PLplot again.
> 
> Before going any further, there seems to be a problem with your 
> SourceForge email address.
> Because I recently wrote you at that email address with regard to your 
> merge request 8, but
> from what you said above, I don't think you ever received that email.

That may be.  But I'm not sure that there is anything I can do about it. 
  Everything seems fine to my in my SF account setting.  I don't see any 
notes in the merge request itself

> The issue, is your merge request 8 fixes just one of the (ignored)
> function pointer versus pointer issues in the PLplot code.  If for git
> master you configure a full PLplot and then run "make install" you
> will find (for gcc-14) a large number of warnings concerning these
> issues, and, it sounds like these turn into errors for gcc-15.
> 
> Would you please take a look at those?  My C skills are so rusty these
> days, I didn't even completely understand your simple fix in merge
> request 8. 

I'm not sure I'm going to have time to look at more things.  FWIW 
plplot is currently building fine in Fedora with gcc 15.

  And my sourceforge skills are also so rusty, I need help from
> you on how to apply your merge requests.  The old-fashioned method I
> am familiar with is git format-patch from you and git am from me to
> apply your commit(s) to a local topic branch that is based on git
> master.  I assume that is easy to do with your merge request, but how?

When you go to https://sourceforge.net/p/plplot/plplot/merge-requests/8/ 
you should have a button to merge the commit.  Alternatively it should 
show you the commands needed to manually do the merge.

If you want a local tree to build, you should be able to do:

git remote add opoplawski ssh://airwin@git.code.sf.net/u/opoplawski/plplot

(above is one line)

git fetch opoplawski
git checkout -b signal opoplawski/signal

> 
> Of course, after your commit is accessible to me on a private topic
> branch, I will test it, and if that is a success, I will amend your
> commit message to say something about my good test, merge --ff-only to
> master and push it.
> 
> Other issues you mentioned above:
> 
> * lib-LASi:  Good point, and I will get to that eventually.  Meanwhile, 
> disable those devices.
> 
> * Tcl/Tk 9:  I was not aware of version 9 issues, but I believe my 
> recent commit has solved all
>    version 8 issues, so please try 9 again to see if there are any 
> issues left.

There are definitely issues.  One example:

/builddir/build/BUILD/plplot-5.15.0-build/plplot-plplot-323ccb5c8dd5d42a926fbbbaca94022767a98a2f/bindings/tcl/tclMatrix.c:536:46: 
error: passing argument 3 of ‘Tcl_SplitList’ from incompatible pointer 
type [-Wincompatible-pointer-types]
   536 |         if ( Tcl_SplitList( interp, args[i], &numnewargs, 
&newargs )
       |                                              ^~~~~~~~~~~
       |                                              |
       |                                              int *
In file included from /usr/include/tcl.h:2431,
                  from 
/builddir/build/BUILD/plplot-5.15.0-build/plplot-plplot-323ccb5c8dd5d42a926fbbbaca94022767a98a2f/bindings/tcl/tclMatrix.h:36,
                  from 
/builddir/build/BUILD/plplot-5.15.0-build/plplot-plplot-323ccb5c8dd5d42a926fbbbaca94022767a98a2f/bindings/tcl/tclMatrix.c:41:
/usr/include/tclDecls.h:1799:64: note: expected ‘Tcl_Size *’ {aka ‘long 
int *’} but argument is of type ‘int *’
  1799 |                                 const char *listStr, Tcl_Size 
*argcPtr,
       | 
~~~~~~~~~~^~~~~~~


> 
> * Qt6 (and apparently the pyqt5 and pyqt6 sip issues mentioned by
>    Rafael): my recent commit message gave a roadmap for dealing with
>    all these issues, but it will take some time because sip's modern
>    replacement uses an entirely different method to generate python
>    bindings for Qt5 and Qt6.  Meanwhile, Qt5 (but not pyqt5) works
>    really well (all previous segfaults for the earlier versions of the
>    Qt5 library are now gone) for Debian Trixie so dealing with these
>    Qt6 and pyqt5 and 6 issues should not be too hard.
> 
> BTW, there are several other roadmaps in that commit message for issues 
> I discovered but
> ignored.  But I believe the function pointer versus ordinary pointer 
> issue is the most
> important of these.
> 
> Cheers,
> 
> Alan

-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/