So, I have a little problem with DLLs. I have a [hid] object. The filename is hid.pd_linux, hid.pd_darwin, and hid.dll. The Windows DDK HID library is called... hid.dll. Arg. It gets worse... my hid.dll is of course dependent on the Windows hid.dll. So when Pd opens up my hid.dll, it looks for the Windows symbols in my hid.dll, and they are, of course, not there.
So I did a little LoadLibrary(), but that does not help because it seems that Windows wants to follow all of the links immediately when it opens my hid.dll, before even the setup function is called, so I get the errors before any function is called.
Any suggestions as to how to deal with this?
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hi Hans-Christoph, if you really want to stick to your name, the only chance i see is to load all symbols from the Windows hid.dll dynamically (LoadLibrary and GetProcAdress). It depends on the number of functions you are using but should be doable in principle. Apart from that this _could_ work, it's a really dirty solution.
You could also name your object hidwin.dll and load it as a library ;-) Or use a hid abstraction, encapsulating a hidwin object.
best greetings, Thomas
Am 20.12.2005 um 06:54 schrieb Hans-Christoph Steiner:
So, I have a little problem with DLLs. I have a [hid] object. The filename is hid.pd_linux, hid.pd_darwin, and hid.dll. The Windows DDK HID library is called... hid.dll. Arg. It gets worse... my hid.dll is of course dependent on the Windows hid.dll. So when Pd opens up my hid.dll, it looks for the Windows symbols in my hid.dll, and they are, of course, not there.
So I did a little LoadLibrary(), but that does not help because it seems that Windows wants to follow all of the links immediately when it opens my hid.dll, before even the setup function is called, so I get the errors before any function is called.
Any suggestions as to how to deal with this?
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I thought of both of those too, and they also seem messy. Hmm... maybe a hid_windows.dll that's loaded by my hid.dll. That right now seems to be the best option. Do I have to explicitly load every function with GetProcAddress()?
.hc
On Dec 20, 2005, at 6:16 AM, Thomas Grill wrote:
Hi Hans-Christoph, if you really want to stick to your name, the only chance i see is to load all symbols from the Windows hid.dll dynamically (LoadLibrary and GetProcAdress). It depends on the number of functions you are using but should be doable in principle. Apart from that this _could_ work, it's a really dirty solution.
You could also name your object hidwin.dll and load it as a library ;-) Or use a hid abstraction, encapsulating a hidwin object.
best greetings, Thomas
Am 20.12.2005 um 06:54 schrieb Hans-Christoph Steiner:
So, I have a little problem with DLLs. I have a [hid] object. The filename is hid.pd_linux, hid.pd_darwin, and hid.dll. The Windows DDK HID library is called... hid.dll. Arg. It gets worse... my hid.dll is of course dependent on the Windows hid.dll. So when Pd opens up my hid.dll, it looks for the Windows symbols in my hid.dll, and they are, of course, not there.
So I did a little LoadLibrary(), but that does not help because it seems that Windows wants to follow all of the links immediately when it opens my hid.dll, before even the setup function is called, so I get the errors before any function is called.
Any suggestions as to how to deal with this?
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
On Dec 20, 2005, at 12:54 AM, Hans-Christoph Steiner wrote:
So, I have a little problem with DLLs. I have a [hid] object. The filename is hid.pd_linux, hid.pd_darwin, and hid.dll. The Windows DDK HID library is called... hid.dll. Arg. It gets worse... my hid.dll is of course dependent on the Windows hid.dll. So when Pd opens up my hid.dll, it looks for the Windows symbols in my hid.dll, and they are, of course, not there
...snip...
Any suggestions as to how to deal with this?
...is it impossible to use different postfix's on windows? Not that it'll help, but in Xcode it's called "executable extension", so maybe there's an option equally obscure on windoze?
l8r, james
Hi all,
...is it impossible to use different postfix's on windows? Not that it'll help, but in Xcode it's called "executable extension", so maybe there's an option equally obscure on windoze?
i have always wondered why there is just .dll, and no .pd_win or .pd_nt or whatever, similar to pd_darwin. Just having done some short tests, doesn't seem to be a reason for that, as everything is working ok. Clearly the pd loader would have to be extended. To my mind, it's advantageous to be able to use both the native shared library extensions (like .so, .dylib, .dll) and custom pd ones. The former to easily use it with dynamic linking and the latter to resolve name clashes....
greetings, Thomas
On Dec 20, 2005, at 12:36 PM, Thomas Grill wrote:
Hi all,
...is it impossible to use different postfix's on windows? Not that it'll help, but in Xcode it's called "executable extension", so maybe there's an option equally obscure on windoze?
i have always wondered why there is just .dll, and no .pd_win or .pd_nt or whatever, similar to pd_darwin. Just having done some short tests, doesn't seem to be a reason for that, as everything is working ok. Clearly the pd loader would have to be extended. To my mind, it's advantageous to be able to use both the native shared library extensions (like .so, .dylib, .dll) and custom pd ones. The former to easily use it with dynamic linking and the latter to resolve name clashes....
Make a diff and I'll included it in Pd-extended.
.hc
________________________________________________________________________ ____
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
This is a good idea all around... I'd suggest "pd_msw", and to search for "pd_msw" extensions before falling back to ".dll". If you don't do it first I'll go on and code it here.
cheers Miller
On Tue, Dec 20, 2005 at 01:12:57PM -0500, Hans-Christoph Steiner wrote:
On Dec 20, 2005, at 12:36 PM, Thomas Grill wrote:
Hi all,
...is it impossible to use different postfix's on windows? Not that it'll help, but in Xcode it's called "executable extension", so maybe there's an option equally obscure on windoze?
i have always wondered why there is just .dll, and no .pd_win or .pd_nt or whatever, similar to pd_darwin. Just having done some short tests, doesn't seem to be a reason for that, as everything is working ok. Clearly the pd loader would have to be extended. To my mind, it's advantageous to be able to use both the native shared library extensions (like .so, .dylib, .dll) and custom pd ones. The former to easily use it with dynamic linking and the latter to resolve name clashes....
Make a diff and I'll included it in Pd-extended.
.hc
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-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
How about pd_windows? After all "darwin" and "linux" are full OS names, so it would be consistent.
pd_linux pd_darwin pd_windows
.hc
On Dec 20, 2005, at 1:21 PM, Miller Puckette wrote:
This is a good idea all around... I'd suggest "pd_msw", and to search for "pd_msw" extensions before falling back to ".dll". If you don't do it first I'll go on and code it here.
cheers Miller
On Tue, Dec 20, 2005 at 01:12:57PM -0500, Hans-Christoph Steiner wrote:
On Dec 20, 2005, at 12:36 PM, Thomas Grill wrote:
Hi all,
...is it impossible to use different postfix's on windows? Not that it'll help, but in Xcode it's called "executable extension", so maybe there's an option equally obscure on windoze?
i have always wondered why there is just .dll, and no .pd_win or .pd_nt or whatever, similar to pd_darwin. Just having done some short tests, doesn't seem to be a reason for that, as everything is working ok. Clearly the pd loader would have to be extended. To my mind, it's advantageous to be able to use both the native shared library extensions (like .so, .dylib, .dll) and custom pd ones. The former to easily use it with dynamic linking and the latter to resolve name clashes....
Make a diff and I'll included it in Pd-extended.
.hc
__ ____
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-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
Yes, but "windows" is also a generic term, which "darwin" and "linux" aren't. Perhaps "pd_microsoft", but that would be a 12-letter suffix!
M On Tue, Dec 20, 2005 at 02:03:24PM -0500, Hans-Christoph Steiner wrote:
How about pd_windows? After all "darwin" and "linux" are full OS names, so it would be consistent.
pd_linux pd_darwin pd_windows
.hc
On Dec 20, 2005, at 1:21 PM, Miller Puckette wrote:
This is a good idea all around... I'd suggest "pd_msw", and to search for "pd_msw" extensions before falling back to ".dll". If you don't do it first I'll go on and code it here.
cheers Miller
On Tue, Dec 20, 2005 at 01:12:57PM -0500, Hans-Christoph Steiner wrote:
On Dec 20, 2005, at 12:36 PM, Thomas Grill wrote:
Hi all,
...is it impossible to use different postfix's on windows? Not that it'll help, but in Xcode it's called "executable extension", so maybe there's an option equally obscure on windoze?
i have always wondered why there is just .dll, and no .pd_win or .pd_nt or whatever, similar to pd_darwin. Just having done some short tests, doesn't seem to be a reason for that, as everything is working ok. Clearly the pd loader would have to be extended. To my mind, it's advantageous to be able to use both the native shared library extensions (like .so, .dylib, .dll) and custom pd ones. The former to easily use it with dynamic linking and the latter to resolve name clashes....
Make a diff and I'll included it in Pd-extended.
.hc
__ ____
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-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
http://at.or.at/hans/
On Tue, 20 Dec 2005, Miller Puckette wrote:
Yes, but "windows" is also a generic term, which "darwin" and "linux" aren't. Perhaps "pd_microsoft", but that would be a 12-letter suffix!
But "micro" is a generic term, and so is "soft", and so is "pédé".
So what do we do now?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Well, "msw" is pretty specific!
On Tue, Dec 20, 2005 at 02:54:53PM -0500, Mathieu Bouchard wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
Yes, but "windows" is also a generic term, which "darwin" and "linux" aren't. Perhaps "pd_microsoft", but that would be a 12-letter suffix!
But "micro" is a generic term, and so is "soft", and so is "p?d?".
So what do we do now?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Except that no one outside of Pd world (AFAIK) uses MSW to mean Windows. As for windows being a generic term, I don't know anyone that would be confused as to which OS you are talking about if you say "windows". Its a common word, yes, but by de facto in computer land "windows" means Microsoft. Win32 might be a comprimise.
.hc
On Dec 20, 2005, at 3:12 PM, Miller Puckette wrote:
Well, "msw" is pretty specific!
On Tue, Dec 20, 2005 at 02:54:53PM -0500, Mathieu Bouchard wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
Yes, but "windows" is also a generic term, which "darwin" and "linux" aren't. Perhaps "pd_microsoft", but that would be a 12-letter suffix!
But "micro" is a generic term, and so is "soft", and so is "p?d?".
So what do we do now?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
On Tue, 20 Dec 2005, Hans-Christoph Steiner wrote:
Except that no one outside of Pd world (AFAIK) uses MSW to mean Windows. As for windows being a generic term, I don't know anyone that would be confused as to which OS you are talking about if you say "windows". Its a common word, yes, but by de facto in computer land "windows" means Microsoft. Win32 might be a comprimise.
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
One could also use, say, .pd_lib or .pd_ext for all platforms and have separate build directories for each platform.
Martin
On 12/20/05, Martin Peach martinrp@vax2.concordia.ca wrote:
One could also use, say, .pd_lib or .pd_ext for all platforms and have separate build directories for each platform.
my vote is for reverting to system's native shared library filetype extension. it would simplify the build process to not have to override linker settings to use onstandard file names etc...
c wrote:
On 12/20/05, Martin Peach martinrp@vax2.concordia.ca wrote:
One could also use, say, .pd_lib or .pd_ext for all platforms and have separate build directories for each platform.
my vote is for reverting to system's native shared library filetype extension. it would simplify the build process to not have to override linker settings to use onstandard file names etc...
But then you'll have .so for linux (and darwin?), not .pd_linux, and .dll for mswindows, which was the source of the problem in the first place: a shared library unrelated to pd could have the same name as a pd external.
Martin
On Tue, 20 Dec 2005, Martin Peach wrote:
But then you'll have .so for linux (and darwin?), not .pd_linux, and .dll for mswindows, which was the source of the problem in the first place: a shared library unrelated to pd could have the same name as a pd external.
That's a platform-specific problem, as both Linux and OSX rely on full filenames with directories. When Microsoft gets to that point, we may declare it to have transcended MSDOS 1.x.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Tue, 20 Dec 2005, Martin Peach wrote:
But then you'll have .so for linux (and darwin?), not .pd_linux, and .dll for mswindows, which was the source of the problem in the first place: a shared library unrelated to pd could have the same name as a pd external.
That's a platform-specific problem, as both Linux and OSX rely on full filenames with directories. When Microsoft gets to that point, we may declare it to have transcended MSDOS 1.x.
Sure, but on all platforms you can have multiple search paths which are not forseeable by the programmer. AFAIK there's nothing to stop a user adding /usr/local/lib to a linux pd's path, where there could be lurking a hid.so entirely unrelated to pd...
Martin
On Tue, 20 Dec 2005, Martin Peach wrote:
Sure, but on all platforms you can have multiple search paths which are not forseeable by the programmer. AFAIK there's nothing to stop a user adding /usr/local/lib to a linux pd's path, where there could be lurking a hid.so entirely unrelated to pd...
Sure, but on all platforms you can also add /tmp to the system PATH and write a script called /tmp/pd that would start a web browser pointing to Cycling666's website...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 20 Dec 2005, c wrote:
On 12/20/05, Martin Peach martinrp@vax2.concordia.ca wrote:
One could also use, say, .pd_lib or .pd_ext for all platforms and have separate build directories for each platform.
my vote is for reverting to system's native shared library filetype extension. it would simplify the build process to not have to override linker settings to use onstandard file names etc...
Except that would solve the Pd hid.dll vs. Windows hid.dll issue which started this thread.
.hc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
it would make it much easier to figure out which files need to be deleted when upgrading to pd64, in 2038...
OK, I'm liking "pd_win32" more and more. If Microsoft makes a new dll format that permits bundling, that would be a good moment to change the suffix again...
cheers Miller
On Tue, Dec 20, 2005 at 08:37:34PM +0000, c wrote:
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
it would make it much easier to figure out which files need to be deleted when upgrading to pd64, in 2038...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 20 Dec 2005, Miller Puckette wrote:
OK, I'm liking "pd_win32" more and more. If Microsoft makes a new dll format that permits bundling, that would be a good moment to change the suffix again...
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
Günter
cheers Miller
On Tue, Dec 20, 2005 at 08:37:34PM +0000, c wrote:
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
it would make it much easier to figure out which files need to be deleted when upgrading to pd64, in 2038...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 21 Dec 2005, at 10:06, geiger wrote:
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
Is it feasible to have compounded suffixes? If it is, Günter's question is very valid...I ran PD on Debian on a pismo powerbook for some time, and it would have been nice to be able to compile pd_linux_ppc stuff.
Just my 2 €cents.
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
geiger wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
OK, I'm liking "pd_win32" more and more. If Microsoft makes a new dll format that permits bundling, that would be a good moment to change the suffix again...
pwersonally i would prefer "w32" instead of "win32", just to get rid of the competitive attitude ;-)
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
true. i noticed very similar problems on my amd64 which is mostly use with 64bit linux but sometimes with the 32bit version of the same os. obviously i have xxx.pd_linux which cannot be opened by the "architecture" i am currently working on so i have to recompile.
mfg.asd.r IOhannes
geiger wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
OK, I'm liking "pd_win32" more and more. If Microsoft makes a new dll format that permits bundling, that would be a good moment to change the suffix again...
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
I think .pd_lib for a suffix on all platforms is a good idea.
Then inside pd/src would be a set of platform-specific subdirectories containing the code that only works on one platform, replacing the #ifdef system currently in use, which is difficult to maintain outside of m_pd.h. (s_loader.c currently has six ifdef variants and uses six file extensions).
The makefile would access the appropriate directory and install would put the libraries in the right place. So in a few sols when Ps and PPCs are only toxic scrap all that needs to be changed to run on hyperspintiums is in one place and the files will have the same names...
Given that files with .pd suffix have the same function for all platforms, using .pd_ext for externs and maybe .pd_lib for libraries makes sense to me.
If you have the wrong one, it will probably fail to load rather than crashing pd.
Each library format is identifiable* (e.g. the first 8 bytes of a 32-bit intel .pd_linux looks like 7F 45 4C 46 01 01 01 00 or 0x7f "ELF", the first 2 bytes of a .dll are 4D 5A or "MZ") so user-friendly code could even determine what platform the thing was for before attempting to load it. Currently in sys_load_lib the file is opened once before it is loaded anyway, just to see if it exists.
Martin
_________________________________________________________ *From the ELF Specification (http://www.skyfree.org/linux/references/ELF_Format.pdf):
The first 4 bytes of the file hold a "magic number" identifying the file as an ELF object file. They are {0x7f, 'E', 'L', 'F'}. Following these are bytes for 32/64-bit big/little-endian, etc.
typedef struct { unsigned char e_ident [16]; //"The initial bytes mark the file //as an object file and provide //machine-independent data //with which to decode and interpret the //file’s contents." Elf32_Half e_type; // should be ET_DYN 3 Shared object file Elf32_Half e_machine; // e.g. EM_386 3 Intel 80386 ... } Elf32_Ehdr;
On Wed, 21 Dec 2005, Martin Peach wrote:
Then inside pd/src would be a set of platform-specific subdirectories containing the code that only works on one platform, replacing the #ifdef system currently in use, which is difficult to maintain outside of m_pd.h. (s_loader.c currently has six ifdef variants and uses six file extensions).
I don't think it's that useful to separate the code so much. What really helps readability is when only whole functions get #ifdef'd, instead of having a mess of #ifdefs inside one huge function. This doesn't have to incur much code duplication, as new functions can be thought out to represent the platform-specific tasks as closely as possible.
Stuff like using separate files and separate directories is optional and doesn't have much of an impact -- especially separate directories.
For executables, the dynamics is different, as it's not possible to easily merge two pd libraries. Either using different suffixes or different directories would be ok with me.
Given that files with .pd suffix have the same function for all platforms, using .pd_ext for externs and maybe .pd_lib for libraries makes sense to me.
Pd doesn't think of externs and libraries as being different things. However, some users do.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I think it's better to use file extents than directory structure to disambiguate this, so that people can distribute "fat" externs within a single directory. If we want the suffix to combine both the architecture and the OS, maybe the best name scheme is
.lin_32 .lin_64 .lin_ppc .mac_ppc .mac_64 .msw_32 .msw_64
The original ".pd" business was to disambiguate between pd, jmax, "max 0.26" and Max/MSP, but now that that's down to only two offerings maybe that's not an issue right now.
cheers Miller
On Wed, Dec 21, 2005 at 11:06:36AM +0100, geiger wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
OK, I'm liking "pd_win32" more and more. If Microsoft makes a new dll format that permits bundling, that would be a good moment to change the suffix again...
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
G?nter
cheers Miller
On Tue, Dec 20, 2005 at 08:37:34PM +0000, c wrote:
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
it would make it much easier to figure out which files need to be deleted when upgrading to pd64, in 2038...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed, 21 Dec 2005, Miller Puckette wrote:
I think it's better to use file extents than directory structure to disambiguate this, so that people can distribute "fat" externs within a single directory.
Why is it any important to be able to use 1 directory instead of 2 ?
The original ".pd" business was to disambiguate between pd, jmax, "max 0.26" and Max/MSP, but now that that's down to only two offerings maybe that's not an issue right now.
there are variations in Pd's APIs that may require different versions of externals.
If you have an external that gets compiled with class_settooltip capability then it cannot be loaded in Pure/MSP. That was introduced in devel_0_37.
The impd/desiredata API is also different. It has gobj_subscribe, pd_upload, pd_scanargs, etc. and will continue to diverge unless it is followed by compatible changes in other APIs.
In the light of this, there is room for four offerings, short of putting exact API versions in the filename.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi all,
I think it's better to use file extents than directory structure to disambiguate this, so that people can distribute "fat" externs within a single directory. If we want the suffix to combine both the architecture and the OS, maybe the best name scheme is
.lin_32 .lin_64 .lin_ppc .mac_ppc .mac_64 .msw_32 .msw_64
is _32 and _64 meant to be ix86 and amd64/emt64, respectively? Anyone running pd on ia64 (itanium)? The mac binaries might be ppc32 and ppc64 bits, but also ix86 and amd64.
here are some namings, explicitly including the cpu architecture:
.lnx_ix86 .lnx_ia64 .lnx_amd64 .lnx_ppc32 .mac_ppc32 .mac_ppc64 .mac_ix86 .mac_amd64 .win_ix86 .win_amd64 .irix_mips
on the other hand, i find it getting uglier and uglier.... preferring some kind of folder-based bundles (optionally as a zip archive) more and more.
best greetings, Thomas
On Wed, 21 Dec 2005, Thomas Grill wrote:
.mac_amd64 .win_ix86 .win_amd64 .irix_mips on the other hand, i find it getting uglier and uglier.... preferring some kind of folder-based bundles (optionally as a zip archive) more and more.
What about my proposal with suffixes like .i686-linux.so ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Am 22.12.2005 um 15:08 schrieb Mathieu Bouchard:
On Wed, 21 Dec 2005, Thomas Grill wrote:
.mac_amd64 .win_ix86 .win_amd64 .irix_mips on the other hand, i find it getting uglier and uglier.... preferring some kind of folder-based bundles (optionally as a zip archive) more and more.
What about my proposal with suffixes like .i686-linux.so ?
must have overread this.... that's probably the best solution.
best greetings, Thomas
On Thu, 22 Dec 2005, Thomas Grill wrote:
Am 22.12.2005 um 15:08 schrieb Mathieu Bouchard:
What about my proposal with suffixes like .i686-linux.so ?
must have overread this.... that's probably the best solution.
http://lists.puredata.info/pipermail/pd-dev/2005-12/005541.html
But make sure that you compare with my other proposals first (in the same mail).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Both Perl and Ruby use directories labeled like i386-linux and
what exactly is the purpose of this? maybe some crazy netboot AFS setup for an entire university that had a sitewide ruby or perl install but everyone had arch specific interpreter binaries in their $HOME/bin? i just don't see it...even on a multilib system, its not like theres a /usr/lib/ruby/i8086-hurd/bin/ruby, yet for the extensions theres /usr/lib64/ruby/1.8/x86_64-linux and /usr/lib32/ruby/1.8/i686-linux -> the second platform specification is redundant and could easily be replaced by 'lib' or 'extra' or such...
the most fitting thing for pd would probably be branch-specific dirs, for example itd be great when running canonical it didnt bomb out loading externals that reference a fftw symbol or use idle callbacks, and likewise id rather not have stock devel try to load GUI externals compiled for desire_devel...etc. it got to the point i had to recompile externals every time i was switching pd versions (maybe version-specific .pdrc sections would work too...)
not that anyone would want to externalize these differences onto the filesystem, but they exist anyway, and the user is far more likely to run into them then accidentally ending up with a darwin external on their windows install??
c
After going thru all of the disparate proposals, I think that the simplest is best: why not just one extension for all platforms? This is how programs like Photoshop do it, for example. As for the fat library, that is an interesting idea, but that could be done with named directories as well. And since this would be a rare case, it seems that making the common cases simpler would be preferred.
Almost all packages which are compiled for distribution are done on on the processor/platform that they are targeted for. So its relatively straightforward to package the compiled files separately for each platform. This is how its currently done with Pd and Pd-extended, for example
.hc
On Dec 22, 2005, at 1:09 PM, c wrote:
Both Perl and Ruby use directories labeled like i386-linux and
what exactly is the purpose of this? maybe some crazy netboot AFS setup for an entire university that had a sitewide ruby or perl install but everyone had arch specific interpreter binaries in their $HOME/bin? i just don't see it...even on a multilib system, its not like theres a /usr/lib/ruby/i8086-hurd/bin/ruby, yet for the extensions theres /usr/lib64/ruby/1.8/x86_64-linux and /usr/lib32/ruby/1.8/i686-linux -> the second platform specification is redundant and could easily be replaced by 'lib' or 'extra' or such...
the most fitting thing for pd would probably be branch-specific dirs, for example itd be great when running canonical it didnt bomb out loading externals that reference a fftw symbol or use idle callbacks, and likewise id rather not have stock devel try to load GUI externals compiled for desire_devel...etc. it got to the point i had to recompile externals every time i was switching pd versions (maybe version-specific .pdrc sections would work too...)
not that anyone would want to externalize these differences onto the filesystem, but they exist anyway, and the user is far more likely to run into them then accidentally ending up with a darwin external on their windows install??
c
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
Hi all, picking up that thread again, so that i won't be forgotten before some tracker patch is submitted....
After going thru all of the disparate proposals, I think that the simplest is best: why not just one extension for all platforms? This is how programs like Photoshop do it, for example. As for the fat library, that is an interesting idea, but that could be done with named directories as well. And since this would be a rare case, it seems that making the common cases simpler would be preferred.
Almost all packages which are compiled for distribution are done on on the processor/platform that they are targeted for. So its relatively straightforward to package the compiled files separately for each platform. This is how its currently done with Pd and Pd-extended, for example
ok, from the point of current practice that's ok as well.... it's much better than the current situation. What could the unified extension be? .pdext? (i don't like underscores in extensions, i have to admit) Later, there would still be the possibility to introduce something like .i686-linux.pdext as a specialization that has precedence before .pdext (if one doesn't care about . in externals' names)
best greetings, Thomas
Thomas Grill wrote:
After going thru all of the disparate proposals, I think that the simplest is best: why not just one extension for all platforms? This
just some random remarks on this (the main reason why i reply to the mail, comes at the end):
because it breaks _my_ way of working with pd. and even though i am probably the only one who is sharing one home-directory with compiled externals across 4 different platforms, i don't think it is valid to ignore this need. (like in: we don't need a per-host pdrc-mechanism, since hardly anybody will use it)
Almost all packages which are compiled for distribution are done on on the processor/platform that they are targeted for. So its relatively straightforward to package the compiled files separately for each platform. This is how its currently done with Pd and Pd-extended, for
i guess this is valid from the packager's point of view. however, there are non-packages fighting with compilers too.
ok, from the point of current practice that's ok as well.... it's much better than the current situation. What could the unified extension be? .pdext? (i don't like underscores in extensions, i have to admit)
i have to admit, that i prefer 3 character extensions (being a DOSosaur). thus i would suggest using .pdc or .pdo (just like in .pyc or .pyo)
Later, there would still be the possibility to introduce something like .i686-linux.pdext as a specialization that has precedence before .pdext (if one doesn't care about . in externals' names)
i like this idea.
mf.asdr. IOhannes
because it breaks _my_ way of working with pd. and even though i am probably the only one who is sharing one home-directory with compiled externals across 4 different platforms, i don't think it is valid to ignore this need. (like in: we don't need a per-host pdrc-mechanism, since hardly anybody will use it)
hardly nnobody would have 4 platforms of externals in the same folder either :).
the point behind the per-host .pdrc would be to add a different -path for each one, so you can just use the native .so extension and -path extra/pd_linux -path extra/pd_win... just an idea (personally it think it should append some paths automagicaly based on uname, then you can just use subfolders...and dont need to add features to pdrc (its not like miller wants that or he'd have accepted the commenting and win32 support for pdrc long ago..)
so you can just use the native .so extension
the point behind this (i hope its obvious) is so you dont have to override the default extension in dlopen() and SCons..i cant think of another cross-platform app that decided it needed to invent new library extensions. can anyone name some?
cdr
hi all,
Am Montag 09 Januar 2006 14:17 schrieb cdr:
so you can just use the native .so extension
the point behind this (i hope its obvious) is so you dont have to override the default extension in dlopen() and SCons..i cant think of another cross-platform app that decided it needed to invent new library extensions. can anyone name some?
cdr
photoshop & plugins, premiere & plugins ....
altough im not sure that premiere is still available on x86 and ppc ...
greets,
chris
On Jan 9, 2006, at 8:17 AM, cdr wrote:
so you can just use the native .so extension
the point behind this (i hope its obvious) is so you dont have to override the default extension in dlopen() and SCons..i cant think of another cross-platform app that decided it needed to invent new library extensions. can anyone name some?
The whole reason why this thread started was because of problems with using the native extension: My [hid] object cannot access hid.dll since the file names are the same.
Photoshop is an example of a program that uses a special, cross-platform extension for its extensions (.8ba). QuickTime is another example. (.qtx).
Mac OS X's .bundle and .framework are examples of packaging .so differently. So there are plenty of precedents.
.hc ________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
The whole reason why this thread started was because of problems with using the native extension: My [hid] object cannot access hid.dll since the file names are the same.
the MSDN docuentation for LoadLibrary says theres support for absolute paths, in which case it wont search the system PATH first. this is misadvertised?
The whole reason why this thread started was because of problems with using the native extension: My [hid] object cannot access hid.dll since the file names are the same.
the MSDN docuentation for LoadLibrary says theres support for absolute paths, in which case it wont search the system PATH first. this is misadvertised?
er, right... "A similar limitation exists for modules with the same name but residing in different directories. For example, if LoadLibrary is called on \Windows\Sample.dll, and then LoadLibrary is called on \MyDir\Sample.dll, \Windows\Sample.dll will simply be reloaded."
nice "gotcha"..
er, right... "A similar limitation exists for modules with the same name but residing in different directories. For example, if LoadLibrary is called on \Windows\Sample.dll, and then LoadLibrary is called on \MyDir\Sample.dll, \Windows\Sample.dll will simply be reloaded."
however, it gets even more insane:
"Two different modules cannot have the same file name, even if the extensions are different. These effectively have the same module name. For example, if LoadLibrary is made on Sample.cpl, the operating system will not load Sample.cpl, but instead will again load Sample.dll."
does this not mean hid.pd_losedows will still reload hid.dll instead? i guess you just can't win with Windows...
On Jan 9, 2006, at 1:41 PM, cdr wrote:
er, right... "A similar limitation exists for modules with the same name but residing in different directories. For example, if LoadLibrary is called on \Windows\Sample.dll, and then LoadLibrary is called on \MyDir\Sample.dll, \Windows\Sample.dll will simply be reloaded."
however, it gets even more insane:
"Two different modules cannot have the same file name, even if the extensions are different. These effectively have the same module name. For example, if LoadLibrary is made on Sample.cpl, the operating system will not load Sample.cpl, but instead will again load Sample.dll."
does this not mean hid.pd_losedows will still reload hid.dll instead? i guess you just can't win with Windows...
Yes indeed, this sounds like classic Microsoft. Arcane APIs and arbitrary limitations.
So it sounds like .cpl is a also a .dll, which would be another example of a special file extension for a shared lib. Hopefully the above rule only applies to Windows system files, like .cpl. Otherwise, I'm screwed!
I knew there was a good reason why I tried to avoid programming on Windows...
.hc
________________________________________________________________________ ____
so you can just use the native .so extension
Sorry, i forgot to mention it, but as stated in my original proposal (in December), platform-native shared library extensions (.so,.dll,.dylib) should be supported as well. Still, to avoid name-clashes with system or third-party libraries having a pd-specific extension is important. .pdo doesn't sound too bad (.pdx and .pdb don't seem to be good, because ambigous choices)
best greetings, Thomas
On Jan 9, 2006, at 9:33 AM, Thomas Grill wrote:
so you can just use the native .so extension
Sorry, i forgot to mention it, but as stated in my original proposal (in December), platform-native shared library extensions (.so,.dll,.dylib) should be supported as well.
Why do we need to support the platform-specific shared lib formats? I think this will just add confusion for no real gain that I can see.
Still, to avoid name-clashes with system or third-party libraries having a pd-specific extension is important. .pdo doesn't sound too bad (.pdx and .pdb don't seem to be good, because ambigous choices)
Do we really need to use a 3 character extension? I mean how many people are really using DOS any more? .pd_darwin and .pd_linux have been working fine for a long time, Windows has no problem with .jpeg and .html for example.
.pdo is taken by Microsoft. It looks like basically all .pd? extensions are taken:
http://filext.com/alphalist.php?extstart=%5EP
We could make it technically correct (for single file objects at least) and use .pdclass. But .pdext seems acceptable.
.hc ________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
so you can just use the native .so extension
Sorry, i forgot to mention it, but as stated in my original proposal (in December), platform-native shared library extensions (.so,.dll,.dylib) should be supported as well.
Why do we need to support the platform-specific shared lib formats? I think this will just add confusion for no real gain that I can see.
yes, i think you are right... I was arguing from my viewpoint as a developer, where it's clearer to have 3 different extensions for 3 platforms but yet, having separate folders is just as good.
Still, to avoid name-clashes with system or third-party libraries having a pd-specific extension is important. .pdo doesn't sound too bad (.pdx and .pdb don't seem to be good, because ambigous choices)
Do we really need to use a 3 character extension? I mean how many people are really using DOS any more? .pd_darwin and .pd_linux have been working fine for a long time, Windows has no problem with .jpeg and .html for example.
.pdo is taken by Microsoft. It looks like basically all .pd? extensions are taken:
http://filext.com/alphalist.php?extstart=%5EP
We could make it technically correct (for single file objects at least) and use .pdclass. But .pdext seems acceptable.
To my mind, there's no reason to stay with 3 characters. .pdext seems to be clear and self-descriptive. I'm open for any reasonable extension, as long as this stuff gets implemented
best greetings, Thomas
On Jan 9, 2006, at 7:48 AM, IOhannes m zmoelnig wrote:
Thomas Grill wrote:
After going thru all of the disparate proposals, I think that the simplest is best: why not just one extension for all platforms? This
just some random remarks on this (the main reason why i reply to the mail, comes at the end):
because it breaks _my_ way of working with pd. and even though i am probably the only one who is sharing one home-directory with compiled externals across 4 different platforms, i don't think it is valid to ignore this need. (like in: we don't need a per-host pdrc-mechanism, since hardly anybody will use it)
I think there is a very good chance that you are the only place doing this, plus there are easy workarounds. Going forward, the .pdrc is deprecated, so I don't think we should waste time supporting it. It would not be hard to write a script which will generate the various platform-specific conf files when given a common set of options. Then this would allow you to move off of the .pdrc. I have been thinking about doing it for the Pd-extended conf files anyway...
Let's try to keep this clean. That's not possible if we try to cater to every possibility under the sun.
.hc
Almost all packages which are compiled for distribution are done on on the processor/platform that they are targeted for. So its relatively straightforward to package the compiled files separately for each platform. This is how its currently done with Pd and Pd-extended, for
i guess this is valid from the packager's point of view. however, there are non-packages fighting with compilers too.
ok, from the point of current practice that's ok as well.... it's much better than the current situation. What could the unified extension be? .pdext? (i don't like underscores in extensions, i have to admit)
i have to admit, that i prefer 3 character extensions (being a DOSosaur). thus i would suggest using .pdc or .pdo (just like in .pyc or .pyo)
Later, there would still be the possibility to introduce something like .i686-linux.pdext as a specialization that has precedence before .pdext (if one doesn't care about . in externals' names)
i like this idea.
mf.asdr. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
ohoh, this sounds all too familiar...
apparently i am the only one who is working in a multiuser environment. for me, you seem a bit arrogant when denying other people's needs. (but i guess, this sounds arrogant too :-)) i mean, universities started using unix a long time ago, and even though nobody is interested in a multi-user environment, today you (and you) are using linux, os-X and what else which are based on that. i mean, 640k are enough.
Hans-Christoph Steiner wrote:
because it breaks _my_ way of working with pd. and even though i am probably the only one who is sharing one home-directory with compiled externals across 4 different platforms, i don't think it is valid to ignore this need. (like in: we don't need a per-host pdrc-mechanism, since hardly anybody will use it)
I think there is a very good chance that you are the only place doing this, plus there are easy workarounds. Going forward, the .pdrc is deprecated, so I don't think we should waste time supporting it. It
with "pdrc-mechanism" i was referring to a settings-mechanism rather than the .pdrc-implementation. i don't care whether my settings are stored in .pdrc or my registry, as long as i can have a per-host setting and a per-user setting.
would not be hard to write a script which will generate the various platform-specific conf files when given a common set of options. Then
do i understand you correctly, that i should regenerate my .pdsettings each time i switch machines? my workflow is: pd on machineA, ssh to machineB and pd there, leave both instances running and walk to machineC to run pd there. switch between the 3 machines randomly; start and stop pd at will.
please tell me, that this is the wrong way to use pd, and since i am the only one who is doing so, it doesn't matter at all.
Let's try to keep this clean. That's not possible if we try to cater to every possibility under the sun.
yep. thus i would suggest to use .dll as the only extension and w32 as the only platform. we wouldn't have problems with "every possibility under the sun" then.
this sounds very ridiculous.
mfg.af. IOhannes
I have no problem with whatever setup you want to run. My problem is that you block progress expecting the rest of us to implement things for your very specific setup. If you would do the work and come up with a solution that works for all of us, then it would be a different story.
There are lots of things that broke _my_ way of working with Pd. But sometimes I've recognized that the community is better off because of it, so I have accepted the changes, and adapted to them.
As for the script, you would only need to run it whenever you make changes to your setup. Its that simple. I don't really know how your setup works, that's why I can't tell you what to do. But I can tell you that I think there is a very good chance that a simple script will work for you. I even offered to write something. What's the problem?
.hc
On Mon, 9 Jan 2006, IOhannes m zmoelnig wrote:
ohoh, this sounds all too familiar...
apparently i am the only one who is working in a multiuser environment. for me, you seem a bit arrogant when denying other people's needs. (but i guess, this sounds arrogant too :-)) i mean, universities started using unix a long time ago, and even though nobody is interested in a multi-user environment, today you (and you) are using linux, os-X and what else which are based on that. i mean, 640k are enough.
Hans-Christoph Steiner wrote:
because it breaks _my_ way of working with pd. and even though i am probably the only one who is sharing one home-directory with compiled externals across 4 different platforms, i don't think it is valid to ignore this need. (like in: we don't need a per-host pdrc-mechanism, since hardly anybody will use it)
I think there is a very good chance that you are the only place doing this, plus there are easy workarounds. Going forward, the .pdrc is deprecated, so I don't think we should waste time supporting it. It
with "pdrc-mechanism" i was referring to a settings-mechanism rather than the .pdrc-implementation. i don't care whether my settings are stored in .pdrc or my registry, as long as i can have a per-host setting and a per-user setting.
would not be hard to write a script which will generate the various platform-specific conf files when given a common set of options. Then
do i understand you correctly, that i should regenerate my .pdsettings each time i switch machines? my workflow is: pd on machineA, ssh to machineB and pd there, leave both instances running and walk to machineC to run pd there. switch between the 3 machines randomly; start and stop pd at will.
please tell me, that this is the wrong way to use pd, and since i am the only one who is doing so, it doesn't matter at all.
Let's try to keep this clean. That's not possible if we try to cater to every possibility under the sun.
yep. thus i would suggest to use .dll as the only extension and w32 as the only platform. we wouldn't have problems with "every possibility under the sun" then.
this sounds very ridiculous.
mfg.af. IOhannes
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
I have no problem with whatever setup you want to run. My problem is
most likely i am a bit over-sensitive in this region.
that you block progress expecting the rest of us to implement things for your very specific setup. If you would do the work and come up with a solution that works for all of us, then it would be a different story.
oh now that sounds great (but i guess, i was just too aggressive to get a cool answer ,-))
since you were talking about "getting a clean solution", i thought we were at the stage of _talking_ about things _before_ implementing them. maybe i was wrong. i apologize in this case.
i would prefer pd-dev not to become a "hey, i have implemented feature xyz" kind of list, with loads of people getting frustrated since neither feature x nor y (not to speak of z) are accepted into pd-core. that is why i thought, that the main purpose of pd-dev is talking about development (but then there is also the irc-chat, which might have this purpose)
mfg.asdr. IOhannes
Hans-Christoph Steiner wrote:
I have no problem with whatever setup you want to run. My problem is that you block progress expecting the rest of us to implement things for your very specific setup. If you would do the work and come up with a solution that works for all of us, then it would be a different story.
and of course it would be trivial to implement a different extension.
mfg.asdr. IOhannes
On Thu, 22 Dec 2005, c wrote:
what exactly is the purpose of this? maybe some crazy netboot AFS setup for an entire university that had a sitewide ruby or perl install but everyone had arch specific interpreter binaries in their $HOME/bin? i just don't see it...even on a multilib system, its not like theres a /usr/lib/ruby/i8086-hurd/bin/ruby, yet for the extensions theres /usr/lib64/ruby/1.8/x86_64-linux and /usr/lib32/ruby/1.8/i686-linux -> the second platform specification is redundant and could easily be replaced by 'lib' or 'extra' or such...
I agree.
the most fitting thing for pd would probably be branch-specific dirs, for example itd be great when running canonical it didnt bomb out loading externals that reference a fftw symbol or use idle callbacks, and likewise id rather not have stock devel try to load GUI externals compiled for desire_devel...etc. it got to the point i had to recompile externals every time i was switching pd versions (maybe version-specific .pdrc sections would work too...)
I agree too.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 21 Dec 2005, geiger wrote:
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
Both Perl and Ruby use directories labeled like i386-linux and powerpc-darwin and such, to put platform-specific files. Following that convention, imagine this:
/usr/lib/pd/extra/ for platform-independent files, except /usr/lib/pd/extra/i686-linux/ for platform-specific files and both of those dirs appear in Pd's default path.
Alternately, those same suffixes may be applied to filenames instead, though there aren't many popular precedents. If we want to expand on Pd's tradition, it could be like this:
/usr/lib/pd/extra/expr~.pd_i686-linux
but to people outside of Pd it would appear less weird like this:
/usr/lib/pd/extra/expr~.i686-linux.so
also, by default, Tcl and Python don't support multiple archs, at least not in my distro.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
on win64, the 64bit system libraries are in a folder called "system32" and the 32bit libraries are in a folder called "syswow64". so maybe we should stick to that and start using win64 for now, and update to to win32 later on..(im pretty sure discovering that was the moment i decided i couldnt handle windows any longer)
On Dec 20, 2005, at 3:48 PM, c wrote:
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
on win64, the 64bit system libraries are in a folder called "system32" and the 32bit libraries are in a folder called "syswow64". so maybe we should stick to that and start using win64 for now, and update to to win32 later on..(im pretty sure discovering that was the moment i decided i couldnt handle windows any longer)
...hahaha: I just got the image of carmen sitting in a window-less bunker, carefully straightening his tinfoil cap while looking disapprovingly at the door... ;-)
jamie
On Tue, 20 Dec 2005, Miller Puckette wrote:
On Tue, Dec 20, 2005 at 02:54:53PM -0500, Mathieu Bouchard wrote:
and so is "p?d?".
Well, "msw" is pretty specific!
Hey I found the first step towards I18N in CANONICAL PD ! Miller should at least enable ISO-8859-1 support in his mailclient. 7-bit ascii is like, even parity, 1 stop bit, half-duplex, and the like...
(And if possible, also enable Unicode, and I mean UTF8 and not UCS2)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
On Tue, Dec 20, 2005 at 02:54:53PM -0500, Mathieu Bouchard wrote:
and so is "p?d?".
Well, "msw" is pretty specific!
Hey I found the first step towards I18N in CANONICAL PD ! Miller should at least enable ISO-8859-1 support in his mailclient.
Hm, according to the mail header, he was using Apple Mail. Wasn't Apple famous for creating user friendly software and having sensible defaults for everything? ;)
(Btw: I recently struggled with setting the search-path in Pd on a german OS-X for half an hour before I figured out that the german "Dokumente" in the Finder actually is called "Documents" in the file system. I18n totally gone wrong, if you ask me ...)
Sorry for interrupting with off-topicness.
Ciao
I'm on 'mutt'. The good thing about ASCII is perhaps someday it will persuade the world to stop using diacriticals...
M
On Tue, Dec 20, 2005 at 10:14:37PM +0100, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
On Tue, Dec 20, 2005 at 02:54:53PM -0500, Mathieu Bouchard wrote:
and so is "p?d?".
Well, "msw" is pretty specific!
Hey I found the first step towards I18N in CANONICAL PD ! Miller should at least enable ISO-8859-1 support in his mailclient.
Hm, according to the mail header, he was using Apple Mail. Wasn't Apple famous for creating user friendly software and having sensible defaults for everything? ;)
(Btw: I recently struggled with setting the search-path in Pd on a german OS-X for half an hour before I figured out that the german "Dokumente" in the Finder actually is called "Documents" in the file system. I18n totally gone wrong, if you ask me ...)
Sorry for interrupting with off-topicness.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 20 Dec 2005, Miller Puckette wrote:
I'm on 'mutt'. The good thing about ASCII is perhaps someday it will persuade the world to stop using diacriticals...
Wow. What does the ASCII abbreviation stand for then?
American Supremacist Committee for Inequality in Informatics ?
(nota bene: American as in Unitedstatesian, of course. I don't mean to offend most people living in the Americas)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I'm on 'mutt'. The good thing about ASCII is perhaps someday it will persuade the world to stop using diacriticals...
Oh, yes, sorry to all sides. ;) I was reading Hans' reply to your mail instead, who is using Apple Mail.
I have this in my ~/.muttrc:
set charset=iso-8859-15 set send_charset="us-ascii:iso-8859-15:iso-8859-1:utf-8"
It was copied from somewhere. Can you all see my umlauts: öÀÌ ?
Ciao
On Tue, 20 Dec 2005, Frank Barknecht wrote:
(Btw: I recently struggled with setting the search-path in Pd on a german OS-X for half an hour before I figured out that the german "Dokumente" in the Finder actually is called "Documents" in the file system. I18n totally gone wrong, if you ask me ...)
According to you, what would be a not-totally-gone-wrong way to handle the I18N of filenames?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 20 Dec 2005, Frank Barknecht wrote:
(Btw: I recently struggled with setting the search-path in Pd on a german OS-X for half an hour before I figured out that the german "Dokumente" in the Finder actually is called "Documents" in the file system. I18n totally gone wrong, if you ask me ...)
According to you, what would be a not-totally-gone-wrong way to handle the I18N of filenames?
The problem is, that there is no file called "Dokumente" on the machine, the actual file (or folder) is called "Documents". However the Finder - which I thought was a *File* manager, but it seems, it isn't one - showed a folder called "Dokumente", which just doesn't exist! I18N done right would just use a real folder called "Dokumente". That's one thing, that's better on MS-Windows, where "My Documents" on a english machine actually is a folder "Meine Dateien" on a german windows box. Of course the unixish '~' is even better and solves all language problems. ;)
Ciao
On Tue, 20 Dec 2005, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 20 Dec 2005, Frank Barknecht wrote:
(Btw: I recently struggled with setting the search-path in Pd on a german OS-X for half an hour before I figured out that the german "Dokumente" in the Finder actually is called "Documents" in the file system. I18n totally gone wrong, if you ask me ...)
According to you, what would be a not-totally-gone-wrong way to handle the I18N of filenames?
The problem is, that there is no file called "Dokumente" on the machine, the actual file (or folder) is called "Documents". However the Finder - which I thought was a *File* manager, but it seems, it isn't one - showed a folder called "Dokumente", which just doesn't exist! I18N done right would just use a real folder called "Dokumente". That's one thing, that's better on MS-Windows, where "My Documents" on a english machine actually is a folder "Meine Dateien" on a german windows box. Of course the unixish '~' is even better and solves all language problems. ;)
Even better, there are global environment variables for this stuff, on Windows, there is %ProgramFile%, %SystemRoot%, etc. on UNIXish there is $HOME, etc. etc.
We should allow Pd to use those env vars in the preferences, that would make it much easier to write defaults prerefences files that are included in distros (i.e. pd-settings.reg and org.pure-data.pd.plist).
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Even better, there are global environment variables for this stuff, on Windows, there is %ProgramFile%, %SystemRoot%, etc. on UNIXish there is $HOME, etc. etc.
We should allow Pd to use those env vars in the preferences, that would make it much easier to write defaults prerefences files that are included in distros (i.e. pd-settings.reg and org.pure-data.pd.plist).
*That* would be immensely useful, also in workshops.
Ciao
Then the users would have to dump "pd-settings.reg" into their registrys somehow? I wouldn't know how to do that. Is this just to make patches able to find libraries relative to the Pd install? I think that could be done much more OS-independently...
cheers Miller
On Wed, Dec 21, 2005 at 12:10:14AM +0100, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Even better, there are global environment variables for this stuff, on Windows, there is %ProgramFile%, %SystemRoot%, etc. on UNIXish there is $HOME, etc. etc.
We should allow Pd to use those env vars in the preferences, that would make it much easier to write defaults prerefences files that are included in distros (i.e. pd-settings.reg and org.pure-data.pd.plist).
*That* would be immensely useful, also in workshops.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Dec 20, 2005, at 7:36 PM, Miller Puckette wrote:
Then the users would have to dump "pd-settings.reg" into their registrys somehow? I wouldn't know how to do that.
You just double-click any .reg file, and it'll prompt you whether you want to add it to the registry. You then press Yes, then OK.
Is this just to make patches able to find libraries relative to the Pd install? I think that could be done much more OS-independently...
This is to distribute with Pd-extended so that newbies don't have to figure out how to load libraries in order to use patches that rely on them. Currently, I maintain a Mac OS X and a Windows file. I think its fine to do it this way, it just uses the existing preferences system. The .pdrc would be a OS-independent way ;).
The env vars that I mentioned would all me to replace "C:\Program Files" with %ProgramFiles% which would work on Windows for any language. For example auf Deutsch, its called "C:\Programme".
.hc
cheers Miller
On Wed, Dec 21, 2005 at 12:10:14AM +0100, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Even better, there are global environment variables for this stuff, on Windows, there is %ProgramFile%, %SystemRoot%, etc. on UNIXish there is $HOME, etc. etc.
We should allow Pd to use those env vars in the preferences, that would make it much easier to write defaults prerefences files that are included in distros (i.e. pd-settings.reg and org.pure-data.pd.plist).
*That* would be immensely useful, also in workshops.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
So the simplest way I can think of doing this would be to put a "settings" file in the pd bin directory, which would be read in if any user who doesn't already have Pd preferences set starts Pd up. Then when the user saves new (customized) settings they would take over from the initial settings.
And yes, it would be necessary to have some way to specify paths relative to "pd" rather than to the current patch... maybe any directory named in "path" should be taken as a filename either relative to the running Pd binary or to the current document (as it is now.)
cheers Miller
On Tue, Dec 20, 2005 at 11:44:48PM -0500, Hans-Christoph Steiner wrote:
On Dec 20, 2005, at 7:36 PM, Miller Puckette wrote:
Then the users would have to dump "pd-settings.reg" into their registrys somehow? I wouldn't know how to do that.
You just double-click any .reg file, and it'll prompt you whether you want to add it to the registry. You then press Yes, then OK.
Is this just to make patches able to find libraries relative to the Pd install? I think that could be done much more OS-independently...
This is to distribute with Pd-extended so that newbies don't have to figure out how to load libraries in order to use patches that rely on them. Currently, I maintain a Mac OS X and a Windows file. I think its fine to do it this way, it just uses the existing preferences system. The .pdrc would be a OS-independent way ;).
The env vars that I mentioned would all me to replace "C:\Program Files" with %ProgramFiles% which would work on Windows for any language. For example auf Deutsch, its called "C:\Programme".
.hc
cheers Miller
On Wed, Dec 21, 2005 at 12:10:14AM +0100, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Even better, there are global environment variables for this stuff, on Windows, there is %ProgramFile%, %SystemRoot%, etc. on UNIXish there is $HOME, etc. etc.
We should allow Pd to use those env vars in the preferences, that would make it much easier to write defaults prerefences files that are included in distros (i.e. pd-settings.reg and org.pure-data.pd.plist).
*That* would be immensely useful, also in workshops.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
On Tue, 20 Dec 2005, Frank Barknecht wrote:
The problem is, that there is no file called "Dokumente" on the machine, the actual file (or folder) is called "Documents". However the Finder - which I thought was a *File* manager, but it seems, it isn't one - showed a folder called "Dokumente", which just doesn't exist!
It just depends on what your expectations from the file manager are. I'm happy with such a scheme as long as it's easy for me to find what the untranslated name is.
That's one thing, that's better on MS-Windows, where "My Documents" on a english machine actually is a folder "Meine Dateien" on a german windows box. Of course the unixish '~' is even better and solves all language problems. ;)
The latter is not a joke. Expecting the directory "C:\Program Files" to exist on Windows is a common mistake. A database of untranslated names to translated names is required. On OSX, programs don't have to make the translations themselves, because the translations are made only in the user interface.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi all, i'm sorry i haven't really followed the thread entirely, but it should be clear that noone should rely on "c:\program files" or "meine dokumente". There are env variables for that, called ProgramFiles, USERPROFILE and others, so there's hardly any difference to ~.
greetings, Thomas
Mathieu Bouchard schrieb:
On Tue, 20 Dec 2005, Frank Barknecht wrote:
The problem is, that there is no file called "Dokumente" on the machine, the actual file (or folder) is called "Documents". However the Finder - which I thought was a *File* manager, but it seems, it isn't one - showed a folder called "Dokumente", which just doesn't exist!
It just depends on what your expectations from the file manager are. I'm happy with such a scheme as long as it's easy for me to find what the untranslated name is.
That's one thing, that's better on MS-Windows, where "My Documents" on a english machine actually is a folder "Meine Dateien" on a german windows box. Of course the unixish '~' is even better and solves all language problems. ;)
The latter is not a joke. Expecting the directory "C:\Program Files" to exist on Windows is a common mistake. A database of untranslated names to translated names is required. On OSX, programs don't have to make the translations themselves, because the translations are made only in the user interface.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Yeah, we need to figure out how to support env vars in the preferences system so that we can distribute a set of default settings that will work on any computer.
.hc
On Dec 23, 2005, at 4:43 PM, Thomas Grill wrote:
Hi all, i'm sorry i haven't really followed the thread entirely, but it should be clear that noone should rely on "c:\program files" or "meine dokumente". There are env variables for that, called ProgramFiles, USERPROFILE and others, so there's hardly any difference to ~.
greetings, Thomas
Mathieu Bouchard schrieb:
On Tue, 20 Dec 2005, Frank Barknecht wrote:
The problem is, that there is no file called "Dokumente" on the machine, the actual file (or folder) is called "Documents". However the Finder - which I thought was a *File* manager, but it seems, it isn't one - showed a folder called "Dokumente", which just doesn't exist!
It just depends on what your expectations from the file manager are. I'm happy with such a scheme as long as it's easy for me to find what the untranslated name is.
That's one thing, that's better on MS-Windows, where "My Documents" on a english machine actually is a folder "Meine Dateien" on a german windows box. Of course the unixish '~' is even better and solves all language problems. ;)
The latter is not a joke. Expecting the directory "C:\Program Files" to exist on Windows is a common mistake. A database of untranslated names to translated names is required. On OSX, programs don't have to make the translations themselves, because the translations are made only in the user interface.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Thomas Grill http://grrrr.org
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
-
c -
cdr -
Christian Klippel -
David Plans Casal -
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle -
Martin Peach -
Mathieu Bouchard -
Miller Puckette -
Thomas Grill