[Pdl-general] SciPDL v2.088 release

[Karl Glazebrook via pdl-general]

Hi PDL folk,

I have now made a SciPDL version (drag and drop MacOS installer) of the latest 
PDL v2.088

Please find it, and some previous builds, at the new location:

https://github.com/PDLPorters/SciPDL/releases 


Let me know if there any issues using GitHub

Happy ANZAC day!


Karl


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

Re: [Pdl-general] SciPDL move

[Karl Glazebrook via pdl-general]

FYI I have now uploaded to the repo the scripts I use to build the DMG files 
and done a ‘release’ for my DMG build of PDL 2.084. The disclaimer is that I 
have zero confidence that the scripts will work for anyone other than me. But 
knock yourself out if you want to play

The releases are here:

https://github.com/PDLPorters/SciPDL/releases 
<https://github.com/PDLPorters/SciPDL/releases>

My next step will be to do this for the latest version

(The reason it is old is I was originally doing this back in January, but I was 
waiting until I could figure our the Apple Dev stuff…)

I will look forward to my first ‘issue’ :-)

Karl


> On 17 Apr 2024, at 8:52 pm, Ed .  wrote:
> 
> Hi Karl,
> 
> This seems like a really good approach!
> 
> I'm wondering whether to piggyback off the same repo to host the upcoming 
> Homebrew recipe for PDL, or make a new one? Probably the latter to minimise 
> conflicts.
> 
> Best regards,
> Ed
> 
> From: Karl Glazebrook via pdl-general 
> Sent: 16 April 2024 2:35 AM
> To: perldl 
> Subject: [Pdl-general] SciPDL move
>  
> Hi all
> 
> I’ve moved my SciPDL distribution (easy MacOS kitchen sink install) to a new 
> location:
> 
> 
> 
> PDLPorters/SciPDL: This is a repository for creating SciPDL distributions 
> (easy install of PDL on MacOS)
> github.com
>  <https://github.com/PDLPorters/SciPDL>PDLPorters/SciPDL: This is a 
> repository for creating SciPDL distributions (easy install of PDL on MacOS) 
> <https://github.com/PDLPorters/SciPDL>
> github.com <https://github.com/PDLPorters/SciPDL>
> This means I can do ‘releases’ without mucking up the main GitHub repo (sorry 
> Ed!)
> 
> I have even updated the pdl.perl.org <http://pdl.perl.org/> web pages to 
> point there, (first change in 2 years!)
> 
> Will add some more recent versions. I have 2.084 sitting on disk (Arm and 
> Intel) so I will just re-check and put that up in the next few days, and then 
> look at v2.087 which is hopefully straight forward…
> 
> I hope this is a good approach for the future.
> 
> best
> 
> Karl
> 

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

Re: [Pdl-general] SciPDL move

[Karl Glazebrook via pdl-general]

Thanks, probably best to keep seperate as they seem quite orthogonal?KarlOn 17 Apr 2024, at 8:52 PM, Ed .  wrote:




Hi Karl,


This seems like a really good approach!


I'm wondering whether to piggyback off the same repo to host the upcoming Homebrew recipe for PDL, or make a new one? Probably the latter to minimise conflicts.


Best regards,
Ed


From: Karl Glazebrook via pdl-general 
Sent: 16 April 2024 2:35 AM
To: perldl 
Subject: [Pdl-general] SciPDL move
 

Hi all


I’ve moved my SciPDL distribution (easy MacOS kitchen sink install) to a new location:



















PDLPorters/SciPDL: This is a repository for creating SciPDL distributions (easy install of PDL on MacOS)

github.com














This means I can do ‘releases’ without mucking up the main GitHub repo (sorry Ed!)


I have even updated the pdl.perl.org web pages to point there, (first change in 2 years!)


Will add some more recent versions. I have 2.084 sitting on disk (Arm and Intel) so I will just re-check and put that up in the next few days, and then look at v2.087 which is hopefully straight forward…


I hope this is a good approach for the future.


best


Karl





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

[Pdl-general] SciPDL move

[Karl Glazebrook via pdl-general]

Hi all

I’ve moved my SciPDL distribution (easy MacOS kitchen sink install) to a new 
location:

https://github.com/PDLPorters/SciPDL
PDLPorters/SciPDL: This is a repository for creating SciPDL distributions (easy 
install of PDL on MacOS)
github.com

This means I can do ‘releases’ without mucking up the main GitHub repo (sorry 
Ed!)

I have even updated the pdl.perl.org  web pages to point 
there, (first change in 2 years!)

Will add some more recent versions. I have 2.084 sitting on disk (Arm and 
Intel) so I will just re-check and put that up in the next few days, and then 
look at v2.087 which is hopefully straight forward…

I hope this is a good approach for the future.

best

Karl

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

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Thanks Ed.

Yes I can confirm the code snippet bugs as you describe on PDL-2.084

Good detective work and impressive use of git! Hope it is just a bug. I can 
also confirm it works on 2.077 and bugs on 2.078

Karl


> On 14 Jan 2024, at 1:16 am, Ed .  wrote:
> 
> Hi Karl,
>  
> Thank you for both reporting this issue, then doing this deep investigation 
> as well.
>  
> In order to track down exactly when this changed, I stripped down your repro 
> code to:
> use PDL::LiteF; # not full PDL so can just build “make core”
> $x = sequence(4)+1;
> $x = $x->mv(-1,0)->slice("0:2");
> $x *= 100;
> $y=::_clump_int($x,-1);
> print "x=$x y=$y\n";
> $wrong = "$y" eq "[0 0 0]";
> exit $wrong;
>  
> As you can see in that comment, if one comments out the multiplication, it 
> all still works correctly. The “sequence” can be replaced with hardcoded “pdl 
> [1..5]”. But if one changes either the “mv”, or the “slice”, or the inplace 
> “*=” (including replacing with “$x = $x * 100” ), or the “_clump_int”, it 
> doesn’t misbehave.
>  
> Anyway, using the above code to tell me whether I’d found where it started 
> failing, I did “git bisect” as follows (noted here to help anyone who wants 
> to do this themselves; I’d forgotten and had to look up how):
> git bisect start
> git bisect bad # current “master” is bad
> git bisect good 2.025 # tell it it was working as of 2.025
> perl Makefile.PL && time make core && perl -Mblib repro-script; echo $? # 
> kept running this, then:
> git bisect bad # if failing
> git bisect good # if working correctly
> git bisect reset # when finished, to close down the bisect
> Note the use of “make core” which takes about 2 mins from scratch on my 
> system, vs about 6 to “make” everything, saving lots of time.
>  
> It turns out it was this, which was released with 2.078:
> commit a4678091acf7e450c02a7b0feaf3c7578f37e53f
> Author: Ed J  <mailto:moha...@users.noreply.github.com>>
> Date:   Sun Apr 3 22:27:28 2022 +0100
>  
> parents of non-flowing trans also track trans_children so can de-register 
> on destroy
>  
> Basic/Core/pdlapi.c | 46 +++---
> 1 file changed, 19 insertions(+), 27 deletions(-)
>  
> I am now investigating a fix, which given how specific it is to trigger, will 
> probably be small, and is surely related to book-keeping of parents vs 
> children, and flowing transformations.
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook via pdl-general 
> <mailto:pdl-general@lists.sourceforge.net>
> Sent: 07 January 2024 06:30
> To: perldl <mailto:pdl-general@lists.sourceforge.net>
> Subject: Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue
>  
> Seems I can’t help myself! I have now found the offending line in rcols() and 
> can now reproduce this without rcols. That should at least make it easier to 
> track down.
>  
> use PDL;
> $x = sequence(100)+1; # This works
> $x = $x->mv(-1,0)->slice("0:3");
> print $x, "\n";
> $x *= 100;
> print $x, "\n";
> $y=::_clump_int($x,-1);
> print $y, "\n"; # prints [0 0 0 0]
> 1;
>  
> It seems to be the particular combination of ->mv and ->slice (that was on 
> line 693 of misc.pd). This is a 1D ndarray so the ->mv(-1,0) should do 
> nothing. Removing it however makes the problem go away.
>  
> Works fine in PDL-2.025. Some bug that has been introduced in ->mv ?
>  
> Sorry to the stream of consciousness series of emails. I will stop looking 
> now...
>  
> Karl
>  
>  
>  
> 
> 
> On 7 Jan 2024, at 4:32 pm, Karl Glazebrook  <mailto:karlglazebr...@mac.com>> wrote:
>  
> OK here is some deeper diving in to the problem
>  
>  
> use PDL;
> $x = rcols 'tmp.dat'; # This does causes the error
> #$x = sequence(4)+1; # This works
> print $x, "\n";
> $x *= 100;
> print $x, "\n";
> $y=::_clump_int($x,-1);
> print $y, "\n"; # prints [0 0 0 0]
> ;
>  
>  
>  
>  looks like the error is happening in the internal pp routine _clump_int in 
> slices.pd.
>  
>  
> I also found ->sever() had the same behaviour with rcols:
>  
> pdl> $x = rcols 'tmp.dat' 
>   
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
>  
> pdl> $x *= 100
>   
>  
> pdl> p $x                

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - scalars vs piddles

[Karl Glazebrook via pdl-general]

Hi Ed

I believe the original logic here (likely mine) was that if the 0D PDLs turned 
automatically in to scalars they could be fed directly, without casting, in to 
perl-to-C calls and PDL did a lot of that. e.g. I used to do a lot of direct 
calling of the PGPLOT module commands.

I guess if that sort of thing has now been extirpated from the PDL source 
(which seems likely given all tests pass) itself all is good. Probably not many 
end user scripts need fixing. I think you are right it is better these days if 
objects do not magically change type.

Happy for the name change :) It was not my joke...

Karl

> On 14 Jan 2024, at 12:46 am, Ed .  wrote:
> 
> Hi Karl,
>  
> Good to hear from you! And I hope that apart from the issues you’ve raised, 
> that your experience with the new PDL is good. Have a look at the updated 
> demo system, including the updated 3D demos, and see if you can tell the 
> pthreading is done automatically on large-enough data by detecting the number 
> of cores available by default.
>  
> The change in the aggregate functions was introduced in 2.056. I would now 
> say I didn’t take sufficient account of backwards compatibility on that one. 
> Sorry for the inconvenience. My reasoning was in how shocked I was that those 
> functions were returning Perl scalars.
>  
> By the way, you (of all people!) are welcome to call these data objects what 
> you like, but another change made (this time in 2.040) was to rename 
> “piddles” (which always struck me as faintly juvenile, and I felt would 
> undermine PDL’s credibility for no good reason) to “ndarrays”, which is a 
> widely-used term. The “piddle” function was retained for back-compatibility.
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook via pdl-general 
> <mailto:pdl-general@lists.sourceforge.net>
> Sent: 07 January 2024 00:29
> To: perldl <mailto:pdl-general@lists.sourceforge.net>
> Subject: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - scalars vs 
> piddles
>  
> Hi all,
> 
> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
> lame)
> 
> I noticed a few things when running one of my complicated codes, I will start 
> seperate email threads
> 
> Next I think this one is a design choice change I missed.
> 
> - Functions like median() max() etc now return a 0D piddle and no longer a 
> scalar. This broke some gnarly code I had.
> 
> I expect this change was sensible, I am just curious as the reasons and when 
> it happened?
> 
> 
> best
> 
> Karl
> 
> 
> 
> 
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net <mailto:pdl-general@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/pdl-general 
> <https://lists.sourceforge.net/lists/listinfo/pdl-general>
___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - PDL::NiceSlice issue

[Karl Glazebrook via pdl-general]

Thanks Ed & Luis. I will chalk that one as being down to the limitations of 
NiceSlice and update that particular code not to use it.

Karl


