You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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?
No PS fonts, here is the Change log
I am trying to get in touch with Tim Pearson. It is still copyright Caltech and it would be painful to have that changed I imagine, but if he put it on the ftp site at least we would have an official place to pull it from
Karl
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?
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).
@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.
@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?
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).
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.
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.
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.
Yes, I would not be confident how long that might stick around. But we definitely want to start from 5.3.1
HEASARC could be an option, do you have any contacts there?
Karl
On 25 Oct 2023, at 4:35 am, djerius ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADU7FGQCNGBJ2NY4Y6TAQN3YA735VAVCNFSM5C7VPXZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXG43TCMBZHA4A>.
You are receiving this because you were mentioned.
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.
Seems reasonable. I am surprised that it is even possible to get pgplot to work given how old it is!
I was meaning to take another look at Giza, they resolved a whole bunch of my ‘different behaviour to real pgplot issues’ recently
Karl
On 28 Oct 2023, at 3:51 am, djerius ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADU7FGUSVYTYTJ5GZEAGPG3YBPRBJAVCNFSM5C7VPXZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGMZDEMJXHAYQ>.
You are receiving this because you were mentioned.
@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.
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.
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.
Activity
djerius commentedon Aug 29, 2021
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?
karlglazebrook commentedon Aug 30, 2021
mohawk2 commentedon Oct 26, 2021
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?
karlglazebrook commentedon Oct 27, 2021
zmughal commentedon Jan 5, 2022
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/.
karlglazebrook commentedon Jan 5, 2022
karlglazebrook commentedon Jan 10, 2022
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.
zmughal commentedon Jan 13, 2022
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
autotoolparts 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.
mohawk2 commentedon Jan 13, 2022
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.
mohawk2 commentedon Jan 13, 2022
@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
f2cto 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?karlglazebrook commentedon Jan 17, 2022
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).
karlglazebrook commentedon Jan 17, 2022
PS I will recommend the 3-clause BSD to Tim. I think the VDP article is very persuasive.
mohawk2 commentedon Jan 17, 2022
This all makes sense. I think it will be useful for him to formulate an answer to this question:
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.
mohawk2 commentedon Feb 7, 2022
Any updates on this? Was just reminded by some conversation on
#debian-perl.djerius commentedon Feb 23, 2022
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.
11 remaining items
djerius commentedon Oct 23, 2023
Karl, I got your email to Tim; did Tim ever reply? If he did, he didn't reply-all.
karlglazebrook commentedon Oct 24, 2023
djerius commentedon Oct 24, 2023
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.
karlglazebrook commentedon Oct 26, 2023
djerius commentedon Oct 26, 2023
I've sent email to the help address for Xspec, the HEASARC package which incorporates PGPLOT.
djerius commentedon Oct 27, 2023
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.
karlglazebrook commentedon Nov 7, 2023
mohawk2 commentedon Mar 3, 2024
@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.
mohawk2 commentedon Mar 30, 2024
@karlglazebrook By the way, if you looped me in on any email to anyone at Caltech, I never received it?
karlglazebrook commentedon Apr 10, 2024
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.
karlglazebrook commentedon Apr 10, 2024
Regarding Giza, that is something I need to test again. I saw they made a bunch of changes last year but haven't tested.
mohawk2 commentedon Apr 11, 2024
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.
karlglazebrook commentedon Apr 12, 2024
mohawk2 commentedon Apr 13, 2024
ETJ at cpan.org please!
karlglazebrook commentedon Apr 14, 2024