Re: [PD] suggestion: $0 in messages

[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, Jonathan Wilkes  wrote:
> 
> > 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 caches a glist instead of the dollarzero value.
> That seems a little cleaner since glist is public data and
> dollarzero isn't.
> 
> Performance looks ok to me.
> 
> -Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 
evaluation errors to the relevant object.
Like when a user loads some monstrously large patch with many levels of nested 
abstractions and gets an error about an out-of-range argument. Now in Purr Data 
they can click a link to highlight the relevant message box (if it exists).
Finally, there's an additional branch that was merged after this to add some 
simple regression tests.
-Jonathan  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 function so it's easy to change.
-Jonathan

 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 caches a glist instead of the dollarzero value. That seems a little 
cleaner since glist is public data and dollarzero isn't.
Performance looks ok to me.
-Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Christof Ressi]

I am biased of course, but checking for t_message_responder class within 
canvas_getdollarzero seems a bit weird to me. I rather preferred to add a 
function which gets the canvas $0 from a glist (which can be useful anyway) and 
made both binbuf_dorealizedollarsym and binbuf_doeval take the $0 value 
explicitly. but it's a matter of taste I guess. 

 
Gesendet: Dienstag, 17. April 2018 um 14:10 Uhr
Von: "Dan Wilcox" <danomat...@gmail.com>
An: "Jonathan Wilkes" <jancs...@yahoo.com>
Cc: Pd-List <pd-list@lists.iem.at>, "Christof Ressi" <christof.re...@gmx.at>
Betreff: Re: [PD] suggestion: $0 in messages

Is this compatible with https://github.com/pure-data/pure-data/pull/347/files? 
Are there pros/cons between the implementations? 
 
On Apr 17, 2018, at 12:00 PM, 
pd-list-requ...@lists.iem.at[mailto:pd-list-requ...@lists.iem.at] wrote: 
From: Jonathan Wilkes <jancs...@yahoo.com[mailto:jancs...@yahoo.com]>
To: pd-list <pd-l...@iem.at[mailto:pd-l...@iem.at]>, Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@gmx.at]>
Subject: Re: [PD] suggestion: $0 in messages
Message-ID: 
<90704651.1049256.1523926967...@mail.yahoo.com[mailto:90704651.1049256.1523926967...@mail.yahoo.com]>
Content-Type: text/plain; charset="utf-8"
 On Saturday, April 7, 2018, 10:23:31 PM EDT, Jonathan Wilkes via Pd-list 
<pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> wrote:  On Friday, April 6, 
2018, 11:21:05 AM EDT, Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@gmx.at]> 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[https://github.com/pure-data/pure-data/pull/347]Here's
 the beginning of another implementation with some performance 
tests:https://git.purrdata.net/jwilkes/purr-data/merge_requests/199[https://git.purrdata.net/jwilkes/purr-data/merge_requests/199]
 This has now been merged into 2.5.1.
-Jonathan 


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Dan Wilcox]

Is this compatible with https://github.com/pure-data/pure-data/pull/347/files? 
<https://github.com/pure-data/pure-data/pull/347/files?> Are there pros/cons 
between the implementations? 

> On Apr 17, 2018, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Jonathan Wilkes <jancs...@yahoo.com <mailto:jancs...@yahoo.com>>
> To: pd-list <pd-l...@iem.at <mailto:pd-l...@iem.at>>, Christof Ressi 
> <christof.re...@gmx.at <mailto:christof.re...@gmx.at>>
> Subject: Re: [PD] suggestion: $0 in messages
> Message-ID: <90704651.1049256.1523926967...@mail.yahoo.com 
> <mailto:90704651.1049256.1523926967...@mail.yahoo.com>>
> Content-Type: text/plain; charset="utf-8"
> 
>> On Saturday, April 7, 2018, 10:23:31 PM EDT, Jonathan Wilkes via Pd-list 
>> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> wrote: 
> 
>>> On Friday, April 6, 2018, 11:21:05 AM EDT, Christof Ressi 
>>> <christof.re...@gmx.at <mailto:christof.re...@gmx.at>> 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 
>>> <https://github.com/pure-data/pure-data/pull/347>
>> Here's the beginning of another implementation with some performance 
>> tests:https://git.purrdata.net/jwilkes/purr-data/merge_requests/199 
>> <https://git.purrdata.net/jwilkes/purr-data/merge_requests/199>
>  This has now been merged into 2.5.1.
> -Jonathan


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 performance 
tests:https://git.purrdata.net/jwilkes/purr-data/merge_requests/199
  Performance looks decent on armv7l and it doesn't require changes to 
binbuf_eval.
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Christof Ressi]

here's an alternative implementation which uses no additional memory allocations but is more invasive: https://github.com/pure-data/pure-data/pull/347
 

Gesendet: Freitag, 06. April 2018 um 14:41 Uhr
Von: "Jonathan Wilkes via Pd-list" <pd-list@lists.iem.at>
An: pd-list@lists.iem.at, "Dan Wilcox" <danomat...@gmail.com>
Betreff: Re: [PD] suggestion: $0 in messages



On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list <pd-list@lists.iem.at> 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_gstack y in pd_pushsym

 

But you can nest arbitrarily deep in patch loading, no?

 

Also, patch loading time typically doesn't need to happen in realtime, as

you're also allocating memory for objects during that time plus probably

taking an i/o hit when loading abstractions.

 

On the other hand, it would be interesting to use a memory pool like you

mention below and see its effect on load time. At least for the "canvas" field

of data structures in Purr Data I cache the binbuf so there's no i/o hit

there, only memory allocations.


> - a pre-allocated memory pool meant for short-lived memory allocations to be used in real-time critical cases like this. If no memory available from the pool, only then allocate it (or allocate a new pool). There are probably other cases around the codebase where this would make sense, but why not starting with this?

 

I'd measure performance here first to determine the best course of action.

Even with a memory pool pd_pushsym is doing quite a few assignments. Pushing

and popping on every msg box method may get be noticeably different than

dereferencing a single cached value.

 

Measuring [trigger] performance I could see differences depending on how

exactly the loop for the outlets was constructed.

 

-Jonathan


> Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> wrote:

> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox <danomat...@gmail.com> 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 a potential way to cache the glist
in the t_messresponder to avoid allocation at message evaluation time.
But we haven't implemented that yet (nor measured the current
performance hit).

-Jonathan






Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list





___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 to make 
much more sense.

On the topic of pre-allocated memory pools, SuperCollider, for one, uses a 
pre-allocated pool 
https://github.com/supercollider/supercollider/blob/master/common/SC_AllocPool.cpp
 but it throws an exception upon failure instead of allocating more memory.

Best,
Giulio

On Friday, 6 April 2018, 13:42:26 BST, Jonathan Wilkes via Pd-list 
 wrote: 
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_gstack y in pd_pushsym

But you can nest arbitrarily deep in patch loading, no?

Also, patch loading time typically doesn't need to happen in realtime, as 
you're also allocating memory for objects during that time plus probably 
taking an i/o hit when loading abstractions.

On the other hand, it would be interesting to use a memory pool like you 
mention below and see its effect on load time. At least for the "canvas" field 
of data structures in Purr Data I cache the binbuf so there's no i/o hit 
there, only memory allocations.


> - a pre-allocated memory pool meant for short-lived memory allocations to be 
> used in real-time critical cases like this. If no memory available from the 
> pool, only then allocate it (or allocate a new pool). There are probably 
> other cases around the codebase where this would make sense, but why not 
> starting with this?

I'd measure performance here first to determine the best course of action.
Even with a memory pool pd_pushsym is doing quite a few assignments. Pushing 
and popping on every msg box method may get be noticeably different than 
dereferencing a single cached value.

Measuring [trigger] performance I could see differences depending on how 
exactly the loop for the outlets was constructed.

-Jonathan


> Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
 wrote: 