> On 14 Jan 2024, at 4:42 am, Ed .  wrote:
> 
> Hi Luis,
>  
> Thank you for your help on both this and the “clump” issue.
>  
> NiceSlice got changed (as a default) from the simpler but non-string-aware 
> Filter::Util::Call implementation (which would mangle eg SQL strings in the 
> code) to the string-aware but imperfect in other ways Filter::Simple 
> implementation in 2.063_04. You can set the environment variable 
> “PDL_NICESLICE_ENGINE” to Filter::Util::Call to use that, the previous 
> default.
>  
> Filter::Simple uses Text::Balanced, which got some sizable updates from me to 
> improve its parsing of Perl code, but still makes some mistakes, as you can 
> see. It works by finding all strings, comments, here-docs, and regexes, and 
> removes them from the code before filtering, then puts them back after. The 
> mistake here is that it misidentifies the text “$x/2/3” as having a regex in 
> the middle, which gets removed from the “code” as you see.
>  
> Similarly, Karl’s code which has “$y / (multi lines of stuff) / (other 
> stuff)” is being misidentified as the “y /(multi lines)/” being a regex. 
> Therefore it doesn’t go through the filter, therefore it retains its 
> non-correct Perl status, and Perl gives a syntax error.
>  
> A workaround is to avoid $y as a variable name, and possibly $x as well 
> (since “x” is an operator and may throw off the parsing, for now). I will 
> look at updating T:B to make it behave correctly in these cases, but that 
> won’t happen today I’m afraid. NiceSlice continues to cause me agony out of 
> all proportion to how “nice” it actually is. It’s a pity Perl doesn’t have a 
> properly hookable parser yet (at least to my knowledge).
>  
> Best regards,
> Ed
>  
> From: Luis Mochan <mailto:moc...@icf.unam.mx>
> Sent: 07 January 2024 02:46
> To: Karl Glazebrook <mailto:karlglazebr...@mac.com>
> Cc: perldl <mailto:pdl-general@lists.sourceforge.net>
> Subject: Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - 
> PDL::NiceSlice issue
>  
> I found some time back problems with NiceSlice. Actually, with
> Filter::Simple (used by default by NiceSlice, though it can use other
> options, controlled with environment variables). I vaguely recall that
> two slashes, as in two divisions consecutive, confuse it completely,
> as they seem as regular expression.
> 
> I found this in my notes of 2022-11-05:
> ---
> Make a filter:
>   package MyFilter;
>   use v5.36;
>   use Filter::Simple;
>   FILTER_ONLY
>   code_no_comments => sub { say "Code:\n$_" },
>   all => sub { say "All:\n$_" };
>   1;
> And a program:
>   use v5.36;
>   use lib ".";
>   use MyFilter;
>   my $x=1;
>   say $x/2/3;
> 
> Execution yields:
> 
>   Code:
>   my $x=1;
>   say $x3;
> 
>   All:
>   my $x=1;
>   say $x/2/3;
> 
>   0.1666667
> 
> This means that /2/ is removed incorrectly. The name of the variable
> ($x and not $y) seems important.
> ---
> 
> Regards,
> Luis
> 
> 
> 
> 
> On Sun, Jan 07, 2024 at 12:01:27PM +1100, Karl Glazebrook via pdl-general 
> wrote:
> >
> >
> > > On 7 Jan 2024, at 11:55 am, Karl Glazebrook via pdl-general 
> > >  > > <mailto:pdl-general@lists.sourceforge.net>> wrote:
> > >
> > > (The mismatch of line numbers seems to be related to the use of hereto 
> > > text earlier in the code, the debugger shows different line numbers)
> > >
> >
> >
> > PS just to prove this point given the line numbers issue:
> >
> >
> >
> >
> > syntax error at /Users/karl/Software/perl/KGB/Redshift.pm line 251, near 
> > "$FOO("
> > Execution of /Users/karl/Software/perl/KGB/Redshift.pm aborted due to 
> > compilation errors.
> >
> >
> >
> > You can see FOO triggers a compilation error and BAR does not, use 
> > PDL::NiceSlice is way at the top of the module
> >
> > Karl
> >
> 
> 
> > ___
> > pdl-general mailing list
> > pdl-general@lists.sourceforge.net <mailto:pdl-general@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/pdl-general 
> > <https://lists.sourceforge.net/lists/listinfo/pdl-general>
> 
> 
> -- 
> 
>   

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Seems I can’t help myself! I have now found the offending line in rcols() and 
can now reproduce this without rcols. That should at least make it easier to 
track down.

use PDL;
$x = sequence(100)+1; # This works
$x = $x->mv(-1,0)->slice("0:3");
print $x, "\n";
$x *= 100;
print $x, "\n";
$y=::_clump_int($x,-1);
print $y, "\n"; # prints [0 0 0 0]
1;

It seems to be the particular combination of ->mv and ->slice (that was on line 
693 of misc.pd). This is a 1D ndarray so the ->mv(-1,0) should do nothing. 
Removing it however makes the problem go away.

Works fine in PDL-2.025. Some bug that has been introduced in ->mv ?

Sorry to the stream of consciousness series of emails. I will stop looking 
now...

Karl




> On 7 Jan 2024, at 4:32 pm, Karl Glazebrook  wrote:
> 
> OK here is some deeper diving in to the problem
> 
> 
> use PDL;
> $x = rcols 'tmp.dat'; # This does causes the error
> #$x = sequence(4)+1; # This works
> print $x, "\n";
> $x *= 100;
> print $x, "\n";
> $y=::_clump_int($x,-1);
> print $y, "\n"; # prints [0 0 0 0]
> ;
> 
> 
> 
>  looks like the error is happening in the internal pp routine _clump_int in 
> slices.pd.
> 
> 
> I also found ->sever() had the same behaviour with rcols:
> 
> pdl> $x = rcols 'tmp.dat' 
>  
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
> 
> pdl> $x *= 100
>  
> 
> pdl> p $x 
>  
> [100 200 300 400]
> pdl> p $x->sever  
>  
> [0 0 0 0]
> 
> 
> Note this is not a general problem with dataflow, if I make a sequence and 
> slice or index is then the ops work fine. It is just something weird on the 
> ndarray produced by rcols.
> 
> Karl
> 
> 
> 
> 
> 
>> On 7 Jan 2024, at 3:41 pm, Karl Glazebrook via pdl-general 
>> > <mailto:pdl-general@lists.sourceforge.net>> wrote:
>> 
>> Ah! I believe the difference between medover and median is a clump(-1) to 
>> collapse the dimensions
>> 
>> There does it indeed to be something wrong with clump too, so that is 
>> probably the underlying cause
>> 
>> pdl> $x = rcols 'tmp.dat'
>>
>> Reading data into ndarrays of type: [ Double ]
>> Read in  4  elements.
>> 
>> pdl> p $x
>>
>> [1 2 3 4]
>> pdl> $x *= 100   
>>
>> 
>> pdl> p $x
>>
>> [100 200 300 400]
>> pdl> p $x->clump(-1)     
>>    
>> [0 0 0 0]
>> 
>> What could be happening in rcols() that produces an ndarray that behaves 
>> like that?
>> 
>> Karl
>> 
>> 
>>> On 7 Jan 2024, at 12:48 pm, Luis Mochan >> <mailto:moc...@icf.unam.mx>> wrote:
>>> 
>>> I noticed that medover and maxover do work as expected in this case.
>>> 
>>> 
>>> On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general 
>>> wrote:
>>>> Hi all,
>>>> 
>>>> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that 
>>>> is lame)
>>>> 
>>>> I noticed a few things when running one of my complicated codes, I will 
>>>> start seperate email threads
>>>> 
>>>> First there seems to be a serious rcols bug:
>>>> 
>>>> 
>>>> e.g. create a file
>>>> 
>>>> # tmp.dat
>>>> 1
>>>> 2
>>>> 3
>>>> 4
>>>> 
>>>> 
>>>> Loaded PDL v2.084 (supports bad values)
>>>> pdl> $x = rco

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

OK here is some deeper diving in to the problem


use PDL;
$x = rcols 'tmp.dat'; # This does causes the error
#$x = sequence(4)+1; # This works
print $x, "\n";
$x *= 100;
print $x, "\n";
$y=::_clump_int($x,-1);
print $y, "\n"; # prints [0 0 0 0]
;



 looks like the error is happening in the internal pp routine _clump_int in 
slices.pd.


I also found ->sever() had the same behaviour with rcols:

pdl> $x = rcols 'tmp.dat'   
   
Reading data into ndarrays of type: [ Double ]
Read in  4  elements.

pdl> $x *= 100  
   

pdl> p $x   
   
[100 200 300 400]
pdl> p $x->sever
   
[0 0 0 0]


Note this is not a general problem with dataflow, if I make a sequence and 
slice or index is then the ops work fine. It is just something weird on the 
ndarray produced by rcols.

Karl





> On 7 Jan 2024, at 3:41 pm, Karl Glazebrook via pdl-general 
>  wrote:
> 
> Ah! I believe the difference between medover and median is a clump(-1) to 
> collapse the dimensions
> 
> There does it indeed to be something wrong with clump too, so that is 
> probably the underlying cause
> 
> pdl> $x = rcols 'tmp.dat' 
>  
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
> 
> pdl> p $x 
>  
> [1 2 3 4]
> pdl> $x *= 100
>  
> 
> pdl> p $x 
>  
> [100 200 300 400]
> pdl> p $x->clump(-1)  
>  
> [0 0 0 0]
> 
> What could be happening in rcols() that produces an ndarray that behaves like 
> that?
> 
> Karl
> 
> 
>> On 7 Jan 2024, at 12:48 pm, Luis Mochan > <mailto:moc...@icf.unam.mx>> wrote:
>> 
>> I noticed that medover and maxover do work as expected in this case.
>> 
>> 
>> On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general 
>> wrote:
>>> Hi all,
>>> 
>>> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
>>> lame)
>>> 
>>> I noticed a few things when running one of my complicated codes, I will 
>>> start seperate email threads
>>> 
>>> First there seems to be a serious rcols bug:
>>> 
>>> 
>>> e.g. create a file
>>> 
>>> # tmp.dat
>>> 1
>>> 2
>>> 3
>>> 4
>>> 
>>> 
>>> Loaded PDL v2.084 (supports bad values)
>>> pdl> $x = rcols 'tmp.dat'
>>> Reading data into ndarrays of type: [ Double ]
>>> Read in  4  elements.
>>> 
>>> pdl> p $x
>>> [1 2 3 4]
>>> pdl> $x *= 100
>>> 
>>> pdl> p $x
>>> [100 200 300 400]
>>> pdl> p median($x)
>>> 0
>>> pdl> p $x
>>> [100 200 300 400]
>>> 
>>> 
>>> It seems the median function sees the values BEFORE the inplace 
>>> multiplacation, whereas print does not. This is very bad. min() and max() 
>>> are similar. No idea what is going on here! The behaviour or absent from 
>>> v2.025
>>> 
>>> Notes
>>> - making a $x->copy() removes the effect
>>> - creating $x using sequence also removes, so it is something to do with 
>>> rcols() and not inplace in general?
>>> 
>>> I’d be interested to know if others can reproduce this. It definitely needs 
>>> a fix
>>> 
>>> best
>>> 
>>> Karl
>>> 
>>> 
>>> 
>> 
>> 
>>> ___
>>> pdl-general mailing list
>>> pdl-general@lists.sourceforge.net <mailto:pdl-general@lists.sourceforge.net>
>>> https://lists.sourceforge.net/li

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Ah! I believe the difference between medover and median is a clump(-1) to 
collapse the dimensions

There does it indeed to be something wrong with clump too, so that is probably 
the underlying cause

pdl> $x = rcols 'tmp.dat'   
   
Reading data into ndarrays of type: [ Double ]
Read in  4  elements.

pdl> p $x   
   
[1 2 3 4]
pdl> $x *= 100  
   

pdl> p $x   
   
[100 200 300 400]
pdl> p $x->clump(-1)
   
[0 0 0 0]

What could be happening in rcols() that produces an ndarray that behaves like 
that?

Karl


> On 7 Jan 2024, at 12:48 pm, Luis Mochan  wrote:
> 
> I noticed that medover and maxover do work as expected in this case.
> 
> 
> On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general 
> wrote:
>> Hi all,
>> 
>> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
>> lame)
>> 
>> I noticed a few things when running one of my complicated codes, I will 
>> start seperate email threads
>> 
>> First there seems to be a serious rcols bug:
>> 
>> 
>> e.g. create a file
>> 
>> # tmp.dat
>> 1
>> 2
>> 3
>> 4
>> 
>> 
>> Loaded PDL v2.084 (supports bad values)
>> pdl> $x = rcols 'tmp.dat'
>> Reading data into ndarrays of type: [ Double ]
>> Read in  4  elements.
>> 
>> pdl> p $x
>> [1 2 3 4]
>> pdl> $x *= 100
>> 
>> pdl> p $x
>> [100 200 300 400]
>> pdl> p median($x)
>> 0
>> pdl> p $x
>> [100 200 300 400]
>> 
>> 
>> It seems the median function sees the values BEFORE the inplace 
>> multiplacation, whereas print does not. This is very bad. min() and max() 
>> are similar. No idea what is going on here! The behaviour or absent from 
>> v2.025
>> 
>> Notes
>> - making a $x->copy() removes the effect
>> - creating $x using sequence also removes, so it is something to do with 
>> rcols() and not inplace in general?
>> 
>> I’d be interested to know if others can reproduce this. It definitely needs 
>> a fix
>> 
>> best
>> 
>> Karl
>> 
>> 
>> 
> 
> 
>> ___
>> pdl-general mailing list
>> pdl-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/pdl-general
> 
> 
> -- 
> 
>  o
> W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
> Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
> Av. Universidad s/n CP 62210 |   (*)/\/  \
> Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

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

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Further to this, I looked through the rcols() diff. I could find no significant 
change in the code that smelled like it could cause this.

