On Thu, Jul 3, 2008 at 2:51 PM, Roman Haefeli reduzierer@yahoo.de wrote:
On Thu, 2008-07-03 at 16:05 -0400, Mathieu Bouchard wrote:
On Thu, 3 Jul 2008, Roman Haefeli wrote:
sorry for late reply. i couldn't figure out, what [range] from gridflow does, so it makes you difficult to have an opinion about this. the fact, that it doesn't have a '#' in its name, makes me assume, that it does something, that cannot only be applied to grids, which means, it has kind of a general use.
It's a cascaded [moses]. For example,
[range 11 13 17 19] = [moses 11]/[moses 13]/[moses 17]/[moses 19]
where the slash is a right-outlet-to-left-inlet connection.
this is what jMax had instead of moses, and I added it to GF in order to avoid having to cascade many [moses].
this speaks for keeping the name. on the other hand, i find it problematic, if libraries with a dedicated focus (processing grids in the case of gridflow) include classes, that aren't really part of that focus AND at the same time occupy a generic name.
If they wouldn't be there, they would be in some library that would be required for using GridFlow (because it would be used in GridFlow's abstractions), and the problem would be exactly the same, only with one more library dependency to think about.
Frankly, I don't know what to do to solve your problem. I think that it's a problem of your perception of what GridFlow is supposed to be, vs what it is.
the solution would be to give it a name, that clearly relates to gridflow. [gf.range] or whatsoever (similar to grid processing classnames starting with a '#').
Besides, if you read one sentence of "GridFlow is..." it doesn't tell you the whole picture and you shouldn't take it as such. I also didn't want to call the library MatjuLib just because its most defining characteristic is that all the things in there are things that I have wanted and/or that my collaborators have wanted. I thought about making a separate library but quickly figured out that there was not much of a point to it.
sorry, matju, i didn't meant to tell YOU what the focus of gridflow is or is supposed to be. however, it's not me, who made the distinction between 'core classes' of gridflow (the ones starting with '#' ) and some additional classes, but it's the name, that distinguishes them. this distinction made me believe, that there is something like a core part and a peripheral part (whereas the peripheral part is not necessarily necessary for the core part, that has the dedicated focus, to work properly). this might be wrong and my own faulty personal interpretation.
personally i think, that something like [range] shouldn't be part of an external at all, rather should it be simply an abstraction. however, the naming problem persists (and should be faced by adding some library specific prefix, imo).
Well, as always, the namespace thing is at the root of all this - if the namespace stuff was working (and it sounds like it's getting closer) then it would be perfectly fine to call it just [range] since it would require gridflow/range or import/declare gridflow to use.
And, the second answer is other-language (e.g. Python) style reorganization of libraries to be author-agnostic - ordered by functionality. But, this requires a Organization Czar, it seems, and maybe no one is ready to be that person yet, so, until then, such helper-objects must stay in the homes of their authors for there's nowhere else to put them. (also, I think in this case, since grid-operators in GF have the #-prefix, those objects without the prefix are clearly distinguished as "generic helpers")
Luke
On Jul 4, 2008, at 12:46 AM, Luke Iannini wrote:
On Thu, Jul 3, 2008 at 2:51 PM, Roman Haefeli reduzierer@yahoo.de
wrote:On Thu, 2008-07-03 at 16:05 -0400, Mathieu Bouchard wrote:
On Thu, 3 Jul 2008, Roman Haefeli wrote:
sorry for late reply. i couldn't figure out, what [range] from
gridflow does, so it makes you difficult to have an opinion about this.
the fact, that it doesn't have a '#' in its name, makes me assume, that it
does something, that cannot only be applied to grids, which means, it
has kind of a general use.It's a cascaded [moses]. For example,
[range 11 13 17 19] = [moses 11]/[moses 13]/[moses 17]/[moses 19]
where the slash is a right-outlet-to-left-inlet connection.
this is what jMax had instead of moses, and I added it to GF in
order to avoid having to cascade many [moses].this speaks for keeping the name. on the other hand, i find it problematic, if libraries with a dedicated focus (processing
grids in the case of gridflow) include classes, that aren't really part
of that focus AND at the same time occupy a generic name.If they wouldn't be there, they would be in some library that
would be required for using GridFlow (because it would be used in GridFlow's abstractions), and the problem would be exactly the same, only
with one more library dependency to think about.Frankly, I don't know what to do to solve your problem. I think
that it's a problem of your perception of what GridFlow is supposed to be,
vs what it is.the solution would be to give it a name, that clearly relates to gridflow. [gf.range] or whatsoever (similar to grid processing classnames starting with a '#').
Besides, if you read one sentence of "GridFlow is..." it doesn't
tell you the whole picture and you shouldn't take it as such. I also
didn't want to call the library MatjuLib just because its most defining
characteristic is that all the things in there are things that I have wanted and/or
that my collaborators have wanted. I thought about making a separate
library but quickly figured out that there was not much of a point to it.sorry, matju, i didn't meant to tell YOU what the focus of
gridflow is or is supposed to be. however, it's not me, who made the distinction between 'core classes' of gridflow (the ones starting with '#' ) and some additional classes, but it's the name, that distinguishes them. this distinction made me believe, that there is something like a core part and a peripheral part (whereas the peripheral part is not necessarily necessary for the core part, that has the dedicated
focus, to work properly). this might be wrong and my own faulty personal interpretation.personally i think, that something like [range] shouldn't be part
of an external at all, rather should it be simply an abstraction.
however, the naming problem persists (and should be faced by adding some library specific prefix, imo).Well, as always, the namespace thing is at the root of all this - if the namespace stuff was working (and it sounds like it's getting closer) then it would be perfectly fine to call it just [range] since it would require gridflow/range or import/declare gridflow to use.
And, the second answer is other-language (e.g. Python) style reorganization of libraries to be author-agnostic - ordered by functionality. But, this requires a Organization Czar, it seems, and maybe no one is ready to be that person yet, so, until then, such helper-objects must stay in the homes of their authors for there's nowhere else to put them. (also, I think in this case, since grid-operators in GF have the #-prefix, those objects without the prefix are clearly distinguished as "generic helpers")
Actually, I think it more needs people to wrote those libraries.
Cyrille and I were just talking about this here in Barcelona. Pd
definitely needs working namespaces and logically organized
libraries. If you also think this is important, then pick a topic
and make a clean, well-organized library around it.
.hc
Luke _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
On Fri, 4 Jul 2008, Hans-Christoph Steiner wrote:
Actually, I think it more needs people to wrote those libraries.
In theory, but then, when they get written, they are "better distributed as a separate download". (why not "svn copy" ?)
http://lists.puredata.info/pipermail/pd-list/2008-05/062201.html
It's not my project, but I'm still wondering.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Thu, 3 Jul 2008, Luke Iannini wrote:
And, the second answer is other-language (e.g. Python) style reorganization of libraries to be author-agnostic - ordered by functionality. But, this requires a Organization Czar, it seems, and maybe no one is ready to be that person yet, so, until then, such helper-objects must stay in the homes of their authors for there's nowhere else to put them. (also, I think in this case, since grid-operators in GF have the #-prefix, those objects without the prefix are clearly distinguished as "generic helpers")
They aren't necessarily generic helpers. For example, two of the three HPGL-handling classes don't start with "#" (nor with "gf.") and they don't anything that makes sense to a patch that doesn't deal with HPGL plotters. This is because it's easier to get stuff installed if I don't make a new library for each topic. Making separate libraries doesn't make my life any easier in any other aspect.
I don't know why this discussion gets moved to pd-list instead of pd-dev. Not particularly against it, but I don't see the point.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec