Hi, so, I 'm working with OSC and found out in the specifications you can use something like /{foo,bar} to mach either /foo or /bar as addresses.
I was able to use something like [list tosymbol] to generate '{' and '}' and I see that these can be stored in messages in Pd files. In fact, you can also type them inside a [text] object's window (even tough Pd's window says 'keycode 123/125: dropped').
I see it gets saved unescaped, as in: #X msg 100 82 {;
I'm aware curly braces were never supported and this has been discussed many times, but I couldn't easily find recent information why this is a problem.
It's funny that as I see it now (and I didn't know) it that this is "half" supported. It's not that you can't use them or save in patches, it's just hard and you need ninja tricks.
So, why can't Pd just support this?
thanks
I see there was a request for it some time ago but it isn't quite clear what is the current challenge and issues
https://github.com/pure-data/pure-data/issues/505
a first step to support curly braces was given at https://github.com/pure-data/pure-data/pull/647
Em sex., 6 de jan. de 2023 às 23:20, Alexandre Torres Porres < porres@gmail.com> escreveu:
Hi, so, I 'm working with OSC and found out in the specifications you can use something like /{foo,bar} to mach either /foo or /bar as addresses.
I was able to use something like [list tosymbol] to generate '{' and '}' and I see that these can be stored in messages in Pd files. In fact, you can also type them inside a [text] object's window (even tough Pd's window says 'keycode 123/125: dropped').
I see it gets saved unescaped, as in: #X msg 100 82 {;
I'm aware curly braces were never supported and this has been discussed many times, but I couldn't easily find recent information why this is a problem.
It's funny that as I see it now (and I didn't know) it that this is "half" supported. It's not that you can't use them or save in patches, it's just hard and you need ninja tricks.
So, why can't Pd just support this?
thanks
On 1/7/23 03:20, Alexandre Torres Porres wrote:
So, why can't Pd just support this?
in theory it can (of course).
the main reason why Pd does not support curlies is, that they need special escaping on the GUI side (as in Tcl/Tk they are special characters used to group lists or strings), and it was just much easier to completely forbid them than to worry about getting the escaping right.
in any case, as explained in [1] and reproducing here verbati: i don't think we should lightly add "support for curly braces". the fact that curlies (that is: a pair of matching characters) have been forbidden until now is a unique opportunity. it could allow for a simple and elegant way to write structured data in Pd patches without breaking backward compatibility currently our only data structure we can express within a message are lists of atoms. but with curlies we could introduce list of lists.
[list foo {1 2 3} bar( | [$1( | |list 1 2 3)
I think this is much more interesting that allowing for regexp-groups such as used by OSC or ossia.
note that this is not mutually exclusive; we can have both single curlies denoting some special syntax (like the lists-of-lists above) and curlies within symbols to not carry any specific meaning (so that a symbol like /{foo,bar} can be used as an OSC-path with alternatives, handled by the OSC-receiver).
mfgds IOhannes
[1] https://github.com/pure-data/pure-data/issues/505#issuecomment-1374880190
the fact that curlies (that is: a pair of matching characters) have been forbidden until now is a unique opportunity.
Well, they have not been forbidden. You can not *type* them (yet), but they can appear in text files or in manually assembled symbols. In fact, they are properly displayed with [print] or list/symbol atoms, which suggests that they are already properly escaped when sent to the GUI. One could argue that someone who only uses libpd might not even be aware of this issue.
Curly braces have never been a part of special Pd symbols (semicolon, colon, dollar), so I'm sceptical that we can just give them some meaning. It would break lots of existing code that uses symbols with curly braces. For example, it would completely break the "purest_json" library.
However, we could use *escaped* curly braces. The escape sequences "{" and "}" are not defined, so we might use those for nested lists. I'm not saying it's pretty, though.
Anyway, it's a bit silly that we still can't type curly braces, given how important they are for many use cases. I mean, I cannot even type a JSON string...
Christof
So, we've been actually discussing this on github and maybe others can participate over there, check https://github.com/pure-data/pure-data/issues/505
or... maybe we can use this thread instead... :) seems like github discussions are always more limited.
The thing in the way now is wether "{" and "}" should be officially incorporated with a new syntax, like nested lists. There are arguments against as in the last message by christof here and I agree and think we could just let "{" and "}" be supported as regular characters and that we can expand the usage of dollar signs for expanding Pd's syntax, like ${ and $}
And, also, I'd like to point that there are forks of Pd that actually already allow "{" and "}"... I can see why one would disregard this, but it's something worth noting. You can already do this in PlugData and PurrData/Pd-L2ork, and the patches actually work and are already compatible to Pd Vanilla.
I also don't see an expansion of the language syntax coming up very soon or easily, so just allowing "{" and "}" could be good to at least get this issue out of the way, since it's been bugging people for edge cases for ages.
What do you people say?
cheers
Em dom., 8 de jan. de 2023 às 16:15, Christof Ressi info@christofressi.com escreveu:
the fact that curlies (that is: a pair of matching characters) have been forbidden until now is a unique opportunity.
Well, they have not been forbidden. You can not *type* them (yet), but they can appear in text files or in manually assembled symbols. In fact, they are properly displayed with [print] or list/symbol atoms, which suggests that they are already properly escaped when sent to the GUI. One could argue that someone who only uses libpd might not even be aware of this issue.
Curly braces have never been a part of special Pd symbols (semicolon, colon, dollar), so I'm sceptical that we can just give them some meaning. It would break lots of existing code that uses symbols with curly braces. For example, it would completely break the "purest_json" library.
However, we could use *escaped* curly braces. The escape sequences "{" and "}" are not defined, so we might use those for nested lists. I'm not saying it's pretty, though.
Anyway, it's a bit silly that we still can't type curly braces, given how important they are for many use cases. I mean, I cannot even type a JSON string...
Christof
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I agree and think we could just let "{" and "}" be supported as regular characters
Just for the sake of clarity: "{" and "}" have never been "forbidden" in Pd message, you just cannot /type /them.*)
Christof
*) Actually, you can already type them in [text] windows.
On 13.01.2023 21:03, Alexandre Torres Porres wrote:
So, we've been actually discussing this on github and maybe others can participate over there, check https://github.com/pure-data/pure-data/issues/505
or... maybe we can use this thread instead... :) seems like github discussions are always more limited.
The thing in the way now is wether "{" and "}" should be officially incorporated with a new syntax, like nested lists. There are arguments against as in the last message by christof here and I agree and think we could just let "{" and "}" be supported as regular characters and that we can expand the usage of dollar signs for expanding Pd's syntax, like ${ and $}
And, also, I'd like to point that there are forks of Pd that actually already allow "{" and "}"... I can see why one would disregard this, but it's something worth noting. You can already do this in PlugData and PurrData/Pd-L2ork, and the patches actually work and are already compatible to Pd Vanilla.
I also don't see an expansion of the language syntax coming up very soon or easily, so just allowing "{" and "}" could be good to at least get this issue out of the way, since it's been bugging people for edge cases for ages.
What do you people say?
cheers
Em dom., 8 de jan. de 2023 às 16:15, Christof Ressi info@christofressi.com escreveu:
> the fact that curlies (that is: a pair of matching characters) have > been forbidden until now is a unique opportunity. Well, they have not been forbidden. You can not *type* them (yet), but they can appear in text files or in manually assembled symbols. In fact, they are properly displayed with [print] or list/symbol atoms, which suggests that they are already properly escaped when sent to the GUI. One could argue that someone who only uses libpd might not even be aware of this issue. Curly braces have never been a part of special Pd symbols (semicolon, colon, dollar), so I'm sceptical that we can just give them some meaning. It would break lots of existing code that uses symbols with curly braces. For example, it would completely break the "purest_json" library. However, we could use *escaped* curly braces. The escape sequences "\{" and "\}" are not defined, so we might use those for nested lists. I'm not saying it's pretty, though. --- Anyway, it's a bit silly that we still can't type curly braces, given how important they are for many use cases. I mean, I cannot even type a JSON string... Christof _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sex., 13 de jan. de 2023 às 17:13, Christof Ressi info@christofressi.com escreveu:
I agree and think we could just let "{" and "}" be supported as regular characters
Just for the sake of clarity: "{" and "}" have never been "forbidden" in Pd message, you just cannot *type *them.*)
Christof
*) Actually, you can already type them in [text] windows.
Yup, true, I mentioned it in my first message on this thread about the support in [text], which is one of the possible hacks we already have in Pd to deal with them, as well as using things like [list tosymbol]. These are also good points to just "let it go" and officially and fully supporting them by just dropping the filter that prevents us from typing this into messages.
On 13.01.2023 21:03, Alexandre Torres Porres wrote:
So, we've been actually discussing this on github and maybe others can participate over there, check https://github.com/pure-data/pure-data/issues/505
or... maybe we can use this thread instead... :) seems like github discussions are always more limited.
The thing in the way now is wether "{" and "}" should be officially incorporated with a new syntax, like nested lists. There are arguments against as in the last message by christof here and I agree and think we could just let "{" and "}" be supported as regular characters and that we can expand the usage of dollar signs for expanding Pd's syntax, like ${ and $}
And, also, I'd like to point that there are forks of Pd that actually already allow "{" and "}"... I can see why one would disregard this, but it's something worth noting. You can already do this in PlugData and PurrData/Pd-L2ork, and the patches actually work and are already compatible to Pd Vanilla.
I also don't see an expansion of the language syntax coming up very soon or easily, so just allowing "{" and "}" could be good to at least get this issue out of the way, since it's been bugging people for edge cases for ages.
What do you people say?
cheers
Em dom., 8 de jan. de 2023 às 16:15, Christof Ressi < info@christofressi.com> escreveu:
the fact that curlies (that is: a pair of matching characters) have been forbidden until now is a unique opportunity.
Well, they have not been forbidden. You can not *type* them (yet), but they can appear in text files or in manually assembled symbols. In fact, they are properly displayed with [print] or list/symbol atoms, which suggests that they are already properly escaped when sent to the GUI. One could argue that someone who only uses libpd might not even be aware of this issue.
Curly braces have never been a part of special Pd symbols (semicolon, colon, dollar), so I'm sceptical that we can just give them some meaning. It would break lots of existing code that uses symbols with curly braces. For example, it would completely break the "purest_json" library.
However, we could use *escaped* curly braces. The escape sequences "{" and "}" are not defined, so we might use those for nested lists. I'm not saying it's pretty, though.
Anyway, it's a bit silly that we still can't type curly braces, given how important they are for many use cases. I mean, I cannot even type a JSON string...
Christof
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 1/7/23 03:20, Alexandre Torres Porres wrote:
Hi, so, I 'm working with OSC and found out in the specifications you can use something like /{foo,bar} to mach either /foo or /bar as addresses.
note that the OSC-specs allowed for a large number of address patterns with built-in matching. in practice i think many implementations lack the more complex pattern matching. iirc, most implementations just implement the '*' for an entire address part (that is "/foo/*/pizza" but not "/foo/b*/pizza".
but then my memory might be missing a few bits, at least a casual check with liblo shows that it's pattern matching code indeed implements {}.
gfmadsr IOhannes
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmölnig