Judd - I hear your concern loud and clear but requirements for RHEL5 could live out to 2017, or even 2020<https://access.redhat.com/site/support/policy/updates/errata/#Life_Cycle_Dates>. I don't think it's sensible to tie ourselves to that. Obviously changing the cutting-edge PDL won't change previous versions, and so older PDLs running on your machines will run without trouble. Furthermore---if you can make a strong case for needing a newer PDL on your customers' machines---I would rather volunteer to help you build a custom rpm for PDL with redacted sections, rather than hold PDL back from climbing to newer Perls. I might even entertain the notion of helping build an rpm that installs a newer Perl to /usr/local. And yes, that is a serious offer. I would hate to unnecessarily drop support for your clients, but I would also hate to hold PDL back because RHEL5 will hold on to a version of Perl that will be over a decade out of official support.
David On Thu, Nov 21, 2013 at 6:41 PM, Judd Taylor <[email protected]>wrote: > This is not good news for me, or my 30+ customer systems in the field > running 5.8.8 :( > > Granted, at the moment, I'm not running the bleeding edge PDL, but should > some new feature become a necessity, I would have to find a new OS, and > then upgrade everybody (which usually incurs $$ as shipping hard drives > with preinstalled OSes is easier than having customers do it). > > What would your suggestion be for someone like me as to a workable upgrade > path? > > As far as pack goes, I've always just chained pack calls together to get > what I want. As I do a lot of satellite comm stuff, I tend to use pack and > unpack quite a bit to extract satellite data. The only time I needed to > resort to PDL::PP and do it in C, was dealing with a satellite that was > sending 10bit words (which was a headache, to say the least). > > However, I'm not a user of PDL::IO::Storable, so I guess I'm ok with this > being broken, as long as no other part of PDL that I'm using is using > PDL::IO::Storable in turn. > > -Judd > > > ____________________________ > Judd Taylor > Software Engineer > > Orbital Systems, Ltd. > 3807 Carbon Rd. > Irving, TX 75038-3415 > > (972) 915-3669 x127 > > ________________________________________ > From: [email protected] [[email protected]] > Sent: Thursday, November 21, 2013 4:40 PM > To: Judd Taylor > Cc: [email protected]; pdl-porters > Subject: Re: [Pdl-porters] [Perldl] update PDL perl version to 5.10.x > > From: Judd Taylor > Sent: Friday, November 22, 2013 6:14 AM > > > What specifically are you planning on introducing into the code that will > > break older perls than 5.10? > > Hi Judd, > > There's currently (as of PDL-2.007_01) stuff like "pack 'l<l<A16L<L', ..." > and "pack 'L<*', ..." in PDL/IO/Storable.pm. If that section of code gets > called on pre-5.10, it's a runtime error because those earlier perls don't > understand the coercion to small-endian order via the '<' template. > > Perl 5.8 does have "V" which packs an unsigned long into little-endian > order, but I don't see anything that packs a *signed* long into > little-endian order. > It would seem (to me) a pity to have to work around such deficiencies, > though I'm not passionate about this. > > Cheers, > Rob > > > _______________________________________________ > PDL-porters mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