Here is a visual diff: https://www.diffchecker.com/w2FX8O61/ 
<https://www.diffchecker.com/w2FX8O61/>. (v2.025, v2.084)

I am afraid it must be a subtle bug to do with the internal routines that rcols 
uses (buffering and extending of ndarrays?)  and perhaps the underlying 
dataflow engine. 

Arghh!

Probably worth tracking down as it might be causing other badness….

Karl

> On 7 Jan 2024, at 11:26 am, Karl Glazebrook via pdl-general 
>  wrote:
> 
> Hi all,
> 
> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
> lame)
> 
> I noticed a few things when running one of my complicated codes, I will start 
> seperate email threads
> 
> First there seems to be a serious rcols bug:
> 
> 
> e.g. create a file
> 
> # tmp.dat
> 1
> 2
> 3
> 4
> 
> 
> Loaded PDL v2.084 (supports bad values)
> pdl> $x = rcols 'tmp.dat' 
>  
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
> 
> pdl> p $x 
>  
> [1 2 3 4]
> pdl> $x *= 100
>  
> 
> pdl> p $x 
>  
> [100 200 300 400]
> pdl> p median($x) 
>  
> 0
> pdl> p $x 
>  
> [100 200 300 400]
> 
> 
> It seems the median function sees the values BEFORE the inplace 
> multiplacation, whereas print does not. This is very bad. min() and max() are 
> similar. No idea what is going on here! The behaviour or absent from v2.025
> 
> Notes
> - making a $x->copy() removes the effect
> - creating $x using sequence also removes, so it is something to do with 
> rcols() and not inplace in general?
> 
> I’d be interested to know if others can reproduce this. It definitely needs a 
> fix
> 
> best
> 
> Karl
> 
> 
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general

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

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - PDL::NiceSlice issue

[Karl Glazebrook via pdl-general]

> On 7 Jan 2024, at 11:55 am, Karl Glazebrook via pdl-general 
>  wrote:
> 
> (The mismatch of line numbers seems to be related to the use of hereto text 
> earlier in the code, the debugger shows different line numbers)
> 


PS just to prove this point given the line numbers issue:




syntax error at /Users/karl/Software/perl/KGB/Redshift.pm line 251, near "$FOO("
Execution of /Users/karl/Software/perl/KGB/Redshift.pm aborted due to 
compilation errors.



You can see FOO triggers a compilation error and BAR does not, use 
PDL::NiceSlice is way at the top of the module

Karl

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

[Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - PDL::NiceSlice issue

[Karl Glazebrook via pdl-general]

Hi all,

This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
lame)

I noticed a few things when running one of my complicated codes, I will start 
seperate email threads

This last one - I had PDL::NiceSlice failing randomly halfway through a long 
module?

So the module has ‘use PDL::NiceSlice’

then a line line this:

  $FOO($ix) .= 1;

causes a syntax error (i.e. in compilation) if placed at line 247 but not at 
line 249. Here is the surrounding code with line numbersso you can see it was 
innocuous :



syntax error at /Users/karl/Software/perl/KGB/Redshift.pm line 251, near "$FOO("
Execution of /Users/karl/Software/perl/KGB/Redshift.pm aborted due to 
compilation errors.
Compilation failed in require at /Users/karl/Software/bin/pdlredshift line 3.

(The mismatch of line numbers seems to be related to the use of hereto text 
earlier in the code, the debugger shows different line numbers)

(I was just placing those no-op statements in to try and see what was going 
on). As expected using ->slice instead causes the code to compile

I guess we should be cautious of the robustness of NiceSlice?

best

Karl



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

[Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - scalars vs piddles

[Karl Glazebrook via pdl-general]

Hi all,

This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
lame)

I noticed a few things when running one of my complicated codes, I will start 
seperate email threads

Next I think this one is a design choice change I missed.

- Functions like median() max() etc now return a 0D piddle and no longer a 
scalar. This broke some gnarly code I had.

I expect this change was sensible, I am just curious as the reasons and when it 
happened?


best

Karl





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

[Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Hi all,

This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
lame)

I noticed a few things when running one of my complicated codes, I will start 
seperate email threads

First there seems to be a serious rcols bug:


e.g. create a file

# tmp.dat
1
2
3
4


Loaded PDL v2.084 (supports bad values)
pdl> $x = rcols 'tmp.dat'   
   
Reading data into ndarrays of type: [ Double ]
Read in  4  elements.

pdl> p $x   
   
[1 2 3 4]
pdl> $x *= 100  
   

pdl> p $x   
   
[100 200 300 400]
pdl> p median($x)   
   
0
pdl> p $x   
   
[100 200 300 400]


It seems the median function sees the values BEFORE the inplace multiplacation, 
whereas print does not. This is very bad. min() and max() are similar. No idea 
what is going on here! The behaviour or absent from v2.025

Notes
- making a $x->copy() removes the effect
- creating $x using sequence also removes, so it is something to do with 
rcols() and not inplace in general?

I’d be interested to know if others can reproduce this. It definitely needs a 
fix

best

Karl



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

Re: [Pdl-general] [Pdl-devel] benchmarks

[Karl Glazebrook via pdl-general]

Thanks Ed - I will experiment with -O3.

Indeed it would be good to make the basic ops as optimised as possible

Karl


> On 27 Oct 2021, at 3:08 am, Ed .  wrote:
> 
> If you’re using a typical consumer computer, you’ll get limitations of memory 
> bandwidth, which it seems will limit simple calculations on large amounts of 
> data. It would probably be worth ensuring one’s installation of PDL is 
> compiled with -O3 just in case; -O2 (the usual default) enables vectorisation 
> on clang, but not on GCC which only does so on -O3.
>  
> I just did a bit more experimenting with very latest PDL on a MacBook with 6 
> cores/12 hyperthreads (which apparently defaults to -O3). For comparison, 
> normal Perl takes about 28ms for 1000 iterations, so C will be about 1ms. 
> Best performance was with PDL_AUTOPTHREAD_SIZE=0 PDL_AUTOPTHREAD_TARG=10 (11 
> was about 1.5x as long), where 1000 iterations took about 0.31ms, or a bit 
> over 3x quicker than C, and comparable with the JavaScript (which I suspect 
> benefits from using GPU or maybe just multicore).
>  
> This 2019 presentation 
> (https://indico.cern.ch/event/814979/contributions/3401203/attachments/1831468/3115808/VectorParallelismMultiCoreProc.pdf
>  
> )
>  discusses the various issues in making parallel process go Really Fast. For 
> me, a key takeaway is the problem is generally quite hard, and it’s wise to 
> use e.g. BLAS where all the possible optimisations have been wrung out. PDL 
> could benefit from that by parsing the “Code” etc sections, and inserting 
> BLAS calls. Similarly, we should probably start using LAPACK in core, like 
> GNU Octave etc do. An interesting possibility would be to use the “Matriplex” 
> library for vectorising operations on many smallish matrices (it even 
> generates code using Perl).
>  
> It also mentions Amdahl’s Law, which gives limits to parallelism speedups 
> (fundamentally, the non-parallelisable bits impose limits, including 
> main-memory access).
>  
> From: Karl Glazebrook 
> Sent: 26 October 2021 08:57
> To: Ed . 
> Cc: Luis Mochan ; pdl-de...@lists.sourceforge.net 
> ; perldl 
> 
> Subject: Re: [Pdl-devel] benchmarks
>  
> This thread is interesting.
>  
> I was wondering if anyone has ever seen speedups of 2x or better with 
> PDL_AUTOPTHREAD_TARG > 2? I find it tends to max out at around 1.5-1.7x 
> whatever I set.
>  
> I know about overhead etc. but kind of feel for some of the basic stuff (e.g. 
> A=B*C for large arrays with big chunks) I should see 4x for 
> PDL_AUTOPTHREAD_TARG=4 and never do)
>  
> The various numbers in the tests reported by Ed show <2x.
>  
> Nice getting faster than C!
>  
> Karl
>  
> 
> 
> On 4 Oct 2021, at 1:05 am, Ed .  > wrote:
>  
> Thank you for the independent measurement!
>  
> From: Luis Mochan 
> Sent: 03 October 2021 15:03
> To: pdl-de...@lists.sourceforge.net ; 
> perldl 
> Subject: Re: [Pdl-devel] benchmarks
>  
> 
> Now I have run the C benchmark and Ed's. My results are:
> 
>| Program  | # iterations | time (s) | speed (K/s) | factor |
>|--+--+--+-+|
>| ansi c   |150e6 |  133 |   1127.8195 | 1. |
>| perl |1.5e6 |   56 |   26.785714 |   42.1 |
>| my pdl   | 15e6 |   67 |   223.88060 |5.0 |
>| Ed's pdl | 15e6 |   16 |   937.5 |1.2 |
>| Ed's 4 cores | 15e6 |   11 |   1363.6364 |0.8 |
> 
> So, as Ed wrote, just by stting and environment variable,
> perl+pdl+pp_def can be made faster than c.
> 
> 
> 
> 
> On Sat, Oct 02, 2021 at 07:03:50PM -0500, Luis Mochan wrote:
> > I made my own version of the ray-tracing program (as I tried to
> > understand it). I didn't use pp_def, only Perl and ordinary PDL. I used
> > ...
> 
> --
> 
>   o
> W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
> Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
> Av. Universidad s/n CP 62210 |   (*)/\/  \
> Cuernavaca, Morelos, México  | moc...@fis.unam.mx 
>    /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
> 
> 
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/pdl-devel 
> 
>  
> 

Re: [Pdl-general] [Pdl-devel] benchmarks

[Karl Glazebrook via pdl-general]

This thread is interesting.

I was wondering if anyone has ever seen speedups of 2x or better with 
PDL_AUTOPTHREAD_TARG > 2? I find it tends to max out at around 1.5-1.7x 
whatever I set.

I know about overhead etc. but kind of feel for some of the basic stuff (e.g. 
A=B*C for large arrays with big chunks) I should see 4x for 
PDL_AUTOPTHREAD_TARG=4 and never do)

The various numbers in the tests reported by Ed show <2x.

Nice getting faster than C!

Karl


> On 4 Oct 2021, at 1:05 am, Ed .  wrote:
> 
> Thank you for the independent measurement!
>  
> From: Luis Mochan 
> Sent: 03 October 2021 15:03
> To: pdl-de...@lists.sourceforge.net ; 
> perldl 
> Subject: Re: [Pdl-devel] benchmarks
>  
> 
> Now I have run the C benchmark and Ed's. My results are:
> 
>| Program  | # iterations | time (s) | speed (K/s) | factor |
>|--+--+--+-+|
>| ansi c   |150e6 |  133 |   1127.8195 | 1. |
>| perl |1.5e6 |   56 |   26.785714 |   42.1 |
>| my pdl   | 15e6 |   67 |   223.88060 |5.0 |
>| Ed's pdl | 15e6 |   16 |   937.5 |1.2 |
>| Ed's 4 cores | 15e6 |   11 |   1363.6364 |0.8 |
> 
> So, as Ed wrote, just by stting and environment variable,
> perl+pdl+pp_def can be made faster than c.
> 
> 
> 
> 
> On Sat, Oct 02, 2021 at 07:03:50PM -0500, Luis Mochan wrote:
> > I made my own version of the ray-tracing program (as I tried to
> > understand it). I didn't use pp_def, only Perl and ordinary PDL. I used
> > ...
> 
> --
> 
>   o
> W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
> Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
> Av. Universidad s/n CP 62210 |   (*)/\/  \
> Cuernavaca, Morelos, México  | moc...@fis.unam.mx 
>    /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
> 
> 
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/pdl-devel 
> 
>  
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/pdl-devel 
> 
___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] SciPDL Docker

[Karl Glazebrook via pdl-general]

Hi Ed

As you might gather from the delayed reply to this email, I have limited time 
for this. That includes things like ‘learning how this CI thing works’. But I 
have automated this to some extent and hope to do more. It would be nice to 
have the GitHub CI take care of it, if such a thing is possible? 

Right now I would like some people to try out the docker container, and report 
back.

Karl


