In a first step towards making Pd a micro-language, I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files. The only changes needed to make this happen is to rename and move the relevant g_*.c files to extra, renaming the setup() functions accordingly, and changing the makefile. All of these are pretty trivial.
Thoughts, comments, objections, improvements?
.hc
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Thu, 14 Dec 2006, Hans-Christoph Steiner wrote:
In a first step towards making Pd a micro-language,
I'd like to distinguish between micro-language and micro-environment. Pd is already a micro-language in the sense that it has a micro-syntax: a syntax that is very simple, and that anything that may look like additional syntax in pd, is built in terms of that micro-syntax. (Other languages that have micro-syntax are the Forth family, the Lisp family, and Tcl.)
Pd isn't a micro-environment because there's a lot of things present at runtime that aren't needed, but most of them aren't an obstacle for pd to be called a micro-language, because they fit in the handful of pd's syntactic/semantic rules.
I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files.
What's the advantage of doing that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 14 Dec 2006, at 18:18, Mathieu Bouchard wrote:
On Thu, 14 Dec 2006, Hans-Christoph Steiner wrote:
I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files.
What's the advantage of doing that?
Separation of Concerns:
http://en.wikipedia.org/wiki/Separation_of_concerns
Separation of language, content, and presentation has to be a good move, no?
d
On Fri, 15 Dec 2006, Plans Casal David wrote:
On 14 Dec 2006, at 18:18, Mathieu Bouchard wrote:
On Thu, 14 Dec 2006, Hans-Christoph Steiner wrote:
I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files.
What's the advantage of doing that?
Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns Separation of language, content, and presentation has to be a good move, no?
but the IEMGUIs, like the rest of the Pd GUIs, are part of the language. You can't remove them without breaking the code. If they were just presentation, you could slice them away and the patch would run the same. If you want to separate concerns, what you want to slice away is the t_widgetbehavior section of each of Pd's GUI classes (including that of objectboxes, messageboxes, floatboxes, symbolboxes, patchers, arrays, ...).
The only project that slices away t_widgetbehavior, and thus separate Pd's presentation from Pd's language/content, is called DesireData. The feature doesn't have much to do with namespacing and classloaders: if you want another reimplementation of Pd's GUI that does separation of concerns, you will spend 1% of the effort on getting the thing to load in place of the original classes, and 99% on making sure that it works like the original classes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 16, 2006, at 2:52 PM, Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Plans Casal David wrote:
On 14 Dec 2006, at 18:18, Mathieu Bouchard wrote:
On Thu, 14 Dec 2006, Hans-Christoph Steiner wrote:
I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files.
What's the advantage of doing that?
Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns Separation of language, content, and presentation has to be a good move, no?
but the IEMGUIs, like the rest of the Pd GUIs, are part of the language. You can't remove them without breaking the code. If they were just presentation, you could slice them away and the patch would run the same. If you want to separate concerns, what you want to slice away is the t_widgetbehavior section of each of Pd's GUI classes (including that of objectboxes, messageboxes, floatboxes, symbolboxes, patchers, arrays, ...).
The only project that slices away t_widgetbehavior, and thus separate Pd's presentation from Pd's language/content, is called DesireData. The feature doesn't have much to do with namespacing and classloaders: if you want another reimplementation of Pd's GUI that does separation of concerns, you will spend 1% of the effort on getting the thing to load in place of the original classes, and 99% on making sure that it works like the original classes.
The IEMGUIs were not originally part of the core, they were added later. They originally existed as a separate lib. I have a working version of Pd with the iemguis as externals, so I don't see the "breaking the code" part, especially considering that I didn't change the code, except for adding properly named setup functions and removed the files from the makefile
.hc
------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
On Sat, 16 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 16, 2006, at 2:52 PM, Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Plans Casal David wrote:
Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns Separation of language, content, and presentation has to be a good move, no?
but the IEMGUIs, like the rest of the Pd GUIs, are part of the language. You can't remove them without breaking the code.
I have a working version of Pd with the iemguis as externals, so I don't see the "breaking the code" part,
That's not relevant, because we're talking about what it means to separate concerns. I'm trying to make a point about what it means to separate presentation, and how it is that separating IEMGUI does not constitute separating presentation, and I use the removal of IEMGUI as an example, and then you come in and say that you are not removing IEMGUI. What are you talking about? What am *I* talking about?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 17 Dec 2006, Steffen wrote:
On 16/12/2006, at 23.47, Hans-Christoph Steiner wrote:
The IEMGUIs were not originally part of the core, they were added later.
Would it be of any value/interest to this discussion to bring up the reason why it was added (when it was added)?
As I understood it, PureData was originally supposed to be much more about "Data Structures" ([struct], [drawpolygon], etc), without much of anything else around, hence the name "PureData". However, those new features didn't evolve as quickly as wished and the need for more MAX compatibility was felt, because the world was in need of a free MAX clone (and JAVA-free as well...). I think that it was a good move for Musil/IEM to introduce those (even if I can't agree with the implementation) because cutting-edge artists aren't quite tired of the MAX paradigm yet.
However, I started to use PureData only at 0.34, so I haven't witnessed the introduction of IEMGUI into the core, so, I might not be the best person to tell this story. Maybe Miller, T.Musil or even Mark Danks can provide some background on what was PureData in the 90's.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Anything that adds modularity and allows separate compilation has to be a good thing. It seems a logical partition to make too, graphical things should probably have their own space.
2c
On Thu, 14 Dec 2006 12:26:32 -0500 Hans-Christoph Steiner hans@eds.org wrote:
In a first step towards making Pd a micro-language, I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files. The only changes needed to make this happen is to rename and move the relevant g_*.c files to extra, renaming the setup() functions accordingly, and changing the makefile. All of these are pretty trivial.
Thoughts, comments, objections, improvements?
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
In a first step towards making Pd a micro-language, I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files. The only changes needed to make this happen is to rename and move the relevant g_*.c files to extra, renaming the setup() functions accordingly, and changing the makefile. All of these are pretty trivial.
Thoughts, comments, objections, improvements?
I'm all for it, in my opinion all gui elements should be optional and/ or exchangeable.
greetings, Thomas
Of course, I'm not a developer, but I think that this is a smart way to go. Especially interchangeability of GUI components. Who knows when a nice, new version of a given object may be forged by a rogue programmer to be easily dropped into place...
~Kyle
On 12/14/06, Thomas Grill gr@grrrr.org wrote:
In a first step towards making Pd a micro-language, I propose moving the IEM GUI objects that are embedded in Pd into the "extra" folder, compiled as individual files. The only changes needed to make this happen is to rename and move the relevant g_*.c files to extra, renaming the setup() functions accordingly, and changing the makefile. All of these are pretty trivial.
Thoughts, comments, objections, improvements?
I'm all for it, in my opinion all gui elements should be optional and/ or exchangeable.
greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Thu, 14 Dec 2006, Kyle Klipowicz wrote:
Of course, I'm not a developer, but I think that this is a smart way to go. Especially interchangeability of GUI components. Who knows when a nice, new version of a given object may be forged by a rogue programmer to be easily dropped into place...
It's not like it's impossible to overwrite methods in [objectmaker]. If someone had wanted to change the IEMGUIs, they would've done it already. This suggestion doesn't stem from need. I don't think that this "who knows" is backed by likelihood. If a rogue programmer would please stand up now, we might have a reason...
As the author of the only modified version of IEMGUI in five years, I say no, we don't need this to happen.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 14, 2006, at 3:25 PM, Mathieu Bouchard wrote:
On Thu, 14 Dec 2006, Kyle Klipowicz wrote:
Of course, I'm not a developer, but I think that this is a smart way to go. Especially interchangeability of GUI components. Who knows when a nice, new version of a given object may be forged by a rogue programmer to be easily dropped into place...
It's not like it's impossible to overwrite methods in [objectmaker]. If someone had wanted to change the IEMGUIs, they would've done it already. This suggestion doesn't stem from need. I don't think that this "who knows" is backed by likelihood. If a rogue programmer would please stand up now, we might have a reason...
What is [objectmaker]?
As the author of the only modified version of IEMGUI in five years, I say no, we don't need this to happen.
It wasn't a question of need. We are all fed ;). Do you have any actual objections?
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
As the author of the only modified version of IEMGUI in five years, I say no, we don't need this to happen.
It wasn't a question of need. We are all fed ;). Do you have any actual objections?
well, i would not do it. i am a string advocate of splitting the pd-core from its objects (as far as this is possible: i don't think of getting rid of [pd], [inlet], [switch~] and friends). but there is no real use in getting IEMGUI's separated when the numberbox, the signal-objects and the math are still part of core pd.
however, if you feel the urge to do so and you feel like patching pd-vanilla for each release, go on. you could also do a fork ;-)
(it all boils down to: do you have any real benefits from this? or are you just bored and need some work to do oer the holidays ;-) ?)
mfg.adr IOhannes
On Dec 15, 2006, at 7:52 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
As the author of the only modified version of IEMGUI in five years, I say no, we don't need this to happen.
It wasn't a question of need. We are all fed ;). Do you have any actual objections?
well, i would not do it. i am a string advocate of splitting the pd-core from its objects (as far as this is possible: i don't think of getting rid of [pd], [inlet], [switch~] and friends). but there is no real use in getting IEMGUI's separated when the numberbox, the signal-objects and the math are still part of core pd.
however, if you feel the urge to do so and you feel like patching pd-vanilla for each release, go on. you could also do a fork ;-)
(it all boils down to: do you have any real benefits from this? or are you just bored and need some work to do oer the holidays ;-) ?)
If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library.
The embedded iemgui objects are just an easy place to start, they are already one-class per file. This would provide a test case for the idea, and then we can figure out how to separate the rest.
As for patching the core, each Pd-extended release has 20+ patches applied. This current one has 22-24, depending on platform (you can see the list in packages/patches). Adding patches is trivial with the patch management in packages/Makefile.
.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
If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library.
in Python 2.5, Tk is still a configure-time option, which means, TkInter isnt shipped as a seperate library (Even TCL ships Tk seperately). likewise, the JVM from sun includes a GUI as well. the Squeak VM includes a gui, debugger, source code editor, etc.
these GUIs may be shipped as nonoptional parts of the core, but presambly they do have their own namespace and installation directory on disk - does this mean we'll be cerating [iemgui/numbox2]'s in patches soon (or [declare import iemgui] or whatever)?
my question would be... what do you get out of this change. other than make people's patches slightly harder to build, and have to worry about getting your changes incorporated into miller's version or continually move around files every version bump..
i guess the prefs dialog has a setting for default library imports?
On Dec 15, 2006, at 1:54 PM, carmen wrote:
If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library.
in Python 2.5, Tk is still a configure-time option, which means, TkInter isnt shipped as a seperate library (Even TCL ships Tk seperately). likewise, the JVM from sun includes a GUI as well. the Squeak VM includes a gui, debugger, source code editor, etc.
these GUIs may be shipped as nonoptional parts of the core, but presambly they do have their own namespace and installation directory on disk - does this mean we'll be cerating [iemgui/ numbox2]'s in patches soon (or [declare import iemgui] or whatever)?
my question would be... what do you get out of this change. other than make people's patches slightly harder to build, and have to worry about getting your changes incorporated into miller's version or continually move around files every version bump..
i guess the prefs dialog has a setting for default library imports?
If those files are then included in the "extra" folder in the pd- vanilla, then there would be no change in how you use it. Pd would just load the file when requested, instead of at startup.
On Pd-extended those files would be stuck into a libdir. If you use the prefs file that is included in all of the Pd-extended packages, then this change would be completely transparent, you would do everything the same. Otherwise, the [import], [declare] stuff would need to be used.
Then it would mean that Pd would only load the code that you are actually using. That means you can completely ignore any bugs, etc in code that you are not using.
This also means that there would be very few reserved words in Pd. Classes compiled into the core are basically reserved words, you can't use them in any other way.
.hc
------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote:
If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports.
C/C++'s #includes don't have anything to do with namespaces. C doesn't have any, and C++ allows you to use namespace-directives in whichever way you want regardless of how the #includes work.
Java's "import" directives do implement namespaces, and only namespaces. The loading of classes is done by java.lang.ClassLoader, whose closest pd equivalent is [objectmaker].
Only the bare minimum is in the language itself. Everything else is a library.
Wouldn't it make sense to first categorize built-in classes according to which APIs they require, in order to figure out which of them would be most logically separable? Basically, every class is separable from pd, but that's at the cost of making those new externals depend on a lot of undocumented features that are not guaranteed to stay the same over releases. For example, <g_canvas.h>, <m_imp.h>, <s_stuff.h>, ...
The embedded iemgui objects are just an easy place to start, they are already one-class per file.
How do you handle class_addcreator() in that context?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 15 Dec 2006 13:52:07 +0100 IOhannes m zmölnig zmoelnig@iem.at wrote:
i am a string advocate
Me too, but those damn symbols can't contain whitespace :)
padawan12 wrote:
On Fri, 15 Dec 2006 13:52:07 +0100 IOhannes m zmölnig zmoelnig@iem.at wrote:
i am a string advocate
Me too,
;-)
but those damn symbols can't contain whitespace
?? says who ??
mf.adsr IOhannes
On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 14, 2006, at 3:25 PM, Mathieu Bouchard wrote:
It's not like it's impossible to overwrite methods in [objectmaker].
What is [objectmaker]?
what's at the end of the receive-symbol of the same name, that thing that creates all your objectboxes. When you write something in an objectbox, this is where it gets sent. It's the only object in which methods have return-values. You can't use [s objectmaker] directly, because from pd you can't use the return value; instead you send "obj" messages to canvas.
Do you have any actual objections?
Yes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 15, 2006, at 8:02 PM, Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 14, 2006, at 3:25 PM, Mathieu Bouchard wrote:
It's not like it's impossible to overwrite methods in [objectmaker].
What is [objectmaker]?
what's at the end of the receive-symbol of the same name, that thing that creates all your objectboxes. When you write something in an objectbox, this is where it gets sent. It's the only object in which methods have return-values. You can't use [s objectmaker] directly, because from pd you can't use the return value; instead you send "obj" messages to canvas.
Do you have any actual objections?
Yes.
Are we supposed to guess what they are?
.hc
------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Sat, 16 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 15, 2006, at 8:02 PM, Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Hans-Christoph Steiner wrote:
Do you have any actual objections?
Yes.
Are we supposed to guess what they are?
You could guess using mail archives what I think about one-source-file-per-class. If you can't find it, I could write it once more. (Maybe I'm wrong when I have the impression of repeating myself too much.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
carmen -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Kyle Klipowicz -
Mathieu Bouchard -
padawan12 -
Plans Casal David -
Steffen -
Thomas Grill