Menu
▾
▴
pdl-devel — PDL Developers and Internals Discussion
You can subscribe to this list here.
| 2015 |
Jan
|
Feb
(44) |
Mar
(75) |
Apr
(42) |
May
(50) |
Jun
(82) |
Jul
(17) |
Aug
(45) |
Sep
(32) |
Oct
(32) |
Nov
(41) |
Dec
(22) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 |
Jan
(9) |
Feb
(5) |
Mar
(6) |
Apr
(6) |
May
(34) |
Jun
(47) |
Jul
(10) |
Aug
(2) |
Sep
(6) |
Oct
(35) |
Nov
(6) |
Dec
|
| 2017 |
Jan
(7) |
Feb
(5) |
Mar
(3) |
Apr
(2) |
May
(12) |
Jun
(1) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(16) |
Apr
(7) |
May
(10) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(32) |
May
(11) |
Jun
(5) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2021 |
Jan
|
Feb
(25) |
Mar
(38) |
Apr
(11) |
May
(3) |
Jun
(6) |
Jul
(2) |
Aug
(22) |
Sep
(12) |
Oct
(18) |
Nov
(6) |
Dec
(1) |
| 2022 |
Jan
(5) |
Feb
(47) |
Mar
(6) |
Apr
(9) |
May
(7) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
(17) |
Oct
(5) |
Nov
|
Dec
|
| 2024 |
Jan
(8) |
Feb
(4) |
Mar
(1) |
Apr
(8) |
May
(13) |
Jun
(10) |
Jul
|
Aug
|
Sep
(1) |
Oct
(16) |
Nov
(9) |
Dec
(18) |
| 2025 |
Jan
(47) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ed . <ej...@ho...> - 2024-10-24 13:02:53
|
Hi Guillermo,
You're welcome? To do the exact thing you're referring to here, you'd need to give an argument of 3, rather than 2, to "reduce", for the zero-based 4th dim.
I hope this has in fact solved your problem. If not, please keep asking :-)
Best regards,
Ed
________________________________
From: Guillermo P. Ortiz <go...@ex...>
Sent: 24 October 2024 1:57 PM
To: Ed . <ej...@ho...>
Cc: pdl...@li... <pdl...@li...>; pdl...@li... <pdl...@li...>
Subject: Re: [Pdl-devel] project ordered sequence image
Hello Ed,
thanks for your reply.
That I trying to mean with 'reduce' is some of
projection operation (op) like in PDL::Reduce module
that performs "(op)over" to reduce to N-1
dimension after some operation over the set of
(3,x,y, n) to (3,x,y) rgb images. I mean
a composed rgb image from a set of (layer) n rgb images.
For example:
$imn-> info : pdl D [3,nx,ny,n]
$im=$imn->reduce('op',2);
$im-> info : pdl D [3,nx,ny]
Then, maybe I need to introduce some "sort"
operation in order that when I reduce to one
composed $im image each layer in $imn overlap
the following layer. But, I did not realize how to do that
using some pdl trick.
Thanks a lot for your help
Regards
El jue, 24 oct 2024 a las 9:12, Ed . (<ej...@ho...<mailto:ej...@ho...>>) escribió:
Hi Guillermo,
I believe the situation you're describing is you have effectively a series of (3,x,y) images. You mention "reducing", but you haven't said what you mean by that - would it turn that series of images into one image?
wpic is intended to write out a single image, so an ndarray with multiple images won't work with that. To write out a series of images as a movie you could use wmpeg, or just to store the data you could use https://metacpan.org/pod/PDL::IO::FastRaw and specifically writefraw. Otherwise to write each image in its own file you could use something like:
$_->wpic(sprintf "img%03d.png", $count++) for $pdl->dog;
Does that help?
Best regards,
Ed
________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 23 October 2024 4:42 PM
To: pdl...@li...<mailto:pdl...@li...> <pdl...@li...<mailto:pdl...@li...>>; pdl...@li...<mailto:pdl...@li...> <pdl...@li...<mailto:pdl...@li...>>
Subject: [Pdl-devel] project ordered sequence image
Hello everyone,
I have created a pdl with structure (3,size_x,size_y,np)
in order to manage different layer features to compose an rgb
image.
The idea that I can not connect yet is how to "reduce" over dim 3
to project to 3 X s_x X s_y rgb image in ordered fashion sequence. For example,
suppose that for np=0, 1 and 2, in the resulting image is only view of 2 that
is allowed by 1 and 0 layers, in that order.
I am trying to use wpic command from PDL::IO::Pic module
to convert via for example pnmtopng using options for it.
There are hashes like {FLAGS => options} used for options
{CONVERTER => 'pnmtopng'} indicating which conversor to use.
But is seems to be intended of rgb 3(4) X s_x X s_y
Thanks for your attention in advance
Regards
--
Dr. Guillermo P. Ortiz
Electromagnetismo Aplicado
Dto. Física, Facultad de Ciencias Exactas
Universidad Nacional del Nordeste
Avda Libertad 5460, Campus UNNE.
W3404AAS Corrientes, Argentina.
(+54) 379-4424678 interno 4613
gortiz at unne edu ar
|
|
From: Ed . <ej...@ho...> - 2024-10-24 12:12:12
|
Hi Guillermo, I believe the situation you're describing is you have effectively a series of (3,x,y) images. You mention "reducing", but you haven't said what you mean by that - would it turn that series of images into one image? wpic is intended to write out a single image, so an ndarray with multiple images won't work with that. To write out a series of images as a movie you could use wmpeg, or just to store the data you could use https://metacpan.org/pod/PDL::IO::FastRaw and specifically writefraw. Otherwise to write each image in its own file you could use something like: $_->wpic(sprintf "img%03d.png", $count++) for $pdl->dog; Does that help? Best regards, Ed ________________________________ From: Guillermo P. Ortiz <go...@ex...> Sent: 23 October 2024 4:42 PM To: pdl...@li... <pdl...@li...>; pdl...@li... <pdl...@li...> Subject: [Pdl-devel] project ordered sequence image Hello everyone, I have created a pdl with structure (3,size_x,size_y,np) in order to manage different layer features to compose an rgb image. The idea that I can not connect yet is how to "reduce" over dim 3 to project to 3 X s_x X s_y rgb image in ordered fashion sequence. For example, suppose that for np=0, 1 and 2, in the resulting image is only view of 2 that is allowed by 1 and 0 layers, in that order. I am trying to use wpic command from PDL::IO::Pic module to convert via for example pnmtopng using options for it. There are hashes like {FLAGS => options} used for options {CONVERTER => 'pnmtopng'} indicating which conversor to use. But is seems to be intended of rgb 3(4) X s_x X s_y Thanks for your attention in advance Regards -- Dr. Guillermo P. Ortiz Electromagnetismo Aplicado Dto. Física, Facultad de Ciencias Exactas Universidad Nacional del Nordeste Avda Libertad 5460, Campus UNNE. W3404AAS Corrientes, Argentina. (+54) 379-4424678 interno 4613 gortiz at unne edu ar |
|
From: Guillermo P. O. <go...@ex...> - 2024-10-23 17:47:11
|
Hello everyone,
I have created a pdl with structure (3,size_x,size_y,np)
in order to manage different layer features to compose an rgb
image.
The idea that I can not connect yet is how to "reduce" over dim 3
to project to 3 X s_x X s_y rgb image in ordered fashion sequence. For
example,
suppose that for np=0, 1 and 2, in the resulting image is only view of 2
that
is allowed by 1 and 0 layers, in that order.
I am trying to use wpic command from PDL::IO::Pic module
to convert via for example pnmtopng using options for it.
There are hashes like {FLAGS => options} used for options
{CONVERTER => 'pnmtopng'} indicating which conversor to use.
But is seems to be intended of rgb 3(4) X s_x X s_y
Thanks for your attention in advance
Regards
--
Dr. Guillermo P. Ortiz
Electromagnetismo Aplicado
Dto. Física, Facultad de Ciencias Exactas
Universidad Nacional del Nordeste
Avda Libertad 5460, Campus UNNE.
W3404AAS Corrientes, Argentina.
(+54) 379-4424678 interno 4613
gortiz* at *unne edu ar
|
|
From: Ed . <ej...@ho...> - 2024-09-19 20:57:14
|
Dear PDL folks, PDL 2.092 has just been released. Notable changes since 2.087: * fix badvalue propagation * core support for PDL::Parallel::threads * change dataflow to work one-shot each time like "inplace" * add demos of PDL::GSL::RNG, PDL::GSL::CDF, PDL::Func * fix MatrixOps::eigens for asymmetric case inc complex eigenvectors * wfits fixed to handle multi-line HISTORY * fix handling large Perl scalar values * add spline-handling functions in PDL::Slatec * PP dim sizes can be =CALC(...) instead of explicit RedoDimsCode The IRC channel (#pdl on irc.perl.org) is a great virtual place to come and ask questions, or just watch the GitHub messages flow by. As usual, please give the new release a try and report problems. Best regards, Ed |
|
From: Guillermo P. O. <go...@ex...> - 2024-06-13 20:15:19
|
Thanks to Chris for the inspired information, and
to Ed for suggestions about PDL::Transform that I need to review.
For now I have a first awful but seems to be a functional version
$field is ndarray with doubles [2,$N,$N]
$x are the index for $M < $N that I want to decimate
my @field_int_f=();
my @field_int_c=();
foreach (0..($N-1)){
my
$spl_fx=PDL::GSL::INTERP->init('cspline',sequence($N),$field->((0),,($_)));
my
$spl_cx=PDL::GSL::INTERP->init('cspline',sequence($N),$field->((0),($_),));
my
$spl_fy=PDL::GSL::INTERP->init('cspline',sequence($N),$field->((1),,($_)));
my
$spl_cy=PDL::GSL::INTERP->init('cspline',sequence($N),$field->((1),($_),));
push @field_int_f, pdl($spl_fx->eval($x),$spl_fy->eval($x));
push @field_int_c, pdl($spl_cx->eval($x),$spl_cy->eval($x));
};
my $fint=pdl(pdl(@field_int_f),pdl(@field_int_c))->mv(-1,0)->mv(-1,0);
say $fint->info;
my $ff=index1d($fint(,(0),,), $x->(:,*$x->dims))->mv(-1,0);
Regards
El jue, 13 jun 2024 a las 10:55, chm (<dev...@gm...>) escribió:
> If M and N are integers and N%M == 0 then you could use indexing and
> dimension "tricks" to collect the values for the new pixels to the first
> dim
>
> and then apply your preferred interpolation/smoothing operation.
>
>
> You may find inspiration at
> https://github.com/PDLPorters/pdl/wiki/Resampling-up-a-piddle
>
>
> --Chris
>
>
> On 6/13/2024 8:33 AM, Ed . wrote:
>
> Hi Guillermo,
>
> Try https://metacpan.org/pod/PDL::Transform#match ?
>
> Best regards,
> Ed
> ------------------------------
> *From:* Guillermo P. Ortiz <go...@ex...>
> <go...@ex...>
> *Sent:* 13 June 2024 12:04 AM
> *To:* pdl...@li... <pdl...@li...>
> <pdl...@li...>; pdl...@li...
> <pdl...@li...> <pdl...@li...>
> *Subject:* [Pdl-devel] decimate function
>
> Hello everybody,
> maybe somebody know how to decimate a 2d ndarray
> through some average and reducing the number
> of pixels from (Nx,Ny) to (Mx,My), (in a 2D image for example?)
> where M< N in order to reduce large amounts
> of data but remaining main information as possible.
>
> I can imagine how to use the PDL::GSL::INTERP module
> for inward interpolation, but it seems that no threading
> (broadcasting) is possible with it
>
> Thank you in advance,
>
> Regards
>
>
> --
>
>
> Dr. Guillermo P. Ortiz
> Electromagnetismo Aplicado
> Dto. Física, Facultad de Ciencias Exactas
> Universidad Nacional del Nordeste
> Avda Libertad 5460, Campus UNNE.
> W3404AAS Corrientes, Argentina.
> (+54) 379-4424678 interno 4613
> gortiz* at *unne edu ar
>
>
> _______________________________________________
> pdl-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
> _______________________________________________
> pdl-devel mailing list
> pdl...@li...
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
|
|
From: chm <dev...@gm...> - 2024-06-13 13:55:48
|
If M and N are integers and N%M == 0 then you could use indexing and dimension "tricks" to collect the values for the new pixels to the first dim and then apply your preferred interpolation/smoothing operation. You may find inspiration at https://github.com/PDLPorters/pdl/wiki/Resampling-up-a-piddle --Chris On 6/13/2024 8:33 AM, Ed . wrote: > Hi Guillermo, > > Try https://metacpan.org/pod/PDL::Transform#match ? > > Best regards, > Ed > ------------------------------------------------------------------------ > *From:* Guillermo P. Ortiz <go...@ex...> > *Sent:* 13 June 2024 12:04 AM > *To:* pdl...@li... > <pdl...@li...>; pdl...@li... > <pdl...@li...> > *Subject:* [Pdl-devel] decimate function > Hello everybody, > maybe somebody know how to decimate a 2d ndarray > through some average and reducing the number > of pixels from (Nx,Ny) to (Mx,My), (in a 2D image for example?) > where M< N in order to reduce large amounts > of data but remaining main information as possible. > > I can imagine how to use the PDL::GSL::INTERP module > for inward interpolation, but it seems that no threading > (broadcasting) is possible with it > > Thank you in advance, > > Regards > > > -- > > > Dr. Guillermo P. Ortiz > Electromagnetismo Aplicado > Dto. Física, Facultad de Ciencias Exactas > Universidad Nacional del Nordeste > Avda Libertad 5460, Campus UNNE. > W3404AAS Corrientes, Argentina. > (+54) 379-4424678 interno 4613 > gortiz*at *unne edu ar > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: Ed . <ej...@ho...> - 2024-06-13 12:33:19
|
Hi Guillermo, Try https://metacpan.org/pod/PDL::Transform#match ? Best regards, Ed ________________________________ From: Guillermo P. Ortiz <go...@ex...> Sent: 13 June 2024 12:04 AM To: pdl...@li... <pdl...@li...>; pdl...@li... <pdl...@li...> Subject: [Pdl-devel] decimate function Hello everybody, maybe somebody know how to decimate a 2d ndarray through some average and reducing the number of pixels from (Nx,Ny) to (Mx,My), (in a 2D image for example?) where M< N in order to reduce large amounts of data but remaining main information as possible. I can imagine how to use the PDL::GSL::INTERP module for inward interpolation, but it seems that no threading (broadcasting) is possible with it Thank you in advance, Regards -- Dr. Guillermo P. Ortiz Electromagnetismo Aplicado Dto. Física, Facultad de Ciencias Exactas Universidad Nacional del Nordeste Avda Libertad 5460, Campus UNNE. W3404AAS Corrientes, Argentina. (+54) 379-4424678 interno 4613 gortiz at unne edu ar |
|
From: Guillermo P. O. <go...@ex...> - 2024-06-12 23:27:19
|
Hello everybody, maybe somebody know how to decimate a 2d ndarray through some average and reducing the number of pixels from (Nx,Ny) to (Mx,My), (in a 2D image for example?) where M< N in order to reduce large amounts of data but remaining main information as possible. I can imagine how to use the PDL::GSL::INTERP module for inward interpolation, but it seems that no threading (broadcasting) is possible with it Thank you in advance, Regards -- Dr. Guillermo P. Ortiz Electromagnetismo Aplicado Dto. Física, Facultad de Ciencias Exactas Universidad Nacional del Nordeste Avda Libertad 5460, Campus UNNE. W3404AAS Corrientes, Argentina. (+54) 379-4424678 interno 4613 gortiz* at *unne edu ar |
|
From: Ed . <ej...@ho...> - 2024-06-02 20:07:06
|
PRs welcome! ________________________________ From: chm <dev...@gm...> Sent: Sunday, June 2, 2024 4:54:22 PM To: pdl...@li... <pdl...@li...> Subject: Re: [Pdl-devel] .gitignore strangeness What about output in the files at the top saying something like "This file is generated from XXX.pd. Please modify that instead. Edits to this file will be overwritten."? On 6/2/2024 6:18 AM, Jörg Sommrey wrote: > What about this paragraph as part of the OVERVIEW / WARNING section in > PDL::PP: > > Another problem arises from the number of generated files that may be > confusing especially when dealing with existing code. Bear in mind > that > the only sources are ".pd" and ".pod" files, while ".pm", ".xs" > and ".c" > files are generated from the ".pd" files and shall not be altered as > these changes would be overwritten. > > Best regards, > -jo > > > On Sat 01 Jun 2024 10:47:10 PM CEST, "Ed ." <ej...@ho...> wrote: > >> This should probably be added to PDL::PP docs, both where these files >> come from, and a recommendation to ignore the generated ones. Jörg, >> feel like extending your doc-updating? :-) >> >> Best regards, >> Ed >> >> ________________________________ >> From: Jörg Sommrey <jo...@so...> >> Sent: Friday, May 31, 2024 9:35:55 PM >> To: pdl...@li... <pdl...@li...> >> Subject: Re: [Pdl-devel] .gitignore strangeness >> >> Thanks Ingo and David, >> >> found the source thanks to your hints. The .gitignore makes sense now! >> >> Best regards, >> -jo >> >> On Fri 31 May 2024 10:24:41 PM CEST, Ingo Schmid via pdl-devel >> <pdl...@li...> wrote: >> >>> Hi Jörg, >>> >>> this is because they are generated from basic.pd, ufunc.pd, etc. See >>> PDL::PP! It is a neat feature to generate code for all data types in >>> both C and Perl level. It is not intuitive for newer folk, though. >>> >>> Ingo >>> >>> On 5/31/2024 9:49 PM, Jörg Sommrey wrote: >>>> Hi all, >>>> >>>> just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are >>>> listed in .gitignore. What would be the suggested workflow to patch >>>> such files? >>>> >>>> Best regards, >>>> -jo >>>> >>>> >>>> _______________________________________________ >>>> pdl-devel mailing list >>>> pdl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pdl-devel >>> >>> >>> _______________________________________________ >>> pdl-devel mailing list >>> pdl...@li... >>> https://lists.sourceforge.net/lists/listinfo/pdl-devel >> >> >> >> >> _______________________________________________ >> pdl-devel mailing list >> pdl...@li... >> https://lists.sourceforge.net/lists/listinfo/pdl-devel > > > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel _______________________________________________ pdl-devel mailing list pdl...@li... https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: Jörg S. <jo...@so...> - 2024-06-02 19:12:04
|
On Sun 02 Jun 2024 05:54:22 PM CEST, chm <dev...@gm...> wrote: > What about output in the files at the top saying something > like "This file is generated from XXX.pd. Please modify that instead. > Edits to this file will be overwritten."? It's already there, but only for those who can read: # # GENERATED WITH PDL::PP! Don't modify! # > > On 6/2/2024 6:18 AM, Jörg Sommrey wrote: >> What about this paragraph as part of the OVERVIEW / WARNING section >> in PDL::PP: >> >> Another problem arises from the number of generated files that may be >> confusing especially when dealing with existing code. Bear in mind that >> the only sources are ".pd" and ".pod" files, while ".pm", ".xs" and ".c" >> files are generated from the ".pd" files and shall not be altered as >> these changes would be overwritten. >> >> Best regards, >> -jo >> >> >> On Sat 01 Jun 2024 10:47:10 PM CEST, "Ed ." <ej...@ho...> wrote: >> >>> This should probably be added to PDL::PP docs, both where these >>> files come from, and a recommendation to ignore the generated >>> ones. Jörg, feel like extending your doc-updating? :-) >>> >>> Best regards, >>> Ed >>> >>> ________________________________ >>> From: Jörg Sommrey <jo...@so...> >>> Sent: Friday, May 31, 2024 9:35:55 PM >>> To: pdl...@li... <pdl...@li...> >>> Subject: Re: [Pdl-devel] .gitignore strangeness >>> >>> Thanks Ingo and David, >>> >>> found the source thanks to your hints. The .gitignore makes sense now! >>> >>> Best regards, >>> -jo >>> >>> On Fri 31 May 2024 10:24:41 PM CEST, Ingo Schmid via pdl-devel >>> <pdl...@li...> wrote: >>> >>>> Hi Jörg, >>>> >>>> this is because they are generated from basic.pd, ufunc.pd, etc. See >>>> PDL::PP! It is a neat feature to generate code for all data types in >>>> both C and Perl level. It is not intuitive for newer folk, though. >>>> >>>> Ingo >>>> >>>> On 5/31/2024 9:49 PM, Jörg Sommrey wrote: >>>>> Hi all, >>>>> >>>>> just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are >>>>> listed in .gitignore. What would be the suggested workflow to patch >>>>> such files? >>>>> >>>>> Best regards, >>>>> -jo >>>>> >>>>> >>>>> _______________________________________________ >>>>> pdl-devel mailing list >>>>> pdl...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/pdl-devel >>>> >>>> >>>> _______________________________________________ >>>> pdl-devel mailing list >>>> pdl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pdl-devel >>> >>> >>> >>> >>> _______________________________________________ >>> pdl-devel mailing list >>> pdl...@li... >>> https://lists.sourceforge.net/lists/listinfo/pdl-devel >> >> >> >> >> _______________________________________________ >> pdl-devel mailing list >> pdl...@li... >> https://lists.sourceforge.net/lists/listinfo/pdl-devel > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: chm <dev...@gm...> - 2024-06-02 15:54:31
|
What about output in the files at the top saying something like "This file is generated from XXX.pd. Please modify that instead. Edits to this file will be overwritten."? On 6/2/2024 6:18 AM, Jörg Sommrey wrote: > What about this paragraph as part of the OVERVIEW / WARNING section in > PDL::PP: > > Another problem arises from the number of generated files that may be > confusing especially when dealing with existing code. Bear in mind > that > the only sources are ".pd" and ".pod" files, while ".pm", ".xs" > and ".c" > files are generated from the ".pd" files and shall not be altered as > these changes would be overwritten. > > Best regards, > -jo > > > On Sat 01 Jun 2024 10:47:10 PM CEST, "Ed ." <ej...@ho...> wrote: > >> This should probably be added to PDL::PP docs, both where these files >> come from, and a recommendation to ignore the generated ones. Jörg, >> feel like extending your doc-updating? :-) >> >> Best regards, >> Ed >> >> ________________________________ >> From: Jörg Sommrey <jo...@so...> >> Sent: Friday, May 31, 2024 9:35:55 PM >> To: pdl...@li... <pdl...@li...> >> Subject: Re: [Pdl-devel] .gitignore strangeness >> >> Thanks Ingo and David, >> >> found the source thanks to your hints. The .gitignore makes sense now! >> >> Best regards, >> -jo >> >> On Fri 31 May 2024 10:24:41 PM CEST, Ingo Schmid via pdl-devel >> <pdl...@li...> wrote: >> >>> Hi Jörg, >>> >>> this is because they are generated from basic.pd, ufunc.pd, etc. See >>> PDL::PP! It is a neat feature to generate code for all data types in >>> both C and Perl level. It is not intuitive for newer folk, though. >>> >>> Ingo >>> >>> On 5/31/2024 9:49 PM, Jörg Sommrey wrote: >>>> Hi all, >>>> >>>> just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are >>>> listed in .gitignore. What would be the suggested workflow to patch >>>> such files? >>>> >>>> Best regards, >>>> -jo >>>> >>>> >>>> _______________________________________________ >>>> pdl-devel mailing list >>>> pdl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pdl-devel >>> >>> >>> _______________________________________________ >>> pdl-devel mailing list >>> pdl...@li... >>> https://lists.sourceforge.net/lists/listinfo/pdl-devel >> >> >> >> >> _______________________________________________ >> pdl-devel mailing list >> pdl...@li... >> https://lists.sourceforge.net/lists/listinfo/pdl-devel > > > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: Ed . <ej...@ho...> - 2024-06-02 14:17:29
|
That was what I had in mind. Feel like making a PR?
________________________________
From: Jörg Sommrey <jo...@so...>
Sent: Sunday, June 2, 2024 11:18:28 AM
To: Ed . <ej...@ho...>
Cc: pdl...@li... <pdl...@li...>
Subject: Re: [Pdl-devel] .gitignore strangeness
What about this paragraph as part of the OVERVIEW / WARNING section in
PDL::PP:
Another problem arises from the number of generated files that may be
confusing especially when dealing with existing code. Bear in mind that
the only sources are ".pd" and ".pod" files, while ".pm", ".xs" and ".c"
files are generated from the ".pd" files and shall not be altered as
these changes would be overwritten.
Best regards,
-jo
On Sat 01 Jun 2024 10:47:10 PM CEST, "Ed ." <ej...@ho...> wrote:
> This should probably be added to PDL::PP docs, both where these
> files come from, and a recommendation to ignore the generated ones.
> Jörg, feel like extending your doc-updating? :-)
>
> Best regards,
> Ed
>
> ________________________________
> From: Jörg Sommrey <jo...@so...>
> Sent: Friday, May 31, 2024 9:35:55 PM
> To: pdl...@li... <pdl...@li...>
> Subject: Re: [Pdl-devel] .gitignore strangeness
>
> Thanks Ingo and David,
>
> found the source thanks to your hints. The .gitignore makes sense now!
>
> Best regards,
> -jo
>
> On Fri 31 May 2024 10:24:41 PM CEST, Ingo Schmid via pdl-devel
> <pdl...@li...> wrote:
>
>> Hi Jörg,
>>
>> this is because they are generated from basic.pd, ufunc.pd, etc. See
>> PDL::PP! It is a neat feature to generate code for all data types in
>> both C and Perl level. It is not intuitive for newer folk, though.
>>
>> Ingo
>>
>> On 5/31/2024 9:49 PM, Jörg Sommrey wrote:
>>> Hi all,
>>>
>>> just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are
>>> listed in .gitignore. What would be the suggested workflow to patch
>>> such files?
>>>
>>> Best regards,
>>> -jo
>>>
>>>
>>> _______________________________________________
>>> pdl-devel mailing list
>>> pdl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>>
>>
>> _______________________________________________
>> pdl-devel mailing list
>> pdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
>
>
> _______________________________________________
> pdl-devel mailing list
> pdl...@li...
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
|
|
From: Jörg S. <jo...@so...> - 2024-06-02 10:18:38
|
What about this paragraph as part of the OVERVIEW / WARNING section in
PDL::PP:
Another problem arises from the number of generated files that may be
confusing especially when dealing with existing code. Bear in mind that
the only sources are ".pd" and ".pod" files, while ".pm", ".xs" and ".c"
files are generated from the ".pd" files and shall not be altered as
these changes would be overwritten.
Best regards,
-jo
On Sat 01 Jun 2024 10:47:10 PM CEST, "Ed ." <ej...@ho...> wrote:
> This should probably be added to PDL::PP docs, both where these
> files come from, and a recommendation to ignore the generated ones.
> Jörg, feel like extending your doc-updating? :-)
>
> Best regards,
> Ed
>
> ________________________________
> From: Jörg Sommrey <jo...@so...>
> Sent: Friday, May 31, 2024 9:35:55 PM
> To: pdl...@li... <pdl...@li...>
> Subject: Re: [Pdl-devel] .gitignore strangeness
>
> Thanks Ingo and David,
>
> found the source thanks to your hints. The .gitignore makes sense now!
>
> Best regards,
> -jo
>
> On Fri 31 May 2024 10:24:41 PM CEST, Ingo Schmid via pdl-devel
> <pdl...@li...> wrote:
>
>> Hi Jörg,
>>
>> this is because they are generated from basic.pd, ufunc.pd, etc. See
>> PDL::PP! It is a neat feature to generate code for all data types in
>> both C and Perl level. It is not intuitive for newer folk, though.
>>
>> Ingo
>>
>> On 5/31/2024 9:49 PM, Jörg Sommrey wrote:
>>> Hi all,
>>>
>>> just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are
>>> listed in .gitignore. What would be the suggested workflow to patch
>>> such files?
>>>
>>> Best regards,
>>> -jo
>>>
>>>
>>> _______________________________________________
>>> pdl-devel mailing list
>>> pdl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>>
>>
>> _______________________________________________
>> pdl-devel mailing list
>> pdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
>
>
> _______________________________________________
> pdl-devel mailing list
> pdl...@li...
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
|
|
From: Ed . <ej...@ho...> - 2024-06-01 20:47:24
|
This should probably be added to PDL::PP docs, both where these files come from, and a recommendation to ignore the generated ones. Jörg, feel like extending your doc-updating? :-) Best regards, Ed ________________________________ From: Jörg Sommrey <jo...@so...> Sent: Friday, May 31, 2024 9:35:55 PM To: pdl...@li... <pdl...@li...> Subject: Re: [Pdl-devel] .gitignore strangeness Thanks Ingo and David, found the source thanks to your hints. The .gitignore makes sense now! Best regards, -jo On Fri 31 May 2024 10:24:41 PM CEST, Ingo Schmid via pdl-devel <pdl...@li...> wrote: > Hi Jörg, > > this is because they are generated from basic.pd, ufunc.pd, etc. See > PDL::PP! It is a neat feature to generate code for all data types in > both C and Perl level. It is not intuitive for newer folk, though. > > Ingo > > On 5/31/2024 9:49 PM, Jörg Sommrey wrote: >> Hi all, >> >> just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are >> listed in .gitignore. What would be the suggested workflow to patch >> such files? >> >> Best regards, >> -jo >> >> >> _______________________________________________ >> pdl-devel mailing list >> pdl...@li... >> https://lists.sourceforge.net/lists/listinfo/pdl-devel > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel _______________________________________________ pdl-devel mailing list pdl...@li... https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: Jörg S. <jo...@so...> - 2024-05-31 20:36:08
|
Thanks Ingo and David, found the source thanks to your hints. The .gitignore makes sense now! Best regards, -jo On Fri 31 May 2024 10:24:41 PM CEST, Ingo Schmid via pdl-devel <pdl...@li...> wrote: > Hi Jörg, > > this is because they are generated from basic.pd, ufunc.pd, etc. See > PDL::PP! It is a neat feature to generate code for all data types in > both C and Perl level. It is not intuitive for newer folk, though. > > Ingo > > On 5/31/2024 9:49 PM, Jörg Sommrey wrote: >> Hi all, >> >> just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are >> listed in .gitignore. What would be the suggested workflow to patch >> such files? >> >> Best regards, >> -jo >> >> >> _______________________________________________ >> pdl-devel mailing list >> pdl...@li... >> https://lists.sourceforge.net/lists/listinfo/pdl-devel > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: Ingo S. <in...@gm...> - 2024-05-31 20:24:50
|
Hi Jörg, this is because they are generated from basic.pd, ufunc.pd, etc. See PDL::PP! It is a neat feature to generate code for all data types in both C and Perl level. It is not intuitive for newer folk, though. Ingo On 5/31/2024 9:49 PM, Jörg Sommrey wrote: > Hi all, > > just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are > listed in .gitignore. What would be the suggested workflow to patch > such files? > > Best regards, > -jo > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel |
|
From: David M. <dcm...@gm...> - 2024-05-31 20:23:24
|
Aren't these generated from .pd files? Find the relevant .pd file and modify that. On Fri, May 31, 2024, 4:10 PM Jörg Sommrey <jo...@so...> wrote: > Hi all, > > just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are > listed in .gitignore. What would be the suggested workflow to patch > such files? > > Best regards, > -jo > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel > |
|
From: Jörg S. <jo...@so...> - 2024-05-31 20:09:49
|
Hi all, just realized that principal pm files, e.g. Basic/Ufunc/Ufunc.pm are listed in .gitignore. What would be the suggested workflow to patch such files? Best regards, -jo |
|
From: Ingo S. <in...@gm...> - 2024-05-31 09:03:38
|
😳😳
stat("blib/arch/auto/Prima/Prima.so", {st_mode=S_IFREG|0755,
st_size=2074312, ...}) = 0
openat(AT_FDCWD, "blib/arch/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
This is the output
The system is Ubuntu 18.04:
Linux 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
Ingo
On 31.05.24 12:25 AM, Dmitry Karasik wrote:
> Oh well... sure it was a piece of a very typical strace output, one was not supposed to execute it :)
>
> /dk
>
> On Thu, May 30, 2024 at 01:24:57PM +0000, Ed . wrote:
>> Dmitry, am I right that this:
>>> openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
>> was output from your locally running the strace command?
>>
>> I believe Ingo thought that was a snippet of Perl he was supposed to run, but I think it’s instead strace’s output in (close to) C.
>>
>> Best regards,
>> Ed
>>
>> ________________________________
>> From: Dmitry Karasik <dm...@ka...>
>> Sent: Wednesday, May 29, 2024 9:51:32 PM
>> To: Ingo Schmid <in...@gm...>
>> Cc: Ed . <ej...@ho...>; pdl-devel <pdl...@li...>; perldl <pdl...@li...>
>> Subject: Re: [Pdl-devel] PDL::Drawing::Prima
>>
>> On Wed, May 29, 2024 at 05:12:42PM +0200, Ingo Schmid wrote:
>>> Hi Dimitry,
>>> perl Makefile.PL DL_LOAD_FLAGS=1
>>> was the solution! No reinstall or anything needed.
>>> Thank you so much!
>> Great! I'm really curious what was than system... could you possibly send me (ok if personally, too)
>> output of `uname -a` and `cc -v` ?
>>
>>> PS: I got syntax errors with this (even when using the right location of Prima.so). Is this to be run in bash or perl?
>>> openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
>> I'm not sure I follow the question. Do I understand correctly that if you run this from bash
>>
>> $ perl -Iblib/arch -Iblib/lib -MPDL::Drawing::Prima -e 1
>>
>> you get syntax errors?
>>
>> /dk
>>
>>>
>>> On 29.05.24 3:17 PM, Dmitry Karasik wrote:
>>>> Hi all
>>>>
>>>> Sorry no clue either. But I'd do this:
>>>>
>>>> 1) remove all prima and P:D:P stuff, make sure no lingering .so files, then clean reinstall.
>>>> 2) nm won't help you here because the linking is done by dlopen() during runtime, so
>>>> try this instead:
>>>>
>>>> $ strace perl -Iblib/arch -Iblib/lib -MPDL::Drawing::Prima -e 1 2>&1 | grep Prima.so
>>>> openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
>>>>
>>>> if it cannot find Prima.so then there's something wrong with the installation.
>>>>
>>>> If however it can but cannot bind dynamically it might be that the system is so old that
>>>> Prima couldn't detect that it needs an explicit RTLD_GLOBAL flag. Check this then:
>>>>
>>>> $ grep dl_load_flags Prima/Config.pm
>>>> dl_load_flags => 1,
>>>>
>>>> so if it is not 1, you can try to recompile Prima with this:
>>>>
>>>> perl Makefile.PL DL_LOAD_FLAGS=1
>>>>
>>>> (but this is a really ancient stuff, I think I only used it on Sun/IRIX back then..)
>>>>
>>>> /dk
>>>>
>>>>
>>>> On Mon, May 27, 2024 at 10:06:00AM +0000, Ed . wrote:
>>>>> Hi Ingo,
>>>>>
>>>>> I don’t know either. Dmitry, any ideas? I re-attach the nm output files.
>>>>>
>>>>> Best regards,
>>>>> Ed
>>>>>
>>>>> ________________________________
>>>>> From: Ingo Schmid<in...@gm...>
>>>>> Sent: Monday, May 27, 2024 10:49:04 AM
>>>>> To: Ed .<ej...@ho...>; pdl-devel<pdl...@li...>; perldl<pdl...@li...>; David Mertens<dcm...@gm...>
>>>>> Subject: Re: [Pdl-devel] PDL::Drawing::Prima
>>>>>
>>>>>
>>>>> Hi Ed,
>>>>>
>>>>> after further investigation, I think the Makefile is OK. I have essentially to environments where I need this to run.
>>>>>
>>>>> 1) modern regularly updated linux boxes
>>>>>
>>>>> 2) servers with older stable releases (many kind of different software running, not easily updated)
>>>>>
>>>>> Both have perlbreew installations using perl-5.36.0 (with different aliases.
>>>>>
>>>>> On the modern boxes, P:D:P works fine, while on the server it complains about unresolved symbols (gimme_the_mate) during make test or apc_get_core_version when perl -Mblib -e "use PDL::Drawing::Prima;", Both have Prima 1.73 installed.
>>>>>
>>>>> The build log is inconspicuous, I can load the Utils module.
>>>>>
>>>>> Checking if you have Prima 1.57 ... Yes (1.73)
>>>>> Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.64)
>>>>> Checking if you have Test::More 0.88 ... Yes (1.302190)
>>>>> Checking if you have PDL 2.037 ... Yes (2.089)
>>>>> Building and testing PDL-Drawing-Prima-0.18
>>>>>
>>>>> I am at a complete loss here. I attached the output of nm
>>>>>
>>>>> On 24.05.24 5:59 PM, Ed . wrote:
>>>>>
>>>>> Hi Ingo,
>>>>>
>>>>>
>>>>>
>>>>> I think the relevant part of the attached Makefile.PL is (as changed by you):
>>>>>
>>>>>
>>>>>
>>>>> if ($Prima::Config::Config{dlname}){
>>>>>
>>>>> my ($primalib, $primapath)=fileparse($Prima::Config::Config{dlname});
>>>>>
>>>>> $hash{LIBS}->[0] = " -L$primapath -lPrima "
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> You’ve changed it from an append (.=) to an assign, which might explain why it doesn’t work. Is there a reason you did that? Also, why did you remove the existing code below?
>>>>>
>>>>>
>>>>>
>>>>> $hash{LIBS}[0] .= " $Prima::Config::Config{libs}"
>>>>>
>>>>> if $Prima::Config::Config{libs};
>>>>>
>>>>>
>>>>>
>>>>> What errors did you get? Are you on Ubuntu? Because I’m using Ubuntu, and building P:D:Prima here doesn’t need to link Prima - the dynamic linker takes care of it at runtime.
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Ed
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>> From: Ingo Schmid via pdl-devel<pdl...@li...><mailto:pdl...@li...>
>>>>> Sent: Thursday, May 23, 2024 1:05:37 PM
>>>>> To: pdl-devel<pdl...@li...><mailto:pdl...@li...>; perldl<pdl...@li...><mailto:pdl...@li...>; David Mertens<dcm...@gm...><mailto:dcm...@gm...>
>>>>> Subject: [Pdl-devel] PDL::Drawing::Prima
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> this module does not find Prima.so (from Prima).
>>>>>
>>>>> Makefile.PL needs to lock at Prima::Config::Config{dlname} and set the correct LIBS field. I failed to make it work.
>>>>>
>>>>> I got the parts necessary extracted, but make seems to ignore it. This results in unresolved symbols from Prima.
>>>>>
>>>>> Ingo
>>>>
>>>>
>> --
>> Sincerely,
>> Dmitry Karasik
>>
|
|
From: Ed . <ej...@ho...> - 2024-05-30 13:25:06
|
Dmitry, am I right that this:
> openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
was output from your locally running the strace command?
I believe Ingo thought that was a snippet of Perl he was supposed to run, but I think it’s instead strace’s output in (close to) C.
Best regards,
Ed
________________________________
From: Dmitry Karasik <dm...@ka...>
Sent: Wednesday, May 29, 2024 9:51:32 PM
To: Ingo Schmid <in...@gm...>
Cc: Ed . <ej...@ho...>; pdl-devel <pdl...@li...>; perldl <pdl...@li...>
Subject: Re: [Pdl-devel] PDL::Drawing::Prima
On Wed, May 29, 2024 at 05:12:42PM +0200, Ingo Schmid wrote:
> Hi Dimitry,
> perl Makefile.PL DL_LOAD_FLAGS=1
> was the solution! No reinstall or anything needed.
> Thank you so much!
Great! I'm really curious what was than system... could you possibly send me (ok if personally, too)
output of `uname -a` and `cc -v` ?
> PS: I got syntax errors with this (even when using the right location of Prima.so). Is this to be run in bash or perl?
> openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
I'm not sure I follow the question. Do I understand correctly that if you run this from bash
$ perl -Iblib/arch -Iblib/lib -MPDL::Drawing::Prima -e 1
you get syntax errors?
/dk
>
>
> On 29.05.24 3:17 PM, Dmitry Karasik wrote:
> > Hi all
> >
> > Sorry no clue either. But I'd do this:
> >
> > 1) remove all prima and P:D:P stuff, make sure no lingering .so files, then clean reinstall.
> > 2) nm won't help you here because the linking is done by dlopen() during runtime, so
> > try this instead:
> >
> > $ strace perl -Iblib/arch -Iblib/lib -MPDL::Drawing::Prima -e 1 2>&1 | grep Prima.so
> > openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
> >
> > if it cannot find Prima.so then there's something wrong with the installation.
> >
> > If however it can but cannot bind dynamically it might be that the system is so old that
> > Prima couldn't detect that it needs an explicit RTLD_GLOBAL flag. Check this then:
> >
> > $ grep dl_load_flags Prima/Config.pm
> > dl_load_flags => 1,
> >
> > so if it is not 1, you can try to recompile Prima with this:
> >
> > perl Makefile.PL DL_LOAD_FLAGS=1
> >
> > (but this is a really ancient stuff, I think I only used it on Sun/IRIX back then..)
> >
> > /dk
> >
> >
> > On Mon, May 27, 2024 at 10:06:00AM +0000, Ed . wrote:
> >> Hi Ingo,
> >>
> >> I don’t know either. Dmitry, any ideas? I re-attach the nm output files.
> >>
> >> Best regards,
> >> Ed
> >>
> >> ________________________________
> >> From: Ingo Schmid<in...@gm...>
> >> Sent: Monday, May 27, 2024 10:49:04 AM
> >> To: Ed .<ej...@ho...>; pdl-devel<pdl...@li...>; perldl<pdl...@li...>; David Mertens<dcm...@gm...>
> >> Subject: Re: [Pdl-devel] PDL::Drawing::Prima
> >>
> >>
> >> Hi Ed,
> >>
> >> after further investigation, I think the Makefile is OK. I have essentially to environments where I need this to run.
> >>
> >> 1) modern regularly updated linux boxes
> >>
> >> 2) servers with older stable releases (many kind of different software running, not easily updated)
> >>
> >> Both have perlbreew installations using perl-5.36.0 (with different aliases.
> >>
> >> On the modern boxes, P:D:P works fine, while on the server it complains about unresolved symbols (gimme_the_mate) during make test or apc_get_core_version when perl -Mblib -e "use PDL::Drawing::Prima;", Both have Prima 1.73 installed.
> >>
> >> The build log is inconspicuous, I can load the Utils module.
> >>
> >> Checking if you have Prima 1.57 ... Yes (1.73)
> >> Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.64)
> >> Checking if you have Test::More 0.88 ... Yes (1.302190)
> >> Checking if you have PDL 2.037 ... Yes (2.089)
> >> Building and testing PDL-Drawing-Prima-0.18
> >>
> >> I am at a complete loss here. I attached the output of nm
> >>
> >> On 24.05.24 5:59 PM, Ed . wrote:
> >>
> >> Hi Ingo,
> >>
> >>
> >>
> >> I think the relevant part of the attached Makefile.PL is (as changed by you):
> >>
> >>
> >>
> >> if ($Prima::Config::Config{dlname}){
> >>
> >> my ($primalib, $primapath)=fileparse($Prima::Config::Config{dlname});
> >>
> >> $hash{LIBS}->[0] = " -L$primapath -lPrima "
> >>
> >> }
> >>
> >>
> >>
> >> You’ve changed it from an append (.=) to an assign, which might explain why it doesn’t work. Is there a reason you did that? Also, why did you remove the existing code below?
> >>
> >>
> >>
> >> $hash{LIBS}[0] .= " $Prima::Config::Config{libs}"
> >>
> >> if $Prima::Config::Config{libs};
> >>
> >>
> >>
> >> What errors did you get? Are you on Ubuntu? Because I’m using Ubuntu, and building P:D:Prima here doesn’t need to link Prima - the dynamic linker takes care of it at runtime.
> >>
> >>
> >>
> >> Best regards,
> >>
> >> Ed
> >>
> >>
> >>
> >> ________________________________
> >> From: Ingo Schmid via pdl-devel<pdl...@li...><mailto:pdl...@li...>
> >> Sent: Thursday, May 23, 2024 1:05:37 PM
> >> To: pdl-devel<pdl...@li...><mailto:pdl...@li...>; perldl<pdl...@li...><mailto:pdl...@li...>; David Mertens<dcm...@gm...><mailto:dcm...@gm...>
> >> Subject: [Pdl-devel] PDL::Drawing::Prima
> >>
> >>
> >> Hi,
> >>
> >> this module does not find Prima.so (from Prima).
> >>
> >> Makefile.PL needs to lock at Prima::Config::Config{dlname} and set the correct LIBS field. I failed to make it work.
> >>
> >> I got the parts necessary extracted, but make seems to ignore it. This results in unresolved symbols from Prima.
> >>
> >> Ingo
> >
> >
> >
--
Sincerely,
Dmitry Karasik
|
|
From: Ingo S. <in...@gm...> - 2024-05-29 15:13:00
|
Hi Dimitry,
perl Makefile.PL DL_LOAD_FLAGS=1
was the solution! No reinstall or anything needed.
Thank you so much!
Ingo
PS: I got syntax errors with this (even when using the right location of Prima.so). Is this to be run in bash or perl?
openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
On 29.05.24 3:17 PM, Dmitry Karasik wrote:
> Hi all
>
> Sorry no clue either. But I'd do this:
>
> 1) remove all prima and P:D:P stuff, make sure no lingering .so files, then clean reinstall.
> 2) nm won't help you here because the linking is done by dlopen() during runtime, so
> try this instead:
>
> $ strace perl -Iblib/arch -Iblib/lib -MPDL::Drawing::Prima -e 1 2>&1 | grep Prima.so
> openat(AT_FDCWD, "/usr/local/lib/x86_64-linux-gnu/perl/5.34.0/auto/Prima/Prima.so", O_RDONLY|O_CLOEXEC) = 5
>
> if it cannot find Prima.so then there's something wrong with the installation.
>
> If however it can but cannot bind dynamically it might be that the system is so old that
> Prima couldn't detect that it needs an explicit RTLD_GLOBAL flag. Check this then:
>
> $ grep dl_load_flags Prima/Config.pm
> dl_load_flags => 1,
>
> so if it is not 1, you can try to recompile Prima with this:
>
> perl Makefile.PL DL_LOAD_FLAGS=1
>
> (but this is a really ancient stuff, I think I only used it on Sun/IRIX back then..)
>
> /dk
>
>
> On Mon, May 27, 2024 at 10:06:00AM +0000, Ed . wrote:
>> Hi Ingo,
>>
>> I don’t know either. Dmitry, any ideas? I re-attach the nm output files.
>>
>> Best regards,
>> Ed
>>
>> ________________________________
>> From: Ingo Schmid<in...@gm...>
>> Sent: Monday, May 27, 2024 10:49:04 AM
>> To: Ed .<ej...@ho...>; pdl-devel<pdl...@li...>; perldl<pdl...@li...>; David Mertens<dcm...@gm...>
>> Subject: Re: [Pdl-devel] PDL::Drawing::Prima
>>
>>
>> Hi Ed,
>>
>> after further investigation, I think the Makefile is OK. I have essentially to environments where I need this to run.
>>
>> 1) modern regularly updated linux boxes
>>
>> 2) servers with older stable releases (many kind of different software running, not easily updated)
>>
>> Both have perlbreew installations using perl-5.36.0 (with different aliases.
>>
>> On the modern boxes, P:D:P works fine, while on the server it complains about unresolved symbols (gimme_the_mate) during make test or apc_get_core_version when perl -Mblib -e "use PDL::Drawing::Prima;", Both have Prima 1.73 installed.
>>
>> The build log is inconspicuous, I can load the Utils module.
>>
>> Checking if you have Prima 1.57 ... Yes (1.73)
>> Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.64)
>> Checking if you have Test::More 0.88 ... Yes (1.302190)
>> Checking if you have PDL 2.037 ... Yes (2.089)
>> Building and testing PDL-Drawing-Prima-0.18
>>
>> I am at a complete loss here. I attached the output of nm
>>
>> On 24.05.24 5:59 PM, Ed . wrote:
>>
>> Hi Ingo,
>>
>>
>>
>> I think the relevant part of the attached Makefile.PL is (as changed by you):
>>
>>
>>
>> if ($Prima::Config::Config{dlname}){
>>
>> my ($primalib, $primapath)=fileparse($Prima::Config::Config{dlname});
>>
>> $hash{LIBS}->[0] = " -L$primapath -lPrima "
>>
>> }
>>
>>
>>
>> You’ve changed it from an append (.=) to an assign, which might explain why it doesn’t work. Is there a reason you did that? Also, why did you remove the existing code below?
>>
>>
>>
>> $hash{LIBS}[0] .= " $Prima::Config::Config{libs}"
>>
>> if $Prima::Config::Config{libs};
>>
>>
>>
>> What errors did you get? Are you on Ubuntu? Because I’m using Ubuntu, and building P:D:Prima here doesn’t need to link Prima - the dynamic linker takes care of it at runtime.
>>
>>
>>
>> Best regards,
>>
>> Ed
>>
>>
>>
>> ________________________________
>> From: Ingo Schmid via pdl-devel<pdl...@li...><mailto:pdl...@li...>
>> Sent: Thursday, May 23, 2024 1:05:37 PM
>> To: pdl-devel<pdl...@li...><mailto:pdl...@li...>; perldl<pdl...@li...><mailto:pdl...@li...>; David Mertens<dcm...@gm...><mailto:dcm...@gm...>
>> Subject: [Pdl-devel] PDL::Drawing::Prima
>>
>>
>> Hi,
>>
>> this module does not find Prima.so (from Prima).
>>
>> Makefile.PL needs to lock at Prima::Config::Config{dlname} and set the correct LIBS field. I failed to make it work.
>>
>> I got the parts necessary extracted, but make seems to ignore it. This results in unresolved symbols from Prima.
>>
>> Ingo
>
>
>
|
|
From: Ingo S. <in...@gm...> - 2024-05-29 08:02:15
|
Hi Ed, I got a message that I could not send to the list because the server was not responding for some time, or something like that. Hmm, I thought I saw in the docs something like clump (1 ... -1), which isn't there right now. So I must have applied wishful thinking and use negative index in the slice syntax way (1:-1) to (1..-1). It would still be nice, though. ;-) Sorry to bother you Ingo On 28.05.24 6:34 PM, Ed . wrote: > > Hi Ingo, > > I’m getting bounces from pdl-devel the last couple of days, and the > archive isn’t showing new messages including yours, but I did receive > your message via pdl-devel, so I don’t know what’s going on. > > To answer your point: which bits of the docs explicitly says > clump(1..-1) should work? Because that’s a Perl expression that will > make an empty list, since -1 is a number that’s lower than 1, which is > why you’re getting an error. > > The second error you’re showing is because dimensions are numbered in > a zero-based way, so ndims (which is 14) will be the 15^th one, which > is too big, as the error explicitly tells you. > > Best regards, > > Ed > > ------------------------------------------------------------------------ > *From:* Ingo Schmid via pdl-devel <pdl...@li...> > *Sent:* Tuesday, May 28, 2024 7:26:59 AM > *To:* pdl-devel <pdl...@li...> > *Subject:* Re: [Pdl-devel] clump glitch > > could not send mail. > > On 27.05.24 5:27 PM, Ingo Schmid wrote: >> >> Hi, >> >> $x->clump (1 .. -1) should work according to the docs, but it >> apparently doesn't. boundaries 0 ... ndims -1 work fine. >> >> pdl> help $k2 >> This variable is Float D [2,772096,1,1,1,1,30,1,1,1,1,1] >> >> pdl> $k2= $k->clump(2 .. ($k->ndims-1)) >> >> Best >> >> Ingo >> >> pdl> help $k2 >> This variable is Float D [2,1,23162880] -C 0.00KB >> pdl> $k2= $k->clump(2 .. (-1)) >> Runtime error: Usage: PDL::_clump_int(PARENT,CHILD,n) (you may leave >> output variables out of list) at (eval 692) line 5. >> pdl> $k2= $k->clump(2 .. ($k->ndims)) >> Runtime error: dimension index 14 larger than greatest dimension at >> /ceph/mri.meduniwien.ac.at/departments/physics/metabolism/lab/cardiac_31P/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0/x86_64-linux/PDL/Core.pm >> line 1587. >> PDL::clump(MRI::ReadData=HASH(0x559ebeffb570), 2, 3, 4, 5, 6, 7, >> 8, ...) called at (eval 693) line 5 >> >> >> |
|
From: Ingo S. <in...@gm...> - 2024-05-28 19:55:54
|
Hi Ed,
after further investigation, I think the Makefile is OK. I have
essentially to environments where I need this to run.
1) modern regularly updated linux boxes
2) servers with older stable releases (many kind of different software
running, not easily updated)
Both have perlbreew installations using perl-5.36.0 (with different aliases.
On the modern boxes, P:D:P works fine, while on the server it complains
about unresolved symbols (gimme_the_mate) during make test or
apc_get_core_version when perl -Mblib -e "use PDL::Drawing::Prima;",
Both have Prima 1.73 installed.
The build log is inconspicuous, I can load the Utils module.
Checking if you have Prima 1.57 ... Yes (1.73)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.64)
Checking if you have Test::More 0.88 ... Yes (1.302190)
Checking if you have PDL 2.037 ... Yes (2.089)
Building and testing PDL-Drawing-Prima-0.18
I am at a complete loss here. I attached the output of nm
On 24.05.24 5:59 PM, Ed . wrote:
>
> Hi Ingo,
>
> I think the relevant part of the attached Makefile.PL is (as changed
> by you):
>
> if ($Prima::Config::Config{dlname}){
>
> my ($primalib,
> $primapath)=fileparse($Prima::Config::Config{dlname});
>
> $hash{LIBS}->[0] = " -L$primapath -lPrima "
>
> }
>
> You’ve changed it from an append (.=) to an assign, which might
> explain why it doesn’t work. Is there a reason you did that? Also, why
> did you remove the existing code below?
>
> |$hash{LIBS}[0] .= " $Prima::Config::Config{libs}"|
>
> | if||$Prima::Config::Config{libs};|
>
> What errors did you get? Are you on Ubuntu? Because I’m using Ubuntu,
> and building P:D:Prima here doesn’t need to link Prima - the dynamic
> linker takes care of it at runtime.
>
> Best regards,
>
> Ed
>
> ------------------------------------------------------------------------
> *From:* Ingo Schmid via pdl-devel <pdl...@li...>
> *Sent:* Thursday, May 23, 2024 1:05:37 PM
> *To:* pdl-devel <pdl...@li...>; perldl
> <pdl...@li...>; David Mertens
> <dcm...@gm...>
> *Subject:* [Pdl-devel] PDL::Drawing::Prima
>
> Hi,
>
> this module does not find Prima.so (from Prima).
>
> Makefile.PL needs to lock at Prima::Config::Config{dlname} and set the
> correct LIBS field. I failed to make it work.
>
> I got the parts necessary extracted, but make seems to ignore it. This
> results in unresolved symbols from Prima.
>
> Ingo
>
|
|
From: Ingo S. <in...@gm...> - 2024-05-28 17:21:24
|
Hi, $x->clump (1 .. -1) should work according to the docs, but it apparently doesn't. boundaries 0 ... ndims -1 work fine. pdl> help $k2 This variable is Float D [2,772096,1,1,1,1,30,1,1,1,1,1] pdl> $k2= $k->clump(2 .. ($k->ndims-1)) Best Ingo pdl> help $k2 This variable is Float D [2,1,23162880] -C 0.00KB pdl> $k2= $k->clump(2 .. (-1)) Runtime error: Usage: PDL::_clump_int(PARENT,CHILD,n) (you may leave output variables out of list) at (eval 692) line 5. pdl> $k2= $k->clump(2 .. ($k->ndims)) Runtime error: dimension index 14 larger than greatest dimension at /ceph/mri.meduniwien.ac.at/departments/physics/metabolism/lab/cardiac_31P/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0/x86_64-linux/PDL/Core.pm line 1587. PDL::clump(MRI::ReadData=HASH(0x559ebeffb570), 2, 3, 4, 5, 6, 7, 8, ...) called at (eval 693) line 5 |
|
From: Ed . <ej...@ho...> - 2024-05-28 16:34:57
|
Hi Ingo,
I’m getting bounces from pdl-devel the last couple of days, and the archive isn’t showing new messages including yours, but I did receive your message via pdl-devel, so I don’t know what’s going on.
To answer your point: which bits of the docs explicitly says clump(1..-1) should work? Because that’s a Perl expression that will make an empty list, since -1 is a number that’s lower than 1, which is why you’re getting an error.
The second error you’re showing is because dimensions are numbered in a zero-based way, so ndims (which is 14) will be the 15th one, which is too big, as the error explicitly tells you.
Best regards,
Ed
________________________________
From: Ingo Schmid via pdl-devel <pdl...@li...>
Sent: Tuesday, May 28, 2024 7:26:59 AM
To: pdl-devel <pdl...@li...>
Subject: Re: [Pdl-devel] clump glitch
could not send mail.
On 27.05.24 5:27 PM, Ingo Schmid wrote:
Hi,
$x->clump (1 .. -1) should work according to the docs, but it apparently doesn't. boundaries 0 ... ndims -1 work fine.
pdl> help $k2
This variable is Float D [2,772096,1,1,1,1,30,1,1,1,1,1]
pdl> $k2= $k->clump(2 .. ($k->ndims-1))
Best
Ingo
pdl> help $k2
This variable is Float D [2,1,23162880] -C 0.00KB
pdl> $k2= $k->clump(2 .. (-1))
Runtime error: Usage: PDL::_clump_int(PARENT,CHILD,n) (you may leave output variables out of list) at (eval 692) line 5.
pdl> $k2= $k->clump(2 .. ($k->ndims))
Runtime error: dimension index 14 larger than greatest dimension at /ceph/mri.meduniwien.ac.at/departments/physics/metabolism/lab/cardiac_31P/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0/x86_64-linux/PDL/Core.pm line 1587.
PDL::clump(MRI::ReadData=HASH(0x559ebeffb570), 2, 3, 4, 5, 6, 7, 8, ...) called at (eval 693) line 5
|