> On 17 Aug 2021, at 11:58 am, Ed .  wrote:
> 
> Hi Karl,
>  
> In the Agile methodology, they say if e.g. making a release is painful, do it 
> more so that you’ll be forced to automate away the pain. I’d suggest a 
> similar benefit would arise if you released SciPDL more often, but it’s up to 
> you.
>  
> Having thought more about this, I think the existing PDLPorters/devops repo 
> would be ideal: could you please push on a branch of that, making a new 
> directory within it called something like build-docker, putting your files in 
> there, then make a PR so that people can take a look?
>  
> Regarding the number of releases of PDL, my approach has been to release it 
> when I thought something valuable was ready. You’ll recall that in the past, 
> just because PDL wasn’t released very often, didn’t mean every single release 
> was perfect. There’s one bit in a release notes from the past proudly noting 
> a release with over 50 fixed tickets. Those fixes were sat on for a 
> considerable period of time, with users unable to benefit from them.
>  
> We do have literal “continuous integration” (using GitHub Actions) which has 
> all the tests Zaki and I could think of to throw at it, for every single push 
> on any branch: it builds on Ubuntu, CentOS, MacOS, Windows, Cygwin (only for 
> releases, it’s too slow otherwise). It would be easy(ish) to have, probably 
> only for releases, an additional build step that updated a Docker image with 
> SciPDL (and as an added benefit, would show any breakages of that). The CI 
> reports all pushes, and build results, on the IRC channel, which I do 
> recommend sitting on. Having SciPDL be an additional “canary in the coal 
> mine” would be of considerable value.
>  
> As for which is the last “stable release”, I understand the question, but for 
> the reasons in the last two paragraphs I can’t really accept the premise. If 
> you look at https://metacpan.org/pod/PDL <https://metacpan.org/pod/PDL>, 
> there’s a not-very-up-to-date “Testers” readout (the numbers are cached, it 
> only shows currently 100 passes), and link. If you follow the link, the 
> current version shown is for 2.057 (the latest), 
> http://matrix.cpantesters.org/?dist=PDL+2.057 
> <http://matrix.cpantesters.org/?dist=PDL+2.057>: it shows 131 passes, 7 
> unknown (which are build failures, each of which I know the reason for), and 
> no failures (either 100% passes, or 95%, depending on how you count it), 
> across 70 configurations (OS, Perl version). How “stable” were you after, 
> exactly? 
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook <mailto:karlglazebr...@mac.com>
> Sent: 17 August 2021 01:56
> To: Ed . <mailto:ej...@hotmail.com>
> Cc: perldl <mailto:pdl-general@lists.sourceforge.net>; Bob Abraham 
> <mailto:abra...@astro.utoronto.ca>
> Subject: Re: [Pdl-general] SciPDL Docker
>  
> Hi Ed,
>  
> It’s a Dockerfile and a build shell script that runs inside it. I went that 
> way as that is what I did for MacOS and docker seemed a nice way of bypassing 
> all the issues with Debian packaging (see other thread) which are frankly 
> doing my head in!
>  
> I am not sure I feel comfortable sharing my dubious build scripts, could be 
> dangerous, but maybe if it sits within PDL repo.
>  
> BTW I only make a new SciPDL once or twice a year. It’s kind of my thing to 
> bundle up all the stuff I normally like but others find it useful. So - I see 
> there have been a huge number of new PDL versions this year, which is 
> fantastic (esp. the new complex numbers approach) but I also see things are 
> in a high state of flux. Continuous integration of new changes are not my 
> thing, at least not for SciPDL, what would be the last ’stable version’ to 
> build against do you think? I hope that question makes sense,
>  
> Karl
>  
> 
> 
> On 17 Aug 2021, at 1:01 am, Ed .  <mailto:ej...@hotmail.com>> wrote:
>  
> Hi Karl,
>  
> That’s great! Can you share your Dockerfile? Is it on GitHub? I’m thinking it 
> would be great to have it within PDLPorters, maybe in a repo called (very 
> imaginatively) “docker”.
>  
> Yes, there is in fact now a 2.057 (which restored the DELETEDATA mechanism 
> which it turns out people were using for other than mmap – oops). Please give 
> it a go!
>  
> Best r

Re: [Pdl-general] SciPDL Docker

[Karl Glazebrook via pdl-general]

Hi Ed,

It’s a Dockerfile and a build shell script that runs inside it. I went that way 
as that is what I did for MacOS and docker seemed a nice way of bypassing all 
the issues with Debian packaging (see other thread) which are frankly doing my 
head in!

I am not sure I feel comfortable sharing my dubious build scripts, could be 
dangerous, but maybe if it sits within PDL repo.

BTW I only make a new SciPDL once or twice a year. It’s kind of my thing to 
bundle up all the stuff I normally like but others find it useful. So - I see 
there have been a huge number of new PDL versions this year, which is fantastic 
(esp. the new complex numbers approach) but I also see things are in a high 
state of flux. Continuous integration of new changes are not my thing, at least 
not for SciPDL, what would be the last ’stable version’ to build against do you 
think? I hope that question makes sense,

Karl


> On 17 Aug 2021, at 1:01 am, Ed .  wrote:
> 
> Hi Karl,
>  
> That’s great! Can you share your Dockerfile? Is it on GitHub? I’m thinking it 
> would be great to have it within PDLPorters, maybe in a repo called (very 
> imaginatively) “docker”.
>  
> Yes, there is in fact now a 2.057 (which restored the DELETEDATA mechanism 
> which it turns out people were using for other than mmap – oops). Please give 
> it a go!
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook via pdl-general 
> <mailto:pdl-general@lists.sourceforge.net>
> Sent: 16 August 2021 13:11
> To: perldl <mailto:pdl-general@lists.sourceforge.net>
> Cc: Bob Abraham <mailto:abra...@astro.utoronto.ca>
> Subject: [Pdl-general] SciPDL Docker
>  
> Hi PDL users,
>  
> I made a Docker version of SciPDL and put it on Dockerhub. It was on my to-do 
> list for a while, helped me learn more about Docker.
>  
> So you can run it anywhere you can run Docker with a command like:
>  
> docker run -it karlglazebrook/scipdl pdl
>  
> It has pgplot  (make sure to set X11 DISPLAY for this) and all the usual 
> stuff etc. I include in my SciPDL ‘kitchen sink' 
>  
> This is still on PDL-2.025, same as MacOS, and is an intel builf, next round 
> to it is to update the PDL versions in SciPDL. (Did I see v56 recently! 
> Jeepers...)
>  
> best
>  
> Karl

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

[Pdl-general] SciPDL Docker

[Karl Glazebrook via pdl-general]

Hi PDL users,

I made a Docker version of SciPDL and put it on Dockerhub. It was on my to-do 
list for a while, helped me learn more about Docker.

So you can run it anywhere you can run Docker with a command like:

docker run -it karlglazebrook/scipdl pdl

It has pgplot  (make sure to set X11 DISPLAY for this) and all the usual stuff 
etc. I include in my SciPDL ‘kitchen sink' 

This is still on PDL-2.025, same as MacOS, and is an intel builf, next round to 
it is to update the PDL versions in SciPDL. (Did I see v56 recently! Jeepers...)

best

Karl



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

Re: [Pdl-general] pgplot instructions for Big Sur macOS

[Karl Glazebrook via pdl-general]

The documents are all a bit meta. So they run on github servers? It is never 
clearly said that I could see.

A split is fine if done properly and planned. Without that I’d prefer to keep 
it in.

Karl


