Hi,
I've just made a new external [getpatchname], which will return the filename of the patch in which it is instantiated. It has been committed to the CVS under externals/postlude, and has been tested under Linux.
This functionality may well be available somewhere else, in which case I would be intruiged to know how/where - particularly if it can be done without externals.
Also, the external is currently buggy in the sense that it retains the patch name from the external's instantiation, so if you rename the patch then send a 'bang' message to the object, it will report the 'old' patch name. This is because accessing canvas_getcurrent()->gl_name from a method call rather than from getpatchname_new results in a segfault. I would be interested to know why this is....
best,
Jamie
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
HI all,
canvas_getcurrrent() is only valid in the context of teh new() routine... you can call it there and save the result in the instance structure if you need to refer back to it (as in this case.)
cheers Miller
On Wed, Jul 12, 2006 at 05:00:46PM +0100, Jamie Bullock wrote:
Hi,
I've just made a new external [getpatchname], which will return the filename of the patch in which it is instantiated. It has been committed to the CVS under externals/postlude, and has been tested under Linux.
This functionality may well be available somewhere else, in which case I would be intruiged to know how/where - particularly if it can be done without externals.
Also, the external is currently buggy in the sense that it retains the patch name from the external's instantiation, so if you rename the patch then send a 'bang' message to the object, it will report the 'old' patch name. This is because accessing canvas_getcurrent()->gl_name from a method call rather than from getpatchname_new results in a segfault. I would be interested to know why this is....
best,
Jamie
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 12 Jul 2006, Miller Puckette wrote:
On Wed, Jul 12, 2006 at 05:00:46PM +0100, Jamie Bullock wrote:
Also, the external is currently buggy in the sense that it retains the patch name from the external's instantiation, so if you rename the patch then send a 'bang' message to the object, it will report the 'old' patch name. This is because accessing canvas_getcurrent()->gl_name from a method call rather than from getpatchname_new results in a segfault. I would be interested to know why this is....
canvas_getcurrrent() is only valid in the context of teh new() routine... you can call it there and save the result in the instance structure if you need to refer back to it (as in this case.)
Yes. It seems like every GUI object has such a backpointer in its struct, including msg (Ctrl+2), floatatom (Ctrl+3) and symbolatom (Ctrl+4). Why not make it standard and add it to t_text ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
The usual reason: my reluctance to add bloat to data structures...
cheers Miller
On Wed, Jul 12, 2006 at 08:55:56PM -0400, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, Miller Puckette wrote:
On Wed, Jul 12, 2006 at 05:00:46PM +0100, Jamie Bullock wrote:
Also, the external is currently buggy in the sense that it retains the patch name from the external's instantiation, so if you rename the patch then send a 'bang' message to the object, it will report the 'old' patch name. This is because accessing canvas_getcurrent()->gl_name from a method call rather than from getpatchname_new results in a segfault. I would be interested to know why this is....
canvas_getcurrrent() is only valid in the context of teh new() routine... you can call it there and save the result in the instance structure if you need to refer back to it (as in this case.)
Yes. It seems like every GUI object has such a backpointer in its struct, including msg (Ctrl+2), floatatom (Ctrl+3) and symbolatom (Ctrl+4). Why not make it standard and add it to t_text ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
On Wed, 12 Jul 2006, Miller Puckette wrote:
The usual reason: my reluctance to add bloat to data structures...
Yeah right. If you really cared about "bloat" you wouldn't be abusing linked-lists the way you do.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hmm, how am I abusing linked lists? If there's a cleaner way to manage them than I'm doing, I should learn it :)
M
On Wed, Jul 12, 2006 at 10:15:53PM -0400, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, Miller Puckette wrote:
The usual reason: my reluctance to add bloat to data structures...
Yeah right. If you really cared about "bloat" you wouldn't be abusing linked-lists the way you do.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
On Thu, 13 Jul 2006, Miller Puckette wrote:
On Wed, Jul 12, 2006 at 10:15:53PM -0400, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, Miller Puckette wrote:
The usual reason: my reluctance to add bloat to data structures...
Yeah right. If you really cared about "bloat" you wouldn't be abusing linked-lists the way you do.
Hmm, how am I abusing linked lists? If there's a cleaner way to manage them than I'm doing, I should learn it :)
This is relative. In January I've upgraded a machine from 512M to 1024M just so that I could compile a program within reasonable delays (avoid swapping RAM to disk). This cost me something approx 80 CAD (72 USD or 56 EUR).
In the light of this, "Wasting" 4 or 8 bytes per object (and then, only the ones that don't already have a t_canvas backpointer) doesn't seem like a big deal.
In DesireData, a lot more is "wasted" because each object has a helper struct attached to it with several fields in it ("observers", "dirties", "visuals", and such). Possibly that no-one will ever complain about the size of those things.
Linked-lists waste memory compared to arrays because each element requires both an extra pointer and a malloc, and the cost of one malloc itself is equivalent to a few pointer-sized variables. RAM amounts don't matter so much, I was only saying that to make a point about "bloat". However there are other downsides of linked-lists that you may want to care about: cache locality and algorithmic time.
Cache locality is a problem because you don't control where your mallocs are, so in the worst case a linked list may have each of its elements in a different memory block, which makes it look like it's taking several dozen times more RAM than it really does, in terms of time that the CPU spends downloading RAM.
Algorithmic time is relevant only for long lists. E.g. appending 1000 elements one at the time at the end of a linked list while keeping on forgetting the pointer to the last element. This takes 500000 steps instead of 1000. Similar things may happen with non-linked lists, e.g. list messages that have to be copied all of the time just to add one element, end up taking 500000 steps if [list] appends single elements 1000 times.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 12 Jul 2006 20:55:56 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 12 Jul 2006, Miller Puckette wrote:
On Wed, Jul 12, 2006 at 05:00:46PM +0100, Jamie Bullock wrote:
Also, the external is currently buggy in the sense that it retains the patch name from the external's instantiation, so if you rename the patch then send a 'bang' message to the object, it will report the 'old' patch name. This is because accessing canvas_getcurrent()->gl_name from a method call rather than from getpatchname_new results in a segfault. I would be interested to know why this is....
canvas_getcurrrent() is only valid in the context of teh new() routine... you can call it there and save the result in the instance structure if you need to refer back to it (as in this case.)
Yes. It seems like every GUI object has such a backpointer in its struct, including msg (Ctrl+2), floatatom (Ctrl+3) and symbolatom (Ctrl+4). Why not make it standard and add it to t_text ?
Could you explain what you mean by 'backpointer', Google and Wikipedia aren't throwing up much. I'm just trying to understand why this doesn't work.
TIA,
Jamie
On Thu, 13 Jul 2006, Jamie Bullock wrote:
On Wed, 12 Jul 2006 20:55:56 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 12 Jul 2006, Miller Puckette wrote:
canvas_getcurrrent() is only valid in the context of teh new() routine... you can call it there and save the result in the instance structure if you need to refer back to it (as in this case.)
Yes. It seems like every GUI object has such a backpointer in its struct, including msg (Ctrl+2), floatatom (Ctrl+3) and symbolatom (Ctrl+4). Why not make it standard and add it to t_text ?
Could you explain what you mean by 'backpointer', Google and Wikipedia aren't throwing up much. I'm just trying to understand why this doesn't work.
a backpointer is simply a pointer to the parent node, supposing that there are parent/child relationships. In Pd, this always means a t_canvas*.
what Miller said is that canvas_getcurrent() is only valid while inside the constructor. So you have to make a backup of the value of canvas_getcurrent() from inside the constructor, into the struct t_getpatchname.
BTW, should it be called [getpatchname] or [getcanvasname] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 13 Jul 2006 17:56:33 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
a backpointer is simply a pointer to the parent node, supposing that there are parent/child relationships. In Pd, this always means a t_canvas*.
what Miller said is that canvas_getcurrent() is only valid while inside the constructor. So you have to make a backup of the value of canvas_getcurrent() from inside the constructor, into the struct t_getpatchname.
Thanks. I thought it was something like that. Taking a closer look it seems to work like this:
It is safe to call canvas_getcurrent() outside the constructor, but it just returns 0 because (&s__X)->s_thing points to NULL, whereas inside the constructor it points to the symbol pointer for the current canvas.
BTW, should it be called [getpatchname] or [getcanvasname] ?
I think [getpatchname] is better. Some people might think that [getcanvasname] returned the name of a [cnv].
Jamie
On Fri, 14 Jul 2006, Jamie Bullock wrote:
I think [getpatchname] is better. Some people might think that [getcanvasname] returned the name of a [cnv].
[cnv] isn't a "canvas". Pd already has "canvas" written all over it as synonymous to "patcher". The name of [cnv] is an aberration that better be fixed ASAP, but it's been 5 years like that and it's still confusing people and no-one does anything about it.
[cnv] doesn't allow to do *anything* that one may associate with what a canvas can do, neither the existing pd canvasses, nor the existing tk canvasses, awt canvasses, nor anything else in any other user interface toolkit, and also it doesn't have anything to do with canvasses that are used for painting on (which is the metaphor underlying all other meanings of "canvas").
Because of that, I nickname [cnv] the "can'tvas", but really, I'd prefer it having a name that makes sense and isn't a joke.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I haven't read the full discussion, but I just wanted to check if you're aware of the [namecanvas] object?
You just put the [namecanvas $1-blabla] on a patch, and then you can send messages to that patch by referring to it as $1-blabla.
This is usually how I send messages to any of my (many many) dynamic patchers that I create from C.
-Mike
On Thu, 13 Jul 2006, Mike Wozniewski wrote:
I haven't read the full discussion, but I just wanted to check if you're aware of the [namecanvas] object?
I don't recall why Jamie wants to have a [getpatchname], but there are possible uses of [getpatchname] which aren't doable by [namecanvas], and vice-versa.
the receive-symbol for a given abstraction will contact all canvases of instances of all abstractions while not allowing to contact a single instance in particular, whereas [namecanvas] will only allow to contact one instance.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, Jul 13, 2006 at 06:56:00PM -0400, Mathieu Bouchard wrote:
On Thu, 13 Jul 2006, Mike Wozniewski wrote:
I haven't read the full discussion, but I just wanted to check if you're aware of the [namecanvas] object?
I don't recall why Jamie wants to have a [getpatchname], but there are possible uses of [getpatchname] which aren't doable by [namecanvas], and vice-versa.
Also, I heard something once about [namecanvas] being deprecated. ;)
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Fri, 14 Jul 2006, Chris McCormick wrote:
On Thu, Jul 13, 2006 at 06:56:00PM -0400, Mathieu Bouchard wrote:
I don't recall why Jamie wants to have a [getpatchname], but there are possible uses of [getpatchname] which aren't doable by [namecanvas], and vice-versa.
Also, I heard something once about [namecanvas] being deprecated. ;)
And your point is?
If I want to do real work with canvases, I don't care what Miller's delusions are, I just use freaking deprecated [namecanvas], and if Miller ever removes freaking deprecated [namecanvas] from Pd, I have several ways out, like using the [bindpatcher] extern which does exactly the same, or hack [namecanvas] back into the pd source, or turn [namecanvas] into an extern, or just not upgrade Pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jul 13, 2006, at 6:51 PM, Mike Wozniewski wrote:
I haven't read the full discussion, but I just wanted to check if
you're aware of the [namecanvas] object?You just put the [namecanvas $1-blabla] on a patch, and then you can send messages to that patch by referring to it as $1-blabla.
This is usually how I send messages to any of my (many many) dynamic patchers that I create from C.
In general, I think its a good idea to have things that are settable
also be query-able. I actually just posted to this list wanting this
object, so I am happy.
.hc
On Thu, 13 Jul 2006, Hans-Christoph Steiner wrote:
On Jul 13, 2006, at 6:51 PM, Mike Wozniewski wrote: In general, I think its a good idea to have things that are settable also be query-able. I actually just posted to this list wanting this object, so I am happy.
In general, I think it's also a good idea to make things uniformly queriable, so that if there is a message "foo $1" for setting some property in an object, a message "get foo" to the same object will output the last $1 value that "foo" was set to, and output it on e.g. the rightmost outlet of the object.
For outletless objects, invisible objects (a canvas isn't generally visible as an actual objectbox) and other receive-symbol situations, there should be another mechanism for getting those properties uniformly. For example, an additional argument to the "get" message could be a receive-symbol for sending the result back.
The problem I see with that is that just a message "get" already means getting all attributes at once, but you can't add a receive symbol to it because it would conflict with the syntax for getting one attribute value in particular. So instead, "get *" could signify get all attributes, and get's $1 would default to * so that just "get" still works.
That's all because I don't want each important object-class to be surrounded by a dozen different helper object-classes that only do query the former, all with non-guessable names not following any convention, written by a dozen different developers who only wrote the one querier that they did need. There has to be a more predictable way for things to work.
See also: Jitter, Flext, GridFlow
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Chris McCormick -
Hans-Christoph Steiner -
Jamie Bullock -
Mathieu Bouchard -
Mike Wozniewski -
Miller Puckette