[Pdl-porters] PDL::Types confusion

[Chris Marshall]

I'm trying to sort out better type handling
for the 64bit index support but I'm puzzled
by the apparent duplication of information
in the Types.pm.PL file. Specifically as
relates to the following keys:

* ctype
* realctype
* shortctype

Re ctype, the PDL_Double and others are typedefs
and not macros as the PDL::Types POD suggests.

Re realctype, if we have the typedef done, then
why isn't this just the same as ctype

Re: shortctype, this seems to be a hack to generate
default conversion functions which keeps biting me.
You must be careful that for a PDL_Xxx type that there
is no PDL::xxx() function already defined.

Any thoughts---especially re ctype vs realctype?

Thanks,
Chris

[Ed .]

Based on my experience with Gimp-Perl, it may well be a thing that accreted by different people approaching issues at different times. Would it work to just amalgamate them and see if all the tests still pass?

This also has an important bearing on my near-future work on the build system: do we have confidence that the tests are good enough that if they still pass after a change, the change is unlikely to actually break anything?

Cheers,
Ed

From: Chris Marshall
Sent: Tuesday, April 22, 2014 11:02 PM
To: pdl-porters
Subject: [Pdl-porters] PDL::Types confusion

I'm trying to sort out better type handling
for the 64bit index support but I'm puzzled

by the apparent duplication of information
in the Types.pm.PL file. Specifically as
relates to the following keys:


* ctype

* realctype

* shortctype


Re ctype, the PDL_Double and others are typedefs
and not macros as the PDL::Types POD suggests.


Re realctype, if we have the typedef done, then

why isn't this just the same as ctype


Re: shortctype, this seems to be a hack to generate

default conversion functions which keeps biting me.

You must be careful that for a PDL_Xxx type that there
is no PDL::xxx() function already defined.


Any thoughts---especially re ctype vs realctype?

Thanks,
Chris



--------------------------------------------------------------------------------

[Chris Marshall]

Post by Ed .
Based on my experience with Gimp-Perl, it may well be a thing
that accreted by different people approaching issues at different times.
Would it work to just amalgamate them and see if all the tests still pass?

I doubt it would work...

Post by Ed .
This also has an important bearing on my near-future work on
the build system: do we have confidence that the tests are good
enough that if they still pass after a change, the change is unlikely
to actually break anything?

See http://sourceforge.net/p/pdl/bugs/334/

Thanks for the thoughts. --Chris

Post by Ed .
Cheers,
Ed
From: Chris Marshall
Sent: Tuesday, April 22, 2014 11:02 PM
To: pdl-porters
Subject: [Pdl-porters] PDL::Types confusion
I'm trying to sort out better type handling
for the 64bit index support but I'm puzzled
by the apparent duplication of information
in the Types.pm.PL file. Specifically as
* ctype
* realctype
* shortctype
Re ctype, the PDL_Double and others are typedefs
and not macros as the PDL::Types POD suggests.
Re realctype, if we have the typedef done, then
why isn't this just the same as ctype
Re: shortctype, this seems to be a hack to generate
default conversion functions which keeps biting me.
You must be careful that for a PDL_Xxx type that there
is no PDL::xxx() function already defined.
Any thoughts---especially re ctype vs realctype?
Thanks,
Chris
________________________________
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Ed .]

Yes, I see what you mean. I don’t see any further postings from William Parker on that bug – did he get started on it? I’d be pleased to work with him on this; could you send him my email and/or send me his?

Cheers,
Ed

From: Chris Marshall
Sent: Monday, April 28, 2014 1:16 PM
To: Ed .
Cc: pdl-porters
Subject: Re: [Pdl-porters] PDL::Types confusion

Post by Ed .
Based on my experience with Gimp-Perl, it may well be a thing
that accreted by different people approaching issues at different times.
Would it work to just amalgamate them and see if all the tests still pass?

I doubt it would work...

Post by Ed .
This also has an important bearing on my near-future work on
the build system: do we have confidence that the tests are good
enough that if they still pass after a change, the change is unlikely
to actually break anything?

See http://sourceforge.net/p/pdl/bugs/334/


Thanks for the thoughts. --Chris

Post by Ed .
Cheers,
Ed
From: Chris Marshall
Sent: Tuesday, April 22, 2014 11:02 PM
To: pdl-porters
Subject: [Pdl-porters] PDL::Types confusion
I'm trying to sort out better type handling
for the 64bit index support but I'm puzzled
by the apparent duplication of information
in the Types.pm.PL file. Specifically as
* ctype
* realctype
* shortctype
Re ctype, the PDL_Double and others are typedefs
and not macros as the PDL::Types POD suggests.
Re realctype, if we have the typedef done, then
why isn't this just the same as ctype
Re: shortctype, this seems to be a hack to generate
default conversion functions which keeps biting me.
You must be careful that for a PDL_Xxx type that there
is no PDL::xxx() function already defined.
Any thoughts---especially re ctype vs realctype?
Thanks,
Chris
________________________________
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Ed .]

On reflection, while a “change it and see if the tests pass” wouldn’t work for the substantive code as here, it seems like it would be fine with typemaps – that’s a compile-time issue, not a run-time one?

Cheers,
Ed

From: Chris Marshall
Sent: Monday, April 28, 2014 1:16 PM
To: Ed .
Cc: pdl-porters
Subject: Re: [Pdl-porters] PDL::Types confusion

Post by Ed .
Based on my experience with Gimp-Perl, it may well be a thing
that accreted by different people approaching issues at different times.
Would it work to just amalgamate them and see if all the tests still pass?

I doubt it would work...

Post by Ed .
This also has an important bearing on my near-future work on
the build system: do we have confidence that the tests are good
enough that if they still pass after a change, the change is unlikely
to actually break anything?

See http://sourceforge.net/p/pdl/bugs/334/


Thanks for the thoughts. --Chris

Post by Ed .
Cheers,
Ed
From: Chris Marshall
Sent: Tuesday, April 22, 2014 11:02 PM
To: pdl-porters
Subject: [Pdl-porters] PDL::Types confusion
I'm trying to sort out better type handling
for the 64bit index support but I'm puzzled
by the apparent duplication of information
in the Types.pm.PL file. Specifically as
* ctype
* realctype
* shortctype
Re ctype, the PDL_Double and others are typedefs
and not macros as the PDL::Types POD suggests.
Re realctype, if we have the typedef done, then
why isn't this just the same as ctype
Re: shortctype, this seems to be a hack to generate
default conversion functions which keeps biting me.
You must be careful that for a PDL_Xxx type that there
is no PDL::xxx() function already defined.
Any thoughts---especially re ctype vs realctype?
Thanks,
Chris
________________________________
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters