Re: [PD] suggestion: $0 in messages

2018-04-17 Thread Dan Wilcox
Ok, cool. We should port this as an alternate implementation PR on Github. I think it's worth trying to backport stuff like this and stay more in sync, when possible. Thanks for posting :) enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com > On Apr 17, 2018, at 2:48 PM, J

Re: [PD] suggestion: $0 in messages

2018-04-17 Thread Jonathan Wilkes via Pd-list
> On Tuesday, April 17, 2018, 8:10:47 AM EDT, Dan Wilcox > wrote: > Is this compatible with  > https://github.com/pure-data/pure-data/pull/347/files? Are there pros/cons > between the implementations?  Also-- the code I merged into Purr Data adds a binbuf_error routine which links evalu

Re: [PD] suggestion: $0 in messages

2018-04-17 Thread Jonathan Wilkes via Pd-list
> On Tuesday, April 17, 2018, 8:43:26 AM EDT, Christof Ressi wrote: > I am biased of course, but checking for t_message_responder class within > canvas_getdollarzero seems a bit weird to me. Yeah, it should probably be renamed to something like pd_getdollarzero. It's not a public functio

Re: [PD] suggestion: $0 in messages

2018-04-17 Thread Jonathan Wilkes via Pd-list
> On Tuesday, April 17, 2018, 8:10:47 AM EDT, Dan Wilcox wrote: > Is this compatible with  > https://github.com/pure-data/pure-data/pull/347/files? Are there pros/cons > between the implementations? This implementation doesn't require a change to binbuf_eval's interface. It also cache

Re: [PD] suggestion: $0 in messages

2018-04-17 Thread Christof Ressi
value explicitly. but it's a matter of taste I guess.    Gesendet: Dienstag, 17. April 2018 um 14:10 Uhr Von: "Dan Wilcox" An: "Jonathan Wilkes" Cc: Pd-List , "Christof Ressi" Betreff: Re: [PD] suggestion: $0 in messages Is this compatible with https://gith

Re: [PD] suggestion: $0 in messages

2018-04-17 Thread Dan Wilcox
es mailto:jancs...@yahoo.com>> > To: pd-list mailto:pd-l...@iem.at>>, Christof Ressi > mailto:christof.re...@gmx.at>> > Subject: Re: [PD] suggestion: $0 in messages > Message-ID: <90704651.1049256.1523926967...@mail.yahoo.com > <mailto:90704651.1049256.152

Re: [PD] suggestion: $0 in messages

2018-04-16 Thread Jonathan Wilkes via Pd-list
> On Saturday, April 7, 2018, 10:23:31 PM EDT, Jonathan Wilkes via Pd-list > wrote: >> On Friday, April 6, 2018, 11:21:05 AM EDT, Christof Ressi >> wrote: >> here's an alternative implementation which uses no additional memory >> >> allocations but is more invasive: >> https://githu

Re: [PD] suggestion: $0 in messages

2018-04-07 Thread Jonathan Wilkes via Pd-list
> On Friday, April 6, 2018, 11:21:05 AM EDT, Christof Ressi > wrote: > here's an alternative implementation which uses no additional memory > > allocations but is more invasive: > https://github.com/pure-data/pure-data/pull/347 Here's the beginning of another implementation with some perfo

Re: [PD] suggestion: $0 in messages

2018-04-06 Thread Christof Ressi
x" Betreff: Re: [PD] suggestion: $0 in messages On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list wrote:     > I don't think it makes sense to have a malloc() and free() for each call to a msg box. > Pd is already not very real-time friendly, why make it worse?

Re: [PD] suggestion: $0 in messages

2018-04-06 Thread Giulio Moro via Pd-list
Yeah sorry I have no idea how deep these nest, I am not familiar with that part of the code. In this case the memory could be allocated in the stack and then passed to something like   pd_pushsymnoalloc(t_pd *x, t_gstack* y)  which should in turn skip the allocation. But yes, a cached value seems

Re: [PD] suggestion: $0 in messages

2018-04-06 Thread Jonathan Wilkes via Pd-list
On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list wrote: > I don't think it makes sense to have a malloc() and free() for each call to > a msg box. > Pd is already not very real-time friendly, why make it worse? > There could be ... > - statically allocated memory for t_gsta

Re: [PD] suggestion: $0 in messages

2018-04-06 Thread Dan Wilcox
The second lazy-load option might work pretty well, but what would the per-instance/threading considerations be? > On Apr 6, 2018, at 12:21 PM, Giulio Moro wrote: > > I don't think it makes sense to have a malloc() and free() for each call to a > msg box. > Pd is already not very real-time fri

Re: [PD] suggestion: $0 in messages

2018-04-06 Thread Giulio Moro via Pd-list
I don't think it makes sense to have a malloc() and free() for each call to a msg box. Pd is already not very real-time friendly, why make it worse? There could be ... - statically allocated memory for t_gstack y in pd_pushsym - a pre-allocated memory pool meant for short-lived memory allocations

