Hans-Christoph Steiner wrote:

On Oct 26, 2007, at 2:13 PM, Martin Peach wrote:

Any specific suggestions? You mean casting as (entry_class) or something like that?

you have to copy the struct definitions from whereever to your file. look at "iem/iemguts/src/saveargs.c"

fmasdr IOhannes

On Sat, 27 Oct 2007, Hans-Christoph Steiner wrote:

t_canvas *canvas = (t_canvas*)glist_getcanvas(glist); t_atom *ap = binbuf_getvec(canvas->gl_obj.te_binbuf); t_symbol *s = atom_getsymbol(ap);

ah, you seem to have found the same thing that i just thought about and sent you, but you're doing it on the rendering canvas of a canvas.

glist_getcanvas is related to GOP. t_glist and t_canvas are the same thing. see the source of glist_getcanvas to see what it does.

i don't know why you wrote the first part of that, but the latter is correct. the code in my other mail does that.

in theory it would be better to use atom_getsymbol rather than a_w.w_symbol, for future compatibility in case t_atom changes, but so many externals use the latter, that it doesn't matter much which one you use.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

On Sat, 27 Oct 2007, IOhannes m zmoelnig wrote:

Mathieu Bouchard wrote:

...

...

t_canvas *canvas = (t_canvas*)glist_getcanvas(glist); t_atom *ap = binbuf_getvec(canvas->gl_obj.te_binbuf); t_symbol *s = atom_getsymbol(ap);

that is because the example i mentioned does exactly this: get the arguments of the parent.

Oh, I didn't realise that it was quoted from you.

But it does not do exactly what you say it does. If the parent is a closed gop, it fetches the arguments of the parent of the parent, ... recursively. yes?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

Hans-Christoph Steiner wrote:

I tried this in entry_new() and entry_save(), and in both, "binbuf" ends being nothing useful (i.e. segfault):

 t_glist *glist = (t_glist *) canvas_getcurrent();
 t_canvas *canvas = (t_canvas*) glist_getcanvas(glist);
 t_binbuf *binbuf = canvas->gl_obj.te_binbuf;
 t_atom *ap = binbuf_getvec(binbuf);
 t_symbol *classname = atom_getsymbol(ap);

What's going on here? Am I doing something wrong?

I don't know what you're trying to do but it's normal to check for NULL pointers after each of the above statements. That should give you a clue. I suspect that the binbuf doesn't exist if you didn't allocate it yourself.

Martin

I think the binbuf is always present, but in the case of a top-level canvas, it might be empty; binbuf_getnatom() tells you how many atoms there are.

cheers Miller

On Sun, Oct 28, 2007 at 10:14:48PM -0400, Hans-Christoph Steiner wrote:

On Oct 28, 2007, at 8:47 PM, Martin Peach wrote:

...

Hans-Christoph Steiner wrote:

...

I tried this in entry_new() and entry_save(), and in both, "binbuf" ends being nothing useful (i.e. segfault):

 t_glist *glist = (t_glist *) canvas_getcurrent();
 t_canvas *canvas = (t_canvas*) glist_getcanvas(glist);
 t_binbuf *binbuf = canvas->gl_obj.te_binbuf;
 t_atom *ap = binbuf_getvec(binbuf);
 t_symbol *classname = atom_getsymbol(ap);

What's going on here? Am I doing something wrong?

I don't know what you're trying to do but it's normal to check for NULL pointers after each of the above statements. That should give you a clue. I suspect that the binbuf doesn't exist if you didn't allocate it yourself.

I am just following IOhannes' code, which he says works (I haven't tested it...)

http://pure-data.cvs.sourceforge.net/pure-data/externals/iem/iemguts/ src/saveargs.c?view=markup

Somehow, he magically gets a binbuf with contents in it! ;)

.hc

---

---

There is no way to peace, peace is the way. -A.J. Muste

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

Hmm, well, the way Pd gets it is looking in the binbuf. But perhaps you need to look in the binbuf for the object you're looking at, not that of the containing canvas, no? Or, on the other hand. perhaps you're trying to get the name of the abstraction the object is part of?

