Hey all,
So for the Pd-0.40.3-extended release, I am planning on trying to make the internals available as a library like any other. I'd like this work to be applicable to pd-vanilla, so I'd like to discuss how to make it happen.
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
One of the things I am planning on doing for the tkwidget library is making it have a shared libtkwidget.so which each of the object classes uses. Then each objectclass will have its own file, but they still will have shared code. If this works out well, I think it could be a model for Pd libraries in general.
.hc
------------------------------------------------------------------------ ----
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Hans-Christoph Steiner wrote:
Hey all,
So for the Pd-0.40.3-extended release, I am planning on trying to make the internals available as a library like any other. I'd like this work to be applicable to pd-vanilla, so I'd like to discuss how to make it happen.
cyclone does something like this (it overrides already registered externals, which - at this point - are not different from internals)
it is basically looking whether the class-name is already registered, and if so, overwrites the class-pointers.
however, for this to work, you need first need to call a function in your overriding new library. therefore you will probably need something like a "library" (instead of single, same-named externals)
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
funnily enough i have always been opposed when requesting that the [list] objects get _proper_ names.
One of the things I am planning on doing for the tkwidget library is making it have a shared libtkwidget.so which each of the object classes uses. Then each objectclass will have its own file, but they still will have shared code. If this works out well, I think it could be a model for Pd libraries in general.
well, i don't see a reason why it should not work well. the biggest problem is probably to find a way where the objects will search for the search-lib (if you don't want to put it into a standard place like /usr/lib/ or /usr/local/lib)
fmasd.r IOhannes
On Nov 10, 2007, at 3:55 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Hey all, So for the Pd-0.40.3-extended release, I am planning on trying to make the internals available as a library like any other. I'd like this work to be applicable to pd-vanilla, so I'd like to discuss how to make it happen.
cyclone does something like this (it overrides already registered externals, which - at this point - are not different from internals)
it is basically looking whether the class-name is already registered, and if so, overwrites the class-pointers.
however, for this to work, you need first need to call a function in your overriding new library. therefore you will probably need something like a "library" (instead of single, same-named externals)
I'd rather not use a special mechanism, especially if it is not already widely used.
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
funnily enough i have always been opposed when requesting that the [list] objects get _proper_ names.
Why? For example, [list append] will happily append a symbol to a float, so the "list" part doesn't seem so accurate. Why not just [append]?
One of the things I am planning on doing for the tkwidget library is making it have a shared libtkwidget.so which each of the object classes uses. Then each objectclass will have its own file, but they still will have shared code. If this works out well, I think it could be a model for Pd libraries in general.
well, i don't see a reason why it should not work well. the biggest problem is probably to find a way where the objects will search for the search-lib (if you don't want to put it into a standard place like /usr/lib/ or /usr/local/lib)
The libtkwidget.so would be included in the libdir to make it a simple package.
.hc
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 3:55 AM, IOhannes m zmoelnig wrote:
cyclone does something like this (it overrides already registered externals, which - at this point - are not different from internals)
it is basically looking whether the class-name is already registered, and if so, overwrites the class-pointers.
however, for this to work, you need first need to call a function in your overriding new library. therefore you will probably need something like a "library" (instead of single, same-named externals)
I'd rather not use a special mechanism, especially if it is not already widely used.
well you asked, i gave you an answer. but then i probably have not read your original email as careful as i have should.
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
funnily enough i have always been opposed when requesting that the [list] objects get _proper_ names.
Why? For example, [list append] will happily append a symbol to a float, so the "list" part doesn't seem so accurate. Why not just [append]?
probably because of [append] already exists?
The libtkwidget.so would be included in the libdir to make it a simple package.
so how do you convince the ldopen to look for the libtkwidget.so in your libdir instead of whatever is configured in /etc/ld.so.conf?
i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package".
i would really be interested in a solution for this.
mf.asdr IOhannes
On Nov 10, 2007, at 11:25 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 3:55 AM, IOhannes m zmoelnig wrote:
cyclone does something like this (it overrides already registered externals, which - at this point - are not different from internals)
it is basically looking whether the class-name is already registered, and if so, overwrites the class-pointers.
however, for this to work, you need first need to call a function in your overriding new library. therefore you will probably need something like a "library" (instead of single, same-named externals)
I'd rather not use a special mechanism, especially if it is not already widely used.
well you asked, i gave you an answer. but then i probably have not read your original email as careful as i have should.
No problem, I am just discussing how I think it should be done.
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
funnily enough i have always been opposed when requesting that the [list] objects get _proper_ names.
Why? For example, [list append] will happily append a symbol to a float, so the "list" part doesn't seem so accurate. Why not just [append]?
probably because of [append] already exists?
Ok, but you can use a different word. Why do these things need a special syntax of a meta object and then another selector?
Also consider [trim]. If [list trim] will trim "symbol" from a symbol message, then it's not doing anything with lists.
The libtkwidget.so would be included in the libdir to make it a simple package.
so how do you convince the ldopen to look for the libtkwidget.so in your libdir instead of whatever is configured in /etc/ld.so.conf?
i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package".
i would really be interested in a solution for this.
Thomas had this working with flext, I don't know the details, it's possible. At the very least, you can have a mechanism like Pd does, opening it's own .so libs (aka .pd_darwin, .pd_linux, etc) without touching ld.conf.
.hc
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Hans-Christoph Steiner schrieb:
The libtkwidget.so would be included in the libdir to make it a simple package.
so how do you convince the ldopen to look for the libtkwidget.so in your libdir instead of whatever is configured in /etc/ld.so.conf?
i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package".
i would really be interested in a solution for this.
Thomas had this working with flext, I don't know the details, it's possible. At the very least, you can have a mechanism like Pd does, opening it's own .so libs (aka .pd_darwin, .pd_linux, etc) without touching ld.conf.
Hi, that must have been purely coincidental because i don't even know what exactly you mean here. I guess i know too little about linux for something that this sound like.
greetings, Thomas
On Nov 10, 2007, at 1:06 PM, Thomas Grill wrote:
Hans-Christoph Steiner schrieb:
The libtkwidget.so would be included in the libdir to make it a simple package.
so how do you convince the ldopen to look for the libtkwidget.so in your libdir instead of whatever is configured in /etc/ ld.so.conf?
i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package".
i would really be interested in a solution for this.
Thomas had this working with flext, I don't know the details, it's possible. At the very least, you can have a mechanism like Pd does, opening it's own .so libs (aka .pd_darwin, .pd_linux, etc) without touching ld.conf.
Hi, that must have been purely coincidental because i don't even know what exactly you mean here. I guess i know too little about linux for something that this sound like.
In the Mac OS X build at least, you had a libflext.dylib (or some name like that) that was loaded by flext externals when they were loaded.
.hc
------------------------------------------------------------------------ ----
kill your television
Hans-Christoph Steiner wrote:
probably because of [append] already exists?
Ok, but you can use a different word. Why do these things need a special syntax of a meta object and then another selector?
Also consider [trim]. If [list trim] will trim "symbol" from a symbol message, then it's not doing anything with lists.
i think it is the other way round: a symbol _is_ a list (with only 1 element), the destinction between message "symbol bla" and "list bla" was weird in the first place and is now slowly going away.
otoh, this does not contradict you: if everything (that is: everything 'ordinary', not special messages like [set bla("), then we don't necessarily need special objects called [list ...]
nevertheless, i don't know what we are currently discussing: [openpanel] is called [openpanel], [pd] is called [page], and [list trim] is called [list trim].
miller is unlikely to change that anytime soon (though i still would like him to add aliases [list/trim],...).
after all it is a language, and for the most part of it, you just have to learn the vocabulary.
mfsd.r IOhannes
Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 11:25 AM, IOhannes m zmoelnig wrote:
i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package".
i would really be interested in a solution for this.
Thomas had this working with flext, I don't know the details, it's possible. At the very least, you can have a mechanism like Pd does, opening it's own .so libs (aka .pd_darwin, .pd_linux, etc) without touching ld.conf.
no, the latter won't work, because the external depends on functions provided by the libtkwidkget-library. it will therefore refuse to load, unless the dynamic linker is able to resolve the missing names during initialisation.
therefore i don't know how you would insert an explicit loader mechanism (like the .l_i386 thing)
and i thought, libflext.so was installed into /usr/local/lib, no?
fma.sdr IOhannes
On Nov 10, 2007, at 3:14 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 11:25 AM, IOhannes m zmoelnig wrote:
i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package".
i would really be interested in a solution for this.
Thomas had this working with flext, I don't know the details, it's possible. At the very least, you can have a mechanism like Pd does, opening it's own .so libs (aka .pd_darwin, .pd_linux, etc) without touching ld.conf.
no, the latter won't work, because the external depends on functions provided by the libtkwidkget-library. it will therefore refuse to load, unless the dynamic linker is able to resolve the missing names during initialisation.
therefore i don't know how you would insert an explicit loader mechanism (like the .l_i386 thing)
and i thought, libflext.so was installed into /usr/local/lib, no?
Mac OS X and Windows both look in "." for libs to load, AFAIK. I am not sure about GNU/Linux, but I am sure there is a way.
.hc
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Why? For example, [list append] will happily append a symbol to a float, so the "list" part doesn't seem so accurate. Why not just [append]?
probably because of [append] already exists?
Maybe one could take [list]?
Ciao
On Sat, 10 Nov 2007, IOhannes m zmoelnig wrote:
Why? For example, [list append] will happily append a symbol to a float, so the "list" part doesn't seem so accurate. Why not just [append]?
probably because of [append] already exists?
Tcl has "l" letter prefixes for list operations, but it is not consistent about that convention. Tcl has something like Pd's [list] for string operations, e.g. [string compare $a $b]. A third naming system uses C++-style "::" as a namespace delimiter.
The libtkwidget.so would be included in the libdir to make it a simple package.
so how do you convince the ldopen to look for the libtkwidget.so in your libdir instead of whatever is configured in /etc/ld.so.conf? i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package". i would really be interested in a solution for this.
Use environment variable LD_LIBRARY_PATH.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Nov 10, 2007, at 8:34 PM, Mathieu Bouchard wrote:
On Sat, 10 Nov 2007, IOhannes m zmoelnig wrote:
Why? For example, [list append] will happily append a symbol to a float, so the "list" part doesn't seem so accurate. Why not just [append]?
probably because of [append] already exists?
Tcl has "l" letter prefixes for list operations, but it is not consistent about that convention. Tcl has something like Pd's [list] for string operations, e.g. [string compare $a $b]. A third naming system uses C++-style "::" as a namespace delimiter.
The key question remains: what benefit is there to adding special syntax for list functions? Basically everywhere else, only the first element is ever the selector.
.hc
The libtkwidget.so would be included in the libdir to make it a simple package.
so how do you convince the ldopen to look for the libtkwidget.so in your libdir instead of whatever is configured in /etc/ld.so.conf? i guess, adding your libdir path to /etc/ld.so.conf disqualifies it as "a simple package". i would really be interested in a solution for this.
Use environment variable LD_LIBRARY_PATH.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
------------------------------------------------------------------------ ----
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
Hans-Christoph Steiner wrote:
The key question remains: what benefit is there to adding special syntax for list functions? Basically everywhere else, only the first element is ever the selector.
so you basically are complaining why [list trim] is not called [smuddeldop] (or whatever)? meaning, why doe [list ...] objects have a space in their name, unlike every other object with the noteable exception of [zl].
if so, this brings us back to patch-#1544083
mfgsdr. IOhannes
On Sat, 10 Nov 2007, Hans-Christoph Steiner wrote:
Why? For example, [list append] will happily append a symbol to a float, so the "list" part doesn't seem so accurate. Why not just [append]?
both of list's inlets automatically cast a float or symbol or pointer message to a list. this behaviour is pd-wide as the default methods for float and symbol and pointer redirect to the list-method when it exists, or else to the anything-method.
so, i think that the name "list" is accurate, and if you have a 1-element message with either a list or float selector, it is accurate to call it a float message or a list message or both at once. Pd externals are sort of implicitly expected to not make a distinction, but some externals do make a distinction anyway.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
This sounds interesting Hans. The question would be, what is the default/empty behaviour of Pd with no internals at all?
Does it just become a framework for connecting objects (the Pd way)?
I ask because I considered the following recently:
Say I have a small collection of objects made in Faust, corresponding to all the common audio rate Pd objects ([phasor~],[cos~], [osc~], [+~] ....) and I want to compare a patch written in vanilla with its implementation using my Faust objects. How could I override the vanilla internals...? (As you can see this eventually leads to the possibility of a Pd which lets me generate source and compile it for standalone apps or whatever.)
a.
On Fri, 9 Nov 2007 16:50:55 -0500 Hans-Christoph Steiner hans@eds.org wrote:
Hey all,
So for the Pd-0.40.3-extended release, I am planning on trying to make the internals available as a library like any other. I'd like this work to be applicable to pd-vanilla, so I'd like to discuss how to make it happen.
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
One of the things I am planning on doing for the tkwidget library is making it have a shared libtkwidget.so which each of the object classes uses. Then each objectclass will have its own file, but they still will have shared code. If this works out well, I think it could be a model for Pd libraries in general.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Nov 10, 2007, at 7:45 AM, Andy Farnell wrote:
This sounds interesting Hans. The question would be, what is the default/empty behaviour of Pd with no internals at all?
Does it just become a framework for connecting objects (the Pd way)?
Yeah, pretty much. It leads to the question, what are Pd's essential "reserved words"?
.hc
I ask because I considered the following recently:
Say I have a small collection of objects made in Faust, corresponding to all the common audio rate Pd objects ([phasor~],[cos~], [osc~], [+~] ....) and I want to compare a patch written in vanilla with its implementation using my Faust objects. How could I override the vanilla internals...? (As you can see this eventually leads to the possibility of a Pd which lets me generate source and compile it for standalone apps or whatever.)
a.
On Fri, 9 Nov 2007 16:50:55 -0500 Hans-Christoph Steiner hans@eds.org wrote:
Hey all,
So for the Pd-0.40.3-extended release, I am planning on trying to make the internals available as a library like any other. I'd like this work to be applicable to pd-vanilla, so I'd like to discuss how to make it happen.
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
One of the things I am planning on doing for the tkwidget library is making it have a shared libtkwidget.so which each of the object classes uses. Then each objectclass will have its own file, but they still will have shared code. If this works out well, I think it could be a model for Pd libraries in general.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Use the source
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 7:45 AM, Andy Farnell wrote:
This sounds interesting Hans. The question would be, what is the default/empty behaviour of Pd with no internals at all?
Does it just become a framework for connecting objects (the Pd way)?
Yeah, pretty much. It leads to the question, what are Pd's essential "reserved words"?
I consider the objects currently in Pd-core the essential ones, if alone for practical reasons. But also technically they are a good base selection.
Ciao
On Nov 10, 2007, at 1:12 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 7:45 AM, Andy Farnell wrote:
This sounds interesting Hans. The question would be, what is the default/empty behaviour of Pd with no internals at all?
Does it just become a framework for connecting objects (the Pd way)?
Yeah, pretty much. It leads to the question, what are Pd's essential "reserved words"?
I consider the objects currently in Pd-core the essential ones, if alone for practical reasons. But also technically they are a good base selection.
Reserved words are different than essential functions. Here are the C reserved words:
http://lib.daemon.am/Books/C/apb/apb.htm
Try to write Pd without calloc, sprintf, etc. yet they are not reserved words.
http://en.wikipedia.org/wiki/Reserved_word
.hc
------------------------------------------------------------------------ ----
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
On Sat, 10 Nov 2007, Hans-Christoph Steiner wrote:
Reserved words are different than essential functions. Here are the C reserved words: http://lib.daemon.am/Books/C/apb/apb.htm Try to write Pd without calloc, sprintf, etc. yet they are not reserved words. http://en.wikipedia.org/wiki/Reserved_word
Pd doesn't really have reserved words... Nothing really behaves that specially in Pd, that it has to be handled by the parser. The only special characters really are just colon, semicolon, backslash, dollar and spaces.
The most special words that Pd has (that I can think of) are:
* float symbol pointer list bang. Those are selectors that have special entries in t_class. Four of them have special restrictions on their arguments.
* [pd], [inlet(~)], [outlet(~)], [declare], [objectmaker], [block~], [switch~], get treated specially sometimes. There might be a few other more like that, but there aren't many.
* "set" is a quite common method name, but not universal.
* "#X" "#N" "#A" "pd" as receive-symbols are reserved. (there are some more like that)
None of those symbols is special enough that is disallowed in all circumstances.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andy Farnell -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Thomas Grill