johnpitcairn

In some circumstances, I'd like to deferlow all input, calling my input function again from defer_low using the same input. The following works for a bang:

if(some_condition) defer_low(x,(method)oo_Msg_Bang, NIL, 0, 0L);

and simply passing on the message, argc and argv array appears to work for list/anything input:

void Msg_Anything(t_obj *x, t_symbol *message, short argc, t_atom* argv)

if(some_condition) defer_low(x,(method)oo_Msg_Anything, message, argc, argv);

But I'm momentarily stumped: how can I pass int and float input using the defer_low argument format and call the same int/float input function for:

void Msg_Bang(t_obj *x)
{
if(some_condition) defer_low(x,(method)oo_Msg_Bang, NIL, 0, 0L);
}

void Msg_Anything(t_obj *x, t_symbol *message, short argc, t_atom* argv)
{
if(some_condition) defer_low(x,(method)oo_Msg_Anything, message, argc, argv);
}

void Msg_Int(t_obj *x, long n)
void Msg_Float(t_obj *x, double f)


defer_low-for-int-float-input

> In some circumstances, I'd like to deferlow all input, calling my

> input function again from defer_low using the same input. The

> if(some_condition) defer_low(x,(method)oo_Msg_Bang, NIL, 0, 0L);

> and simply passing on the message, argc and argv array appears to

