Skip to content

pgplot 5.3.1 #1

Open
Open

Description

@karlglazebrook

Are you aware that the final release of pgplot was in fact 5.3.1?

This was released in 2005, and even includes some new pgXX() routines.

It is not on the Caltech ftp site, there is a tarball floating around the web that I have. I used it for SciPDL for a few years as it included sys_darwin configs.

I have written to Tim Pearson to try and ascertain the status to get him to release it. It seems he has retired but I have good contacts at Caltech

Activity

  1. djerius commented on Aug 29, 2021

    @djerius
    Owner

    I had no idea there was a later release. PGPLOT distribution has always been problematic because of the copyright, so if you can get that cleared up I'm more than happy to autotool it.

    The HEASARC XSPEC package has a fairly hacked up version of PGPLOT (includes Postscript fonts). I always assumed they did that themselves, but maybe it's part of 5.3.1?

  2. karlglazebrook commented on Aug 30, 2021

    @karlglazebrook
    Author
  3. mohawk2 commented on Oct 26, 2021

    @mohawk2

    PGPLOT does appear to be copyrighted by Caltech. Therefore, @karlglazebrook are you able to reach out to whomever at Caltech deals with their intellectual property to update the situation, hopefully opening the licence to something more permissive (3-clause BSD?) and/or officially distributing the latest, and/or updating the Tim Pearson site (https://sites.astro.caltech.edu/~tjp/pgplot/#copyright) if he's now retired?

  4. karlglazebrook commented on Oct 27, 2021

    @karlglazebrook
    Author
  5. zmughal commented on Jan 5, 2022

    @zmughal
    Contributor

    Correct me if I'm looking at the wrong thing, but is this the tarball for
    PGPLOT v5.3.1: https://sites.astro.caltech.edu/~tjp/pgplot/macos/pgplot531.tar.gz?

    This is linked via https://sites.astro.caltech.edu/~tjp/pgplot/macos/.

  6. karlglazebrook commented on Jan 5, 2022

    @karlglazebrook
    Author
  7. karlglazebrook commented on Jan 10, 2022

    @karlglazebrook
    Author

    I've finally been able to make contact with Tim. He is willing to ask Caltech to change the license, and to put pgplot on GitHub.

    He asks what might be the best open source license to use? Noting GPL also has problems in derived software.

  8. zmughal commented on Jan 13, 2022

    @zmughal
    Contributor

    Though I do like GPL and use it for some of my code (along with the Perl_5 license), for PGPLOT I would recommend 3-clause BSD:

    It would be compatible with the license of the autotool parts of this project which are under GPLv3 (would be good to clarify which parts are under which license).

    Aside: Giza uses GPLv2 https://github.com/danieljprice/giza/blob/master/COPYING.

  9. mohawk2 commented on Jan 13, 2022

    @mohawk2

    Great work Karl!

    @zmughal I do agree that generally 3-clause BSD is a better approach, and https://wiki.debian.org/DFSGLicenses indicates Debian's DFSG are content with it. That should mean we can switch their packaging of the Perl library back to real PGPLOT, which hopefully is easy to execute. Now that I've dipped my toe in the water of being a Debian Perl person I might even be able to assist.

  10. mohawk2 commented on Jan 13, 2022

    @mohawk2

    @karlglazebrook Do you think that if the project is put on GitHub, that Tim would be open to adding Diab, and maybe Zaki, you, and/or me as collaborators? What is his thinking about who can make new release versions?

    Is he committed to it staying primarily in Fortran, or is he open to using f2c to switch to C? (I can easily imagine it would be important to stay in Fortran, but don't ask, don't get) If he is thus committed, which version? Does it have to stay F77?

  11. karlglazebrook commented on Jan 17, 2022

    @karlglazebrook
    Author

    I think he would be happy to have us as collaborators.

    That said, I think he has no intention of ever doing any more work on it again. I would expect the best course is to get it on GitHub, and then any development should be on a forked copy. (PGPLOTng or something).

  12. karlglazebrook commented on Jan 17, 2022

    @karlglazebrook
    Author

    PS I will recommend the 3-clause BSD to Tim. I think the VDP article is very persuasive.

  13. mohawk2 commented on Jan 17, 2022

    @mohawk2

    I think he would be happy to have us as collaborators.

    That said, I think he has no intention of ever doing any more work on it again. I would expect the best course is to get it on GitHub, and then any development should be on a forked copy. (PGPLOTng or something).

    This all makes sense. I think it will be useful for him to formulate an answer to this question:

    • who is allowed to designate a new version of PGPLOT? Is it only him, or is he happy to pass that to a new release manager?

    If there can be a new release manager, then we could make a PGPLOT 6.0.0 with some tweaks. If not, then as soon as PGPLOT is re-licensed we can make a PGPLOTng 6.0.0.

    Either way, unless there is strong appetite to keep it in Fortran (and as I've just updated PDL's Slatec and Minuit Fortran code to work right under 64-bit, I have opinions on this), we should switch over using f2c. Frankly, the Slatec stuff was agonising due to F77 doing signature-guessing rather than C's header-file signature-specifying.

    A much-less urgent question: where would we want to host this on GitHub? If we have to fork to PGPLOTng, we might as well host it in PDLPorters? Otherwise we can make a PGPLOT organisation.

  14. mohawk2 commented on Feb 7, 2022

    @mohawk2

    Any updates on this? Was just reminded by some conversation on #debian-perl.

  15. djerius commented on Feb 23, 2022

    @djerius
    Owner

    Either way, unless there is strong appetite to keep it in Fortran (and as I've just updated PDL's Slatec and Minuit Fortran code to work right under 64-bit, I have opinions on this), we should switch over using f2c. Frankly, the Slatec stuff was agonising due to F77 doing signature-guessing rather than C's header-file signature-specifying.

    f2c kills performance. it generates loops that are highly inefficient because it doesn't know if increments are positive or negative at run-time, so writes code which checks for both at runtime.

  16. 11 remaining items

  17. djerius commented on Oct 23, 2023

    @djerius
    Owner

    Karl, I got your email to Tim; did Tim ever reply? If he did, he didn't reply-all.

  18. karlglazebrook commented on Oct 24, 2023

    @karlglazebrook
    Author
  19. djerius commented on Oct 24, 2023

    @djerius
    Owner

    One option is that, as long as the CalTech PGPLOT 5.3.1 link is live, this repo turns into a massive patch against that source. We can distribute the patch, and copy the source, patch it and then install it.

    We could reach out to HEASARC, who maintain their own fork of PGPLOT for Xspec, and see how they are allowed to distribute it.

    Or we can simply incorporate the updated code and move on.

  20. karlglazebrook commented on Oct 26, 2023

    @karlglazebrook
    Author
  21. djerius commented on Oct 26, 2023

    @djerius
    Owner

    I've sent email to the help address for Xspec, the HEASARC package which incorporates PGPLOT.

  22. djerius commented on Oct 27, 2023

    @djerius
    Owner

    I've sent email to the help address for Xspec, the HEASARC package which incorporates PGPLOT.

    I've heard back from Keith Arnaud, and their licensing situation is kind of messy, so there's nothing we can gain from their experience.

    Regardless of how we approach the end result, 5.3.1 should be integrated. I'll try and set aside sometime to do that in the near future; feel free to poke me if it seems like it's taking too long.

    In the meantime, I think that the parallel work on the Perl PGPLOT module to use Alien::PGPLOT should begin/continue (or whatever state it's in). With the dropping of PGPLOT from Linux Distributions (and its replacement, at least in Debian, with the not-quite-feature-complete Giza), the current approach in the Perl PGPLOT module to find the PGPLOT library is essentially EOL.

  23. karlglazebrook commented on Nov 7, 2023

    @karlglazebrook
    Author
  24. mohawk2 commented on Mar 3, 2024

    @mohawk2

    @karlglazebrook How close is Giza? I don't mind us switching fully over (including in the Perl binding) if it's properly good enough, but I'm not qualified to judge that.

  25. mohawk2 commented on Mar 30, 2024

    @mohawk2

    @karlglazebrook By the way, if you looped me in on any email to anyone at Caltech, I never received it?

  26. karlglazebrook commented on Apr 10, 2024

    @karlglazebrook
    Author

    Hmm I may have used the wrong email address. I was trying to use non-github ones. Anyway the last two attempts were Aug and Oct 2023. Neither elicited a response.

  27. karlglazebrook commented on Apr 10, 2024

    @karlglazebrook
    Author

    Regarding Giza, that is something I need to test again. I saw they made a bunch of changes last year but haven't tested.

  28. mohawk2 commented on Apr 11, 2024

    @mohawk2

    Please can you loop me in on the conversation? I'd like to reach out to Caltech myself to get this sorted out, and it will help if I have names and/or a bit more context :-)

    Also, if you could try out Giza that will be helpful.

  29. karlglazebrook commented on Apr 12, 2024

    @karlglazebrook
    Author
  30. mohawk2 commented on Apr 13, 2024

    @mohawk2

    ETJ at cpan.org please!

  31. karlglazebrook commented on Apr 14, 2024

    @karlglazebrook
    Author
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions