[PD-dev] call for discussion double-precision file extension

Christof Ressi info at christofressi.com
Tue Mar 29 17:29:55 CEST 2022


+1

I think it's nicer to use a common extension and have the 
platform/arch/floatsize specifier as a seperate component.

On 29.03.2022 11:28, IOhannes m zmoelnig wrote:
>
> hi,
>
> TL;DR i'd like to suggest to use deken-specifiers as (optional) part 
> of external filenames, in order to allow co-installability of 
> externals of different OSs, architectures and floatsizes (and more to 
> come).
>
> i would really love to push the double precision saga towards a 
> (happy) end.
> we have been able to compile Pd for 64bit double precision numbers.
> there's even a double-precision variant available in the Debian 
> "experimental" repositories (but who knows that?)
>
> *very* few people have started to provide externals (i counted: 4).
>
> afaict the biggest hurdle is that you can't really co-install single 
> and double variants of the same external.
> since there are so few double-precision externals available, people 
> who rely on externals will be forced to use single-precision Pd for 
> some time.
> but since installing a double-precision external might overwrite an 
> existing single-precision external (required in your other project), i 
> understand why people are not exactly eager to do that.¹
>
>
> one solution to this problem is to use different installation paths 
> (e.g. ~/Documents/Pd/extra/ vs ~/Documents/Pd/extra64/).
> this doesn't play well with how deken currently works (as it stores 
> the installation path globally (for all versions/variants of Pd).
>
> Lucas suggested to use different file extensions (a year ago...time 
> flies), by inserting `.float64` (and possibly `.float32`) right before 
> our known extension (so we get `foo.float64.m_amd64`)
> I didn't especially like this back then, but in the meantime i've come 
> to the conclusion that it's probably the best way forward.
>
> however, i think that we might do better than just inserting a single 
> `.float64`, and just unify the entire naming scheme to hold all the 
> information we need.
>
> i'd therefore suggest to use the deken-specifier together with the 
> native extension (for dynamic-link libraries), as a new extension.
>
> the "native extension for dynamic-link libraries" is typically defined 
> on an OS level, and is something like ".dll" on Windows, ".dylib" on 
> macOS and ".so" in the un*x world.
>
> the "deken-specifier" is what we use in deken packages to know that 
> they contain binaries for your specific combination of CPU, OS and 
> precision, and looks like "<OS>-<CPU>-<precision>", e.g. 
> "Darwin-arm64-32" (which denotes a macOS binary ("Darwin") that runs 
> on the M1 processor ("arm64") and uses single-precision numbers ("32" 
> bits).
>
> this would give us filenames like "zexy.windows-amd64-32.dll"
> to keep things simple (and reduce the noise with -verbose), i would 
> suggest to only allow lower case specifiers, and no arch variants 
> (e.g. i386 for all x86_32 variants, and amd64 for all x86_64 variants)
>
> pros
>
> - using the system extension does not require us to invent our own 
> extension for each new platform
> - system tools often use the file-extension to recognize the file type
> - deken-specifiers fully cover what we need to know (the problem space 
> is the same for deken package files and externals: allow coexistence 
> of files with multiple OS/arch/precision specs)
> - people can relate the files within a deken-package with the 
> deken-package-filename
> - if we ever need to add a new parameter, the deken specifier and the 
> externals are likely to be affected in a similar way, so we need to 
> solve the problem only once.
> - it gets rid of the super-cryptic 
> .<first-letter-of-the-os>_<cpu-arch> specifier (.o_ia64 anybody?)
>
> cons
>
> it shares the same (final) extensions as any support libraries.
> eg. "zexy.linux-amd64-32.so" + "libzexy.linux-amd64-32.so" (or even 
> libzexy.linux-amd64-32.so.so, but I guess we don't want this)
>
> probably some more...
>
>
> instead of using the system extension for dynamic libraries, we might 
> pick a general unified (final) extension, instead of the system ones, 
> e.g. .pdx (but that is already taken) or .pd_external.
> but i think the less we invent ourselves, the better.
>
>
>
> Lucas had started a feature-request/discussion on this very topic a 
> year ago, but it was dormant until now.
>
> https://github.com/pure-data/pure-data/issues/902
>
> i would like to hear your opinion on this (here or at the issue 
> tracker; or both), and eventually get this done.
>
> once this is solved, i will start to push Pd64 packages to the Debian 
> repositories, so people can start to use it (without having to compile 
> themselves).
>
>
> gfmsdr
> IOhannes
>
>
> ¹ just for the record: the biggest hurdle is of course that there is 
> no double-precision download available right now... but that's a bit 
> of an egg-hen problem.
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev





More information about the Pd-dev mailing list