A long standing complaint of Pd-extended is that it is hard to know
what all is in it and how it got there. Plus the old build system is
a bug ugly whack thing that is not understandable We've made the
library template and that's working well so far. We
Here are some concrete steps to take on to help with this effort,
either as the maintainer of a library, or just where you can help:
- add a page to the the downloads page http://puredata.info/community/projects/software/ (this will become http://puredata.info/downloads soon).
- add releases to the download page
- improving documentation
- making a Debian package
- taking a pure:dyne package and getting it ready for submission to
Debian
- test releases
- update the code in the Pd-extended release branch, once that is in
place
There is some developing documentation here, its not cast in stone yet:
http://puredata.info/docs/AddingYourProjectToDownloads http://puredata.info/docs/LibrariesInPdExtended http://puredata.info/docs/developer/GettingIntoPdextended
There is a library template too. People aren't required to use this,
but it makes things a lot easier IMHO:
http://puredata.info/docs/developer/LibraryTemplate
.hc
On Mon, Dec 13, 2010 at 6:05 PM, Hans-Christoph Steiner
hans@at.or.at wrote:
Hey Alan,
Thanks for the offer! Maintaining a library mostly means keeping
track of the issues and seeing that they get addressed. Things range
from making releases, posting releases, fixing bugs, accepting
patches, etc. It can also mean doing all of the work, if you so
choose. I will help out where I can, and I'm sure many others will too.
You can take on any library you want, I always say its best to take on
one that you feel personally invested in.
.hc
On Dec 13, 2010, at 5:25 AM, ALAN BROOKER wrote:
Sevy,
How is this a constructive comment? In fact, how is it even
constructive criticism? Your proof of the saying that goes, "You can either not say anything and risk people thinking your
ignorant or you can open your mouth and prove it".Really I think you need to grow up, I am really surprised at just
how immature you are. If you don't like the people on the list then
subscribe.Maybe I am wrong however, if you have a grievance then put it
forward in a sensible way so that things can be worked out? If
there is something I can do let me know? I think to have bad
feelings with anyone on this list is not a good thing.Hans, I may be able to maintain a some libraries and it is something
I'm looking into, my programming experience is limited but would
like to contribute.On Mon, Dec 13, 2010 at 3:58 AM, sevy ydegoyon@gmail.com wrote: this basically shows you have 3 collaborators and you call it a 'community'
On Sun, Dec 12, 2010 at 9:03 PM, Hans-Christoph Steiner
hans@eds.org wrote:One of the goals for Pd-extended 0.43 is to have all libraries have
a maintainer, so Pd-extended isn't just a collection of lots of semi- working code. The end goal is to have a maintainer for all
libraries that are included in Pd-extended. Here's the current list
based on my knowledge:http://puredata.info/docs/LibrariesInPdExtended
If you are interested in becoming the maintainer of any of the
libraries that are currently lacking a maintainer, please add your
name next to the library in question. Once you get the library up- to-date for Pd-extended, we can move it up to the "maintained"
section on the top. Here's a rough sketch of the process of getting
libraries into Pd-extended:http://puredata.info/docs/developer/GettingIntoPdextended
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a
better language; and every chapter must be so translated.... -John
Donne
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
“We must become the change we want to see. - Mahatma Gandhi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Seems like the "power to decide" what goes into Pd-extended lies in the same place it does in every other free software project out there: with those willing to do the work. Seems fair to me.
D.
On 12/13/10 7:35 PM, Hans-Christoph Steiner wrote:
Here are some concrete steps to take on to help with this effort, either as the maintainer of a library, or just where you can help:
- add a page to the the downloads page
http://puredata.info/community/projects/software/ (this will become http://puredata.info/downloads soon).
- add releases to the download page
- improving documentation
- making a Debian package
- taking a pure:dyne package and getting it ready for submission to Debian
- test releases
- update the code in the Pd-extended release branch, once that is in place
There is some developing documentation here, its not cast in stone yet:
http://puredata.info/docs/AddingYourProjectToDownloads http://puredata.info/docs/LibrariesInPdExtended http://puredata.info/docs/developer/GettingIntoPdextended
There is a library template too. People aren't required to use this, but it makes things a lot easier IMHO:
http://puredata.info/docs/developer/LibraryTemplate
.hc
As far as improving documentation, I'd say every object in Pd-ext should be documented clearly in a help patch that outlines:
- what the object does
- what its arguments are (and how they function)
- what messages are accepted at each inlet, and output at each outlet
(and the meaning of those messages, unless it's obvious) 4) _clear_ example patch 5) any related objects (esp. internal objects)
If right-clicking "Help" for an object doesn't bring up a help patch, or if that help patch is just a placeholder, it should be considered a bug.
-Jonathan
--- On Mon, 12/13/10, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] libraries in Pd-extended 0.43 To: "PD List" pd-list@iem.at Date: Monday, December 13, 2010, 7:35 PM
A long standing complaint of Pd-extended is that it is hard to know what all is in it and how it got there. Plus the old build system is a bug ugly whack thing that is not understandable We've made the library template and that's working well so far. We Here are some concrete steps to take on to help with this effort, either as the maintainer of a library, or just where you can help:
- add a page to the the downloads page http://puredata.info/community/projects/software/ (this will become http://puredata.info/downloads soon).- add releases to the download page- improving documentation- making a Debian package- taking a pure:dyne package and getting it ready for submission to Debian- test releases- update the code in the Pd-extended release branch, once that is in place
There is some developing documentation here, its not cast in stone yet: http://puredata.info/docs/AddingYourProjectToDownloadshttp://puredata.info/d... There is a library template too. People aren't required to use this, but it makes things a lot easier IMHO: http://puredata.info/docs/developer/LibraryTemplate .hc
On Mon, Dec 13, 2010 at 6:05 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Hey Alan,
Thanks for the offer! Maintaining a library mostly means keeping track of the issues and seeing that they get addressed. Things range from making releases, posting releases, fixing bugs, accepting patches, etc. It can also mean doing all of the work, if you so choose. I will help out where I can, and I'm sure many others will too.
You can take on any library you want, I always say its best to take on one that you feel personally invested in.
.hc
On Dec 13, 2010, at 5:25 AM, ALAN BROOKER wrote:
Sevy,
How is this a constructive comment? In fact, how is it even constructive criticism? Your proof of the saying that goes, "You can either not say anything and risk people thinking your ignorant or you can open your mouth and prove it".
Really I think you need to grow up, I am really surprised at just how immature you are. If you don't like the people on the list then subscribe.
Maybe I am wrong however, if you have a grievance then put it forward in a sensible way so that things can be worked out? If there is something I can do let me know? I think to have bad feelings with anyone on this list is not a good thing.
Hans, I may be able to maintain a some libraries and it is something I'm looking into, my programming experience is limited but would like to contribute.
On Mon, Dec 13, 2010 at 3:58 AM, sevy ydegoyon@gmail.com wrote: this basically shows you have 3 collaborators and you call it a 'community'
On Sun, Dec 12, 2010 at 9:03 PM, Hans-Christoph Steiner hans@eds.org wrote:
One of the goals for Pd-extended 0.43 is to have all libraries have a maintainer, so Pd-extended isn't just a collection of lots of semi-working code. The end goal is to have a maintainer for all libraries that are included in Pd-extended. Here's the current list based on my knowledge:
http://puredata.info/docs/LibrariesInPdExtended
If you are interested in becoming the maintainer of any of the libraries that are currently lacking a maintainer, please add your name next to the library in question. Once you get the library up-to-date for Pd-extended, we can move it up to the "maintained" section on the top. Here's a rough sketch of the process of getting libraries into Pd-extended:
http://puredata.info/docs/developer/GettingIntoPdextended
.hc
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
“We must become the change we want to see. - Mahatma Gandhi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
As far as improving documentation, I'd say every object in Pd-ext should be documented clearly in a help patch that outlines:
I'd say every class in Pd-ext should be documented clearly in a help patch that outlines:
- what the object does
- what the class does
- any related objects (esp. internal objects)
- any related classes (esp. internal classes)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Tue, 12/14/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD List" pd-list@iem.at, "Hans-Christoph Steiner" hans@at.or.at Date: Tuesday, December 14, 2010, 3:04 AM On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
As far as improving documentation, I'd say every
object in Pd-ext should be
documented clearly in a help patch that outlines:
I'd say every class in Pd-ext should be documented clearly in a help patch that outlines:
You're right. I'm an object-o-phile. But do you find "Related Objects" troubling-- should it be "Related Classes"?
- what the object does
- what the class does
In a lot of situations you need both. For something like canvas_class it doesn't make much sense to put all the details of "what the class does" in one giant help file-- for instance, to follow your GFDP model, you'd have one "see also" section that includes [inlet] (which relates to [pd] but not to [table]) as well as [tabread] or the "Put" menu array (vice versa). So you can have one help patch for the class that has links to individual objects.
- any related objects (esp. internal objects)
- any related classes (esp. internal classes)
Ok so you do think it should say related classes.
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, 2010-12-13 at 20:25 -0800, Jonathan Wilkes wrote:
--- On Tue, 12/14/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD List" pd-list@iem.at, "Hans-Christoph Steiner" hans@at.or.at Date: Tuesday, December 14, 2010, 3:04 AM On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
As far as improving documentation, I'd say every
object in Pd-ext should be
documented clearly in a help patch that outlines:
I'd say every class in Pd-ext should be documented clearly in a help patch that outlines:
You're right. I'm an object-o-phile. But do you find "Related Objects" troubling-- should it be "Related Classes"?
Pd doesn't really have classes like OOP (i.e. no inheritance), so I think it can be confusing to use that term. People have been saying objects for a long time with Pd and Max.
.hc
- what the object does
- what the class does
In a lot of situations you need both. For something like canvas_class it doesn't make much sense to put all the details of "what the class does" in one giant help file-- for instance, to follow your GFDP model, you'd have one "see also" section that includes [inlet] (which relates to [pd] but not to [table]) as well as [tabread] or the "Put" menu array (vice versa). So you can have one help patch for the class that has links to individual objects.
- any related objects (esp. internal objects)
- any related classes (esp. internal classes)
Ok so you do think it should say related classes.
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 2010-12-14 05:58, Hans-Christoph Steiner wrote:
Pd doesn't really have classes like OOP (i.e. no inheritance), so I
as a matter of fact Pd implements a simple OOP system in C (including rudimentary inheritance).
think it can be confusing to use that term.
so i think that we should use the term
People have been saying objects for a long time with Pd and Max.
which doesn't make it any better. people have been saying "objects" for a long time in OOP, and you could use this very definition for Pd/Max like "objects" as well: it's the little rectangle things in your Pd-patch.
iirc, this has all been discussed to the end, and since then the term "objectclass" has been pretty much established for what matju refers to as "class" right now.
fgmasdr IOhannes
On Tue, 2010-12-14 at 09:12 +0100, IOhannes m zmoelnig wrote:
On 2010-12-14 05:58, Hans-Christoph Steiner wrote:
Pd doesn't really have classes like OOP (i.e. no inheritance), so I
as a matter of fact Pd implements a simple OOP system in C (including rudimentary inheritance).
think it can be confusing to use that term.
so i think that we should use the term
People have been saying objects for a long time with Pd and Max.
which doesn't make it any better. people have been saying "objects" for a long time in OOP, and you could use this very definition for Pd/Max like "objects" as well: it's the little rectangle things in your Pd-patch.
iirc, this has all been discussed to the end, and since then the term "objectclass" has been pretty much established for what matju refers to as "class" right now.
Yeah, let's stick with 'object class' when describing the functionality and let's call instances of an object class 'objects'.
my 2¢.
Roman
On Dec 14, 2010, at 3:12 AM, IOhannes m zmoelnig wrote:
On 2010-12-14 05:58, Hans-Christoph Steiner wrote:
Pd doesn't really have classes like OOP (i.e. no inheritance), so I
as a matter of fact Pd implements a simple OOP system in C (including rudimentary inheritance).
think it can be confusing to use that term.
so i think that we should use the term
People have been saying objects for a long time with Pd and Max.
which doesn't make it any better. people have been saying "objects" for a long time in OOP, and you
could use this very definition for Pd/Max like "objects" as well: it's the little rectangle things in your Pd-patch.iirc, this has all been discussed to the end, and since then the term "objectclass" has been pretty much established for what matju refers
to as "class" right now.
"objectclass" works for me, but I don't think "class" alone makes
sense for Pd. Pd could be implemented in Java or BASIC in SmallTalk,
and neither would not be an object-oriented programming language. ;)
But yes, there are some similarities between Pd and OO.
.hc
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess himself
of it. - Thomas Jefferson
On Tue, 14 Dec 2010, IOhannes m zmoelnig wrote:
On 2010-12-14 05:58, Hans-Christoph Steiner wrote:
Pd doesn't really have classes like OOP (i.e. no inheritance), so I
as a matter of fact Pd implements a simple OOP system in C (including rudimentary inheritance).
This rudimentary inheritance, I suppose, is a way of looking at the way the C structs are nested : t_pd is in t_gobj, t_gobj is in t_object, t_object is in t_iemgui, t_iemgui is in t_bng, ... However, Pd doesn't implement any inheritance of methods, so I wouldn't say that it supports inheritance. I found this to not be an obstacle to calling Pd an OOP language (see my reply to Hans).
iirc, this has all been discussed to the end, and since then the term "objectclass" has been pretty much established for what matju refers to as "class" right now.
Either "object class" (or "objectclass") or "class" can do, as long as "object" is synonymous with "instance", and there's a separate word meaning "class" in one way or another.
"objectclass" was proposed as a compromise to be more readily accepted by current pd users, but in the end, even the shorthand "class" ought to be understood by everybody.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 14/12/10 09:35 AM, Mathieu Bouchard wrote:
Either "object class" (or "objectclass") or "class" can do, as long as "object" is synonymous with "instance", and there's a separate word meaning "class" in one way or another.
Pd differs from C/python/lua etc. in that it's a graphical/visual language so I tend to think of the object as the thing that gets drawn on the screen by an instance of the class. So in Pd, "object" has a meaning distinct from "instance".
Martin
On Tue, 14 Dec 2010, Martin wrote:
Pd differs from C/python/lua etc. in that it's a graphical/visual language so I tend to think of the object as the thing that gets drawn on the screen by an instance of the class. So in Pd, "object" has a meaning distinct from "instance".
What difference(s) does that make in practice ?
When you use [s pd], are you sending to an object, and if not, what are you sending to, exactly ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-- http://www.jamiebullock.com
On 14 Dec 2010, at 15:51, Martin wrote:
On 14/12/10 09:35 AM, Mathieu Bouchard wrote:
Either "object class" (or "objectclass") or "class" can do, as long as "object" is synonymous with "instance", and there's a separate word meaning "class" in one way or another.
Pd differs from C/python/lua etc. in that it's a graphical/visual language so I tend to think of the object as the thing that gets drawn on the screen by an instance of the class. So in Pd, "object" has a meaning distinct from "instance".
No it doesn't. If you look at Miller's carefully-worded manual, he refers to what you are talking about (the graphical representation) as an "object box".
We have classes , objects (instances), and object boxes (the graphical representation). This makes it very clear:
http://www.crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s1.2
Jamie
On Thu, 16 Dec 2010 20:46:32 +0000 Jamie Bullock jamie@postlude.co.uk wrote:
If you look at Miller's carefully-worded manual, he refers to what you are talking about (the graphical representation) as an "object box".
We call them "boxes". That way an extra 60 seconds saved up by the end of each lecture can be used for something 99% of pd users care about. :)
On 14 Dec 2010, at 08:12, IOhannes m zmoelnig wrote:
On 2010-12-14 05:58, Hans-Christoph Steiner wrote:
Pd doesn't really have classes like OOP (i.e. no inheritance), so I
as a matter of fact Pd implements a simple OOP system in C (including rudimentary inheritance).
think it can be confusing to use that term.
so i think that we should use the term
People have been saying objects for a long time with Pd and Max.
which doesn't make it any better. people have been saying "objects" for a long time in OOP, and you could use this very definition for Pd/Max like "objects" as well: it's the little rectangle things in your Pd-patch.
iirc, this has all been discussed to the end, and since then the term "objectclass" has been pretty much established for what matju refers to as "class" right now.
"objectclass" is a pleonasm and leads to: "an object is an instance of an objectclass", eugh!
On Thu, 16 Dec 2010, Jamie Bullock wrote:
"objectclass" is a pleonasm and leads to: "an object is an instance of an objectclass", eugh!
well, it's also a disambigüator for the case where you have other uses of the word class : pitch class, class of polynomials, school class, struggle of the classes, the class of mammals, business class seat, ... and in a philosophy class you might learn that the word "class" has another meaning in philosophy.
Yet, for us, I think it is appropriate that the word "class" defaults to meaning "objectclass", with or without space or hyphen.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, 13 Dec 2010, Hans-Christoph Steiner wrote:
Pd doesn't really have classes like OOP (i.e. no inheritance),
Inheritance is not an essential feature of OOP, if you consider how much this feature varies a lot from one OOP language to another, moreso than other features.
The more essential features of OOP are data-abstraction, encapsulation, polymorphism, modularity, ... and in nearly all lists of typical OOP features, one is missing (but essential in practice) : the idea that multiple objects share a single class definition (that is, "methods" belong to "classes", not directly to "objects"). Pd's "abstractions" are precisely that : one patch is a class, and each use of that patch as an objectbox in any another patch is an object.
In short, there's a lot that programming languages have in common, that are typical OOP features, without having to even speak about inheritance.
so I think it can be confusing to use that term.
Confusing with what ? What's confusing is that you guys use one word for two things that are normally given two different names in every other language : object vs class in most cases, object vs prototype in some others, instance vs class, etc.
The confusion comes from people who insist on using the word "object" to mean "class".
People have been saying objects for a long time with Pd and Max.
In itself, that doesn't make it a good idea.
The Pd/Max mentality of "we're soooo completely different from everything else !" doesn't serve much more than egos. In the end, problem-solving in Pd/Max is fundamentally similar to that of any other computer programming (in the strategies, not the tactics), so, any kind of isolationism is a manner of making it unnecessarily harder for other programmers to understand us, and vice-versa. If we adopted standard vocabulary, we could focus on real differences between Pd/Max and other languages, instead of terminology.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Tue, 12/14/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: [PD] Objects vs Classes (was: libraries in Pd-extended 0.43) To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com, "PD List" pd-list@iem.at Date: Tuesday, December 14, 2010, 3:23 PM On Mon, 13 Dec 2010, Hans-Christoph Steiner wrote:
Pd doesn't really have classes like OOP (i.e. no
inheritance),
Inheritance is not an essential feature of OOP, if you consider how much this feature varies a lot from one OOP language to another, moreso than other features.
The more essential features of OOP are data-abstraction, encapsulation, polymorphism, modularity, ... and in nearly all lists of typical OOP features, one is missing (but essential in practice) : the idea that multiple objects share a single class definition (that is, "methods" belong to "classes", not directly to "objects"). Pd's "abstractions" are precisely that : one patch is a class, and each use of that patch as an objectbox in any another patch is an object.
In short, there's a lot that programming languages have in common, that are typical OOP features, without having to even speak about inheritance.
so I think it can be confusing to use that term.
Confusing with what ? What's confusing is that you guys use one word for two things that are normally given two different names in every other language : object vs class in most cases, object vs prototype in some others, instance vs class, etc.
The confusion comes from people who insist on using the word "object" to mean "class".
People have been saying objects for a long time with
Pd and Max.
In itself, that doesn't make it a good idea.
The Pd/Max mentality of "we're soooo completely different from everything else !" doesn't serve much more than egos.
You've used this argument before. I don't remember exactly what the
topic was-- maybe recursion-- and you made the point that pretty
much verbatim-- that Pd is very different from everything else.
I don't know, maybe you were talking about "tactics" (see below).
In the end, problem-solving in Pd/Max is fundamentally similar to that of any other computer programming (in the strategies, not the tactics)
It looks as if you a) wrote the "we're-soooo-completely-different" straw man, b) realized it might apply to yourself, and c) decided to give yourself an escape route by making an arbitrary division between strategies and tactics. (How is it that the Pd tacticians are reasonable people but the Pd strategists are egomanical?)
-Jonathan
so, any kind of isolationism is a manner of making it unnecessarily harder for other programmers to understand us, and vice-versa. If we adopted standard vocabulary, we could focus on real differences between Pd/Max and other languages, instead of terminology.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 14 Dec 2010, Jonathan Wilkes wrote:
You've used this argument before. I don't remember exactly what the topic was-- maybe recursion-- and you made the point that pretty much verbatim-- that Pd is very different from everything else. I don't know, maybe you were talking about "tactics" (see below).
Pd is very different from everything else and very similar to everything else. It depends which aspect you look at. You can't look at how one part of pd is original and conclude that all of pd is like that, or vice versa.
On average, I found similarities to happen at a larger scale than differences, but that doesn't apply all of the time, which is why I say «on average». Nevertheless, I thought I'd say strategies for the larger scale, and tactics for the small scale.
It looks as if you a) wrote the "we're-soooo-completely-different" straw man,
Speaking of strawman,
(How is it that the Pd tacticians are reasonable people but the Pd strategists are egomanical?)
I didn't say egomaniacal,
I didn't say that there were tacticians vs strategists : I didn't say
that there were two kinds of people in the Pd community.
To give a few examples, in programming, ordering of operations is often important, and it's like that in Pd as well, but Pd has its own means of dealing with it : hot/cold, right-to-left, [t], etc. ; also, the way to deal with large problems is to make components, and those components are usually classes that are instantiated with constructors to produce objects that respond to messages using methods, and in Pd it's like that too, but the objects also may have inlets, outlets, and the classes may be patches.
c) decided to give yourself an escape route by making an arbitrary division between strategies and tactics.
Can you just make a quick inventory of similarities and differences between Pd and a «written» programming language of your choice, and confirm that more similarities are in the big picture, and more differences are in the details ? It would save us some sweat, and if you can actually find ways to contradict me, I would like it.
b) realized it might apply to yourself,
What are you talking about.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 14 Dec 2010, at 04:58, Hans-Christoph Steiner wrote:
On Mon, 2010-12-13 at 20:25 -0800, Jonathan Wilkes wrote:
--- On Tue, 12/14/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD List" pd-list@iem.at, "Hans-Christoph Steiner" hans@at.or.at Date: Tuesday, December 14, 2010, 3:04 AM On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
As far as improving documentation, I'd say every
object in Pd-ext should be
documented clearly in a help patch that outlines:
I'd say every class in Pd-ext should be documented clearly in a help patch that outlines:
You're right. I'm an object-o-phile. But do you find "Related Objects" troubling-- should it be "Related Classes"?
Pd doesn't really have classes like OOP (i.e. no inheritance), so I think it can be confusing to use that term. People have been saying objects for a long time with Pd and Max.
The concept of classes doesn't have anything to do with inheritance, it's about separating the abstract representation of something (class), and a concrete instance of that thing (object).
The terminology is used liberally in the Pd html manual http://www.crca.ucsd.edu/~msp/Pd_documentation/x2.htm and I think it's perfectly clear and not confusing at all.
In fact it's more confusing to avoid the term class, since this then makes Pd inconsistent with other languages.
Jamie
On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
You're right. I'm an object-o-phile. But do you find "Related Objects" troubling-- should it be "Related Classes"?
well... yes
In a lot of situations you need both. For something like canvas_class it doesn't make much sense to put all the details of "what the class does" in one giant help file
Giant help files aren't much of a problem, but it would be more appropriate to introduce method-categories (as in Smalltalk) in order to avoid the mandatory quasi-alphabetical sorting.
(GF sorts them like : bang float grid symbol pointer list, then all other names in alphabetical order, then <any> at the very end.)
for instance, to follow your GFDP model, you'd have one "see also" section that includes [inlet] (which relates to [pd] but not to [table])
The t_class structure of [pd]/[table]/array/abstractions/patches is especially hairy. If a single t_class acts like it's many classes at once, it may make sense to document it as several classes anyway. However, pd will still refer you to a single help file for all those cases (except abstractions).
The way a single t_class may act like several, is if it contains statements such as
if (binbuf_getvec(x->te_binbuf)[0]==gensym("thatone")) ...
Then it's looking up which alias has been used for the creation and varying the behaviour accordingly. (It could also be using multiple creators that store something to remember the same info, or have a single creator with multiple names, that stores its t_symbol *s in one way or another... I'm talking about all cases of a class acting like it's several)
I mean that something can be called a class documentation-wise even though it might not be the case implementation-wise. What's important, then, is to structure the thought so that people can get the most out of those things, and not to document how the code is really written.
But note that if you have a [table whatever] and a [s pd-whatever], you can do dynamic-patching instead of the [table], even though the [table] won't save the contents. You can try «obj 0 0 inlet» and «obj 0 20 outlet» and see that they really add inlets and outlets on a [table] object. Thus, in that manner, [inlet] and [outlet] are relevant to [table] objects.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Tue, 12/14/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD List" pd-list@iem.at, "Hans-Christoph Steiner" hans@at.or.at Date: Tuesday, December 14, 2010, 4:36 PM On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
You're right. I'm an object-o-phile. But do you
find "Related Objects" troubling-- should it be "Related Classes"?
well... yes
In a lot of situations you need both. For
something like canvas_class it doesn't make much sense to put all the details of "what the class does" in one giant help file
Giant help files aren't much of a problem, but it would be more appropriate to introduce method-categories (as in Smalltalk) in order to avoid the mandatory quasi-alphabetical sorting.
(GF sorts them like : bang float grid symbol pointer list, then all other names in alphabetical order, then <any> at the very end.)
for instance, to follow your GFDP model, you'd have
one "see also" section that includes [inlet] (which relates to [pd] but not to [table])
The t_class structure of [pd]/[table]/array/abstractions/patches is especially hairy. If a single t_class acts like it's many classes at once, it may make sense to document it as several classes anyway. However, pd will still refer you to a single help file for all those cases (except abstractions).
Yeah, so currently I have links inside canvas-help.pd to
table-help.pd, pd-help.pd, graph-help.pd, and a special note
about "Put" menu arrays with a link to array-help.pd.
array-help.pd is necessary to have there because triggering the
help patch for the "Put" menu array is so obscure (I wonder if
anyone here even knows what to click to get it.)
The way a single t_class may act like several, is if it contains statements such as
if (binbuf_getvec(x->te_binbuf)[0]==gensym("thatone")) ...
Then it's looking up which alias has been used for the creation and varying the behaviour accordingly. (It could also be using multiple creators that store something to remember the same info, or have a single creator with multiple names, that stores its t_symbol *s in one way or another... I'm talking about all cases of a class acting like it's several)
I mean that something can be called a class documentation-wise even though it might not be the case implementation-wise. What's important, then, is to structure the thought so that people can get the most out of those things, and not to document how the code is really written.
But note that if you have a [table whatever] and a [s pd-whatever], you can do dynamic-patching instead of the [table], even though the [table] won't save the contents. You can try «obj 0 0 inlet» and «obj 0 20 outlet» and see that they really add inlets and outlets on a [table] object. Thus, in that manner, [inlet] and [outlet] are relevant to [table] objects.
That's true, but just because it's possible to do that doesn't mean that [inlet] and [outlet] are relevant enough to show in the help patch for [table], any more than showing [list] in the help patch for [metro].
Also, it doesn't work the other way around-- [tabread], [tabwrite], etc. are not relevant to [pd].
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 14 Dec 2010, Jonathan Wilkes wrote:
Yeah, so currently I have links inside canvas-help.pd to table-help.pd, pd-help.pd, graph-help.pd, and a special note about "Put" menu arrays with a link to array-help.pd. array-help.pd is necessary to have there because triggering the help patch for the "Put" menu array is so obscure (I wonder if anyone here even knows what to click to get it.)
I don't know how you can possibly not get it. Do you expect that you can get it by right-clicking the array's label ? Because, it doesn't work for any other label (IEMGUI...), so, why would it work for Array's label ?
That's true, but just because it's possible to do that doesn't mean that [inlet] and [outlet] are relevant enough to show in the help patch for [table], any more than showing [list] in the help patch for [metro]. Also, it doesn't work the other way around-- [tabread], [tabwrite], etc. are not relevant to [pd].
Actually, when you have a [table], you don't have one object, you have two of them. When you have [table foo], receive-symbol "pd-foo" sends to a canvas, whereas receive-symbol "foo" sends to the internal t_array object, which has all of the array-specific methods. This has to be made clear, because it's not like an inheritance-like pattern.
An inheritance-like pattern (or interface pattern) would be, for example, to have one single help-patch for most of the common methods in iemguis, those that have exactly the same behaviour, to emphasise that they are one single family (even though inheritance in pd is mostly in our imagination). It's a matter of documenting things in a non-repetitive, synthetic manner, and with a mindset that encourages consistency.
When you have one class that seemingly would include one complete other helpfile's content but not the other way around, that would usually be an inheritance pattern, but it's not here, because instead, it's mostly that a canvas has a t_array tacked onto it, vs not.
It can't be called delegation pattern either, because in a delegation pattern, you have two objects, of which you only send to one, which will forward the message to the other one whenever appropriate. This is not the case here, because you can send to two different receive-symbols, and you have to send to the correct one.
I could have said a lot less, but I just thought I'd give you some more doc ideas.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Sun, 12/19/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD List" pd-list@iem.at, "Hans-Christoph Steiner" hans@at.or.at Date: Sunday, December 19, 2010, 1:54 AM On Tue, 14 Dec 2010, Jonathan Wilkes wrote:
Yeah, so currently I have links inside canvas-help.pd
to table-help.pd, pd-help.pd, graph-help.pd, and a special note about "Put" menu arrays with a link to array-help.pd. array-help.pd is necessary to have there because triggering the help patch for the "Put" menu array is so obscure (I wonder if anyone here even knows what to click to get it.)
I don't know how you can possibly not get it.
That's probably because you've never gotten it. Clicking on the graph that contains the array opens up 'canvas-help.pd'. But you can open a help patch named 'array-help.pd' when you:
a) right-click on the "Put" menu array and choose "Open", b) mouse-over an array element until the arrow cursor changes directions, c) right-click and choose help.
Then you will receive enlightenment from Pd's generous help docs:
sorry, couldn't find help patch for "array.pd"
Though it's certainly to the point, I thought a user might want a tad bit more information than that, so I made an array-help.pd patch, and linked to it in canvas-help.pd for those few boring users who choose not to click random spots within a patch until something helpful and relevant happens.
-Jonathan
Do you expect that you can get it by right-clicking the array's label ? Because, it doesn't work for any other label (IEMGUI...), so, why would it work for Array's label ?
That's true, but just because it's possible to do that
doesn't mean that [inlet] and [outlet] are relevant enough to show in the help patch for [table], any more than showing [list] in the help patch for [metro].
Also, it doesn't work the other way around--
[tabread], [tabwrite], etc. are not relevant to [pd].
Actually, when you have a [table], you don't have one object, you have two of them.
Three of them. There's also a graph within the table.
When you have [table foo], receive-symbol "pd-foo" sends to a canvas, whereas receive-symbol "foo" sends to the internal t_array object, which has all of the array-specific methods. This has to be made clear, because it's not like an inheritance-like pattern.
An inheritance-like pattern (or interface pattern) would be, for example, to have one single help-patch for most of the common methods in iemguis, those that have exactly the same behaviour, to emphasise that they are one single family (even though inheritance in pd is mostly in our imagination). It's a matter of documenting things in a non-repetitive, synthetic manner, and with a mindset that encourages consistency.
How do you make that system of documentation consistent across libraries? (And show links across libraries?)
When you have one class that seemingly would include one complete other helpfile's content but not the other way around, that would usually be an inheritance pattern, but it's not here, because instead, it's mostly that a canvas has a t_array tacked onto it, vs not.
It can't be called delegation pattern either, because in a delegation pattern, you have two objects, of which you only send to one, which will forward the message to the other one whenever appropriate. This is not the case here, because you can send to two different receive-symbols, and you have to send to the correct one.
I could have said a lot less, but I just thought I'd give you some more doc ideas.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 29 Dec 2010, Jonathan Wilkes wrote:
That's probably because you've never gotten it. Clicking on the graph that contains the array opens up 'canvas-help.pd'. But you can open a help patch named 'array-help.pd' when you: a) right-click on the "Put" menu array and choose "Open", b) mouse-over an array element until the arrow cursor changes directions, c) right-click and choose help.
Ah, yeah, so I misunderstood the whole thing.
Then you will receive enlightenment from Pd's generous help docs: sorry, couldn't find help patch for "array.pd"
Yeah, that's quite weird.
And frankly, for some errors like this, I'd rather have a dialogue box open just for that, then having to look at the console.
for those few boring users who choose not to click random spots within a patch until something helpful and relevant happens.
heh
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Andy Farnell -
Derek Holzer -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
Jonathan Wilkes -
Martin -
Mathieu Bouchard -
Roman Haefeli