i just put a bugfix release of Gem-0.91 online.
download it from
or svn checkout from
Changelog:
made [pix_freeframe] not crash on OSX (fixes #2476663)
do not use libTIFF/libJPEG is ImageMagick++ is present (fixes #2449674
& #2506838)
always use RGBA for image-loading on OS-X (fixes #2484087)
check for gl/glu headers (fixes #2032488)
force focus when drawing without borders on X (fixes #2192358)
only use multitexturing if hardware supports it (fixes potential crashes)
have fun
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
IOhannes m zmoelnig wrote:
i just put a bugfix release of Gem-0.91 online.
or svn checkout from
having said that, it would be nice that any autobuilds that explicitely use 0.91(0,1) should be updated to use 0.91-2
fgasm,dr IOhannes
On Jan 19, 2009, at 5:04 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i just put a bugfix release of Gem-0.91 online. or svn checkout from
having said that, it would be nice that any autobuilds that
explicitely use 0.91(0,1) should be updated to use 0.91-2fgasm,dr IOhannes
I think the 'pd-extended' auto-build uses trunk for everything but
'pd', which uses the 'pd-extended/0.41.4' branch. Once I make the
release cycle (soon), I'll make a branch of everything. Should I use
that version of Gem for the release branch?
.hc
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
Hans-Christoph Steiner wrote:
On Jan 19, 2009, at 5:04 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i just put a bugfix release of Gem-0.91 online. or svn checkout from
having said that, it would be nice that any autobuilds that
explicitely use 0.91(0,1) should be updated to use 0.91-2fgasm,dr IOhannes
I think the 'pd-extended' auto-build uses trunk for everything but
'pd', which uses the 'pd-extended/0.41.4' branch. Once I make the
release cycle (soon), I'll make a branch of everything. Should I use
that version of Gem for the release branch?
did you already do the switch (libmpeg3 build errors popped up again)? i just realized it would be better to use https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/branches/0.91/ since this one will eventually get even more bugfixes (and as a matter of fact already has some more in it: 0.91.3; though the libmpeg3 issue has probably not been backported yet)
fgmasdr IOhannes
On Jan 26, 2009, at 11:05 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Jan 19, 2009, at 5:04 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i just put a bugfix release of Gem-0.91 online. or svn checkout from
having said that, it would be nice that any autobuilds that
explicitely use 0.91(0,1) should be updated to use 0.91-2fgasm,dr IOhannes
I think the 'pd-extended' auto-build uses trunk for everything but
'pd', which uses the 'pd-extended/0.41.4' branch. Once I make the
release cycle (soon), I'll make a branch of everything. Should I
use that version of Gem for the release branch?did you already do the switch (libmpeg3 build errors popped up again)? i just realized it would be better to use https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/branches/0.91/ since this one will eventually get even more bugfixes (and as a
matter of fact already has some more in it: 0.91.3; though the
libmpeg3 issue has probably not been backported yet)fgmasdr IOhannes
The pd-extended nightly build is indeed using the branch, not the tag: https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/branches/0.91/Gem
.hc
kill your television
Hans-Christoph Steiner wrote:
The pd-extended nightly build is indeed using the branch, not the tag: https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/branches/0.91/Gem
ah that's perfect (for release candidates). the build-problems with gmerlin and libmpeg3 should be fixed by now.
fgmasdr IOhannes
On 19/01/2009, at 10.57, IOhannes m zmoelnig wrote:
have fun
thanks, but my fun stopped at:
----8<----
/path/to/Gem.d_fat: dlopen(/path/to/Gem.d_fat, 10): Symbol not found:
_close$UNIX2003
Referenced from: /path/to/Gem.d_fat
Expected in: /usr/lib/libSystem.B.dylib
Gem: can't load library ----8<----
This happens with Pd-0.42-3 and Pd-0.41-4 intel mac os x.4.11
What am i doing wrong? `file /path/to/Gem.d_fat´ reports the expected.
Steffen Juul wrote:
On 19/01/2009, at 10.57, IOhannes m zmoelnig wrote:
have fun
thanks, but my fun stopped at:
----8<---- /path/to/Gem.d_fat: dlopen(/path/to/Gem.d_fat, 10): Symbol not found:
_close$UNIX2003 Referenced from: /path/to/Gem.d_fat Expected in: /usr/lib/libSystem.B.dylibGem: can't load library ----8<----
This happens with Pd-0.42-3 and Pd-0.41-4 intel mac os x.4.11
yes, i noticed that too, when today i tested the binary on a 10.4 machine. it was compiled on an 10.5 machine, i guess this is the problem.
i will try to update the binary with a 10.4 compatible version asap.
unless, of course, somebody of the os-x gurus can tell me how to avoid this problem alltogether.
the problem might come from pix_freeframe switching to dlopen(), but i don't know yet.
fmgasdr IOhannes
IOhannes m zmoelnig wrote:
Steffen Juul wrote:
On 19/01/2009, at 10.57, IOhannes m zmoelnig wrote:
have fun
thanks, but my fun stopped at:
----8<---- /path/to/Gem.d_fat: dlopen(/path/to/Gem.d_fat, 10): Symbol not found:
_close$UNIX2003 Referenced from: /path/to/Gem.d_fat Expected in: /usr/lib/libSystem.B.dylibGem: can't load library ----8<----
This happens with Pd-0.42-3 and Pd-0.41-4 intel mac os x.4.11
yes, i noticed that too, when today i tested the binary on a 10.4 machine. it was compiled on an 10.5 machine, i guess this is the problem.
i will try to update the binary with a 10.4 compatible version asap.
unless, of course, somebody of the os-x gurus can tell me how to avoid this problem alltogether.
a bit of googling showed that this is a common problem when compiling for 10.4 on 10.5 [1]
i re-compiled following the suggestions on [2]. could you try the binary at http://iem.at/~zmoelnig/GEM/Gem0.91.2_104.tgz (it seems to work here)
[1] e.g. http://discussions.apple.com/thread.jspa?threadID=1589263&tstart=75
[2] http://lua-users.org/lists/lua-l/2008-08/msg00553.html
the problem might come from pix_freeframe switching to dlopen(), but i don't know yet.
fmgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 20/01/2009, at 22.13, IOhannes m zmoelnig wrote:
could you try the binary at http://iem.at/~zmoelnig/GEM/ Gem0.91.2_104.tgz (it seems to work here)
works/loads. thanks! that was fast.
Then i have another problem but it's not new. it's with pix_data.
when i query it for rgb values from a red part of a png image, i get
(r=0,g=1,b=1) as the output (i also boost the contrast and round
off). to gem-tracker item 2484105 I posted a link to an email in the
(pd-list) archive that have a demo patch. i wonder if it's a user error?
Steffen Juul wrote:
On 20/01/2009, at 22.13, IOhannes m zmoelnig wrote:
could you try the binary at http://iem.at/~zmoelnig/GEM/Gem0.91.2_104.tgz (it seems to work here)
works/loads. thanks! that was fast.
:-)
Then i have another problem but it's not new. it's with pix_data. when i query it for rgb values from a red part of a png image, i get (r=0,g=1,b=1) as the output (i also boost the contrast and round off). to gem-tracker item 2484105 I posted a link to an email in the (pd-list) archive that have a demo patch. i wonder if it's a user error?
no it's definitely a bug in Gem. i don't think i'll fix it for 0.91 thought. it ought to be fixed in 0.92.
thanks for the links
one more thing: could someone test whether [pix_2grey] works with the new 10.4 build?
if so, i will _replace_ the OSX binary on the various sites with the new one (rather than do 0.91.3)
fgmasdr IOhannes
On 21/01/2009, at 10.35, IOhannes m zmoelnig wrote:
one more thing: could someone test whether [pix_2grey] works with
the new 10.4 build?
How do i/one test if it works? It instantiate and does something to
the image loaded by pix_image in the help patch. Like turns my
testbild.png into http://dibidut.dk/tmp/testbild2gray.png
On Jan 20, 2009, at 4:13 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
Steffen Juul wrote:
On 19/01/2009, at 10.57, IOhannes m zmoelnig wrote:
have fun
thanks, but my fun stopped at:
----8<---- /path/to/Gem.d_fat: dlopen(/path/to/Gem.d_fat, 10): Symbol not
found: _close$UNIX2003 Referenced from: /path/to/Gem.d_fat Expected in: /usr/lib/libSystem.B.dylibGem: can't load library ----8<----
This happens with Pd-0.42-3 and Pd-0.41-4 intel mac os x.4.11
yes, i noticed that too, when today i tested the binary on a 10.4
machine. it was compiled on an 10.5 machine, i guess this is the problem. i will try to update the binary with a 10.4 compatible version asap. unless, of course, somebody of the os-x gurus can tell me how to
avoid this problem alltogether.a bit of googling showed that this is a common problem when
compiling for 10.4 on 10.5 [1]i re-compiled following the suggestions on [2]. could you try the
binary at http://iem.at/~zmoelnig/GEM/Gem0.91.2_104.tgz (it seems to work here)[1] e.g. http://discussions.apple.com/thread.jspa?threadID=1589263&tstart=75
Yeah, you need to compile on 10.4 to make it 10.4 compatible. It
should also be possible to use -isysroot to compile for 10.4 on 10.5
if you want to try that.
About .d_fat, I think it is probably best to avoid that. .pd_darwin
works well with fat/universal binaries and will cause much less
confusion. I don't think .d_fat been used anywhere except for 4
objectclasses in extra. I have been using .pd_darwin universal
binaries, and Thomas Grill has as well.
.hc
the problem might come from pix_freeframe switching to dlopen(),
but i don't know yet. fmgasdr IOhannes
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
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner wrote:
Yeah, you need to compile on 10.4 to make it 10.4 compatible. It should also be possible to use -isysroot to compile for 10.4 on 10.5 if you want to try that.
the isysroot seems to work ok so far.
About .d_fat, I think it is probably best to avoid that. .pd_darwin works well with fat/universal binaries and will cause much less confusion. I don't think .d_fat been used anywhere except for 4 objectclasses in extra. I have been using .pd_darwin universal binaries, and Thomas Grill has as well.
do i understand correctly, that there is no real argument against d_fat in the above?
btw, most universal binaries maintained by thomas musil are d_fat.
fgmadr IOhannes
Trying to do a checkout of trunk on Windows using tortoiseSVN fails:
Can't check path 'C:\pd_from_svn\externals\gridflow\abstractions\inv*.pd': The filename, directory name, or volume label syntax is incorrect.
I am left with a partial checkout, not sure how many files are missing. I can't get the remaining files because tortoise can't get past inv*.pd and there is apparently no mechanism to ignore files. (You can have it ignore files so they won't be committed but the only way to filter a checkout seems to be to specify individual directories, so I would have to individually checkout every directory in /externals except for gridflow)
Maybe someone could rename inv*.pd, or recommend another svn client that works better?
Martin
Ideally, inv.*.pd would be renamed. We could also just remove
'externals/gridflow' since it is just an import, and AFAIK is not
being used at all. Or maybe just remove that file.
IIRC, there was one or two other files that had problems on Win32.
.hc
On Jan 21, 2009, at 12:59 PM, Martin Peach wrote:
Trying to do a checkout of trunk on Windows using tortoiseSVN fails:
Can't check path 'C:\pd_from_svn\externals\gridflow\abstractions \inv*.pd': The filename, directory name, or volume label syntax is incorrect.
I am left with a partial checkout, not sure how many files are
missing. I can't get the remaining files because tortoise can't get past
inv*.pd and there is apparently no mechanism to ignore files. (You can have it
ignore files so they won't be committed but the only way to filter a
checkout seems to be to specify individual directories, so I would have to
individually checkout every directory in /externals except for gridflow)Maybe someone could rename inv*.pd, or recommend another svn client
that works better?Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith
On Jan 21, 2009, at 12:39 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Yeah, you need to compile on 10.4 to make it 10.4 compatible. It
should also be possible to use -isysroot to compile for 10.4 on
10.5 if you want to try that.the isysroot seems to work ok so far.
About .d_fat, I think it is probably best to avoid
that. .pd_darwin works well with fat/universal binaries and will
cause much less confusion. I don't think .d_fat been used anywhere
except for 4 objectclasses in extra. I have been using .pd_darwin
universal binaries, and Thomas Grill has as well.do i understand correctly, that there is no real argument against
d_fat in the above?btw, most universal binaries maintained by thomas musil are d_fat.
fgmadr IOhannes
There are numerous real arguments against d_fat:
- Gem has used .pd_darwin 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
- Mac OS X never uses CPU-specific file extensions
- supporting so many file extensions increases load time a lot
and more...
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
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
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... 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_darwinyou 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
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
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 seenpython, 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
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 seenpython, 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
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-o...
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
seenpython, 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
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
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
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
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Miller Puckette -
Roman Haefeli -
Steffen Juul