> 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 a potential way to cache the glist 
in the t_messresponder to avoid allocation at message evaluation time. 
But we haven't implemented that yet (nor measured the current 
performance hit).

-Jonathan






Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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_gstack y in pd_pushsym
But you can nest arbitrarily deep in patch loading, no?
Also, patch loading time typically doesn't need to happen in realtime, as 
you're also allocating memory for objects during that time plus probably taking 
an i/o hit when loading abstractions.

On the other hand, it would be interesting to use a memory pool like you 
mention below and see its effect on load time. At least for the "canvas" field 
of data structures in Purr Data I cache the binbuf so there's no i/o hit there, 
only memory allocations.
 
> - a pre-allocated memory pool meant for short-lived memory allocations to be 
> used in real-time critical cases like this. If no memory available from the 
> pool, only then allocate it (or allocate a new pool). There are probably 
> other cases around the codebase where this would make sense, but why not 
> starting with this?

I'd measure performance here first to determine the best course of action.Even 
with a memory pool pd_pushsym is doing quite a few assignments. Pushing and 
popping on every msg box method may get be noticeably different than 
dereferencing a single cached value.
Measuring [trigger] performance I could see differences depending on how 
exactly the loop for the outlets was constructed.
-Jonathan

> Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
 wrote: 

> 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 a potential way to cache the glist 
in the t_messresponder to avoid allocation at message evaluation time. 
But we haven't implemented that yet (nor measured the current 
performance hit).

-Jonathan






Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 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 to be 
> used in real-time critical cases like this. If no memory available from the 
> pool, only then allocate it (or allocate a new pool).
> There are probably other cases around the codebase where this would make 
> sense, but why not starting with this?
> 
> Giulio
> 
> On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
>  wrote: 
> 
>> 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 a potential way to cache the glist 
> in the t_messresponder to avoid allocation at message evaluation time. 
> But we haven't implemented that yet (nor measured the current 
> performance hit).
> 
> -Jonathan


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 to be 
used in real-time critical cases like this. If no memory available from the 
pool, only then allocate it (or allocate a new pool).
There are probably other cases around the codebase where this would make sense, 
but why not starting with this?

Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
 wrote: 

> 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 a potential way to cache the glist 
in the t_messresponder to avoid allocation at message evaluation time. 
But we haven't implemented that yet (nor measured the current 
performance hit).

-Jonathan






Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 to be. When nobody is looking, I clandestinely
click a message box containing '$0' that has NOTHING CONNECTED TO ITS
INLET!  *shiver*  ;-)

Roman 

 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 one that had me going there - was the inconsistency that $0 in
messages is part of the same thing as arguments, and that $0 in messages
should be the selector. But this has been challenged and shown inconsistent
on its own, as then $0 should be the abstraction name, so I'm not convinced.

I actually always thought/perceived $0 as something else, a third
usage/case of dollarsigns. I guess many considered so, as many of us were
confused as to why not $0 don't work in messages. Hence, I'm actually
interested and after a canonical and formal definition of $0, for the sole
purpose I don't say stupid things to my students. I checked Pd's tutorial
(14.dollarsigns.pd), and it says that the different behaviour in objects
and messages "*may sound inconsistent, but it's not. Object and message
boxes are both actually messages, but in the case of the Object box the
message is passed at creation time, and for the Message box, at message
time*". As I read it, I don't find a conflict or inconsistency if "$0" also
gets evaluated and passed at "message time".

So after all the discussion, I still can't see the issue, as $0 becoming 0
doesn't seem of any use or a good behaviour. But I'm still open to more
clarification. Now, a reasoning in favor of adopting this is that Purr Data
is using it. Not that I think Pd should really adopt anything that a fork
decides to do, on the contrary, but it's hard not to see this does matter,
as many users are now comfortable, happy and abusing this feature in Purr
Data, and those patches can't run in Pd.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Dan Wilcox]

test? https://github.com/pure-data/pure-data/pull/346 



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 environment.


>That makes sense.


