[PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)

IOhannes m zmoelnig zmoelnig at iem.at
Thu Jan 22 10:12:53 CET 2009

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 
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 

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 


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090122/1aa83139/attachment.bin>

More information about the Pd-list mailing list