Hey,
Just a thought here, I am currently porting a Max object to Pd and just saw that the setup is called main(). So how about making it possible to just use setup() as the function name?
.hc
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Hans-Christoph Steiner wrote:
Hey,
Just a thought here, I am currently porting a Max object to Pd and just saw that the setup is called main(). So how about making it possible to just use setup() as the function name?
if i/you remember correctly, we have been talking about this at the LAC. miller has some reservations against it which i think are invalid.
afaik, the point against this is that we would have function name clashes. obviously this is not a problem, as it works in max, in ftm4pd (where i chose "ftm_main()" as the setupfunction for _all_ externals) and in most other plugin APIs.
it becomes more problematic if we are dealing with multi-object libraries rather than single-object externals: in this case we get real nameclashes. to solve this one would have to either discard multi-object libraries or inform the preprocessor on whether we want a library or an external.
then i think that "main(void)" is really the worst name they could have thought of, as it clashes with "main(int argc, char**argv)". i would much more prefer a name like "pdsetup(void)"
all this could be resolved very simple by not having to explicitely call a setup-function but by using the automatic function execution at load-time (on gcc this is "__attribute__ ((constructor))", on M$VC there are other ways...) the only drawback i see here is that you don't have control about which function is executed first.
finally, i don't know why this should be embedded into hexloader. hexloader currently does some clever recursive calling of other loaders in order to be able to use it not only for C-externals but also for lua, python,... therefore you would just have to write a "main loader" that calls "main()" (or whatever) for external initialization. once you have loaded both the "main loader" and the "hexloader", Pd will magically call the "main()" function in your "here0x2d0x3ethere.l_i386"
mfga.sdr IOhannes
On May 28, 2008, at 1:28 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Hey, Just a thought here, I am currently porting a Max object to Pd and just saw that the setup is called main(). So how about making it possible to just use setup() as the function name?
if i/you remember correctly, we have been talking about this at the LAC. miller has some reservations against it which i think are invalid.
I only vaguely remember...
afaik, the point against this is that we would have function name clashes. obviously this is not a problem, as it works in max, in ftm4pd (where i chose "ftm_main()" as the setupfunction for _all_ externals) and in most other plugin APIs.
it becomes more problematic if we are dealing with multi-object libraries rather than single-object externals: in this case we get real nameclashes. to solve this one would have to either discard multi-object libraries or inform the preprocessor on whether we want a library or an external.
I think you can guess which one I think is good ;) the multi- objectclass library file format seems to cause a lot more problems than it solves.
then i think that "main(void)" is really the worst name they could have thought of, as it clashes with "main(int argc, char**argv)". i would much more prefer a name like "pdsetup(void)"
I agree, pdsetup() works for me.
all this could be resolved very simple by not having to explicitely call a setup-function but by using the automatic function execution at load-time (on gcc this is "__attribute__ ((constructor))", on M $VC there are other ways...) the only drawback i see here is that you don't have control about which function is executed first.
We could also switch to gcc on Windows, then we wouldn't have to work about M$VC oddness, unless someone really wants to. gcc was been building Pd-extended for years now.
finally, i don't know why this should be embedded into hexloader. hexloader currently does some clever recursive calling of other loaders in order to be able to use it not only for C-externals but also for lua, python,... therefore you would just have to write a "main loader" that calls "main()" (or whatever) for external initialization. once you have loaded both the "main loader" and the "hexloader", Pd will magically call the "main()" function in your "here0x2d0x3ethere.l_i386"
Sure, makes sense to be system-wide. I don't really have a good grasp on the implementation details, how hard would it be to add this to Pd?
.hc
mfga.sdr IOhannes
------------------------------------------------------------------------ ----
kill your television
Hans-Christoph Steiner wrote:
On May 28, 2008, at 1:28 PM, IOhannes m zmoelnig wrote:
I think you can guess which one I think is good ;) the multi- objectclass library file format seems to cause a lot more problems than it solves.
the key is: have your own opinion, but allow a variety of opinions...
We could also switch to gcc on Windows, then we wouldn't have to work about M$VC oddness, unless someone really wants to. gcc was been building Pd-extended for years now.
again, the key is: have your own opinion, but allow a variety of opinions...
why should i not use a commercial compiler if it produces better code, e.g. icc (i don't say that M$VC produces better code)
apart from that, the same thing is also possible with M$VC, you just have to specify it differently. i think it is via _DLL_InitTerm() or the like. the "__attribute__ ((constructor))" is really a gcc extension. it should not be used in platform independent code...
Sure, makes sense to be system-wide. I don't really have a good grasp on the implementation details, how hard would it be to add this to Pd?
within Pd it should be a couple of lines. in an external loader it would be a couple of more lines (as we have to find and open the library again) plus the glue.
nfvasdr IOhannes
IOhannes m zmoelnig wrote:
apart from that, the same thing is also possible with M$VC, you just have to specify it differently. i think it is via _DLL_InitTerm() or the like.
the only problem about it is, that it is so hard to google. i haven't found many references to _DLL_InitTerm() (and some ofthem refer to OS/2). i think the proper way to do it is to use DllMain() http://msdn.microsoft.com/en-us/library/ms682583.aspx
fmgadsr. IOhannes
IOhannes m zmoelnig wrote:
apart from that, the same thing is also possible with M$VC, you just have to specify it differently. i think it is via _DLL_InitTerm() or the like.
the only problem about it is, that it is so hard to google. i haven't found many references to _DLL_InitTerm() (and some ofthem refer to OS/2). i think the proper way to do it is to use DllMain() http://msdn.microsoft.com/en-us/library/ms682583.aspx
Are you sure it's not GetProcAddress() that you want? s_loader.c line 262 uses it...
http://msdn.microsoft.com/en-us/library/ms683212.aspx
Martin
Martin Peach wrote:
i think the proper way to do it is to use DllMain() http://msdn.microsoft.com/en-us/library/ms682583.aspx
Are you sure it's not GetProcAddress() that you want? s_loader.c line 262 uses it...
yes i am sure. the idea was to not call a however named function by Pd but let the dyloader do it for you.
i implemented something like this in ftm4pd, where the library constructor will register a new loader that then loads the external (though i am currently wondering why i did not just registered the class...)
fgmasdr IOhannes
On May 28, 2008, at 5:13 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On May 28, 2008, at 1:28 PM, IOhannes m zmoelnig wrote: I think you can guess which one I think is good ;) the multi- objectclass library file format seems to cause a lot more problems than it solves.
the key is: have your own opinion, but allow a variety of opinions...
We could also switch to gcc on Windows, then we wouldn't have to work about M$VC oddness, unless someone really wants to. gcc was been building Pd-extended for years now.
again, the key is: have your own opinion, but allow a variety of opinions...
why should i not use a commercial compiler if it produces better code, e.g. icc (i don't say that M$VC produces better code)
apart from that, the same thing is also possible with M$VC, you just have to specify it differently. i think it is via _DLL_InitTerm () or the like. the "__attribute__ ((constructor))" is really a gcc extension. it should not be used in platform independent code...
I am not saying that people shouldn't do it. I am saying those of us who use gcc should not feel compelled to support everyone else's options. If someone wants to maintain M$VC, I won't stop them. I am just saying, we can easily use only gcc.
Same goes for the library formats. I don't use multi-class libraries, I think they cause a lot of problems, and add a lot of unneeded complexity. But I've never stopped anyone else from using them.
.hc
Sure, makes sense to be system-wide. I don't really have a good grasp on the implementation details, how hard would it be to add this to Pd?
within Pd it should be a couple of lines. in an external loader it would be a couple of more lines (as we have to find and open the library again) plus the glue.
nfvasdr IOhannes
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic