On Nov 20, 2007, at 3:21 PM, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: >> On Nov 20, 2007, at 12:16 PM, IOhannes m zmoelnig wrote: >>> Hans-Christoph Steiner wrote: >>>> Is there any particular reason why [print] does not accept >>>> float arguments? I think I want to add them. >>> probably for a similar reason like why [send] does not accept >>> float arguments? >>> >>> (this is of course not true; [send] requires "binding" to a >>> label, and numbers (A_FLOAT) do not provide a mechanism to do >>> so, whereas symbols do) >> I don't understand your point. Basically what I am asking is, >> would anyone object to adding the ability to handle float args to >> [print]? > > which point? > i just tried to give an explanation why things are as they are. > not an excuse. > and i also mentioned that my explanation is most likely wrong as it > draws parallels where there really are none. > > i principally don't object to [print] accepting number arguments, > rather i'd favour it. > (but don't want yet another patch that breaks compatibility with pd- > vanilla; so it's just a matter whether miller has some objections - > after all, why does it not accept floats in the first place?)
Now that I look at it, I think it would make sense to allow multiple atoms in the [print] box as well, converting to text using binbuf_gettext(). Then it seems that having a symbol x->x_sym doesn't work as well, and instead it should be char x->x_text [MAXPDSTRING]; .hc ------------------------------------------------------------------------ ---- You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