cheers M

On Sun, Oct 28, 2007 at 10:57:52PM -0400, Hans-Christoph Steiner wrote:

It sounds like this isn't the way to do it then. But somewhere the whole classname with the namespace prefix must be stored for every single object instantiated, since it will get written out to the file. How do I access that?

.hc

On Oct 28, 2007, at 10:50 PM, Miller Puckette wrote:

...

I think the binbuf is always present, but in the case of a top-level canvas, it might be empty; binbuf_getnatom() tells you how many atoms there are.

cheers Miller

On Sun, Oct 28, 2007 at 10:14:48PM -0400, Hans-Christoph Steiner wrote:

...

On Oct 28, 2007, at 8:47 PM, Martin Peach wrote:

...

Hans-Christoph Steiner wrote:

...

I tried this in entry_new() and entry_save(), and in both, "binbuf" ends being nothing useful (i.e. segfault):

 t_glist *glist = (t_glist *) canvas_getcurrent();
 t_canvas *canvas = (t_canvas*) glist_getcanvas(glist);
 t_binbuf *binbuf = canvas->gl_obj.te_binbuf;
 t_atom *ap = binbuf_getvec(binbuf);
 t_symbol *classname = atom_getsymbol(ap);

What's going on here? Am I doing something wrong?

I don't know what you're trying to do but it's normal to check for NULL pointers after each of the above statements. That should give you a clue. I suspect that the binbuf doesn't exist if you didn't allocate it yourself.

I am just following IOhannes' code, which he says works (I haven't tested it...)

http://pure-data.cvs.sourceforge.net/pure-data/externals/iem/iemguts/ src/saveargs.c?view=markup

Somehow, he magically gets a binbuf with contents in it! ;)

.hc

---

---

---

There is no way to peace, peace is the way. -A.J. Muste

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

---

You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

On Mon, 29 Oct 2007, IOhannes m zmoelnig wrote:

hmm, i think this is just a problem with the code i mentioned: i pointed hc to the [iemguts/saveargs] object, to look how to get the classname of _a_ class. the sole purpose of this object ([saveargs]) is to get (and set) the name (and arguments) of the abstraction it is living in.

So, is your abstraction compatible with GOP ?

t_canvas *glist_getcanvas(t_glist *x) { while (x->gl_owner && !x->gl_havewindow && x->gl_isgraph) x = x->gl_owner; return((t_canvas *)x); }

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

Mathieu Bouchard wrote:

On Wed, 31 Oct 2007, Mathieu Bouchard wrote:

...

On Mon, 29 Oct 2007, IOhannes m zmoelnig wrote:

...

hmm, i think this is just a problem with the code i mentioned: i pointed hc to the [iemguts/saveargs] object, to look how to get the classname of _a_ class. the sole purpose of this object ([saveargs]) is to get (and set) the name (and arguments) of the abstraction it is living in.

So, is your abstraction compatible with GOP ?

duh. I mean external, of course.

yes it is. in fact, it was written with GOP-abstractions in mind. check out the example-file.

fgmdr.sa IOhannes

On Oct 26, 2007, at 8:20 PM, Mathieu Bouchard wrote:

On Fri, 26 Oct 2007, Hans-Christoph Steiner wrote:

...

binbuf_addv(b, "ssiisiiss", gensym("#X"),gensym("obj"), x->x_obj.te_xpix, x->x_obj.te_ypix, pd_class(&z-

...

g_pd)->c_name,

          x->x_width, x->x_height, x->x_bgcolour, x->x_fgcolour);

entry.c:504: error: dereferencing pointer to incomplete type

Oh yeah, you need to #include "m_imp.h" or something, sorry.

Because, in m_pd.h, only the existence of t_class is mentioned, not the content definition of t_class.

Duh... thanks. It now compiles and runs, but sadly, this doesn't work:

binbuf_addv(b, "ssiisiiss", gensym("#X"),gensym("obj"), x->x_obj.te_xpix, x->x_obj.te_ypix, pd_class(&z->g_pd)->c_name, x->x_width, x->x_height, x->x_bgcolour, x->x_fgcolour);

