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

IOhannes m zmoelnig zmoelnig at iem.at
Tue Mar 29 11:28:57 CEST 2022


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220329/d5fb5f22/attachment-0001.sig>


More information about the Pd-dev mailing list