> void Msg_Anything(t_obj *x, t_symbol *message, short argc, t_atom*

> if(some_condition) defer_low(x,(method)oo_Msg_Anything, message,

> But I'm momentarily stumped: how can I pass int and float input using

> the defer_low argument format and call the same int/float input

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

THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.

Never miss a thing. Make Yahoo your home page. 

void Msg_Int(t_obj *x, long n)
{
    t_atom a[1];
    SETLONG(a, n);
    Msg_Anything(x, gensym("int"), 1, a);
}

void Msg_Float(t_obj *x, double f)
{
    t_atom a[1];
    SETFLOAT(a, f);
    Msg_Anything(x, gensym("float"), 1, a);
}

>
> In some circumstances, I'd like to deferlow all input, calling my
> input function again from defer_low using the same input. The
> following works for a bang:
>
> void Msg_Bang(t_obj *x)
> {
> if(some_condition) defer_low(x,(method)oo_Msg_Bang, NIL, 0, 0L);
> }
>
> and simply passing on the message, argc and argv array appears to
> work for list/anything input:
>
> void Msg_Anything(t_obj *x, t_symbol *message, short argc, t_atom*
> argv)
> {
> if(some_condition) defer_low(x,(method)oo_Msg_Anything, message,
> argc, argv);
> }
>
> But I'm momentarily stumped: how can I pass int and float input using
> the defer_low argument format and call the same int/float input
> function for:
>
> void Msg_Int(t_obj *x, long n)
> void Msg_Float(t_obj *x, double f)
>
>
>

------------------------------------------------------------
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION.  ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED.  IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC1-207.
------------------------------------------------------------

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs


Aha. Thanks. I thought something like that might be required but wasn't sure about the correct *message symbol, or the safety of passing a local t_atom to defer_low...

Apparently one of the reasons Cycling has been loath to bow to the constant "can't I have lists with 4,258,364,347,543,237 elements?" questions that come up about weekly on the main list is because atom lists are almost always copied.

I believe atom lists are *always* copied in calls that defer processing. This presumably involves a getbytes() call of whatever the necessary size is.

Quote: Peter Castine wrote on Thu, 06 December 2007 18:46

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

> Apparently one of the reasons Cycling has been loath to bow to the constant "can't I have lists with 4,258,364,347,543,237 elements?" questions that come up about weekly on the main list is because atom lists are almost always copied.

Hmm.. I recall changing the displayed content of object boxes by parsing the string content of argument symbols without explicitly copying them.

Quote: Peter Castine wrote on Thu, 06 December 2007 18:46
----------------------------------------------------
> Apparently one of the reasons Cycling has been loath to bow to the constant "can't I have lists with 4,258,364,347,543,237 elements?" questions that come up about weekly on the main list is because atom lists are almost always copied.

On Dec 6, 2007, at 10:27 AM, Mattijs Kneppers wrote:

> Hmm.. I recall changing the displayed content of object boxes by 

> parsing the string content of argument symbols without explicitly 

FWIW, if I understand you properly (i.e. s=gensym("one thing"); s- 

>s_name = "some other thing") this should be avoided at *all* costs 

as it corrupts the symbol table. Max symbols *need* to be assumed to 

be constant or the whole program breaks. Symbols are copied and 

compared as a 32bit pointer value. The string itself is not copied.

> Hmm.. I recall changing the displayed content of object boxes by  
> parsing the string content of argument symbols without explicitly  
> copying them.

FWIW, if I understand you properly (i.e. s=gensym("one thing"); s- 
 >s_name = "some other thing") this should be avoided at *all* costs  
as it corrupts the symbol table. Max symbols *need* to be assumed to  
be constant or the whole program breaks. Symbols are copied and  
compared as a 32bit pointer value. The string itself is not copied.

Ah! That's right of course. It must have been what went wrong in my case. Thanks for pointing out the relation to the symbol table.

Quote: jkc wrote on Thu, 06 December 2007 21:18

> On Dec 6, 2007, at 10:27 AM, Mattijs Kneppers wrote:

> > Hmm.. I recall changing the displayed content of object boxes by 

> > parsing the string content of argument symbols without explicitly 

> FWIW, if I understand you properly (i.e. s=gensym("one thing"); s- 

> >s_name = "some other thing") this should be avoided at *all* costs 

> as it corrupts the symbol table. Max symbols *need* to be assumed to 

> be constant or the whole program breaks. Symbols are copied and 

> compared as a 32bit pointer value. The string itself is not copied.

Quote: jkc wrote on Thu, 06 December 2007 21:18
----------------------------------------------------
>
> On Dec 6, 2007, at 10:27 AM, Mattijs Kneppers wrote:
>
> > Hmm.. I recall changing the displayed content of object boxes by  
> > parsing the string content of argument symbols without explicitly  
> > copying them.
>
> FWIW, if I understand you properly (i.e. s=gensym("one thing"); s- 
>  >s_name = "some other thing") this should be avoided at *all* costs  
> as it corrupts the symbol table. Max symbols *need* to be assumed to  
> be constant or the whole program breaks. Symbols are copied and  
> compared as a 32bit pointer value. The string itself is not copied.
>
> -Joshua
>
>
----------------------------------------------------


But if I DON'T call gensym(), ie I'm just using a t_symbol struct for some convenient purpose, then the symbol isn't registered in the global symbol table(?) and I CAN safely manipulate that t_symbol's s_name field, right?

On Dec 6, 2007, at 2:44 PM, John Pitcairn wrote:

> But if I DON'T call gensym(), ie I'm just using a t_symbol struct 

> for some convenient purpose, then the symbol isn't registered in 

> the global symbol table(?) and I CAN safely manipulate that 

Any symbol not created by gensym() is relatively useless to standard 

max objects. If you want to do this for special secret hidden sauce 

in your own object set to pass string pointers around, that's fine, 

but no other object will understand it for anything which does symbol 

comparison, which includes among many important things message 

This is to say that in the following example p will never equal q in 

the single pointer comparison if (p==q) which is made on symbols (and 

why message passing and symbol usage can operate at relatively high 

So unless your situation is as I first described (i.e. a knowing 

subversive use of symbol pointers that isn't for actual use by Max 

users in standard objects), then you must always use gensym. Hope 

> But if I DON'T call gensym(), ie I'm just using a t_symbol struct  
> for some convenient purpose, then the symbol isn't registered in  
> the global symbol table(?) and I CAN safely manipulate that  
> t_symbol's s_name field, right?

Any symbol not created by gensym() is relatively useless to standard  
max objects. If you want to do this for special secret hidden sauce  
in your own object set to pass string pointers around, that's fine,  
but no other object will understand it for anything which does symbol  
comparison, which includes among many important things message  
resolution.

This is to say that in the following example p will never equal q in  
the single pointer comparison if (p==q) which is made on symbols (and  
why message passing and symbol usage can operate at relatively high  
speeds).

t_symbol *p=gensym("foo");
t_symbol q;
q->s_name = "foo";

So unless your situation is as I first described (i.e. a knowing  
subversive use of symbol pointers that isn't for actual use by Max  
users in standard objects), then you must always use gensym. Hope  
this clarifies things.

On 2007 Dec 6, at 4:44 PM, John Pitcairn wrote:

> for some convenient purpose, then the symbol isn't registered in the 

> global symbol table(?) and I CAN safely manipulate that t_symbol's 

While this is true, it's extremely bad form, and I would encourage you 

just to make your own struct. Otherwise you will confuse anyone else 

looking at your code -- maybe even yourself!

>
> OK, that explains a lot ...
>
> But if I DON'T call gensym(), ie I'm just using a t_symbol struct  
> for some convenient purpose, then the symbol isn't registered in the  
> global symbol table(?) and I CAN safely manipulate that t_symbol's  
> s_name field, right?

While this is true, it's extremely bad form, and I would encourage you  
just to make your own struct.  Otherwise you will confuse anyone else  
looking at your code -- maybe even yourself!
    Tim


OK, my situation is indeed for purely subversive internal use, but I take Tim's point about confusion. I'll examine what I'm doing accordingly, I don't think there's much that would need to change. Thanks.

defer_low for int & float input