Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
On Fri, 2009-01-23 at 09:26 +0100, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: > > On Jan 22, 2009, at 2:39 PM, IOhannes m zmoelnig wrote: > > > > > > I wasn't saying anything about GNU/Linux or Windows. I was talking > > Mac OS X. .pd_darwin is all that is needed. .d_fat, etc cause more > > troubles than the fix. > > but i was talking about architectures _and_ platforms (the later being > freebsd, linux, irix, windows, darwin, ...) > > i would like to see a naming convention that is valid on all these > platforms and where i can have files live side by side on a network > share. (e.g. .so is bad because i cannot distinguish between linux/i386, > linux/ppc, linux/x86_64 and eventually osx/fat. hi all let me drop my two cents here: i would like to emphasize IOhannes' point here, since i have been a few times in a situation with a group of people using different platforms, where a naming convention respecting platform and architecture would have been helpful. i mean, there is a real practical use in finding such a convention, whereas there seem to be only theoretical reasons for keeping the existing suffixes. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
It is possible to build fat binaries that run on 10.3. Qt and Python did it, for example: http://mail.python.org/pipermail/python-dev/2006-April/063814.html http://blog.outofhanwell.com/2006/05/08/universal-binaries-with-qt-for-max-os-103-and-104/ The key, it seems, it to make sure that the 10.3 arch is the first in the binary: http://lists.apple.com/archives/xcode-users/2005/Oct/msg00810.html http://dev.notoptimal.net/2008/02/one-step-universal-binary-builds.html .hc On Jan 22, 2009, at 11:00 PM, Miller Puckette wrote: > I think the d_fat and d_ppc business is only necessary for folks who > are > maintaining backward compatibility to 10.3 which can't read d_fat > files. > I think it's a good thing to try to keep things running on older > machines > since lots of Pd users can't afford to buy the newest ones. > However, it's > geting hard for me to stay 10.3 compatible as the only remaining > 10.3 machine > around here is getting sick. > > cheers > Miller > > On Thu, Jan 22, 2009 at 05:45:08PM -0500, Hans-Christoph Steiner > wrote: >> >> On Jan 22, 2009, at 2:39 PM, IOhannes m zmoelnig wrote: >> >>> Hans-Christoph Steiner wrote: On Jan 22, 2009, at 4:12 AM, IOhannes m zmoelnig wrote: Lots of people have been doing network shares of applications for decades. Who else is using custom file extensions? I've never seen >>> >>> python, java, ... >> >> Um, Java .jar is the same on all platforms. And JNI files >> are .jnilib >> on Mac OS X regardless of CPU, and .dll on Windows regardless of CPU. >> AFAIK, Windows DLLs are .dll regardless of whether they are 32-bit or >> 64-bit. Even GNU/Linux .so and .a files are the same regardless of >> CPU. >> it. NeXTSTEP/Mac OS X has been doing this since '94, and their solution has been fat binaries all with the same extension. That is what universal binaries are today. It's proven to work well. >>> >>> ok: here is a feature request for fat binaries including linux >>> (i386, x86_64) and windows (i386) binaries. >> >> I wasn't saying anything about GNU/Linux or Windows. I was talking >> Mac OS X. .pd_darwin is all that is needed. .d_fat, etc cause more >> troubles than the fix. >> >> .hc >> >> >> >> >> Access to computers should be unlimited and total. - the hacker >> ethic >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
On Jan 23, 2009, at 3:26 AM, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: >> On Jan 22, 2009, at 2:39 PM, IOhannes m zmoelnig wrote: >> >> I wasn't saying anything about GNU/Linux or Windows. I was >> talking Mac OS X. .pd_darwin is all that is needed. .d_fat, etc >> cause more troubles than the fix. > > but i was talking about architectures _and_ platforms (the later > being freebsd, linux, irix, windows, darwin, ...) > > i would like to see a naming convention that is valid on all these > platforms and where i can have files live side by side on a network > share. (e.g. .so is bad because i cannot distinguish between linux/ > i386, linux/ppc, linux/x86_64 and eventually osx/fat. > > if d_fat is deprecated, i don't have any more problems with it than > with pd_darwin. > however, if it _is_ deprecated, then l_i386 and l_ia64 should be > deprecated as well, and i do see problems with .pd_linux (there is > no fat binary on linux afaik) I don't know in-depth details on this issue on GNU/Linux. If you feel it is necessary there, I am fine with it. > and the most confusing thing i can imagine here is having .dll > (native), .pd_darwin (custom) and .l_ia64 (custom, but different). > > i think there are 2 possibilities: > - use native extensions on all platforms (eg .dylib instead of .d_fat) Sounds great to me! :D > OR > - use custom and consistent extensions on all platforms (either > d_fat or pd_msw; the latter not solving my linux problem, the former > solving them) > i still don't see _any_ trouble caused by d_fat with respect to > pd_darwin, apart from pure reactionary movements. Well, I have experienced them, and tried to outline them here, I wish I could make them clearer. It just seems odd to me that non-OSX users are trying to dictate how to handle OSX issues to someone who has been coding for NeXTSTEP/Mac OS X since 1995. .hc > > > cheers... > > > gmydsr > IOhannes Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
Hans-Christoph Steiner wrote: On Jan 22, 2009, at 2:39 PM, IOhannes m zmoelnig wrote: I wasn't saying anything about GNU/Linux or Windows. I was talking Mac OS X. .pd_darwin is all that is needed. .d_fat, etc cause more troubles than the fix. but i was talking about architectures _and_ platforms (the later being freebsd, linux, irix, windows, darwin, ...) i would like to see a naming convention that is valid on all these platforms and where i can have files live side by side on a network share. (e.g. .so is bad because i cannot distinguish between linux/i386, linux/ppc, linux/x86_64 and eventually osx/fat. if d_fat is deprecated, i don't have any more problems with it than with pd_darwin. however, if it _is_ deprecated, then l_i386 and l_ia64 should be deprecated as well, and i do see problems with .pd_linux (there is no fat binary on linux afaik) and the most confusing thing i can imagine here is having .dll (native), .pd_darwin (custom) and .l_ia64 (custom, but different). i think there are 2 possibilities: - use native extensions on all platforms (eg .dylib instead of .d_fat) OR - use custom and consistent extensions on all platforms (either d_fat or pd_msw; the latter not solving my linux problem, the former solving them) i still don't see _any_ trouble caused by d_fat with respect to pd_darwin, apart from pure reactionary movements. cheers... gmydsr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
I think the d_fat and d_ppc business is only necessary for folks who are maintaining backward compatibility to 10.3 which can't read d_fat files. I think it's a good thing to try to keep things running on older machines since lots of Pd users can't afford to buy the newest ones. However, it's geting hard for me to stay 10.3 compatible as the only remaining 10.3 machine around here is getting sick. cheers Miller On Thu, Jan 22, 2009 at 05:45:08PM -0500, Hans-Christoph Steiner wrote: > > On Jan 22, 2009, at 2:39 PM, IOhannes m zmoelnig wrote: > > > Hans-Christoph Steiner wrote: > >> On Jan 22, 2009, at 4:12 AM, IOhannes m zmoelnig wrote: > >> Lots of people have been doing network shares of applications for > >> decades. Who else is using custom file extensions? I've never seen > > > > python, java, ... > > Um, Java .jar is the same on all platforms. And JNI files are .jnilib > on Mac OS X regardless of CPU, and .dll on Windows regardless of CPU. > AFAIK, Windows DLLs are .dll regardless of whether they are 32-bit or > 64-bit. Even GNU/Linux .so and .a files are the same regardless of CPU. > > >> it. NeXTSTEP/Mac OS X has been doing this since '94, and their > >> solution has been fat binaries all with the same extension. That > >> is what universal binaries are today. It's proven to work well. > > > > ok: here is a feature request for fat binaries including linux > > (i386, x86_64) and windows (i386) binaries. > > I wasn't saying anything about GNU/Linux or Windows. I was talking > Mac OS X. .pd_darwin is all that is needed. .d_fat, etc cause more > troubles than the fix. > > .hc > > > > > Access to computers should be unlimited and total. - the hacker ethic > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
On Jan 22, 2009, at 2:39 PM, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: >> On Jan 22, 2009, at 4:12 AM, IOhannes m zmoelnig wrote: >> Lots of people have been doing network shares of applications for >> decades. Who else is using custom file extensions? I've never seen > > python, java, ... Um, Java .jar is the same on all platforms. And JNI files are .jnilib on Mac OS X regardless of CPU, and .dll on Windows regardless of CPU. AFAIK, Windows DLLs are .dll regardless of whether they are 32-bit or 64-bit. Even GNU/Linux .so and .a files are the same regardless of CPU. >> it. NeXTSTEP/Mac OS X has been doing this since '94, and their >> solution has been fat binaries all with the same extension. That >> is what universal binaries are today. It's proven to work well. > > ok: here is a feature request for fat binaries including linux > (i386, x86_64) and windows (i386) binaries. I wasn't saying anything about GNU/Linux or Windows. I was talking Mac OS X. .pd_darwin is all that is needed. .d_fat, etc cause more troubles than the fix. .hc Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
Hans-Christoph Steiner wrote: On Jan 22, 2009, at 4:12 AM, IOhannes m zmoelnig wrote: Lots of people have been doing network shares of applications for decades. Who else is using custom file extensions? I've never seen python, java, ... it. NeXTSTEP/Mac OS X has been doing this since '94, and their solution has been fat binaries all with the same extension. That is what universal binaries are today. It's proven to work well. ok: here is a feature request for fat binaries including linux (i386, x86_64) and windows (i386) binaries. fmgasd.r IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] d_fat vs. pd_darwin (was Re: Gem 0.91-2 bugfix release)
On Jan 22, 2009, at 4:12 AM, IOhannes m zmoelnig wrote: > 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/v0-40/pd/src/s_loader.c > > and > https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.41/pd/src/s_loader.c > > , 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-sourcesso 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 Lots of people have been doing network shares of applications for decades. Who else is using custom file extensions? I've never seen it. NeXTSTEP/Mac OS X has been doing this since '94, and their solution has been fat binaries all with the same extension. That is what universal binaries are today. It's proven to work well. Just because this broken thing is established doesn't mean we can't fix it. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
