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