Your solution in 438 does not work, period, as I reported. You closed out 438 without knowing for sure it works in older macOS because there is no Darwin Kernel Version 17.7.0 in testers ( I read all the test reports ), so it does compile but only on newer platforms. Also, I don't know enough about PDL internals to posit a solution as what I tried compiled standalone, but when I incorporated it into a full PDL build it failed with the same segmentation fault. That is not the fix I needed. It is disingenuous to blame the "broken" compiler as Apple built entire OSes with those versions of clang. I would not be reporting this going back to 2.060 if anything worked, and I already use perlbrew with the latest clang for my OS. Are you implying Homebrew can do what perlbrew can't? I decided this problem needed more visibility than just you, as just perhaps, there are other PDL users with this problem. My first attempt was a private dialogue with you but all I succeeded in doing was pissing you off (my bad). So, don't revert but why can't *you* find a way to be backward compatible? And don't advise me to do it myself; I teach a full schedule, so I don't have the time to re-engineer PDL. You should have caught and fixed this problem in 2.060. If all you can offer is to upgrade my HW and OS, you're subtly buying into Apple's marketing strategy of "upgrade or else".
On Thu, Jul 27, 2023 at 11:53 AM Ed . <ej...@hotmail.com> wrote: > This issue has been dealt with in far more than useful detail already, on > https://github.com/PDLPorters/pdl/issues/438 which you opened in May. > > > > pdlcore.c will not be getting reverted to the old structure. I will be > happy to incorporate whatever fix short of that makes it work on your > broken version of clang. > > > > I am fairly sure you can get the latest GCC, and most likely the latest > clang as well, on your machine by using Homebrew, and you will probably > benefit from also installing Homebrew perl as well. There isn’t yet a > recipe for PDL, perhaps you’d like to make one? > > > > Best regards, > > Ed > > > > *From: *William Schmidt <t.william.schm...@gmail.com> > *Sent: *27 July 2023 17:17 > *To: *pdl-general@lists.sourceforge.net > *Subject: *[Pdl-general] pdlcore.c segmentation fault starting in at > least PDL 2.060 > > > > I teach an undergraduate college course in Applied Linear Algebra in which > I have been using PDL 2.026, as well as R and Python, these three to > encourage an awareness that *TIMTOWTDI*. My students may use Linux or > macOS and I personally use High Sierra, 10.13.6. My Perl was 5.30.2 > managed with perlbrew. At the end of the last term I decided to upgrade > Perl in macOS to 5.36.1 in anticipation of fall classes, and of course, > this meant I had to reinstall all my site_perl modules, including PDL. > Unfortunately, pdlcore.c segmentation faults using both clang 9.2 and 10.1, > the last clang for my version of macOS. Thus began an odyssey to find a > way to get the latest PDL installed. > > > > I won't detail all the research I did but sufficient to say pdlcore.c > underwent significant refactoring after 2.026, specifically a macro > expansion of *pdl_kludge_copy_* *where * maps to a set of C data-object > typedefs. Not willing to give up on PDL, and not knowing which version I > could safely use in my macOS (without having to upgrade my Mac, a brutal > process), I attempted working backward from 2.084 with *cpanm PDL@2.0** > until I could find one that would compile, to wit: > > > > ./.cpanm/work/1690007816.5251/PDL-2.084/Basic/Core/pdlcore.c > ./.cpanm/work/1690012699.22291/PDL-2.083/Basic/Core/pdlcore.c > ./.cpanm/work/1690013806.25715/PDL-2.082/Basic/Core/pdlcore.c > ./.cpanm/work/1690400634.44615/PDL-2.082/Basic/Core/pdlcore.c > ./.cpanm/work/1690400709.46037/PDL-2.080/Basic/Core/pdlcore.c > ./.cpanm/work/1690400791.48025/PDL-2.076/Basic/Core/pdlcore.c > ./.cpanm/work/1690400867.49448/PDL-2.060/Basic/Core/pdlcore.c > ./.cpanm/work/1690400949.52220/PDL-2.026/Basic/Core/pdlcore.c > > > > I grew tired of this exercise after 2.060 failed, so I went back to my old > standby 2.026 and *voilà*, I again have a usable, but ancient, PDL. > > > > It seems obvious that PDL lacks an older macOS platform in testers, > otherwise, you would have seen this problem before now. Either that, or > leaving older macOS platforms behind is a strategic decision (meaning no > disrespect; it *is* what it *is*), one that Apple makes all the time to > generate more sales. > > > > My question is, would it be possible to revert *pdlcore.c* back to the > switch structure used in 2.026? I can think of a number of ways to > implement this functionality without resorting to that massive macro > expansion, but of course, the callers would also need to change. The > alternative is never being able to upgrade PDL beyond 2.026 without the > pain of upgrading the HW and the OS. That strikes me as a thumb in the eye > to the principles of open-source. Obviously, my use of PDL is rudimentary > to what the software is capable of, but what a joy it would be if the > developers could find a way to do PDL magic while at the same time being > backward compatible to older OSes. At the least, could you add to testers > older macOS platforms to refine the build process? > > > Thanks in advance and regards, > T. William (perlboy) Schmidt > > > >
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