Re: [PD] suggestion: $0 in messages

2018-04-06 Thread Roman Haefeli
On Don, 2018-04-05 at 21:17 +0200, Dan Wilcox wrote: > test? https://github.com/pure-data/pure-data/pull/346 Better do than talk, hey? ;-) Works fine and is definitely convenient. Can't see any disadvantage or problem with compatibility, though it challenges my notion of how things are supposed t

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Alexandre Torres Porres
2018-04-05 16:17 GMT-03:00 Dan Wilcox : > test? https://github.com/pure-data/pure-data/pull/346 > wow, didn't see that coming :) THANKS! Well, since I opened this thread and mentioned I wanted to do such a Pull Request, let me respond so some issues raised here. One argument against this - and o

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Jonathan Wilkes via Pd-list
> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox > wrote: > test? https://github.com/pure-data/pure-data/pull/346 That will add a malloc/free for every method call to a msg box. So I'd measure the performance impact before using that implementation. On the l2ork dev list I mentioned

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Dan Wilcox
test? https://github.com/pure-data/pure-data/pull/346 Dan Wilcox @danomatika danomatika.com robotcowboy.com

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Seb Shader via Pd-list
>>>What is wrong with [my_selector(--[list]--[$1( >> for instance, [42(--[list]--[$1( will give 42 not float, >> similarly [symbol crabs(--[list]--[$1( will give crabs not symbol > >Also it seems reasonable to just have 1 object box for querying a selector, > >which is a main element of t

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Christof Ressi
t it *doesn't* work the same way as in object boxes. BTW: I think it's unfortunate that msgbox allows 'anything' messages at all. Gesendet: Donnerstag, 05. April 2018 um 17:44 Uhr Von: "Jonathan Wilkes via Pd-list" An: pd-list@lists.iem.at, "sebfumas...@aol.co

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Jonathan Wilkes via Pd-list
>>What is wrong with [my_selector(--[list]--[$1( > for instance, [42(--[list]--[$1( will give 42 not float, > similarly [symbol > crabs(--[list]--[$1( will give crabs not symbol > Also it seems reasonable to > just have 1 object box for querying a selector, > which is a main element of > the pd

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Jonathan Wilkes via Pd-list
>> whereas you cannot get an abstraction's selector (which would >> be handy >> for error reporting).  > What is the selector of an abstraction? [my_abs arg1 arg2] The selector is "my_abs". The reason consistency probably keeps coming up is because everything on the Pd canvas as well as Pd file

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Seb Shader via Pd-list
>What is wrong with [my_selector(--[list]--[$1( for instance, [42(--[list]--[$1( will give 42 not float, similarly [symbol crabs(--[list]--[$1( will give crabs not symbol Also it seems reasonable to just have 1 object box for querying a selector, which is a main element of the pd message environ

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Jonathan Wilkes via Pd-list
> From patching I know that it would be far more convenient to be able to > reference the patch-local $0 variable in messages. That's what users have requested $0 in msg boxes to do for over a decade. And that is what Ico implemented in Pd-l2ork. > Perhaps in that case there should also be a [se

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread IOhannes m zmoelnig
On 2018-04-05 13:44, Roman Haefeli wrote: > I already pointed out that dollar variables > are a totally different thing in messages and objects. they are very much the same (from Pd's POV). > >> whereas you cannot get an abstraction's selector (which would  >> be handy for error reporting).  >

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread hans w. koch
yes, great to say that, chris: thank you so much miller for the wonderful pure data! hans > Am 05.04.2018 um 12:53 schrieb Chris McCormick : > > Anyway, I'm sorry to conjure up the spectacle of another several decades of > challenging software development and maintenance work. We probably don'

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Roman Haefeli
On Die, 2018-04-03 at 13:52 +, Jonathan Wilkes wrote: > > Why is nobody complaining about not being able to use the third > > creation argument directly withing a message? What's the fuzz about > the > > $0? > > $0 isn't part of the argument vector. It's certainly not part of the incoming me

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Chris McCormick
On 03/04/18 03:02, Miller Puckette wrote: shouldn't this be expanded into a full-on scripting language? Heck yes! For audio vectors the dataflow paradigm is glorious. But building k-rate algorithms and logic with a mouse makes one i-rate (a bit weird to whinge about this when I choose to spen

Re: [PD] suggestion: $0 in messages

2018-04-05 Thread Chris McCormick
On 03/04/18 21:52, Jonathan Wilkes via Pd-list wrote: When users for a decade have said they wanted $0 in msg boxes, they mean that they want to use Pd's notion of send-symbol locality inside message boxes. They want that instead of manually querying the value of a reserved dollarsign variable an

Re: [PD] suggestion: $0 in messages

2018-04-04 Thread Seb Shader via Pd-list
t: Wed, Apr 4, 2018 1:00 am Subject: Re: [PD] suggestion: $0 in messages > Why is nobody complaining about not being able to use the third > creation argument directly withing a message? What's the fuzz about the > $0? $0 isn't part of the argument vector. It&#x

Re: [PD] suggestion: $0 in messages

2018-04-04 Thread Jonathan Wilkes via Pd-list
> Why is nobody complaining about not being able to use the third > creation > argument directly withing a message? What's the fuzz about the > $0? $0 isn't part of the argument vector. It's a unique id automatically generated for a patch/abstraction which the user happens to access through a dol

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Alexandre Torres Porres
2018-04-02 15:55 GMT-03:00 Roman Haefeli : > > By implementing that, you would once forever prohibit the proper way to > expand $0 which is expanding to the selector of the message. I agree it would make sense for $0 to expand to the message selector. But that doesn't happen... So I don't see

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Alexandre Torres Porres
2018-04-02 16:02 GMT-03:00 Miller Puckette : > Well, I've been trying to stay out of this, but here's a thing... someone > could implement a "msg" object that you could invoke like > [msg 1 $0 3] to get a message with a 'true' $0 built into it. This would > also work for $1, etc, so would be much

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread João Pais
For me, I can't count how many times I had to add a [$0], or a pack or some extra workaround before a message so that I could send messages to my variables (I hardly use variables without a $0). I can't count how many times I had to loop back the outlet of a [+ 1] to the right inlet of a [f ] to

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Miller Puckette
Well, I've been trying to stay out of this, but here's a thing... someone could implement a "msg" object that you could invoke like [msg 1 $0 3] to get a message with a 'true' $0 built into it. This would also work for $1, etc, so would be much smarter than changing the message box semantics. But

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Roman Haefeli
On Mon, 2018-04-02 at 05:01 -0700, Derek Kwan wrote: > > For me, I can't count how many times I had to add a [$0], or a pack > > or > > some extra workaround before a message so that I could send > > messages > > to my variables (I hardly use variables without a $0). > > > > Joao > I do face this

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Roman Haefeli
On Mon, 2018-04-02 at 11:26 +0200, João Pais wrote: >  > For me, I can't count how many times I had to add a [$0], or a pack > or some extra workaround before a message so that I could send > messages to my variables (I hardly use variables without a $0). I can't count how many times I had to loop

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Roman Haefeli
yawn. On Son, 2018-04-01 at 17:42 -0300, Alexandre Torres Porres wrote: > Hi, currently, if you want to use $0, you need an object cause it > becomes "0" when it's inside messages. > > Pd-l2ork and Purr Data implemented a way that $0 works in the same > way as in objects than in messages, an

[PD] suggestion: $0 in messages

2018-04-02 Thread Nicolas Danet
: [PD] suggestion: $0 in messages 2018-04-02 9:02 GMT-03:00 Nicolas Danet : > > I also added that feature in my fork "Spaghettis". what's and where's that? :) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE a

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Alexandre Torres Porres
2018-04-02 9:02 GMT-03:00 Nicolas Danet : > > I also added that feature in my fork "Spaghettis". what's and where's that? :) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

[PD] suggestion: $0 in messages

2018-04-02 Thread Nicolas Danet
I also added that feature in my fork "Spaghettis". It is very handy. For now i have not found any situation that make me regret that "inconsistent" behavior. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.pur

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Derek Kwan
> > like mostly, i'm opposing. this has been discussed about 15 years > ago, and my arguments still stand (mainly: consistency with > dollar-parsing throughout Pd) > Yes, but there is no consistency either now. So the question would be: > is the current inconsistency a productive one (d

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread Matt Davey
even though it is bad practice, i'd support $0 being passed to messages the same as it is to objects. Just easier that way. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

2018-04-02 Thread João Pais
> > I just can't see how there could be any problem, or, in other words, I > > can't see how $0 becoming "0" in messages is a desired feature or if > anyone > > could rely on this behaviour. > > "0" certainly isn't a good behaviour. > What would be the good behaviour, in this case? > > > > > But

Re: [PD] suggestion: $0 in messages

2018-04-01 Thread Alexandre Torres Porres
2018-04-01 18:51 GMT-03:00 IOhannes m zmölnig : > > like mostly, i'm opposing. > this has been discussed about 15 years ago, and my arguments still stand > (mainly: consistency with dollar-parsing throughout Pd) > Hi, just so I understand the issue, what complications would derive from this incon

Re: [PD] suggestion: $0 in messages

2018-04-01 Thread IOhannes m zmölnig
On 04/01/2018 10:42 PM, Alexandre Torres Porres wrote: > I just can't see how there could be any problem, or, in other words, I > can't see how $0 becoming "0" in messages is a desired feature or if anyone > could rely on this behaviour. "0" certainly isn't a good behaviour. > > But, if there's

[PD] suggestion: $0 in messages

2018-04-01 Thread Alexandre Torres Porres
Hi, currently, if you want to use $0, you need an object cause it becomes "0" when it's inside messages. Pd-l2ork and Purr Data implemented a way that $0 works in the same way as in objects than in messages, and I think it is a great feature, as many patches can be significantly simplified. I gues