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