I stuck this in entry_new() also

post("new objectclass: %s", (*(t_pd *)x)->c_name->s_name);

Both of them returned "entry" as the class, even when I loaded with a namespace prefix.

.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

On Sat, 27 Oct 2007, Claude Heiland-Allen wrote:

See attached external and Pd patch for a solution (workaround?) using an A_GIMME constructor, at least with pd-miller-0.40-2...

This is because the first argument of the constructor is the same thing as the first element of the binbuf of the object, as that element is the selector in the message that is sent to [objectmaker]. So it does like what our latest solutions do, but because you get it from the constructor, you can only use it in the constructor or you have to store it. but it's already stored in the object, as the first element of the binbuf, so...

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

On Sat, 27 Oct 2007, Claude Heiland-Allen wrote:

Mathieu Bouchard wrote:

...

On Sat, 27 Oct 2007, Claude Heiland-Allen wrote:

...

See attached external and Pd patch for a solution (workaround?) using an A_GIMME constructor, at least with pd-miller-0.40-2...

This is because the first argument of the constructor is the same thing as the first element of the binbuf of the object, as that element is the selector in the message that is sent to [objectmaker]. So it does like what our latest solutions do, but because you get it from the constructor, you can only use it in the constructor or you have to store it. but it's already stored in the object, as the first element of the binbuf, so...

Ah, I didn't quite understand what was going on. Thanks for clarification.

If you understood it now you'd be asking me why is it that even though the constructor looks like a anything-method, and that in general it's so much like a method in an object, why is it that it doesn't have a self argument? I don't know. Miller felt like making a special case for that. Deep in the internals you have things like "if (x==&pd_objectmaker) ..."

(I was going to say requiring non-m_pd.h files was bad, but that's no issue for modifying Pd itself...)

If every external class that has a savefn has to do it, it's not about modifying pd itself. besides, apart from iemgui, pd internals don't use savefn, they use a big if/else with every special case in it.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

On Oct 27, 2007, at 2:25 AM, Mathieu Bouchard wrote:

On Sat, 27 Oct 2007, Hans-Christoph Steiner wrote:

...

Duh... thanks. It now compiles and runs, but sadly, this doesn't work: Both of them returned "entry" as the class, even when I loaded with a namespace prefix.

I don't really know how your namespace system works. Do you have any field that is set with that prefix? you could lookup -

...

c_externdir->s_name, but it stores only the absolute dirname,

which is too much.

There's at least one version of the namespace system that was putting the prefix in ->c_name because DesireData's class browser was broken by such a change, back in devel_0_39 days.

Now that I think of it, you could try:

binbuf_getvec(((t_text *)x)->te_binbuf)[0]->a_w.w_symbol->s_name

or something like that.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

post("classname: %s", binbuf_getvec(((t_text *)x)->te_binbuf)[0]-

a_w.w_symbol->s_name);

gives me:

entry.c:671: error: request for member 'te_binbuf' in something not a structure or union entry.c:671: error: invalid type argument of '->'

.hc

------------------------------------------------------------------------ ----

Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams

On Oct 27, 2007, at 2:25 AM, Mathieu Bouchard wrote:

On Sat, 27 Oct 2007, Hans-Christoph Steiner wrote:

...

Duh... thanks. It now compiles and runs, but sadly, this doesn't work: Both of them returned "entry" as the class, even when I loaded with a namespace prefix.

I don't really know how your namespace system works. Do you have any field that is set with that prefix? you could lookup -

...

c_externdir->s_name, but it stores only the absolute dirname,

which is too much.

There's at least one version of the namespace system that was putting the prefix in ->c_name because DesireData's class browser was broken by such a change, back in devel_0_39 days.

Now that I think of it, you could try:

binbuf_getvec(((t_text *)x)->te_binbuf)[0]->a_w.w_symbol->s_name

or something like that.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

In another attempt, this is gave me a segfault:

t_atom *ap = binbuf_getvec(((t_text *)x)->te_binbuf);

.hc

------------------------------------------------------------------------ ----

Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams