Collect no longer returns arrays beginning and ending with spaces in SC 3.14?

I just sorted out a bug in my live coding system. It uses a method that collects methods of certain classes and formats them into a regExp string for the preProcessor. It’s a bit clumsy, but kind of works. However, it seems that collect no longer returns arrays with spaces at the beginning and end? I have nothing against this change, but it turned out to be a breaking change in this case, because "[ " is obviously not the same regexp as "[". I just though that it might be useful to highlight this in case someone else stumbles upon it.

So, this:
Array.methods.collect{|m| m.name};
now returns:
-> [reverse, scramble, mirror, mirror1, mirror2, stutter, dupEach, rotate...]
instead of the previous:
-> [ reverse, scramble, mirror, mirror1, mirror2, stutter, dupEach, rotate... ]

Hi there,

Regarding the change to SC 3.14 that you mentioned, Please rake a look at this pull request.

I just though that it might be useful to highlight this in case someone else stumbles upon it.

It is documented in

The rendered help documentation:
https://docs.supercollider.online/Guides/News-3_14.html#Changed

If I’ve understood your intent correctly — that you now need to match [, [ , ], and ] — you might consider using one of the following regular expressions as examples.

  • \[\s*
    matches a [ followed by zero or more whitespace characters

  • \[ *
    matches a [ followed by zero or more spaces

  • \[ ?
    matches a [ followed by zero or one space

  • \[\s?
    matches a [ followed by zero or one whitespace character

  • \[( |)
    matches a [ followed by either a space or nothing

1 Like

To clarify: arrays don’t have spaces in them.

[ 1, 2, 3 ] == [1, 2, 3]
-> true

The string representation of arrays changed – so the issue is not collect (which will return the same list of symbols) – it’s the asString that is providing the regexp-able content.

hjh

2 Likes

IIRC the change was to conform with the style guidelines - of course someone was actually relying on it!

2 Likes

Issues like this are why I think we should move towards hanging dsls be their own symbol in the lexer A more structured approach to DSLs

3 Likes

Thanks! I somehow missed this in the list of changes.
It was easy to fix once I found it.

Of course! Sorry about that.
As it says in the PR:

it should not actually break any reasonably written code

Hehe.

1 Like