I think of it as a variant. It's the same program but with 64 bit precision.
Just like we have the section "*Compiled versions for older, 32-bit processors*" for download in miller's site. As far as externals go, those have the same problem and one would need to get pd 32 bits just to run old external libraries not available for the newer Pd. One example is the [hid] external that we just now made available (finally). And in the end if we have downloads for Pd 0.52-0 in 64 bit precision, then it'd be Pd 0.52-0 just like the one with Pd with 32 bit precision... So yeah, I guess we need to make it available for download for 32 bits precision as well, just like we should keep the ones for 32 bit processors and even for PPC (although no new versions will be made available I guess as miller's machine broke, so probably not). So, just make a section "*Compiled with double (64-bit) precision*" and another as "*Compiled with single (32-bit) precision*" As for how the app comes out. I remember that when it was something new, the ones compiled for 64-bit processors had a different name. Now it's the other way around. For example, the mac one comes as "i386" at the end of the app name! We can just have something like that and start by making a distinction, with something like Pd-0.52-0-double, and some time in the future (up to 3 versions later the most, I guess) it'll be the "regular" one and the others can be called Pd-0.55-0-single. cheers Em ter., 24 de nov. de 2020 às 12:21, Christof Ressi <i...@christofressi.com> escreveu: > > unless a 64-bit version had some way > > of running 32-bit externals > > Pleeease, let's not call it "64-bit" vs. "32-bit". Those terms usually > refer to the CPU target architecture. It's "single precision" vs. > "double precision" > > > so any externals > > built for previous versions would crash > IOhannes added a clever mechanism to avoid runtime crashes. Incompatible > externals will instead refuse to load. > > What we need is to find an easy way to create "fat" binaries (containing > both single and double precision of the same library) and/or come up > with a naming convention, so both versions can co-exist (similar to how > we use ".*_amd64" and ".*_i386" to distinguish between 64-bit and 32-bit > Intel binaries). > > > it would be effectively a > > different program, not just a new version. > I would say it's neither. It's just a build option. > > Christof > > On 24.11.2020 16:07, Martin Peach wrote: > > On Tue, Nov 24, 2020 at 5:07 AM jayrope <jayr...@gmail.com> wrote: > >> Why do we need _any_ name change? > >> Any obvious version jump would do it already, 0.6, no? > > A 64-bit Pd would not be compatible with any previous version because > > all the memory structures would be differently sized, so any externals > > built for previous versions would crash. While any patches using > > vanilla objects would still work, unless a 64-bit version had some way > > of running 32-bit externals in parallel, it would be effectively a > > different program, not just a new version. > > > > Martin > > > > > > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
