This is great. I am assuming that you are using the new loader
functionality from Thomas. Would it be possible if you could put up
some notes about what you did? It'll help others like me write other
loaders.
.hc
On Jan 17, 2006, at 11:07 AM, Davide Morelli wrote:
hello!
[clr] is an external that lets you create externals using clr
languages (C#, vb.net, ruby.net, dotLisp, etc..), it embeds mono.you can find it in /externals/clr
At the moment it can only receive and send bangs, floats, symbols and
lists. ASAP I'll add support for pointers, signals and Gem. Also many
important functions are not present (things like timer callbacks
etc..)I've tested it on winXp and osx 10.3 but i'm pretty sure it will work
on linux too. I need help writing makefiles, defining dependancies and testing. I will soon build binary packages. It is possible to build binary packages including mono and all the GAC
so the "end-user" won't need to install mono to use [clr] and the
externals needing itrequirements:
- mono installed
- glib, gthread, iconv in path (they should be inside mono as well)
what you need to do to compile it:
- edit PATHs in the makefile so the compiler can find mono, glib,
gthread, etc...
to write an external you need to:
- in the pd folder compile pd.cs and Atom.cs into PureData.dll
- use the PureData namespace
- add PureData.dll to the references
- declare an "private intPtr x" variable
- declare a "void SetUp()" function and put there inlet, outlet and
selectors creation (see the external folder for a couple of examples)
features:
- you can write externals in any clr language (C#, managed C++, J#,
Jscript.Net, PerlNET, Ruby, Scheme, VB.NET, dotLisp and a lot more.. )
- use bangs, symbols, lists (both in and out)
- declare inlets, outlets, selectors
- use initialization arguments
- multi-instance
- compile many externals into one single .dll file
- extend an external including its assembly instead of modifying its
source code
- you can compile the external using whichever clr compiler you like
most
- assemblies are "cross-platform" (a single .dll file for all
platforms)
what is missing:
- support for signals, Gem, graphical externals
- many callback functions like timers etc..
- there may be threading issues
- testing, testing, testing!
detailed implementation notes, (future) binary pakages here: http://www.davidemorelli.it/dokuwiki/doku.php?id=csharp:csharp
PS. many thanks to Thomas Grill for his help!
Ciao, Davide Morelli www.davidemorelli.it
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
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
well, not yet.. I mean i've asked Thomas how to use it and he kindly explained me but I haven't had time yet to write that code.. I'd surely need more info from him.. and a bit of time to recompile pd with his patch, read the source code, understand how it works and modify my external.. this way sounds complicated but that is not tru, should be simple
...maybe the better thing would be that he modify clr directly on CVS?
or write a very very simple how-to?
davide.
-----Messaggio originale----- Da: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Per conto di Hans-Christoph Steiner Inviato: martedì 17 gennaio 2006 20.57 A: pd-list@iem.kug.ac.at Oggetto: [PD] Re: [PD-announce] clr: externals in CLR assemblies
This is great. I am assuming that you are using the new loader functionality from Thomas. Would it be possible if you could put up some notes about what you did? It'll help others like me write other loaders.
.hc
On Jan 17, 2006, at 11:07 AM, Davide Morelli wrote:
hello!
[clr] is an external that lets you create externals using clr languages (C#, vb.net, ruby.net, dotLisp, etc..), it embeds mono.
you can find it in /externals/clr
At the moment it can only receive and send bangs, floats,
symbols and
lists. ASAP I'll add support for pointers, signals and Gem.
Also many
important functions are not present (things like timer callbacks etc..)
I've tested it on winXp and osx 10.3 but i'm pretty sure it
will work
on linux too. I need help writing makefiles, defining dependancies and testing. I will soon build binary packages. It is possible to build binary packages including mono and
all the GAC
so the "end-user" won't need to install mono to use [clr] and the externals needing it
requirements:
- mono installed
- glib, gthread, iconv in path (they should be inside mono as well)
what you need to do to compile it:
- edit PATHs in the makefile so the compiler can find mono, glib,
gthread, etc...
to write an external you need to:
- in the pd folder compile pd.cs and Atom.cs into PureData.dll
- use the PureData namespace
- add PureData.dll to the references
- declare an "private intPtr x" variable
- declare a "void SetUp()" function and put there inlet,
outlet and
selectors creation (see the external folder for a couple of
examples)
features:
- you can write externals in any clr language (C#, managed
C++, J#,
Jscript.Net, PerlNET, Ruby, Scheme, VB.NET, dotLisp and a
lot more.. )
- use bangs, symbols, lists (both in and out)
- declare inlets, outlets, selectors
- use initialization arguments
- multi-instance
- compile many externals into one single .dll file
- extend an external including its assembly instead of
modifying its
source code
- you can compile the external using whichever clr
compiler you like
most
- assemblies are "cross-platform" (a single .dll file for all
platforms)
what is missing:
- support for signals, Gem, graphical externals
- many callback functions like timers etc..
- there may be threading issues
- testing, testing, testing!
detailed implementation notes, (future) binary pakages here: http://www.davidemorelli.it/dokuwiki/doku.php?id=csharp:csharp
PS. many thanks to Thomas Grill for his help!
Ciao, Davide Morelli www.davidemorelli.it
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.
-William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thomas' loader patch is now part of pd in CVS. It'll be in Pd 0.40.
Or you can compile it now from CVS.
.hc
On Jan 17, 2006, at 5:20 PM, Davide Morelli wrote:
well, not yet.. I mean i've asked Thomas how to use it and he kindly explained me but I haven't had time yet to write that code.. I'd surely need more info from him.. and a bit of time to recompile pd
with his patch, read the source code, understand how it works and modify my external.. this way sounds complicated but that is not tru, should be simple...maybe the better thing would be that he modify clr directly on CVS?
or write a very very simple how-to?
davide.
-----Messaggio originale----- Da: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Per conto di Hans-Christoph Steiner Inviato: martedì 17 gennaio 2006 20.57 A: pd-list@iem.kug.ac.at Oggetto: [PD] Re: [PD-announce] clr: externals in CLR assemblies
This is great. I am assuming that you are using the new loader functionality from Thomas. Would it be possible if you could put up some notes about what you did? It'll help others like me write other loaders.
.hc
On Jan 17, 2006, at 11:07 AM, Davide Morelli wrote:
hello!
[clr] is an external that lets you create externals using clr languages (C#, vb.net, ruby.net, dotLisp, etc..), it embeds mono.
you can find it in /externals/clr
At the moment it can only receive and send bangs, floats,
symbols and
lists. ASAP I'll add support for pointers, signals and Gem.
Also many
important functions are not present (things like timer callbacks etc..)
I've tested it on winXp and osx 10.3 but i'm pretty sure it
will work
on linux too. I need help writing makefiles, defining dependancies and testing. I will soon build binary packages. It is possible to build binary packages including mono and
all the GAC
so the "end-user" won't need to install mono to use [clr] and the externals needing it
requirements:
- mono installed
- glib, gthread, iconv in path (they should be inside mono as well)
what you need to do to compile it:
- edit PATHs in the makefile so the compiler can find mono, glib,
gthread, etc...
to write an external you need to:
- in the pd folder compile pd.cs and Atom.cs into PureData.dll
- use the PureData namespace
- add PureData.dll to the references
- declare an "private intPtr x" variable
- declare a "void SetUp()" function and put there inlet,
outlet and
selectors creation (see the external folder for a couple of
examples)
features:
- you can write externals in any clr language (C#, managed
C++, J#,
Jscript.Net, PerlNET, Ruby, Scheme, VB.NET, dotLisp and a
lot more.. )
- use bangs, symbols, lists (both in and out)
- declare inlets, outlets, selectors
- use initialization arguments
- multi-instance
- compile many externals into one single .dll file
- extend an external including its assembly instead of
modifying its
source code
- you can compile the external using whichever clr
compiler you like
most
- assemblies are "cross-platform" (a single .dll file for all
platforms)
what is missing:
- support for signals, Gem, graphical externals
- many callback functions like timers etc..
- there may be threading issues
- testing, testing, testing!
detailed implementation notes, (future) binary pakages here: http://www.davidemorelli.it/dokuwiki/doku.php?id=csharp:csharp
PS. many thanks to Thomas Grill for his help!
Ciao, Davide Morelli www.davidemorelli.it
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
Hi all, i was busy with live recordings for the last couple of days. (looking forward to a fantastic Low Frequency Orchestra CD!!) When things have calmed down a bit i'll gladly try to implement the loader functionality for the clr external. Great work Davide!
best greetings, Thomas
Am 17.01.2006 um 23:20 schrieb Davide Morelli:
well, not yet.. I mean i've asked Thomas how to use it and he kindly explained me but I haven't had time yet to write that code.. I'd surely need more info from him.. and a bit of time to recompile pd with his patch, read the source code, understand how it works and modify my external.. this way sounds complicated but that is not tru, should be simple
...maybe the better thing would be that he modify clr directly on CVS?
or write a very very simple how-to?
davide.
-----Messaggio originale----- Da: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Per conto di Hans-Christoph Steiner Inviato: martedì 17 gennaio 2006 20.57 A: pd-list@iem.kug.ac.at Oggetto: [PD] Re: [PD-announce] clr: externals in CLR assemblies
This is great. I am assuming that you are using the new loader functionality from Thomas. Would it be possible if you could put up some notes about what you did? It'll help others like me write other loaders.
.hc
On Jan 17, 2006, at 11:07 AM, Davide Morelli wrote:
hello!
[clr] is an external that lets you create externals using clr languages (C#, vb.net, ruby.net, dotLisp, etc..), it embeds mono.
you can find it in /externals/clr
At the moment it can only receive and send bangs, floats,
symbols and
lists. ASAP I'll add support for pointers, signals and Gem.
Also many
important functions are not present (things like timer callbacks etc..)
I've tested it on winXp and osx 10.3 but i'm pretty sure it
will work
on linux too. I need help writing makefiles, defining dependancies and testing. I will soon build binary packages. It is possible to build binary packages including mono and
all the GAC
so the "end-user" won't need to install mono to use [clr] and the externals needing it
requirements:
- mono installed
- glib, gthread, iconv in path (they should be inside mono as well)
what you need to do to compile it:
- edit PATHs in the makefile so the compiler can find mono, glib,
gthread, etc...
to write an external you need to:
- in the pd folder compile pd.cs and Atom.cs into PureData.dll
- use the PureData namespace
- add PureData.dll to the references
- declare an "private intPtr x" variable
- declare a "void SetUp()" function and put there inlet,
outlet and
selectors creation (see the external folder for a couple of
examples)
features:
- you can write externals in any clr language (C#, managed
C++, J#,
Jscript.Net, PerlNET, Ruby, Scheme, VB.NET, dotLisp and a
lot more.. )
- use bangs, symbols, lists (both in and out)
- declare inlets, outlets, selectors
- use initialization arguments
- multi-instance
- compile many externals into one single .dll file
- extend an external including its assembly instead of
modifying its
source code
- you can compile the external using whichever clr
compiler you like
most
- assemblies are "cross-platform" (a single .dll file for all
platforms)
what is missing:
- support for signals, Gem, graphical externals
- many callback functions like timers etc..
- there may be threading issues
- testing, testing, testing!
detailed implementation notes, (future) binary pakages here: http://www.davidemorelli.it/dokuwiki/doku.php?id=csharp:csharp
PS. many thanks to Thomas Grill for his help!
Ciao, Davide Morelli www.davidemorelli.it
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Davide, i'm starting to work with the clr external. Running the clr on OSX crashes PD for now, i'm trying to find the reason a bit later. Concerning the cvs, it would be great if you could also add the source for the PureData.dll which is now a kind of black box.
A thought a bit about the naming of functions for the Pd domain and also the external classes. I find it a bit too verbose. Are you sure that it's necessary to call it "DelegateWithoutArguments" or "PostMessage" when the functions are in their own namespace? It's really my personal taste, but i would prefer sticking closer to the naming of the original PD API functions (and i admit i don't like typing that much...) What i'm also wondering about is the mixture of class and objects initialization in SetUp (wouldn't Main be a better choice, since that's already reserved in C#?). In the example externals, you are setting up both selectors (which is bound to the class) and inlets/outlets (which must be done during object construction). I guess SetUp/Main() should be static, so that it can be called on class initialization (e.g. in the loader) independently from an object instance, and then, the object initialization (like AddInlet etc.) should be done in the object constructor.
I don't completely understand the usage of namespaces in the CLI, but is it really necessary to put the client externals into the PureData namespace? It's also a bit misleading that the Pd functions are in the Pd class, but a PureData.dll is needed for using them.
I'm really looking forward to working with the clr external!
best greetings, Thomas
Am 17.01.2006 um 23:20 schrieb Davide Morelli:
well, not yet.. I mean i've asked Thomas how to use it and he kindly explained me but I haven't had time yet to write that code.. I'd surely need more info from him.. and a bit of time to recompile pd with his patch, read the source code, understand how it works and modify my external.. this way sounds complicated but that is not tru, should be simple
...maybe the better thing would be that he modify clr directly on CVS?
or write a very very simple how-to?
davide.
-----Messaggio originale----- Da: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Per conto di Hans-Christoph Steiner Inviato: martedì 17 gennaio 2006 20.57 A: pd-list@iem.kug.ac.at Oggetto: [PD] Re: [PD-announce] clr: externals in CLR assemblies
This is great. I am assuming that you are using the new loader functionality from Thomas. Would it be possible if you could put up some notes about what you did? It'll help others like me write other loaders.
.hc
On Jan 17, 2006, at 11:07 AM, Davide Morelli wrote:
hello!
[clr] is an external that lets you create externals using clr languages (C#, vb.net, ruby.net, dotLisp, etc..), it embeds mono.
you can find it in /externals/clr
At the moment it can only receive and send bangs, floats,
symbols and
lists. ASAP I'll add support for pointers, signals and Gem.
Also many
important functions are not present (things like timer callbacks etc..)
I've tested it on winXp and osx 10.3 but i'm pretty sure it
will work
on linux too. I need help writing makefiles, defining dependancies and testing. I will soon build binary packages. It is possible to build binary packages including mono and
all the GAC
so the "end-user" won't need to install mono to use [clr] and the externals needing it
requirements:
- mono installed
- glib, gthread, iconv in path (they should be inside mono as well)
what you need to do to compile it:
- edit PATHs in the makefile so the compiler can find mono, glib,
gthread, etc...
to write an external you need to:
- in the pd folder compile pd.cs and Atom.cs into PureData.dll
- use the PureData namespace
- add PureData.dll to the references
- declare an "private intPtr x" variable
- declare a "void SetUp()" function and put there inlet,
outlet and
selectors creation (see the external folder for a couple of
examples)
features:
- you can write externals in any clr language (C#, managed
C++, J#,
Jscript.Net, PerlNET, Ruby, Scheme, VB.NET, dotLisp and a
lot more.. )
- use bangs, symbols, lists (both in and out)
- declare inlets, outlets, selectors
- use initialization arguments
- multi-instance
- compile many externals into one single .dll file
- extend an external including its assembly instead of
modifying its
source code
- you can compile the external using whichever clr
compiler you like
most
- assemblies are "cross-platform" (a single .dll file for all
platforms)
what is missing:
- support for signals, Gem, graphical externals
- many callback functions like timers etc..
- there may be threading issues
- testing, testing, testing!
detailed implementation notes, (future) binary pakages here: http://www.davidemorelli.it/dokuwiki/doku.php?id=csharp:csharp
PS. many thanks to Thomas Grill for his help!
Ciao, Davide Morelli www.davidemorelli.it
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Thomas!
Hi Davide, i'm starting to work with the clr external. Running the clr on OSX crashes PD for now, i'm trying to find the reason a bit later.
pland also reports this.. at work i have a G4 with osx 10.3 installed and the external performs well, no crashes no latency no startup time (as in winXP) etc...
Concerning the cvs, it would be great if you could also add the source for the PureData.dll which is now a kind of black box.
PureData.dll sources are in the pd folder.. maybe we should rename this folder to PureData so it would be more intuitive? that is here: http://cvs.sourceforge.net/viewcvs.py/pure-data/externals/clr/pd/
A thought a bit about the naming of functions for the Pd domain and also the external classes. I find it a bit too verbose. Are you sure that it's necessary to call it "DelegateWithoutArguments" or "PostMessage" when the functions are in their own namespace? It's really my personal taste, but i would prefer sticking closer to the naming of the original PD API functions (and i admit i don't like typing that much...)
yeah, me too, i was misleaded by visual studio auto-completition feature (I just need to write "pd." and I get all available functions...
I gave verbose names thinking that this maybe the clr external will be usefull to not experienced developers.. that was my first time using delegates and I guess fiew developers know them.. also i thought that maybe this external could help how is not comfortable with writing C externals so giving a more "user friendly" interface could be good..
but that is just my personal point of view, that is something I am happy to change if you think is better..
What i'm also wondering about is the
mixture of class and objects initialization in SetUp (wouldn't Main be a better choice, since that's already reserved in C#?). In the example externals, you are setting up both selectors (which is bound to the class) and inlets/outlets (which must be done during object construction). I guess SetUp/Main() should be static, so that it can be called on class initialization (e.g. in the loader) independently from an object instance, and then, the object initialization (like AddInlet etc.) should be done in the object constructor.
Ok, I must admit that in my mind wasn't clear enough the external.setup() vs external.new() distinction.. now it is becoming a bit more clear, but i must admin, not enough...
anyway the SetUp() name could lead to misunderstanding: the clr external doesn't really register those selectors! actually it registers only 4 methods:
- one for bangs
- one for floats
- one for symbols
- one for lists
when you call AddSelector the clr instance simply stores that string in an array together with a MonoMethod (which will be called when this selector is the first atom of an incoming list). So the selectors registration is not performed at class initialization but at object initialization.
really it may be better to use just another name than SetUp.. maybe just the C# class constructor?
I don't completely understand the usage of namespaces in the CLI, but is it really necessary to put the client externals into the PureData namespace?
.. now that i think better.. i don't think is necessary for externals to be in the PureData namespace
It's also a bit misleading that
the Pd functions are in the Pd class, but a PureData.dll is needed for using them.
yes, that's weird, but i didn't find a way to have functions outside a class, so I was forced to create a static class for them.
I'm really looking forward to working with the clr external!
hey, let's rock!
best greetings, Thomas
Am 17.01.2006 um 23:20 schrieb Davide Morelli:
well, not yet.. I mean i've asked Thomas how to use it and he kindly
explained me but
I haven't had time yet to write that code.. I'd surely need more info from him.. and a bit of time to
recompile pd
with his patch, read the source code, understand how it works and modify my external.. this way sounds complicated but that is not tru, should be simple
...maybe the better thing would be that he modify clr
directly on CVS?
or write a very very simple how-to?
davide.
-----Messaggio originale----- Da: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at]
Per conto
di Hans-Christoph Steiner Inviato: martedì 17 gennaio 2006 20.57 A: pd-list@iem.kug.ac.at Oggetto: [PD] Re: [PD-announce] clr: externals in CLR assemblies
This is great. I am assuming that you are using the new loader functionality from Thomas. Would it be possible if you
could put up
some notes about what you did? It'll help others like me
write other
loaders.
.hc
On Jan 17, 2006, at 11:07 AM, Davide Morelli wrote:
hello!
[clr] is an external that lets you create externals using clr languages (C#, vb.net, ruby.net, dotLisp, etc..), it embeds mono.
you can find it in /externals/clr
At the moment it can only receive and send bangs, floats,
symbols and
lists. ASAP I'll add support for pointers, signals and Gem.
Also many
important functions are not present (things like timer callbacks etc..)
I've tested it on winXp and osx 10.3 but i'm pretty sure it
will work
on linux too. I need help writing makefiles, defining dependancies and testing. I will soon build binary packages. It is possible to build binary packages including mono and
all the GAC
so the "end-user" won't need to install mono to use [clr] and the externals needing it
requirements:
- mono installed
- glib, gthread, iconv in path (they should be inside
mono as well)
what you need to do to compile it:
- edit PATHs in the makefile so the compiler can find
mono, glib,
gthread, etc...
to write an external you need to:
- in the pd folder compile pd.cs and Atom.cs into PureData.dll
- use the PureData namespace
- add PureData.dll to the references
- declare an "private intPtr x" variable
- declare a "void SetUp()" function and put there inlet,
outlet and
selectors creation (see the external folder for a couple of
examples)
features:
- you can write externals in any clr language (C#, managed
C++, J#,
Jscript.Net, PerlNET, Ruby, Scheme, VB.NET, dotLisp and a
lot more.. )
- use bangs, symbols, lists (both in and out)
- declare inlets, outlets, selectors
- use initialization arguments
- multi-instance
- compile many externals into one single .dll file
- extend an external including its assembly instead of
modifying its
source code
- you can compile the external using whichever clr
compiler you like
most
- assemblies are "cross-platform" (a single .dll file for all
platforms)
what is missing:
- support for signals, Gem, graphical externals
- many callback functions like timers etc..
- there may be threading issues
- testing, testing, testing!
detailed implementation notes, (future) binary pakages here: http://www.davidemorelli.it/dokuwiki/doku.php?id=csharp:csharp
PS. many thanks to Thomas Grill for his help!
Ciao, Davide Morelli www.davidemorelli.it
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Man has survived hitherto because he was too ignorant to
know how to
realize his wishes. Now that he can realize them, he must either change them,
or perish.
-William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 19 Jan 2006, Thomas Grill wrote:
A thought a bit about the naming of functions for the Pd domain and also the external classes. I find it a bit too verbose. Are you sure that it's necessary to call it "DelegateWithoutArguments" or "PostMessage" when the functions are in their own namespace? It's really my personal taste, but i would prefer sticking closer to the naming of the original PD API functions (and i admit i don't like typing that much...)
What's disturbing about PostMessage() is that, if I guess what it does, it doesn't post what is normally called a Message in Pd, and that may be confusing to people learning the API. Sometimes less is more and thus I think post() is better.
What i'm also wondering about is the mixture of class and objects initialization in SetUp (wouldn't Main be a better choice, since that's already reserved in C#?).
If following C# conventions has any practical advantage, then C# conventions should be followed. For anything else, it should be as close as possible to Pd's C API. Bonus points if there is a way to guess the C# API from knowing the C API or the Flext API.
BTW, anyone looked at SWIG ? It could provide a multilanguage interface to Pd's API and/or Flext's API. SWIG generates wrappers from C++ code to Python, Ruby, Perl, Java, C#, Tcl, PHP, Lua, and several kinds of LISP (Guile, AllegroCL, CMUCL, ...).
SWIG might be the key to unifying the Pd API in various programming languages (currently, PyExt, GridFlow, k_guile, all do things quite differently from each other). Note that I don't want a "common denominator" API which would prevent from using any special features of a given language in the Pd API for that language. Nevertheless I would like language-specific APIs to be easy to guess (deduce) so that it's easy to start writing externals in language X for someone who has general experience in language X and experience in writing Pd externals in language Y.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi all,
BTW, anyone looked at SWIG ? It could provide a multilanguage interface to Pd's API and/or Flext's API. SWIG generates wrappers from C++ code to Python, Ruby, Perl, Java, C#, Tcl, PHP, Lua, and several kinds of LISP (Guile, AllegroCL, CMUCL, ...).
i tried to use SWIG with Python, but the wrappers which should be independent from the actual targetted language quickly became cluttered with language stubs, especially with API functions using callbacks and such, which i felt very unconfident about. Consequenty I switched to Python-specific C++-wrappers (PyCXX) that i found much more usable. Concerning CLR i would prefer a well-designed PD-API interface specific for CLR (which then includes a number of target languages) over a compromise using SWIG. On the other hand, it might well be that SWIG has developed in the meantime, providing all the things needed for a language-independent wrapper definition.
greetings, Thomas
On Fri, 20 Jan 2006, Thomas Grill wrote:
i tried to use SWIG with Python, but the wrappers which should be independent from the actual targetted language quickly became cluttered with language stubs, especially with API functions using callbacks and such, which i felt very unconfident about.
Why was it so?
When was that?
On the other hand, it might well be that SWIG has developed in the meantime, providing all the things needed for a language-independent wrapper definition.
I don't know which SWIG you've tried, but I subscribed to the SWIG mailing-lists one month ago and those guys are very active.
I suspect that, if you have feature requests for SWIG, they would get implemented rather quickly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Here is a list of what I'd like to change in [clr]:
- rename PostMessage() to post()
- rename ErrorMessage() to error()
- wipe out the SetUp() function: initialization (selectors, inlets, outlets)
will be done in the class constructor
about the last point: I know that in "real" externals selectors declaration is done in setup() and inlet/outlet creation in new() but here we only have what corresponds to new(), I mean we can't register methods before actually initializing the object. So I think the best thing to do is what Mathieu calls "following C# conventions" and use the class constructor: this is what C# developers are used to.
But, Thomas, feel free to change anything needed to make it work with your loader patch (hadn't tried it yet..)
ciao, davide
----- Original Message ----- From: "Mathieu Bouchard" matju@artengine.ca To: "Thomas Grill" gr@grrrr.org Cc: pd-list@iem.kug.ac.at; "'Hans-Christoph Steiner'" hans@eds.org; "Davide Morelli" info@davidemorelli.it Sent: Friday, January 20, 2006 11:32 AM Subject: Re: R: [PD] Re: [PD-announce] clr: externals in CLR assemblies
On Thu, 19 Jan 2006, Thomas Grill wrote:
A thought a bit about the naming of functions for the Pd domain and also the external classes. I find it a bit too verbose. Are you sure that it's necessary to call it "DelegateWithoutArguments" or "PostMessage" when the functions are in their own namespace? It's really my personal taste, but i would prefer sticking closer to the naming of the original PD API functions (and i admit i don't like typing that much...)
What's disturbing about PostMessage() is that, if I guess what it does, it doesn't post what is normally called a Message in Pd, and that may be confusing to people learning the API. Sometimes less is more and thus I think post() is better.
What i'm also wondering about is the mixture of class and objects initialization in SetUp (wouldn't Main be a better choice, since that's already reserved in C#?).
If following C# conventions has any practical advantage, then C# conventions should be followed. For anything else, it should be as close as possible to Pd's C API. Bonus points if there is a way to guess the C# API from knowing the C API or the Flext API.
BTW, anyone looked at SWIG ? It could provide a multilanguage interface to Pd's API and/or Flext's API. SWIG generates wrappers from C++ code to Python, Ruby, Perl, Java, C#, Tcl, PHP, Lua, and several kinds of LISP (Guile, AllegroCL, CMUCL, ...).
SWIG might be the key to unifying the Pd API in various programming languages (currently, PyExt, GridFlow, k_guile, all do things quite differently from each other). Note that I don't want a "common denominator" API which would prevent from using any special features of a given language in the Pd API for that language. Nevertheless I would like language-specific APIs to be easy to guess (deduce) so that it's easy to start writing externals in language X for someone who has general experience in language X and experience in writing Pd externals in language Y.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Davide,
- wipe out the SetUp() function: initialization (selectors, inlets,
outlets) will be done in the class constructor
about the last point: I know that in "real" externals selectors declaration is done in setup() and inlet/outlet creation in new() but here we only have what corresponds to new(), I mean we can't register methods before actually initializing the object. So I think the best thing to do is what Mathieu calls "following C# conventions" and use the class constructor: this is what C# developers are used to.
that's not completely correct: the PD-like style would be to register the class (that's the actual CLR assembly) when loading it the first time. There, a static Main function could be called registering the methods. When creating the CLR object, the constructor is called, registering inlets and outlets. This has the advantage that the objects would be more lightweight (method table is needed only once per class, not per instance) and that loading is faster.
But, Thomas, feel free to change anything needed to make it work with your loader patch (hadn't tried it yet..)
I've just created an xcode project where i'll track down the crashes and restructure the code. I'll propose the changes to you before comitting them.
best greetings, Thomas
Hi Thomas,
that's not completely correct: the PD-like style would be to register the class (that's the actual CLR assembly) when loading it the first time. There, a static Main function could be called registering the methods. When creating the CLR object, the constructor is called, registering inlets and outlets. This has the advantage that the objects would be more lightweight (method table is needed only once per class, not per instance) and that loading is faster.
well, for that I'd use the pd-equivalent class_setup().. (that's waht external developers are used to..) ..then a setup() function for selectors and class constructor for inlet/outlets ?
WDYT ?
I've just created an xcode project where i'll track down the crashes and restructure the code. I'll propose the changes to you before comitting them.
btw, we really don't know why but with plans we noticed that in osx clr will crash if compiled against a packaged version of mono, if you install mono using fink it won't crash!
i mean the same code works well on :
- winxp
- osx with mono from fink
crash on :
- osx with mono from package
so i guess you won't find the solution in the code but maybe in the linking chain..
ciao, Davide.
Hi Davide,
When creating the CLR object, the constructor is called, registering inlets and outlets. This has the advantage that the objects would be more lightweight (method table is needed only once per class, not per instance) and that loading is faster.
well, for that I'd use the pd-equivalent class_setup().. (that's waht external developers are used to..) ..then a setup() function for selectors and class constructor for inlet/outlets ?
WDYT ?
as proposed earlier i would use static Main, because that's the one normally used in C# app setup. I'm currently wrapping my proposals into code...
I've just created an xcode project where i'll track down the crashes and restructure the code. I'll propose the changes to you before comitting them.
btw, we really don't know why but with plans we noticed that in osx clr will crash if compiled against a packaged version of mono, if you install mono using fink it won't crash!
I'm experiencing crashes right at the start when i call the mono_jit_init function (from the Mono framework, not fink). There's not much one can do about it - other than trying the latest Mono version, which i'm downloading just now.
greetings, Thomas
On Fri, 20 Jan 2006, Thomas Grill wrote:
that's not completely correct: the PD-like style would be to register the class (that's the actual CLR assembly) when loading it the first time. There, a static Main function could be called registering the methods. When creating the CLR object, the constructor is called, registering inlets and outlets. This has the advantage that the objects would be more lightweight (method table is needed only once per class, not per instance) and that loading is faster.
Wait. Does Davide mean the thing that constructs the objects or the thing that constructs the class itself? I seem to recall that in Java the latter would be called "static initializers" and would be written like "static{ blah };", right? What's the CLR-equivalent of that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Am 20.01.2006 um 20:33 schrieb Mathieu Bouchard:
On Fri, 20 Jan 2006, Thomas Grill wrote:
that's not completely correct: the PD-like style would be to register the class (that's the actual CLR assembly) when loading it the first time. There, a static Main function could be called registering the methods. When creating the CLR object, the constructor is called, registering inlets and outlets. This has the advantage that the objects would be more lightweight (method table is needed only once per class, not per instance) and that loading is faster.
Wait. Does Davide mean the thing that constructs the objects or the thing that constructs the class itself? I seem to recall that in Java the latter would be called "static initializers" and would be written like "static{ blah };", right? What's the CLR-equivalent of that?
don't know what a static initializer is like, but in C# it's like in C++. There are static functions that belong to a class, so that there is no instance pointer. A reserved one is Main which is normally used to bootstrap application classes.
gr~~~
What I mean is: AFAIK we can't know which selectors the Assembly will register before actually initializing the [clr] external: from its argument we'll know which Assembly the user wants to use.. and to have args we must wait the class_new() function.
..but I think Thomas' loader patch changes those rules and the clr might be able to know which Assemblies the user wants to load at class_setup() time instead of class_new() time...
about SWIG: I've tried to use it to translate the t_atom to a C# data structure but I got a lot of source files, I simply couldn't read them.. Maybe because t_atom isn't that simple and uses other struct and pointers to other struct and so on.. I simply wrote a simplified atom struct and wrote by hand the corresponding struct in C#. I don't know SWIG but isn't it useful if we'd want to call a C library from C#? we want to do the opposite: call C# from C. we need to access C function only for callbacks, but once we have a C# Assembly loaded in C we can tell the assembly to map a C# function declaration to a C implementation very easily (in mono at least)
Wait. Does Davide mean the thing that constructs the objects or the thing that constructs the class itself? I seem to recall that in Java the latter would be called "static initializers" and would be written like "static{ blah };", right? What's the CLR-equivalent of that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Davide Morelli -
Hans-Christoph Steiner -
Mathieu Bouchard -
Thomas Grill