"$0" becomes "#0" in gui's properties

hi, if i write something like $0-send in the "send" part of a gui properties windows, next time i open it it's "#0" - same goes when opening saved patches

all my reports are in mac os sierra

cheers

This is the same as in Pd-l2ork and Pd Vanilla, no?

what do you mean? well, I'm trying purr data and i cant use pd-l2ork really (no linux)

but this never happens in vanilla no... $0 always remains $0

I vaguely recall some related discussion with Ico (or maybe a bug report) upstream, will try to dig that out over the weekend.

what do you mean? well, I'm trying purr data and i cant use pd-l2ork really (no linux) but this never happens in vanilla no... $0 always remains $0

Because of a long standing weakness in the iemgui dialog parser, "#0" and "$0" are synonymous inside iemgui dialog boxes across all Pds. If you give the iemgui receive name of "#0-foo" and do [42(---[s $0-foo], you will successfully send a message to that iemgui.

The only difference between Purr Data and Pd Vanilla is that Vanilla maps all "#" to "$" when displayed inside the dialog box. But the problem remains the same. (This is why I said in the devlist to just find a langsec expert and ask them how to do parsing the right way, rather than coming up with all these separate workarounds with ugly edge cases.)

Because of a long standing weakness in the iemgui dialog parser, "#0" and "$0" are synonymous inside iemgui dialog boxes across all Pds.

I don't think that iemgui is the main culprit here. Yes, it accepts # in lieu of $, but that's apparently related to the fact that vanilla stores a $<number> in the send/receive symbols of number and symbol boxes as #<number> in patch files, whereas it's \$<number> in all other cases (including iemgui, send/receive objects, and messages). When reading, #<number> will work in both vanilla and iemgui gui objects (but not in send/receive objects or messages). Has been that way since the dawn of Pd IIRC. Why the #? I don't really know, but maybe it's Max heritage. You'd have to ask Miller to be sure.

But since it's part of the Pd patch format, I'm afraid that we're stuck with this idiosyncrasy for the time being. And IMHO that means that like vanilla, purr-data should show #<number> as $<number> in the gui, anything else will just confuse the user. Upstream pd-l2ork also does this.

And IMHO that means that like vanilla, purr-data should show # as $ in the gui, anything else will just confuse the user. Upstream pd-l2ork also does this.

I second that, as I got REALLY confused by knowing all this :)

Anyway, been using pd for over 10 years wihtout knowing this issue or having a problem with it...

The only difference between Purr Data and Pd Vanilla is that Vanilla maps all "#" to "$" when displayed inside the dialog box.

I see that now, but why are you doing the opposite here? Cause now if I type "$" it becomes "#" and that is confusing

And very confusing when, after all, if you have a [send #0-foo] object and a "#0-foo" as the receive name of a GUI, they won't talk to each other!

I don't think that iemgui is the main culprit here.

It's not. But this idea of aliasing ASCII characters has nasty side-effects, especially when the character being aliased-- "#"-- is itself printable.

If we want to solve it we need to spec out the parser and understand what it's currently doing before we try to fix it. Otherwise we'll just be creating more subtle bugs. For example, it turns out I'm wrong about Pd Vanilla's behavior-- it apparently only maps leading dollar signs.

After the initial release I'm happy to help fix this and make the parser more robust. In this instance, for example, we also need to prevent the user from typing a "#" in the dialog for a send/receive/label. In other words, we can't assume that the user will know that "#" has a special meaning.

If we want to solve it we need to spec out the parser and understand what it's currently doing before we try to fix it. Otherwise we'll just be creating more subtle bugs. For example, it turns out I'm wrong about Pd Vanilla's behavior-- it apparently only maps leading dollar signs.

There must be some code in upstream pd-l2ork which does the necessary translation when the dialog pops up. That's all we need. IIRC, there are some corresponding commits in the upstream repo in recent time. I'll try to dig these out and see whether I can make any sense of the code and port it over to purr-data. In any case I think that this needs to be fixed before 1.0, I consider this a real bug.

There must be some code in upstream pd-l2ork which does the necessary translation when the dialog pops up.

While Vanilla and Pd-l2ork attempt to completely hide the "#" alias from the user, neither one of them perform the aliasing correctly.

Consider a user setting a vsl receive in the dialog to "$1-foo-$2-bar". If you close the dialog in Pd Vanilla and open it again, you get "$1-foo-#2-bar". Do the same in Purr Data and you get "#1 (closed)-foo-#2-bar". Both are bad, but which is worse?

Even worse: if you try "$1-foo-$0-bar" in any flavor of Pd, you get corrupted data the next time you open the dialog. The "$0" turns into "0". That doesn't happen when using "#0", thought. Hm...

If you want to backport the stopgap behavior from Vanilla/Pd-l2ork I'll merge it for a release. But we really need to get a simple, consistent symmetric interface for handling these problem characters.

Consider a user setting a vsl receive in the dialog to "$1-foo-$2-bar". If you close the dialog in Pd Vanilla and open it again, you get "$1-foo-#2-bar".

I consider this a bug in vanilla (it only allows you to have a single $ substitution per send/receive symbol, IIRC). Upstream pd-l2ork does this correctly.

Both are bad, but which is worse?

Both are equally bad. :) $n is the official notation that people use, it shouldn't suddenly turn into a #n in the dialog. The original sin is obviously with Pd here (there shouldn't be any # alias at all), but as it's also ingrained in the patch format, we can't really help it.

Even worse: if you try "$1-foo-$0-bar" in any flavor of Pd, you get corrupted data the next time you open the dialog. The "$0" turns into "0".

Again, upstream pd-l2ork does this right.

If you want to backport the stopgap behavior from Vanilla/Pd-l2ork I'll merge it for a release.

My take is that pd-l2ork does this right, not vanilla, so that's the behavior that we should try to replicate as closely as possible. I'll look into it later today.

But we really need to get a simple, consistent symmetric interface for handling these problem characters.

I agree, but as you know this is going to be a painful process, since all this stuff is deep down in Pd. So let's keep that for later. ;-)

My take is that pd-l2ork does this right, not vanilla, so that's the behavior that we should try to replicate as closely as possible. I'll look into it later today.

If Pd-l2ork has done more than just backported the Vanilla behavior I'm happy to merge it.

If Pd-l2ork has done more than just backported the Vanilla behavior I'm happy to merge it.

Yes, pd-l2ork considerably improves on vanilla's treatment of the $ substitutions.

For the record, what I'm talking about here is a series of upstream commits from Dec 7, 2015 which dealt with the handling of $ substitutions in iemguis and other objects, see the top of the following list:

https://github.com/pd-l2ork/pd/commits/master?after=Y3Vyc29yOt4e4Ri4%2BnEswc7GXaIyFq2T5ytbKzEwNA%3D%3D

The end result was that $ could be substituted anywhere in a symbol (also multiple occurrences), but only if it was followed by a digit (to make sure that a lone $ or # in a label or symbol would not be taken to be a $ substitution). The relevant commits are:

https://github.com/pd-l2ork/pd/commit/b5cc40c501a57db608411e1217b016c6942a4cb5
https://github.com/pd-l2ork/pd/commit/6cdce86e007a18301ee378146af3f627ad6f95a2
https://github.com/pd-l2ork/pd/commit/613e32a40134d2bdeeac8f1ceed40c417e80d19c

This was actually a follow-up to an earlier (misguided) attempt to replace the # symbol in the patch format by a control character (ASCII 1) which, not very surprisingly, broke patch compatibility with vanilla and resulted in most of the non-trivial abstractions included in pd-l2ork's library being broken, so I reported it. You can find that commit here:

https://github.com/pd-l2ork/pd/commit/57914b7dd166aa0f77a6e0d8ce47df2149c57813

The resulting discussion on l2ork-dev starts here:

http://disis.music.vt.edu/pipermail/l2ork-dev/2015-November/000779.html

and continues here:

http://disis.music.vt.edu/pipermail/l2ork-dev/2015-December/000782.html

Obviously, none of the mentioned commits ever made it into purr-data (it happened after the purr-data code base was forked from pd-l2ork). So I now have to figure out which of the C code changes are still relevant and should be applied to purr-data, and also how to port the Tcl code changes to the new JS GUI code.

The question is do we want full pd-l2ork compatibility here, meaning that s/r symbols with multiple substitutions like $0-foo-$1-bar work? This is useful in some cases, but of course it's not backward-compatible with vanilla which will only perform a single $ substitution on each given symbol.

My answer to this would be yes (we want full pd-l2ork compatibility, don't we?), so the proposed course of action would be:

• Port the C code changes from the commits mentioned above over to purr-data so that multiple $ substitutions will work.

• Modify all relevant property dialogs in purr-data so that # (if followed by a digit) is translated to $ on display (and translated back to # when changes in the dialog are committed).

This shouldn't be too hard to do. If noone complains I'll go ahead with this.

I've actually kept up with most of the commits from Pd-l2ork.

There was one set of commits that used non-printable ASCII character which I avoided. At the time I believe I was using the same non-printable ASCII in the GUI parser (which again is a reason to do parsing "the right way"), but I switched to a different non-printable ASCII character since then.

This may be that same series of commits, but I cannot remember for sure.

There was one set of commits that used non-printable ASCII character which I avoided.

Yep, that's exactly what I'm talking about here. :) But note that the series of commits I mentioned then got rid of the control character again.

The question is do we want full pd-l2ork compatibility here, meaning that s/r symbols with multiple substitutions like $0-foo-$1-bar work?

AFAICT the only thing that doesn't work is the case where an inner "$0" turns to "0" and therefore loses data. All the other variations of dollar-to-number-sign tricks are dialog display problems. In my tests of Purr Data and Pd Vanilla, [nbx]---[s $1-foo-$2-bar] will always send to a [vsl] receiver, regardless of whether it displays in the [vsl] dialog as "$1-foo-#2-bar", "#1 (closed)-foo-#2-bar", or "$1-foo-$2-bar".

Well, if multiple $ substitutions already work then it all boils down to the display problem. How hard is it to fix that?

If you can take care of the display problem then I'll look at the C code and see what needs to be done there. There's still the old sharptodollar routine in g_array.c that needs to be updated, as well as iemgui_dollar2raute/iemgui_raute2dollar in g_all_guis.c.

Ok, I've taken a look at the JS side now. Looks like in order to fix the display problem, we'll just need to apply some "unescaping" in the populate_form function of dialog_gatom.html and dialog_iemgui.html. Also, gatom_escape and pd_symbol_carwash need to be looked at. Together with the C code changes mentioned above this will hopefully be enough to port over all upstream changes from Dec 7, 2015. I guess that I can tackle this myself now.

mentioned in merge request !43 (merged)

There you go: !43 (merged)

Did you have a look?

closed via commit 33bf9711

closed via merge request !43 (merged)

merged.

Thanks!