Hans-Christoph Steiner wrote:
On Jan 21, 2009, at 12:39 PM, IOhannes m zmoelnig wrote:
There are numerous real arguments against d_fat:
- Gem has used .pd_darwin for a long time and it has worked well
holy cow: Gem has used .dll for a long time and it has worked well :-)
- Using .d_fat will cause confusion when people have both a
Gem.pd_darwin and a Gem.d_fat
that's why people shouldn't have and pd_darwin's on their machines.
seriously, the way it is now, with Pd-extended shipping pd_darwin and me shipping d_fat, i can only see that both profit. people can upgrade using my binary, without actually having to overwrite the original binary and can revert to it later.
- Mac OS X never uses CPU-specific file extensions
OS-X does not come with Pd.
- supporting so many file extensions increases load time a lot
yes that's a good one.
according to s_loader in both https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended... and https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended..., Pd will _first_ look for .d_fat and only then for .pd_darwin. now wait, the links above actually point to Pd-extended's branch of the Pd-sources....so Pd-extended will speed up if we use .d_fat instead of .pd_darwin
you can either accept this, or patch Pd for Pd-extended to not be able to load .d_fat's.
and more...
the original arguments why the new suffixes have been introduced was
- to create a consistent naming scheme across all platforms
- to allow binaries of multiple architectures/platforms live side by side
the latter still holds true, even when using OSX: please do accept that people use network-shares across multiple archtiectures and platforms(!) for their workspaces, even if you don't do so yourself. even if you don't know any such persons.
side effects of not using the platforms native suffix are numerous and benevolent.
finally: i would have preferred and indication of Pd in the suffix, e.g. .pd.d_fat instead of just .d_fat; for this is is arguably too late.
fmgasdr. IOhannes