>Are you after the literal selector in this case, or the one that the 
>documentation 
>implies should be there? For example, if I feed a list with a single floatarg 
>(e.g., "list 42") to [selector] does it tell me the selector is "float" or 
>"list"?










I would say whatever route would do with it, in this case float


-Seb













___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Christof Ressi]

I don't understand this whole thing about getting the selector of a message to 
a msgbox and why this could be a useful feature. can someone give me a real 
world example?

when I have a msgbox like [foo $1 $2 $3 $4( I expect the input to be a list of 
(at least) 4 atoms which is then expanded. [foo $1( expects a list of length 1 
- why should I care about the selector? if I need the type of a message for my 
program logic, this can already be done with [route] (with anythings to [list 
split 1]-->[list trim]).

so I think expanding $0 to the selector - although reasonable from a 
theoretical point of view - would be rather pointless in practice. 
I agree with people pointing out that $0 in object boxes already has nothing to 
do with the argument list and is an inconsistency in itself so I think it's 
actually quite consistent to also introduce it to msgboxes :-). needless to say 
that I would find it incredibly handy.

Pd users have been accepting the fact that $0 in object boxes expands to a 
unique canvas ID for decades now. why do some people think introducing this 
behaviour to msgboxes could confuse anyone? on the contrary: new users are 
often surprised that 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" <pd-list@lists.iem.at>
An: pd-list@lists.iem.at, "sebfumas...@aol.com" <sebfumas...@aol.com>
Betreff: Re: [PD] suggestion: $0 in messages

>>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 environment.
 
That makes sense.
 
Are you after the literal selector in this case, or the one that the 
documentation
implies should be there? For example, if I feed a list with a single floatarg
(e.g., "list 42") to [selector] does it tell me the selector is "float" or 
"list"?
 

 

 

 

 
>>I don't understand what the word "solution" means here. If users
have repeatedly requested msg box $0 to expand to glist's
ce_dollarzero, why would Pd Vanilla give $0 in msg boxes a
different function that is incompatible with object box $0?
 > here "solution" means a good way to resolve $0 in message boxes..I don't 
think what users request is necessarily the end all of reasons to implement a 
feature in a language..
 
$0 in message boxes may be the most often requested feature for Pd.
That certainly doesn't mean it has to be implemented.
 
But filling $0 with something completely unrelated is probably a good way
to irritate your userbase for very little gain.
 
-Jonathan
 
 
 
 
 
 
 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 message environment.
That makes sense.
Are you after the literal selector in this case, or the one that the 
documentation implies should be there? For example, if I feed a list with a 
single floatarg (e.g., "list 42") to [selector] does it tell me the selector is 
"float" or "list"?

>>I don't understand what the word "solution" means here. If users have 
>>repeatedly requested msg box $0 to expand to glist's ce_dollarzero, why would 
>>Pd Vanilla give $0 in msg boxes a different function that is incompatible 
>>with object box $0?
> here "solution" means a good way to resolve $0 in message boxes..I don't 
> think what users request is necessarily the end all of reasons to implement a 
> feature in a language..
$0 in message boxes may be the most often requested feature for Pd. That 
certainly doesn't mean it has to be implemented.
But filling $0 with something completely unrelated is probably a good way to 
irritate your userbase for very little gain.

-Jonathan




  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 files is just a Pd message. The possibility of learning a 
single set of rules for how messages behave is way easier than keeping track of 
special cases and inconsistencies.
So having a rule, "$0 expands to the first element of the argument vector," is 
great if the user can be guaranteed that the rule holds regardless of context 
of the evaluation.
On the other hand, suppose the rule is, "$0 expands to the first element of the 
argument vector UNLESS we're loading a canvas in which case it expands to a 
unique value to simulate locality with Pd's global binding mechanism." That's 
harder to reason about.
If you want $0 as selector in msg boxes
you could try to teach the inconsistency by reminding users that load time and 
message time are completely different contexts and therefore may have different 
expansion behaviors for dollarsign variables. But they're still going to notice 
that $1-n have *analogous* behavior in each context while $0 doesn't.
Anyhow, given the choice between an inconsistency that very few (if any) ask 
for in daily patching and one that a multitude of users have pleaded for in 
daily patching, I'm obviously in favor of the latter.

-Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 environment.





>> On the other hand, having $0 represent the selector would be the most 
>> consistent solution, because you can not get other patch-local variables
or arguments in message boxes, [...]


>I don't understand what the word "solution" means here. If users 
have repeatedly requested msg box $0 to expand to glist's 
ce_dollarzero, why would Pd Vanilla give $0 in msg boxes a 
different function that is incompatible with object box $0?


here "solution" means a good way to resolve $0 in message boxes..
I don't think what users request is necessarily the end all of reasons to 
implement a feature in a language..



and again, the reason that $0 would be different in object boxes and message 
boxes is because everything else already is
different in object and message boxes

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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). 
> 
> What is the selector of an abstraction? 

the name of the abstraction.

fgmasr
dIOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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't say 
> this often enough around here: thank you very much for Pd, Miller.
> 
> Cheers,
> 
> Chris.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 spend so much time doing 
it I'll admit).


This was my exact motivation for lolPd[1]. There are some very very 
little TCL implementations[2][3] which could map quite nicely to Pd. 
Another fun idea is a visual LISP-like such as Blockly[4].


Anyway, I'm sorry to conjure up the spectacle of another several decades 
of challenging software development and maintenance work. We probably 
don't say this often enough around here: thank you very much for Pd, Miller.


Cheers,

Chris.

[1] https://github.com/chr15m/lolPd
[2] https://github.com/zserge/partcl (600 lines of code!)
[3] https://wiki.tcl.tk/17975
[4] http://bpp.rs/blockly/apps/turtle/index.html?lang=en

--
http://mccormick.cx/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 and sending that value
to the relevant message box in order to get "let" behavior.



Absolutely. Given some of Pd's other quirks the $0 issue seems like a 
funny time for semantic purity. The forks have given people what they want.


Cheers,

Chris.

--
http://mccormick.cx/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Seb Shader 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. 
Perhaps in that case there should also be a [selector] object that reports the 
selector of a message? getting it using [route] seems
unnecessarily complicated..


On the other hand, having $0 represent the selector would be the most 
consistent solution, because you can not get other patch-local variables
or arguments in message boxes, and yet you can use $1 $2 etc. to refer to the 
elements of an incoming message. So the behavior of dollar signs
in object boxes and message boxes is already separate and have very different 
uses. It almost would seem more confusing to be the same
for just 1 of the dollar sign numbers, yet different for all the others.


-Seb



-Original Message-
From: Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>
To: pd-list <pd-list@lists.iem.at>; Roman Haefeli <reduz...@gmail.com>
Sent: 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's a unique id automatically 
generated for a patch/abstraction which the user happens to access 
through a dollarsign variable.



That locality hack doesn't require that the unique id be fetched by 
an unused dollarsign arg. For example, you could reserve the keyword 
"let" such that a message box with "let token2" would get converted 
behind the scenes to "1003-token2".


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 and sending that value 
to the relevant message box in order to get "let" behavior.


Also, since "$0" is already being used for this purpose it doesn't 
make much sense to try to also get "$0" to refer to the selector. 
You'd end up with inconsistent meaning where it fetches the 
selector in msg boxes but not in object boxes. Plus you can 
already get the selector of an incoming message with [list] 
whereas you cannot get an abstraction's selector (which would 
be handy for error reporting). So adding that inconsistency 
would only duplicate existing functionality without adding 
new functionality. 


-Jonathan


> Roman


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___pd-l...@lists.iem.at mailing 
listUNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 your point here. Do you mean we should propose "$0" to
expand to message selectors? I'd be down with that!

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 smarter than changing the message
> box semantics.
>
> But then the question is, how would you allow message-box-style $
> substitutions?
> OK, we can do this:
>
> [msg $1 #1]
>
> which would be the exact reverse of Max's #1 convention - #1 could be the
> message-box $1.


> I've shrunk from actually doing this, not just because it makes my teeth
> hurt,
> but also because... shouldn't this be expanded into a full-on scripting
> language?  And what then would be its relationship with the expr family?
> It quickly got too deep for me to figure out what would be a good,
> canonical
> solution.
>

Well... if the idea was to expand Pd's message syntax, why not add #0, #1,
etc... as a way to expand creation arguments in messages? It wouldn't be in
reverse to Max (if that's any positive)... sure, there are backwards
compatibility concerns, but it feels it was a good thing to have.

But yeah, since IOhannes' "no" and me accepting the fact the current
behaviour remains so as the result of a conscious decision, I've started
working on an external, and much inspired by max's message box. But not
being a max user, I did know about "#1" there.

Anyway, by getting my hands dirty on it, I realized how "$1" would
naturally expand to arguments, and hardly would expand to message's input
(maybe possible with some ninja tricks, but maybe not even possible). Then
I thought both ways could useful in a message, so it became this deal not
only about "$0" anymore... and also the fact that, Ideally, there would be
two different prefixes for message expansion and creation argument
expansion.

So I was looking for a syntax to refer to message inputs as well. By
considering the [expr] way of doing such a thing (with "$f#" and stuff), I
thought a generic "$a#" ("a" for "atom", symbol or float). Though I kinda
like the "#1" idea now that you mention it, haha, even though if reversed
if compared to max... but yeah, something like "$a1" looks more "PD-ish",
right?

In any case, I welcome any kind of feedback!

cheers


>
> cheers
> Miller
>
> On Mon, Apr 02, 2018 at 08:55:58PM +0200, Roman Haefeli wrote:
> > 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, and I think it is a great
> > > feature, as many patches can be significantly simplified. I guess
> > > most Pd users here know what I'm talking about.
> >
> > By implementing that, you would once forever prohibit the proper way to
> > expand $0 which is expanding to the selector of the message. That's why
> > I oppose your proposition. (Actually, it doesn't matter whether I'm
> > opposing it or not since I don't contribute any Pd code. But I can at
> > least point to the fallacies.)
> >
> > I absolutely see the convenience of your proposition, but there would
> > be no good explanation for it. Consider it a bad coincidence that both
> > kinds of variables use a dollar prefix, there is nothing in common
> > between them (expanding to creation arguments versus expanding to atoms
> > of messages). Personally, I would totally find it convenient if Pi was
> > an integer number, it would make so many things so much easier.
> >
> > Roman
>
>
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 build counter.


You can use [jmmmp/f+], it's prepared to avoid such repetitive tasks. Or,  
you can request for a new object be part of pd vanilla, since this is an  
operation that I would bet 99.999% of users come up to sooner or later.




Apparently, you need to figure out the creation argument first before
you build a message using it. I don't see anything specially tedious
about this process.


You can, but is it really necessary to add more objects for something that  
could be easily solved by the language? The point isn't that something is  
impossible to do now, but that it would make work much easier.




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?


Maybe because the $3 of a patch is most likely used a fraction of the  
times compared to $0. If your patch doesn't have any abstractions, there's  
no $3 to use.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 then the question is, how would you allow message-box-style $ substitutions?
OK, we can do this:

[msg $1 #1]

which would be the exact reverse of Max's #1 convention - #1 could be the
message-box $1.

I've shrunk from actually doing this, not just because it makes my teeth hurt,
but also because... shouldn't this be expanded into a full-on scripting
language?  And what then would be its relationship with the expr family?
It quickly got too deep for me to figure out what would be a good, canonical
solution.

cheers
Miller

On Mon, Apr 02, 2018 at 08:55:58PM +0200, Roman Haefeli wrote:
> 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, and I think it is a great
> > feature, as many patches can be significantly simplified. I guess
> > most Pd users here know what I'm talking about.
> 
> By implementing that, you would once forever prohibit the proper way to
> expand $0 which is expanding to the selector of the message. That's why
> I oppose your proposition. (Actually, it doesn't matter whether I'm
> opposing it or not since I don't contribute any Pd code. But I can at
> least point to the fallacies.)
> 
> I absolutely see the convenience of your proposition, but there would
> be no good explanation for it. Consider it a bad coincidence that both
> kinds of variables use a dollar prefix, there is nothing in common
> between them (expanding to creation arguments versus expanding to atoms
> of messages). Personally, I would totally find it convenient if Pi was
> an integer number, it would make so many things so much easier. 
> 
> Roman



> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 too where I use $0 with all my [v]s and [s]s and [r]s
> and
> it does get to be a bit tedious BUT I'm not quite sure if mixing the
> two
> worlds and their rules are worth it...

Yeah! Ideally, there would be two different prefixes for message
expansion and creation argument expansion. THEN you could have it
convenient, #0 would expand to the message selector, $0 to the implicit
ID, $1 to the first creation argument, #1 to the first atom of the
incoming message, etc... And everyone would be happy.

I just see no way to go from here to there...

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 back the outlet of a [+ 1]
to the right inlet of a [f ] to build counter. 

Apparently, you need to figure out the creation argument first before
you build a message using it. I don't see anything specially tedious
about this process. 

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?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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, and I think it is a great
> feature, as many patches can be significantly simplified. I guess
> most Pd users here know what I'm talking about.

By implementing that, you would once forever prohibit the proper way to
expand $0 which is expanding to the selector of the message. That's why
I oppose your proposition. (Actually, it doesn't matter whether I'm
opposing it or not since I don't contribute any Pd code. But I can at
least point to the fallacies.)

I absolutely see the convenience of your proposition, but there would
be no good explanation for it. Consider it a bad coincidence that both
kinds of variables use a dollar prefix, there is nothing in common
between them (expanding to creation arguments versus expanding to atoms
of messages). Personally, I would totally find it convenient if Pi was
an integer number, it would make so many things so much easier. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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

Re: [PD] suggestion: $0 in messages

[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 (do people benefit from
> having a 0 there), or would people benefit more from having an
> inconsistency that provides them with a new useful feature?


I can see the argument (no pun intended, haha) here where $1 $2 (and $0
included) mean very different things in non-messages (patch arguments
where $0 is the internal/default argument) vs messages and having $0
resolve in messages as it would in objects could be quite confusing
as we're mixing two worlds (and then users would perhaps expect $1 $2
and so on to resolve similarly but they don't). So the matter of
consistency would be in message world and non-message world where $0
is just simply out of range in message world (as $100 would be if your
incoming list doesn't have 100 atoms).

Note that this opens the can of worms of not only message boxes but also
things like [text] where $0 behaves as it does in messages boxes.

>
> 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 too where I use $0 with all my [v]s and [s]s and [r]s and
it does get to be a bit tedious BUT I'm not quite sure if mixing the two
worlds and their rules are worth it...

-- 
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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

[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 inconsistency? I'm cool if this has been discussed before and that
this is the way it needs to be, but I'm just really curious.


> apart from that, i wonder how you imagine your "external" (object) to
> fix Pd's message-box. for an external, $0 is expanded as you'd like it
> automatically anyhow.
>

not sure I get the question or what you want me to respond. Yeah, $0
normally expands it, so I figure it wouldn't be hard to do that. Well, if
you're curious about the design, it'd be much like the same as a message
box, but being able to expand $0, surely I'm thinking about other ideas,
cause only this would be too little, for me, to motivate an external, so
I'm guessing other things like being able to set the size and color and
stuff.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[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 any concern or resistance to this, no problem, my
> alternative would be to create an external that would do that. but then I'd
> like to know here first where should I aim my efforts, if to a Pull Request
> to Vanilla or to an external design.
> 

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)

apart from that, i wonder how you imagine your "external" (object) to
fix Pd's message-box.
for an external, $0 is expanded as you'd like it automatically anyhow.

gfamsrd
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list