> On 16 Feb 2021, at 6:45 pm, Ed .  wrote:
> 
> Hi Karl,
>  
> GitHub Actions are all explained in the link I gave in my previous message  
> (spoiler: it’s a classic example of cloud computing)
>  
> By “more modern” I’m referring to one of the many other possibilities like 
> PLplot, Gnuplot, Prima – of the ones that already have PDL support (and that 
> have better RGB support, among other features – see 
> https://en.wikipedia.org/wiki/PGPLOT  
> for info on e.g. PG2PLplot, a transition library)! The harm is in needing to 
> ensure that ideally all of the PDL distribution (which has 99 separate 
> components) works, in every release, which is a major task for the maintainer.
>  
> A good solution would be to finally start pulling “PDL” the distribution into 
> some of its component parts, as has long been discussed: for instance 
> PDL::Core with maybe just the REPLs and the packages imported by “use PDL” 
> would be a separate distribution; the various Proj libraries could be a 
> separate component; the PGPLOT another; maybe GSL another one. That way if 
> PDL::Graphics::PGPLOT needs fixing, that can be done (and released) 
> independently.
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook 
> Sent: 16 February 2021 07:23
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
> Right. I took a look at that yml file and I can sort of see what is going on. 
> On what machine is that CI stuff being run?
>  
> Re FreeBSD. Are there many users? I have no idea how ports files would work 
> on that distribution, I haven’t even learned how to do this on Macports or 
> Homebrew (though I should), but I can certainly advise someone on the command 
> line tricks needed to build it.
>  
> PGPLOT is not really ‘in PDL’. The module PDL::Graphics::PGPLOT is perl only, 
> and depends on PGPLOT module being present and working - which is not part of 
> PDL (and in fact predates it). I see no harm in leaving it in?
>  
> I would be interested to know what you mean by ‘more modern alternatives’. 
> Such as?
>  
> Karl
>  
>  
> 
> 
> On 16 Feb 2021, at 1:15 pm, Ed .  > wrote:
>  
> Whatever is specified in any “.github/workflows/*.yml”! 
> https://docs.github.com/en/actions 
>  
> By the way, I think I’m about to make PGPLOT work somewhat better on FreeBSD 
> in the imminent next version. The FreeBSD port says it’s not got a 
> maintainer, and they’re asking for volunteers. Karl, if you’re keen on 
> keeping PGPLOT going, that might be useful? I spun up a FreeBSD virtual 
> machine this evening, there are many tutorials.
>  
> One other possibility is for PGPLOT to get dropped from PDL, because it’s 
> taking up a fair bit of effort, for not a great deal of benefit given there 
> are various more modern alternatives. I’m reluctant, but there are only so 
> many hours in the day. What do others think?
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook 
> Sent: 16 February 2021 01:31
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
> OK . … in this case what ‘action’ is actually run?
>  
> 
> 
> 
> On 16 Feb 2021, at 12:25 pm, Ed .  > wrote:
>  
> CI is “continuous integration”, run every time a commit is pushed to the 
> server (or a pull request is created or updated) to give instant feedback on 
> problems. GitHub Actions is the new-ish service provided by GitHub for this. 
> It’s much better than Travis now is, given Travis are deliberately turning 
> off their open-source support.
>  
> GitHub actions are configured in the files under .github. There are tutorials 
> which are very good, but the starting point we have works, which always helps 
> 
>  
> From: Karl Glazebrook 
> Sent: 16 February 2021 01:22
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
>  
> Hi Ed
>  
> Sorry for the dumb question - can you explain what ' GitHub Action CI’ is? Do 
> I need to know about it?
>  
> Karl
>  
> 
> 
> 
> 
> On 15 Feb 2021, at 4:26 pm, Ed .  > wrote:
>  
> I’ve updated the CPAN PGPLOT somewhat, including adding GitHub Action CI. I 
> tried to make it also test on MacOS by using your instructions, but I don’t 
> know enough about the MacOS specifics. I’ve left the attempt on a branch, 
> 

Re: [Pdl-general] pgplot instructions for Big Sur macOS

[Karl Glazebrook via pdl-general]

Right. I took a look at that yml file and I can sort of see what is going on. 
On what machine is that CI stuff being run?

Re FreeBSD. Are there many users? I have no idea how ports files would work on 
that distribution, I haven’t even learned how to do this on Macports or 
Homebrew (though I should), but I can certainly advise someone on the command 
line tricks needed to build it.

PGPLOT is not really ‘in PDL’. The module PDL::Graphics::PGPLOT is perl only, 
and depends on PGPLOT module being present and working - which is not part of 
PDL (and in fact predates it). I see no harm in leaving it in?

I would be interested to know what you mean by ‘more modern alternatives’. Such 
as?

Karl



> On 16 Feb 2021, at 1:15 pm, Ed .  wrote:
> 
> Whatever is specified in any “.github/workflows/*.yml”! 
> https://docs.github.com/en/actions 
>  
> By the way, I think I’m about to make PGPLOT work somewhat better on FreeBSD 
> in the imminent next version. The FreeBSD port says it’s not got a 
> maintainer, and they’re asking for volunteers. Karl, if you’re keen on 
> keeping PGPLOT going, that might be useful? I spun up a FreeBSD virtual 
> machine this evening, there are many tutorials.
>  
> One other possibility is for PGPLOT to get dropped from PDL, because it’s 
> taking up a fair bit of effort, for not a great deal of benefit given there 
> are various more modern alternatives. I’m reluctant, but there are only so 
> many hours in the day. What do others think?
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook 
> Sent: 16 February 2021 01:31
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
> OK . … in this case what ‘action’ is actually run?
>  
> 
> 
> On 16 Feb 2021, at 12:25 pm, Ed .  > wrote:
>  
> CI is “continuous integration”, run every time a commit is pushed to the 
> server (or a pull request is created or updated) to give instant feedback on 
> problems. GitHub Actions is the new-ish service provided by GitHub for this. 
> It’s much better than Travis now is, given Travis are deliberately turning 
> off their open-source support.
>  
> GitHub actions are configured in the files under .github. There are tutorials 
> which are very good, but the starting point we have works, which always helps 
> 
>  
> From: Karl Glazebrook 
> Sent: 16 February 2021 01:22
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
>  
> Hi Ed
>  
> Sorry for the dumb question - can you explain what ' GitHub Action CI’ is? Do 
> I need to know about it?
>  
> Karl
>  
> 
> 
> 
> On 15 Feb 2021, at 4:26 pm, Ed .  > wrote:
>  
> I’ve updated the CPAN PGPLOT somewhat, including adding GitHub Action CI. I 
> tried to make it also test on MacOS by using your instructions, but I don’t 
> know enough about the MacOS specifics. I’ve left the attempt on a branch, 
> hopefully a Mac expert (Karl? ) can fix it: 
> https://github.com/PDLPorters/perl5-PGPLOT/tree/macos-ci 
> 
>  
> From: Karl Glazebrook 
> Sent: 14 January 2021 00:26
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
> Hi all
>  
> An update on this. The config there uses Apple’s CC, but I have now come 
> across some random segv’s that seem to be avoided if one uses GCC 11 and 
> GFORTRAN 11.
>  
> So I would recommend editing gfortran_cc_BigSur.conf from that patch to use 
> GCC - and take it from http://hpc.sourceforge.net 
>  (which is where I got GFORTRAN)
>  
> Karl
>  
> 
> 
> 
> 
> On 7 Jan 2021, at 4:57 pm, Karl Glazebrook  > wrote:
>  
> Here you go Ed et al:
> 
> This below installs a fully functioning pgplot on my Big Sur ARM Mac in 
> /usr/local/pgplot. I expect it will also work the same on Big Sur Intel. You 
> need to have prerequisites:
> 1. Macports X11 installed in the usual place under /opt/…  (I have 
> xorg-server 1.20.10)
> 2. gfortran installed in /usr/local/... (I have version '11.0.0 20201128 
> (experimental)’ installed from http://hpc.sourceforge.net 
> )
> Things are dynamically linked.
> 
> 
> # Run these shell commands to install pgplot
> curl --remote-name 
> https://astronomy.swin.edu.au/~karl/pgplot/pgplot531.tar.gz 
> 
> curl --remote-name 
> https://astronomy.swin.edu.au/~karl/pgplot/pgplotpatch.diff 
> 

Re: [Pdl-general] pgplot instructions for Big Sur macOS

[Karl Glazebrook via pdl-general]

OK . … in this case what ‘action’ is actually run?


> On 16 Feb 2021, at 12:25 pm, Ed .  wrote:
> 
> CI is “continuous integration”, run every time a commit is pushed to the 
> server (or a pull request is created or updated) to give instant feedback on 
> problems. GitHub Actions is the new-ish service provided by GitHub for this. 
> It’s much better than Travis now is, given Travis are deliberately turning 
> off their open-source support.
>  
> GitHub actions are configured in the files under .github. There are tutorials 
> which are very good, but the starting point we have works, which always helps 
> 
>  
> From: Karl Glazebrook 
> Sent: 16 February 2021 01:22
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
>  
> Hi Ed
>  
> Sorry for the dumb question - can you explain what ' GitHub Action CI’ is? Do 
> I need to know about it?
>  
> Karl
>  
> 
> 
> On 15 Feb 2021, at 4:26 pm, Ed .  > wrote:
>  
> I’ve updated the CPAN PGPLOT somewhat, including adding GitHub Action CI. I 
> tried to make it also test on MacOS by using your instructions, but I don’t 
> know enough about the MacOS specifics. I’ve left the attempt on a branch, 
> hopefully a Mac expert (Karl? ) can fix it: 
> https://github.com/PDLPorters/perl5-PGPLOT/tree/macos-ci 
> 
>  
> From: Karl Glazebrook 
> Sent: 14 January 2021 00:26
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
> Hi all
>  
> An update on this. The config there uses Apple’s CC, but I have now come 
> across some random segv’s that seem to be avoided if one uses GCC 11 and 
> GFORTRAN 11.
>  
> So I would recommend editing gfortran_cc_BigSur.conf from that patch to use 
> GCC - and take it from http://hpc.sourceforge.net 
>  (which is where I got GFORTRAN)
>  
> Karl
>  
> 
> 
> 
> On 7 Jan 2021, at 4:57 pm, Karl Glazebrook  > wrote:
>  
> Here you go Ed et al:
> 
> This below installs a fully functioning pgplot on my Big Sur ARM Mac in 
> /usr/local/pgplot. I expect it will also work the same on Big Sur Intel. You 
> need to have prerequisites:
> 1. Macports X11 installed in the usual place under /opt/…  (I have 
> xorg-server 1.20.10)
> 2. gfortran installed in /usr/local/... (I have version '11.0.0 20201128 
> (experimental)’ installed from http://hpc.sourceforge.net 
> )
> Things are dynamically linked.
> 
> 
> # Run these shell commands to install pgplot
> curl --remote-name 
> https://astronomy.swin.edu.au/~karl/pgplot/pgplot531.tar.gz 
> 
> curl --remote-name 
> https://astronomy.swin.edu.au/~karl/pgplot/pgplotpatch.diff 
> 
> tar xvf pgplot531.tar.gz
> cd pgplotsrc
> patch  -p 1 -i ../pgplotpatch.diff
> SRC=$PWD
> sudo mkdir /usr/local/pgplot
> cd  /usr/local/pgplot
> sudo cp $SRC/drivers.list .
> sudo $SRC/makemake $SRC/ darwin gfortran_cc_BigSur
> sudo make
> sudo make clean
> ./pgdemo1 # Works
> 
> 
> 
> I hope that can be passed on to the Macports, Homebrew people to take what 
> tricks they need from this. I guess the patch and the latest hard to find 
> pgplot tarball is the most important thing. The patch selects drivers that 
> work and are relevant today, fixes up the makefile generator, and changes one 
> line of code in the png driver to avoid an error.
> 
> cheers
> 
> Karl
> 
> 
> 
> 
> On 6 Jan 2021, at 2:18 am, Ed .  > wrote:
> 
> Hi Karl,
> 
> Could you capture on here what lines of code etc you changed, hopefully along 
> with all the software versions you used etc, so that ideally someone else 
> arriving fresh could do exactly what you did and get the same results?
> 
> Best regards,
> Ed

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

Re: [Pdl-general] pgplot instructions for Big Sur macOS

[Karl Glazebrook via pdl-general]

Hi Ed

Sorry for the dumb question - can you explain what ' GitHub Action CI’ is? Do I 
need to know about it?

Karl


> On 15 Feb 2021, at 4:26 pm, Ed .  wrote:
> 
> I’ve updated the CPAN PGPLOT somewhat, including adding GitHub Action CI. I 
> tried to make it also test on MacOS by using your instructions, but I don’t 
> know enough about the MacOS specifics. I’ve left the attempt on a branch, 
> hopefully a Mac expert (Karl? ) can fix it: 
> https://github.com/PDLPorters/perl5-PGPLOT/tree/macos-ci 
> 
>  
> From: Karl Glazebrook 
> Sent: 14 January 2021 00:26
> To: Ed . 
> Cc: pdl-general@lists.sourceforge.net 
> 
> Subject: Re: pgplot instructions for Big Sur macOS
>  
> Hi all
>  
> An update on this. The config there uses Apple’s CC, but I have now come 
> across some random segv’s that seem to be avoided if one uses GCC 11 and 
> GFORTRAN 11.
>  
> So I would recommend editing gfortran_cc_BigSur.conf from that patch to use 
> GCC - and take it from http://hpc.sourceforge.net 
>  (which is where I got GFORTRAN)
>  
> Karl
>  
> 
> 
> On 7 Jan 2021, at 4:57 pm, Karl Glazebrook  > wrote:
>  
> Here you go Ed et al:
> 
> This below installs a fully functioning pgplot on my Big Sur ARM Mac in 
> /usr/local/pgplot. I expect it will also work the same on Big Sur Intel. You 
> need to have prerequisites:
> 1. Macports X11 installed in the usual place under /opt/…  (I have 
> xorg-server 1.20.10)
> 2. gfortran installed in /usr/local/... (I have version '11.0.0 20201128 
> (experimental)’ installed from http://hpc.sourceforge.net 
> )
> Things are dynamically linked.
> 
> 
> # Run these shell commands to install pgplot
> curl --remote-name 
> https://astronomy.swin.edu.au/~karl/pgplot/pgplot531.tar.gz 
> 
> curl --remote-name 
> https://astronomy.swin.edu.au/~karl/pgplot/pgplotpatch.diff 
> 
> tar xvf pgplot531.tar.gz
> cd pgplotsrc
> patch  -p 1 -i ../pgplotpatch.diff
> SRC=$PWD
> sudo mkdir /usr/local/pgplot
> cd  /usr/local/pgplot
> sudo cp $SRC/drivers.list .
> sudo $SRC/makemake $SRC/ darwin gfortran_cc_BigSur
> sudo make
> sudo make clean
> ./pgdemo1 # Works
> 
> 
> 
> I hope that can be passed on to the Macports, Homebrew people to take what 
> tricks they need from this. I guess the patch and the latest hard to find 
> pgplot tarball is the most important thing. The patch selects drivers that 
> work and are relevant today, fixes up the makefile generator, and changes one 
> line of code in the png driver to avoid an error.
> 
> cheers
> 
> Karl
> 
> 
> 
> On 6 Jan 2021, at 2:18 am, Ed .  > wrote:
> 
> Hi Karl,
> 
> Could you capture on here what lines of code etc you changed, hopefully along 
> with all the software versions you used etc, so that ideally someone else 
> arriving fresh could do exactly what you did and get the same results?
> 
> Best regards,
> Ed

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

[Pdl-general] SciPDL 2.025 for MacOS (including ARM!)

[Karl Glazebrook via pdl-general]

Hi all,

I’ve made a new build of SciPDL** for PDL v2.025 natively compiled for M1 
(arm64) CPU Macs:

https://www.dropbox.com/s/n4699qg2vhg2kog/SciPDL-v2.025-arm64.dmg?dl=0 


This was built on MacOS 11 Big Sur and extensively ‘statically linked’ using 
various tricks which means it should not need anything else installed to run. 
(Except X11 if you want the pgplot graphics)

Similarly I made the same build for Intel Macs:

https://www.dropbox.com/s/rck3dmnyjp3nb9j/SciPDL-v2.025-x86_64.dmg?dl=0 


Also compiled on Big Sur, but it seems to work on MacOS versions at least as 
far back as Mojave. (Let me know!)

You will see there is now an extra install step needed to dodge around newer 
MacOS security. I probably need to pay for an Apple developer account to sign 
the code properly. But for now you can trust me and let me know if this PDL 
works!?

Once I get a few reports I can put it up officially. If people want other stuff 
in the kitchen sink we can discuss,

BTW - typical single threaded benchmarks seem to show the M1 PDL is roughly 
twice as fast as Intel for single thread performance.

best

Karl

**my double click  kitchen sink standalone MacOS install which includes its own 
perl and PGPLOT build.








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

Re: [Pdl-general] pgplot instructions for Big Sur macOS

[Karl Glazebrook via pdl-general]

Hi all

An update on this. The config there uses Apple’s CC, but I have now come across 
some random segv’s that seem to be avoided if one uses GCC 11 and GFORTRAN 11.

So I would recommend editing gfortran_cc_BigSur.conf from that patch to use GCC 
- and take it from http://hpc.sourceforge.net  
(which is where I got GFORTRAN)

Karl


> On 7 Jan 2021, at 4:57 pm, Karl Glazebrook  wrote:
> 
> Here you go Ed et al:
> 
> This below installs a fully functioning pgplot on my Big Sur ARM Mac in 
> /usr/local/pgplot. I expect it will also work the same on Big Sur Intel. You 
> need to have prerequisites:
> 1. Macports X11 installed in the usual place under /opt/…  (I have 
> xorg-server 1.20.10)
> 2. gfortran installed in /usr/local/... (I have version '11.0.0 20201128 
> (experimental)’ installed from http://hpc.sourceforge.net)
> Things are dynamically linked.
> 
> 
> # Run these shell commands to install pgplot
> curl --remote-name https://astronomy.swin.edu.au/~karl/pgplot/pgplot531.tar.gz
> curl --remote-name https://astronomy.swin.edu.au/~karl/pgplot/pgplotpatch.diff
> tar xvf pgplot531.tar.gz
> cd pgplotsrc
> patch  -p 1 -i ../pgplotpatch.diff
> SRC=$PWD
> sudo mkdir /usr/local/pgplot
> cd  /usr/local/pgplot
> sudo cp $SRC/drivers.list .
> sudo $SRC/makemake $SRC/ darwin gfortran_cc_BigSur
> sudo make
> sudo make clean
> ./pgdemo1 # Works
> 
> 
> 
> I hope that can be passed on to the Macports, Homebrew people to take what 
> tricks they need from this. I guess the patch and the latest hard to find 
> pgplot tarball is the most important thing. The patch selects drivers that 
> work and are relevant today, fixes up the makefile generator, and changes one 
> line of code in the png driver to avoid an error.
> 
> cheers
> 
> Karl
> 
> 
>> On 6 Jan 2021, at 2:18 am, Ed .  wrote:
>> 
>> Hi Karl,
>> 
>> Could you capture on here what lines of code etc you changed, hopefully 
>> along with all the software versions you used etc, so that ideally someone 
>> else arriving fresh could do exactly what you did and get the same results?
>> 
>> Best regards,
>> Ed
> 
> 

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

[Pdl-general] pgplot instructions for Big Sur macOS

[Karl Glazebrook via pdl-general]

Here you go Ed et al:

This below installs a fully functioning pgplot on my Big Sur ARM Mac in 
/usr/local/pgplot. I expect it will also work the same on Big Sur Intel. You 
need to have prerequisites:
1. Macports X11 installed in the usual place under /opt/…  (I have xorg-server 
1.20.10)
2. gfortran installed in /usr/local/... (I have version '11.0.0 20201128 
(experimental)’ installed from http://hpc.sourceforge.net)
Things are dynamically linked.


# Run these shell commands to install pgplot
curl --remote-name https://astronomy.swin.edu.au/~karl/pgplot/pgplot531.tar.gz
curl --remote-name https://astronomy.swin.edu.au/~karl/pgplot/pgplotpatch.diff
tar xvf pgplot531.tar.gz
cd pgplotsrc
patch  -p 1 -i ../pgplotpatch.diff
SRC=$PWD
sudo mkdir /usr/local/pgplot
cd  /usr/local/pgplot
sudo cp $SRC/drivers.list .
sudo $SRC/makemake $SRC/ darwin gfortran_cc_BigSur
sudo make
sudo make clean
./pgdemo1 # Works



I hope that can be passed on to the Macports, Homebrew people to take what 
tricks they need from this. I guess the patch and the latest hard to find 
pgplot tarball is the most important thing. The patch selects drivers that work 
and are relevant today, fixes up the makefile generator, and changes one line 
of code in the png driver to avoid an error.

cheers

Karl


> On 6 Jan 2021, at 2:18 am, Ed .  wrote:
> 
> Hi Karl,
>  
> Could you capture on here what lines of code etc you changed, hopefully along 
> with all the software versions you used etc, so that ideally someone else 
> arriving fresh could do exactly what you did and get the same results?
>  
> Best regards,
> Ed



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

Re: [Pdl-general] PDL for Apple Silicon

[Karl Glazebrook via pdl-general]

Hi Craig,

Yes the pgplot core dates from the 1980s and I first used it as a callow youth 
on a VAX 11/780 running VMS.   Of course the UNIX core in the Mac I am writing 
this email on dates from the 1970s!!

The various graphic systems drivers are more recent though, it only *feels* 
like a 20 year old program than a 40 year old one! 

These days I generally plot in something more modern like Matplotlib. It would 
be nice to have something like that for PDL.

I build SciPDL with PGPLOT because that is what all my 20 year old scripts use, 
that I occasionally resurrect. I’d be happy to look in to adding something else 
for you. PLplot? GNUplot?

Karl


> On 6 Jan 2021, at 2:36 am, Craig DeForest  wrote:
> 
> Wow, I haven’t used PGPLOT in a very, very long time.  That made me reflect a 
> bit.  When PGPLOT was first written, Jobs and Wozniak were still working on 
> the Apple ///.
> 
> 
>> On Jan 5, 2021, at 8:18 AM, Ed . > <mailto:ej...@hotmail.com>> wrote:
>> 
>> Hi Karl,
>>  
>> Could you capture on here what lines of code etc you changed, hopefully 
>> along with all the software versions you used etc, so that ideally someone 
>> else arriving fresh could do exactly what you did and get the same results?
>>  
>> Best regards,
>> Ed
>>  
>> From: Karl Glazebrook via pdl-general 
>> <mailto:pdl-general@lists.sourceforge.net>
>> Sent: 05 January 2021 08:13
>> To: Derek Lamb <mailto:de...@boulder.swri.edu>
>> Cc: pdl-general@lists.sourceforge.net 
>> <mailto:pdl-general@lists.sourceforge.net>
>> Subject: Re: [Pdl-general] PDL for Apple Silicon
>>  
>> Hi Derek,
>>  
>> I was using gcc and gfortran which I got from http://hpc.sourceforge.net 
>> <http://hpc.sourceforge.net/>
>>  
>> However this particular gcc seems buggy (libgsl make check  failed!) and I 
>> am looking next to re-compile everything consistently with either Apple CC 
>> or Apple GCC - still experimenting! Apple GCC avoids the libgsl problem and 
>> I expect it will also do fine for pgplot - both GCCs are gcc11 variants.
>>  
>> Note I am also using the X11 server that comes with Macports, which has been 
>> ported to the M1.
>>  
>> Not sure what is going on with that bug report - I’ve always built SciPDL 
>> with pgplot v5.3.1 which was the final version and may have fixed some bugs. 
>> I now see though it was never properly released. I would start by switching 
>> to that. I also tweaked one of the lines of code in one of the drivers and 
>> changed some folder defaults.
>>  
>> It would be great to get all of PDL, pgplot etc going in Macports. I now 
>> know a bunch of tricks for getting everything to build but I don’t really 
>> know how to write port files - I’d be most happy to work with you or 
>> whomever on this off-list.
>>  
>> best,
>>  
>> Karl
>>  
>>  
>>  
>> 
>> 
>> On 5 Jan 2021, at 8:39 am, Derek Lamb > <mailto:de...@boulder.swri.edu>> wrote:
>>  
>> Hi Karl,
>> 
>> I don't have any Apple Silicon to test on, but I'm wondering: how are you 
>> getting that dinosaur pgplot (fortran lib, not the Perl) to compile?  What 
>> compiler & version?  
>> 
>> I'm using MacPorts and ever since gcc updated to version 8 I was not able to 
>> avoid segfaults (https://trac.macports.org/ticket/57726 
>> <https://trac.macports.org/ticket/57726>).  Are you using Homebrew, or 
>> building it from scratch?
>> 
>> Derek
>> 
>> 
>> On Jan 2, 2021, at 11:23 PM, Karl Glazebrook via pdl-general 
>> > <mailto:pdl-general@lists.sourceforge.net>> wrote:
>> 
>> Happy New Year everyone! Hopefully 2021 will be better than 2020.
>> 
>> I just got PDL built and working for Apple Silicon!
>> 
>> See screenshot, this is on a M1 MacBook Air.
>> 
>> A few wrinkles in the process, but not that bad.
>> 
>> Who wants to test a new SciPDL for Apple Silicon?
>> 
>> Karl
>> 
>> 
>> 
>> ___
>> pdl-general mailing list
>> pdl-general@lists.sourceforge.net <mailto:pdl-general@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/pdl-general 
>> <https://lists.sourceforge.net/lists/listinfo/pdl-general>
>>  
>>  
>>  
>> ___
>> pdl-general mailing list
>> pdl-general@lists.sourceforge.net <mailto:pdl-general@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/pdl-general 
>> <https://lists.sourceforge.net/lists/listinfo/pdl-general>

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

Re: [Pdl-general] PDL for Apple Silicon

[Karl Glazebrook via pdl-general]

Yes I will. But let me run through it one more time first.



Karl


> On 6 Jan 2021, at 2:18 am, Ed .  wrote:
> 
> Hi Karl,
>  
> Could you capture on here what lines of code etc you changed, hopefully along 
> with all the software versions you used etc, so that ideally someone else 
> arriving fresh could do exactly what you did and get the same results?
>  
> Best regards,
> Ed
>  
> From: Karl Glazebrook via pdl-general 
> <mailto:pdl-general@lists.sourceforge.net>
> Sent: 05 January 2021 08:13
> To: Derek Lamb <mailto:de...@boulder.swri.edu>
> Cc: pdl-general@lists.sourceforge.net 
> <mailto:pdl-general@lists.sourceforge.net>
> Subject: Re: [Pdl-general] PDL for Apple Silicon
>  
> Hi Derek,
>  
> I was using gcc and gfortran which I got from http://hpc.sourceforge.net 
> <http://hpc.sourceforge.net/>
>  
> However this particular gcc seems buggy (libgsl make check  failed!) and I am 
> looking next to re-compile everything consistently with either Apple CC or 
> Apple GCC - still experimenting! Apple GCC avoids the libgsl problem and I 
> expect it will also do fine for pgplot - both GCCs are gcc11 variants.
>  
> Note I am also using the X11 server that comes with Macports, which has been 
> ported to the M1.
>  
> Not sure what is going on with that bug report - I’ve always built SciPDL 
> with pgplot v5.3.1 which was the final version and may have fixed some bugs. 
> I now see though it was never properly released. I would start by switching 
> to that. I also tweaked one of the lines of code in one of the drivers and 
> changed some folder defaults.
>  
> It would be great to get all of PDL, pgplot etc going in Macports. I now know 
> a bunch of tricks for getting everything to build but I don’t really know how 
> to write port files - I’d be most happy to work with you or whomever on this 
> off-list.
>  
> best,
>  
> Karl
>  
>  
>  
> 
> 
> On 5 Jan 2021, at 8:39 am, Derek Lamb  <mailto:de...@boulder.swri.edu>> wrote:
>  
> Hi Karl,
> 
> I don't have any Apple Silicon to test on, but I'm wondering: how are you 
> getting that dinosaur pgplot (fortran lib, not the Perl) to compile?  What 
> compiler & version?  
> 
> I'm using MacPorts and ever since gcc updated to version 8 I was not able to 
> avoid segfaults (https://trac.macports.org/ticket/57726 
> <https://trac.macports.org/ticket/57726>).  Are you using Homebrew, or 
> building it from scratch?
> 
> Derek
> 
> 
> On Jan 2, 2021, at 11:23 PM, Karl Glazebrook via pdl-general 
>  <mailto:pdl-general@lists.sourceforge.net>> wrote:
> 
> Happy New Year everyone! Hopefully 2021 will be better than 2020.
> 
> I just got PDL built and working for Apple Silicon!
> 
> See screenshot, this is on a M1 MacBook Air.
> 
> A few wrinkles in the process, but not that bad.
> 
> Who wants to test a new SciPDL for Apple Silicon?
> 
> Karl
> 
> 
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net <mailto:pdl-general@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/pdl-general

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

Re: [Pdl-general] PDL for Apple Silicon

[Karl Glazebrook via pdl-general]

Hi Derek,

I was using gcc and gfortran which I got from http://hpc.sourceforge.net 
<http://hpc.sourceforge.net/>

However this particular gcc seems buggy (libgsl make check  failed!) and I am 
looking next to re-compile everything consistently with either Apple CC or 
Apple GCC - still experimenting! Apple GCC avoids the libgsl problem and I 
expect it will also do fine for pgplot - both GCCs are gcc11 variants.

Note I am also using the X11 server that comes with Macports, which has been 
ported to the M1.

Not sure what is going on with that bug report - I’ve always built SciPDL with 
pgplot v5.3.1 which was the final version and may have fixed some bugs. I now 
see though it was never properly released. I would start by switching to that. 
I also tweaked one of the lines of code in one of the drivers and changed some 
folder defaults.

It would be great to get all of PDL, pgplot etc going in Macports. I now know a 
bunch of tricks for getting everything to build but I don’t really know how to 
write port files - I’d be most happy to work with you or whomever on this 
off-list.

best,

Karl




> On 5 Jan 2021, at 8:39 am, Derek Lamb  wrote:
> 
> Hi Karl,
> 
> I don't have any Apple Silicon to test on, but I'm wondering: how are you 
> getting that dinosaur pgplot (fortran lib, not the Perl) to compile?  What 
> compiler & version?  
> 
> I'm using MacPorts and ever since gcc updated to version 8 I was not able to 
> avoid segfaults (https://trac.macports.org/ticket/57726).  Are you using 
> Homebrew, or building it from scratch?
> 
> Derek
> 
>> On Jan 2, 2021, at 11:23 PM, Karl Glazebrook via pdl-general 
>>  wrote:
>> 
>> Happy New Year everyone! Hopefully 2021 will be better than 2020.
>> 
>> I just got PDL built and working for Apple Silicon!
>> 
>> See screenshot, this is on a M1 MacBook Air.
>> 
>> A few wrinkles in the process, but not that bad.
>> 
>> Who wants to test a new SciPDL for Apple Silicon?
>> 
>> Karl
>> 
>> 
>> 
>> ___
>> pdl-general mailing list
>> pdl-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/pdl-general
> 

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

[Pdl-general] M1 Macs with Big Sur

[Karl Glazebrook via pdl-general]

Hi there PDL users

If anyone is interested - I just got a M1 MacBook Air and I can report that 
SciPDL works just fine!

The trick is to 'break it out of quarantine’ (ironic for 2020):

e.g.

karl@Karls-MacBook-Air ~ % sudo xattr -r -d com.apple.quarantine 
/Applications/PDL

This is under Rosetta obviously (2019 intel binaries) - I will look at 
recompiling it with a new PDL version. Maybe I will even ’sign’ it if I can 
figure out how.

I must say when I started doing SciPDL I hoped it would work across major MacOS 
updates but I didn’t imaging it working across architectures!

Anyone got a good PDL benchmark?

Karl

p.s. the thing is bloody fast! About 4x faster than the intel one it replaced.


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

Re: [Pdl-general] Blue sky - raku

[Karl Glazebrook via pdl-general]

Hi Boyd et al.,

I finally got round to having a play with raku/perl6. Here are some random 
thoughts for the list:

Installed with a one line homebrew command, the executable is still called 
perl6.

Everything it says on the tin (https://raku.guide ) works.

They finally made a built in object system, rationalised the use of sigils and 
cleaned up syntax and subroutine arguments. I kind of think that should have 
been done 15 years ago. Regarding objects they now use something called  
‘roles’, I don’t know enough about OO together this or know if it is a good 
idea. I hope someone can enlighten me.

Added built-ins complex numbers, multidim arrays and rational fractions as 
defaults for decimals. 

The very easy C native calling is extremely nice. 

You can use unicode for variable names e.g. greek letters. You can do this:

> e**(π*i)
-1+1.2246467991473532e-16i

Most of this is stuff python2 had a decade ago.

Here is a nice review:
https://www.evanmiller.org/a-review-of-perl-6.html 
 

A few more interesting things
> e**(π×i) + 1 ≅ 0
True

I read the bit on built in N:M concurrency - that DID look interesting and 
novel. There is no global interpreter thread lock.
https://www.evanmiller.org/why-im-learning-perl-6.html 


I am not a big thread person. Is concurrency a killer app for numerics? It 
seems more useful for massive web loads. I think this depends on the MoarVM - 
so wouldn’t reach down to C-level extensions?

Regarding the future of PDL, any thing like that for raku would be a complete 
rewrite. That is overdue anyway, but would be a lot of work. It’s not so much 
the implementation of the fast array type and slicing, the real work would be 
in catching up with the vast ecosystem of scipy in terms of graphics libraries, 
machine learning toolkits, documentation etc. Given the number of people 
writing new stuff for that ecosystem it seems like a Sisyphean task, unless 
there is some killer new stuff that can only be done in raku. I haven’t seen 
that yet. The ruby folk have started down the path - http://sciruby.com 
 is acknowledged by them to be an order of magnitude 
behind python and R.

Maybe there is a short cut where we can use the python libraries but still 
program in perl? For those of us who don’t think whitespace should be a syntax 
error and like real scoping.

It all puts PDL in a very awkward position. Should we be re-factoring for 
perl5? Does perl5 have a future? Is there a case for numerical extension for 
raku? 

As with all OSS any re-factor or re-write will depend on enough people having a 
passion and a use case to do this.

Anyway I would be most interested to hear what others think! The list seems to 
have gone to quiet low traffic in the last year, which I suspect represents all 
this,

Best,

Karl




> On 11 Jan 2020, at 1:41 am, Boyd Duffee  wrote:
> 
> I've dipped my toe in the Raku waters and can recommend Andrew Shitov's Deep 
> Dive as a good first book for those on this list.
> 
> The one thing that I could see that Raku brings to numerical computing is 
> concurrency[0], making parallelization easy(ish)  Being able to distribute 
> your computation over multiple cores has got to find a win from some types of 
> problems.  Also, it makes it easier to use external libraries with the 
> NativeCall[1] interface.  It calls the library (C++, python, fortran even?) 
> directly without resorting to something like XS.
> 
> The Rat type is interesting, storing numbers as numerator and denominator 
> Ints to avoid rounding errors, but I'm not sure who's going to take advantage 
> of it in heavy numerical situations.  Sequences are lazy iterators [3] and 
> there are types for Set theory and other math operations which could be 
> interesting.
> 
> I think you'd get a lot of millage from listing the "5 things you hate" about 
> PDL (or numpy) and then looking through the docs and/or ask the 
> community[4][5][6] to see if you can find a solution for any of them.
> 
> Boyd
> 

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

[Pdl-general] Blue sky - raku

[Karl Glazebrook via pdl-general]

I wanted to open a blue sky discussion. I see that Perl 6 is now renamed as 
‘Raku’

https://raku.org 

So camels are now butterflies.

Seems like a good decision to me, it seems quite a different language 
syntactically and makes clear there will be different paths for Perl vs Raku 
going forward. No one will expect PDL to work on Raku for example

Has anyone on the list had a good play with Raku? I was wondering what features 
it might have that could be good for numerical computing (future PDL like 
extension?). Does it offer things and features that would be hard to achieve in 
numpy for example?

Karl

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

Re: [Pdl-general] CHM passing on PDL maintainer torch

[Karl Glazebrook via pdl-general]

Thanks Chris for all your hard work. I find it hard to believe too, and equally 
hard to believe PDL is now 23 years old

best

Karl


> On 28 Jul 2019, at 6:25 am, Chris Marshall  wrote:
> 
> Dear PDL Users and Developers,
> 
> I've just transferred maintainership for PDL et. al. to
> EDJ/DJERIUS and am stepping down as the PDL release manager.
> It is hard to believe that it has been 10 years!
> 
> Best wishes to PDL for the next ten years...
> 
> V/r,
> Chris
> 
> "so long and thanks for all the fish!"
> 
> 
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general



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

Re: [Pdl-general] Converting NumPY examples to PDL

[Karl Glazebrook via pdl-general]

Also, a good general rule is any multidim operation which is naturally ‘first 
index first’ in PDL is better expressed as ‘last index first’ in numpy. Then 
the threading <> broadcasting and reduction operations translates reasonably 
naturally. This may require you to transpose your data.

Karl


> On 14 Jul 2019, at 4:54 am, Robert Ryley  wrote:
> 
> I've been working on translating some NumPY examples into PDL.  There
> has been some positive reinforcement on Perl Monks as can be seen
> here:
> 
> https://www.perlmonks.org/?node_id=1233413
> 
> I am stuck on the following NumPy example:
> 
> Q. Create the following pattern without hardcoding. Use only numpy
> functions and the below input array a.
> 
> Input:
> a = np.array([1,2,3])`
> 
> Desired Output:
> array([1, 1, 1, 2, 2, 2, 3, 3, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3])
> 
> Solution
> np.r_[np.repeat(a, 3), np.tile(a, 3)]
> #> array([1, 1, 1, 2, 2, 2, 3, 3, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3])
> 
> Does PDL have something equivalent to NumPy's "tile" function?  I've
> looked through the docs and do not see anything obvious to solve the
> problem.
> 
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general



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

Re: [Pdl-general] Introducing Perl port of R's ggplot2

[Karl Glazebrook via pdl-general]

That is very interesting

Does it support piddles directly?

Karl


> On 24 Mar 2019, at 9:04 pm, Stephan Loyd  wrote:
> 
> Hi pdl users, 
> 
> Hereby I would like to introduce my Perl port of ggplot2: 
> https://metacpan.org/pod/Chart::GGPlot 
> . It's still quite incomplete 
> compared to ggplot2, but the core features already work well. It now supports 
> scatter, line, bar charts and histograms. Also to support this library I 
> created https://metacpan.org/pod/Alt::Data::Frame::ButMore 
> , as I was not able to 
> reach the orginal author of the Data-Frame dist. 
> 
> If interested please try out the libraries from CPAN, or look at the github 
> repos. Any comments or issue reports are welcome. 
> 
> Regards, 
> Stephan
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general

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

[Pdl-general] Fwd: PGPLOT on Mac OSX (Mojave) 10.14.2

[Karl Glazebrook via pdl-general]

I thought I would forward this question to the wider PDL community. I don’t 
know of anything to recommend. Any perl interfaces to things like TensorFlow?

> Begin forwarded message:
> 
> From: 諏訪園秀吾 
> Subject: Re: PGPLOT on Mac OSX (Mojave) 10.14.2
> Date: 6 March 2019 at 12:28:50 am AEDT
> To: Karl Glazebrook 
> 
> 
> By the way, I am looking for libraries for deep learning using Perl, because 
> a recent paper reported that 
> epilepsy diagnosis of electroencephalogram files reached around 70% correct 
> answers (close to those by using the traditional commercial softwares).
> Well, in that paper actually, screenshots of the waveforms were analyzed as 
> images, but not as time series, though…
> Do you know any good example of deep learning with Perl?  Or astronomy does 
> not use deep learning so much as medicine?
> 
> With my best regards,
> Shugo
> 


I did find this with google:

http://blogs.perl.org/users/sergey_kolychev/2017/02/machine-learning-in-perl.html
 

 

Karl

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

Re: [Pdl-general] extutils-f77

[Karl Glazebrook via pdl-general]

This seems like a reasonable change. I am not sure though where the original 
bug was introduced and why/

Can you file it as an issue on github and we can discuss it there?

Also is the debug output a seperate issue? I know a recent patch tried to clean 
up outputs

Karl


> On 19 Feb 2019, at 7:41 am, Luis Mochan  wrote:
> 
> On Mon, Feb 18, 2019 at 11:08:09AM -0500, Chris Marshall wrote:
>> I was going to suggest enabling the debug option
>> by setting $ExtUtils::F77::DEBUG = 1 before the
>> use ExtUtils::F77 but while that worked for my
>> installed version 1.20 it generated no useful
>> output from the version 1.23.
>> 
>> My 1.20 version did not show any extra quotations.
>> If you regress to version 1.20 do things work again?
> 
> I unpacked version 1.20 and it seem to work.
> 
> ...ExtUtils-F77-1.20$ perl -Mlib=blib/lib -MExtUtils::F77 -E 'say 
> ExtUtils::F77->runtime'
> .
> .
> .
> -L/usr/lib/gcc/x86_64-linux-gnu/8 -L/usr/lib -lgfortran -lm
> 
> ...ExtUtils-F77-1.20$ perl -MExtUtils::F77 -E 'say ExtUtils::F77->runtime'
> .
> "-L/usr/lib/gcc/x86_64-linux-gnu/8"  -L/usr/lib -lgfortran -lm
> 
>> If you set $DB::single = 1 before the use ExtUtils::F77
>> line and run your script under the debugger, you should be
>> able to step through the code to see where the values are
>> being generated.
> 
> Thanks for the advice. I believe I found the problem. Line 96 of 
> ExtUtils::F77.pm has
> 
>   return( qq{"-L$dir" $append -L/usr/lib -l$lib -lm} );
> 
> so it quotes with qq *and* with "". I guess it can be fixed removing the 
> double quotes "".
> 
> 
> Best regards,
> Luis
> 
> --patch
> 
> 96c96
> <   return( qq{"-L$dir" $append -L/usr/lib -l$lib -lm} );
> ---
>>  return( qq{-L$dir $append -L/usr/lib -l$lib -lm} );
> 
> --end patch
> 
> 
> 
> 
> -- 
> 
>  o
> W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
> Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
> Apdo. Postal 48-3, 62251 |   (*)/\/  \
> Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
> 
> 
> 
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general



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

Re: [Pdl-general] [PDLPorters/extutils-f77] v1.21 (#3)

[Karl Glazebrook via pdl-general]

Hi PDL-general

So I released a new version of ExtUtils::F77 to CPAN with minor tweaks (via 
PAUSE, see below). However this seems to have resulted in the deletion of the 
entire module!

(Searching CPAN does not find it)

Does anyone have a clue what might have happened? (Note the testing link below 
seems to generate a lot of red, maybe that is something to do with it)

Karl



> The uploaded file
> 
>ExtUtils-F77-1.21.tar.gz
> 
> has entered CPAN as
> 
>  file: $CPAN/authors/id/K/KG/KGB/ExtUtils-F77-1.21.tar.gz
>  size: 12229 bytes
>   md5: c2dfd4f5bc6c57ceb7eb25a669749183
>  sha1: b9777889785fc4a3df660e1e41e5f742099772c1
> 
> CPAN Testers will start reporting results in an hour or so:
> 
>  http://matrix.cpantesters.org/?dist=ExtUtils-F77 
> 
> 
> Request entered by: KGB (Karl Glazebrook)
> Request entered on: Sun, 25 Nov 2018 02:52:36 GMT
> Request completed:  Sun, 25 Nov 2018 02:53:02 GMT
> 
> Thanks,
> -- 
> paused, v1049
___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] SciPDL 2.019

[Karl Glazebrook via pdl-general]

BTW everyone - how do we update the web site?

Maybe that should also be on github.

Karl


> On 20 Oct 2018, at 7:19 pm, Karl Glazebrook  wrote:
> 
> Hi PDL-folk,
> 
> Belated action on this. I read the article linked below by Sergey and it 
> describes how to add binary files to releases.
> 
> So I’ve added SciPDL-v2.019.dmg to the binary files for the 2.019 release, I 
> hope I got that right
> 
> https://github.com/PDLPorters/pdl/releases/download/v2.019/SciPDL-v2.019.dmg
> 
> Will try and make it a habit
> 
> Karl
> 
> 
> 
>> On 29 Sep 2018, at 2:44 am, Sergey Kolychev 
>>  wrote:
>> 
>> One way (not sure if optimal) is creating a repository for SciPDL with just 
>> a README file and then creating a release 
>> https://help.github.com/articles/about-releases/ with included binary file.
>> 
>> On Fri, Sep 28, 2018 at 3:19 AM Karl Glazebrook via pdl-general 
>>  wrote:
>> Hi everyone
>> 
>> HOW do I put it on github?
>> 
>> I am looking at  PDLPorters/pdl and I do not see an obvious place to put a 
>> big fat binary file… I don’t want to put them in the source code tree 
>> obviously.
>> 
>> KArl
>> 
>> 
> 



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

Re: [Pdl-general] SciPDL 2.019

[Karl Glazebrook via pdl-general]

Hi PDL-folk,

Belated action on this. I read the article linked below by Sergey and it 
describes how to add binary files to releases.

So I’ve added SciPDL-v2.019.dmg to the binary files for the 2.019 release, I 
hope I got that right

 https://github.com/PDLPorters/pdl/releases/download/v2.019/SciPDL-v2.019.dmg

Will try and make it a habit

Karl



> On 29 Sep 2018, at 2:44 am, Sergey Kolychev  
> wrote:
> 
> One way (not sure if optimal) is creating a repository for SciPDL with just a 
> README file and then creating a release 
> https://help.github.com/articles/about-releases/ with included binary file.
> 
> On Fri, Sep 28, 2018 at 3:19 AM Karl Glazebrook via pdl-general 
>  wrote:
> Hi everyone
> 
> HOW do I put it on github?
> 
> I am looking at  PDLPorters/pdl and I do not see an obvious place to put a 
> big fat binary file… I don’t want to put them in the source code tree 
> obviously.
> 
> KArl
> 
> 



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

Re: [Pdl-general] SciPDL 2.019

[Karl Glazebrook via pdl-general]

Hi everyone

HOW do I put it on github?

I am looking at  PDLPorters/pdl and I do not see an obvious place to put a big 
fat binary file… I don’t want to put them in the source code tree obviously.

KArl



> On 27 Aug 2018, at 6:23 am, Craig DeForest  wrote:
> 
> I would put it on github.
> 
> I’m still using PDL, but I’m sorry to admit I’ve never really used SciPDL.  
> I’ve got too much custom stuff around.  
> 
> 
>> On Aug 25, 2018, at 9:09 PM, Karl Glazebrook via pdl-general 
>>  wrote:
>> 
>> opinion/advice? defeaning silence! Maybe you are all using numpy now :)
>> 
>> 
>>> On 30 Jul 2018, at 6:23 pm, Karl Glazebrook via pdl-general 
>>>  wrote:
>>> 
>>> I am happy to try adding other modules, yes it is supposed to be a kitchen 
>>> sink.
>>> 
>>> I’d like to know first who else on this list wants these things?
>>> 
>>> 
>>> I think I should put the file on github. Probably I should a special 
>>> repository under ‘PDL porters’ to avoid polluting the main folder? Or is 
>>> there an alternative github means to associate binary files with projects?
>>> 
>>> 
>>> Karl
>>> 
>>> 
>>> 
>>> 
>>>> On 29 Jul 2018, at 4:26 am, Chris Marshall  wrote:
>>>> 
>>>> TriD is not deprecated and will be built if you have the OpenGL module 
>>>> installed.  Since the SciPDL is a basic kitchen sink for PDL on MacOSX, I 
>>>> think it would be nice to have trid, gnuplot and prima available.  More 
>>>> power to you that you have PGPLOT as well.
>>>> 
>>>> Although PDL development is done at github now, we can still use the files 
>>>> option at sf.net for SciPDL.  Which reminds me that I was forgot to push a 
>>>> PDL-2.019 release for sf.net downloaders.  I can put SciPDL there as well.
>>>> 
>>>> --Chris
>>>> 
>>>> On 7/27/2018 22:45, Karl Glazebrook via pdl-general wrote:
>>>>> 
>>>>> 
>>>>> Thanks. I have never built it with gnuplot or prima, but could consider 
>>>>> that by popular demand. I think the TriD is now deprecated?
>>>>> 
>>>>> Karl
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 28 Jul 2018, at 4:43 am, Sergey Kolychev 
>>>>>>  wrote:
>>>>>> 
>>>>>> Hi Karl,
>>>>>> 
>>>>>> Works on MacOS Sierra, 10.12.6, I tried following demos (marked ones 
>>>>>> that did not work, packages missing I think):
>>>>>> 
>>>>>>demo pdl # general demo
>>>>>> 
>>>>>> -   demo 3d  # 3d demo (requires TriD with OpenGL or Mesa)
>>>>>> -   demo 3d2 # 3d demo, part 2. (Somewhat memory-intensive)
>>>>>> -   demo 3dgal   # the 3D gallery: make cool images with 3-line 
>>>>>> scripts
>>>>>> 
>>>>>>demo pgplot  # PGPLOT graphics output (Req.: PGPLOT)
>>>>>>demo OOplot  # PGPLOT OO interface(Req.: PGPLOT)
>>>>>> 
>>>>>> -   demo gnuplot # Gnuplot graphics (requires PDL::Graphics::Gnuplot)
>>>>>> -   demo prima   # Prima graphics (requires PDL::Graphics::Prima)
>>>>>> 
>>>>>>demo transform   # Coordinate transformations (Req.: PGPLOT)
>>>>>>demo cartography # Cartographic projections (Req.: PGPLOT)
>>>>>> 
>>>>>>demo bad # Bad-value demo (Req.: bad value support)
>>>>>>demo bad2# Bad-values, part 2 (Req.: bad value support and 
>>>>>> PGPLOT)
>>>>>> 
>>>>>> Thanks. 
>>>>>> P.S.
>>>>>> I'd vote for github if my vote matters.
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jul 27, 2018 at 2:14 AM, Karl Glazebrook via pdl-general 
>>>>>>  wrote:
>>>>>> I’ve made SciPDL 2.019 for MacOS X (sorry for the delay, I will do 
>>>>>> better next time, I filed this under ‘do later’ and didn't)
>>>>>> 
>>>>>> https://www.dropbox.com/s/dwgmmegvzk5zt7n/SciPDL-v2.019.dmg?dl=0
>>>>>> 
>>>>>> Where should I put it? SF or github?
>>>>>> 
>>>>>> (Also someone please test)
>>>>>

Re: [Pdl-general] SciPDL 2.019

[Karl Glazebrook via pdl-general]

opinion/advice? defeaning silence! Maybe you are all using numpy now :)


> On 30 Jul 2018, at 6:23 pm, Karl Glazebrook via pdl-general 
>  wrote:
> 
> I am happy to try adding other modules, yes it is supposed to be a kitchen 
> sink.
> 
> I’d like to know first who else on this list wants these things?
> 
> 
> I think I should put the file on github. Probably I should a special 
> repository under ‘PDL porters’ to avoid polluting the main folder? Or is 
> there an alternative github means to associate binary files with projects?
> 
> 
> Karl
> 
> 
> 
> 
>> On 29 Jul 2018, at 4:26 am, Chris Marshall > <mailto:devel.chm...@gmail.com>> wrote:
>> 
>> TriD is not deprecated and will be built if you have the OpenGL module 
>> installed.  Since the SciPDL is a basic kitchen sink for PDL on MacOSX, I 
>> think it would be nice to have trid, gnuplot and prima available.  More 
>> power to you that you have PGPLOT as well.
>> 
>> Although PDL development is done at github now, we can still use the files 
>> option at sf.net <http://sf.net/> for SciPDL.  Which reminds me that I was 
>> forgot to push a PDL-2.019 release for sf.net <http://sf.net/> downloaders.  
>> I can put SciPDL there as well.
>> 
>> --Chris
>> 
>> On 7/27/2018 22:45, Karl Glazebrook via pdl-general wrote:
>>> 
>>> 
>>> Thanks. I have never built it with gnuplot or prima, but could consider 
>>> that by popular demand. I think the TriD is now deprecated?
>>> 
>>> Karl
>>> 
>>> 
>>> 
>>> 
>>>> On 28 Jul 2018, at 4:43 am, Sergey Kolychev 
>>>> mailto:sergeykolychev.git...@gmail.com>> 
>>>> wrote:
>>>> 
>>>> Hi Karl,
>>>> 
>>>> Works on MacOS Sierra, 10.12.6, I tried following demos (marked ones that 
>>>> did not work, packages missing I think):
>>>> 
>>>>demo pdl # general demo
>>>> 
>>>> -   demo 3d  # 3d demo (requires TriD with OpenGL or Mesa)
>>>> -   demo 3d2 # 3d demo, part 2. (Somewhat memory-intensive)
>>>> -   demo 3dgal   # the 3D gallery: make cool images with 3-line scripts
>>>> 
>>>>demo pgplot  # PGPLOT graphics output (Req.: PGPLOT)
>>>>demo OOplot  # PGPLOT OO interface(Req.: PGPLOT)
>>>> 
>>>> -   demo gnuplot # Gnuplot graphics (requires PDL::Graphics::Gnuplot)
>>>> -   demo prima   # Prima graphics (requires PDL::Graphics::Prima)
>>>> 
>>>>demo transform   # Coordinate transformations (Req.: PGPLOT)
>>>>demo cartography # Cartographic projections (Req.: PGPLOT)
>>>> 
>>>>demo bad # Bad-value demo (Req.: bad value support)
>>>>demo bad2# Bad-values, part 2 (Req.: bad value support and 
>>>> PGPLOT)
>>>> 
>>>> Thanks. 
>>>> P.S.
>>>> I'd vote for github if my vote matters.
>>>> 
>>>> 
>>>> On Fri, Jul 27, 2018 at 2:14 AM, Karl Glazebrook via pdl-general 
>>>> >>> <mailto:pdl-general@lists.sourceforge.net>> wrote:
>>>> I’ve made SciPDL 2.019 for MacOS X (sorry for the delay, I will do better 
>>>> next time, I filed this under ‘do later’ and didn't)
>>>> 
>>>> https://www.dropbox.com/s/dwgmmegvzk5zt7n/SciPDL-v2.019.dmg?dl=0 
>>>> <https://www.dropbox.com/s/dwgmmegvzk5zt7n/SciPDL-v2.019.dmg?dl=0>
>>>> 
>>>> Where should I put it? SF or github?
>>>> 
>>>> (Also someone please test)
>>>> 
>>>> cheers,
>>>> 
>>>> Karl
>>>> 
>>>> 
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org <http://slashdot.org/>! 
>>>> http://sdm.link/slashdot <http://sdm.link/slashdot>
>>>> ___
>>>> pdl-general mailing list
>>>> pdl-general@lists.sourceforge.net 
>>>> <mailto:pdl-general@lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/pdl-general 
>>>> <https://lists.sourceforge.net/lists/listinfo/pdl-general>
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -

[Pdl-general] SciPDL 2.019

[Karl Glazebrook via pdl-general]

I’ve made SciPDL 2.019 for MacOS X (sorry for the delay, I will do better next 
time, I filed this under ‘do later’ and didn't)

https://www.dropbox.com/s/dwgmmegvzk5zt7n/SciPDL-v2.019.dmg?dl=0 


Where should I put it? SF or github?

(Also someone please test)

cheers,

Karl

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