Re: Running SuperColliderAU

[email protected] Tue, 30 Mar 2021 15:59:22 +0000
Newsgroups gmane.comp.audio.supercollider.user
Message-ID <JL1Fx3-Z6q97Dt4nJ2dIGAmEXOsNq7XkDSOJOJUJB4vZ6-vOhUfJlMwC1wpPGn49Y_is11qCNkyk4YAefgnKiung02dgY44ox00PqQr__ao=@brianlheim.com>
Hi David,

I reviewed your earlier messages, and realized you are not running version 3.11.2, you are running something from the develop branch. Your earlier error message had this in the stack trace:

Object:doesNotUnderstand
arg this = nil
arg selector = 'protocol'
arg args = [*0]
Meta_Server:remote
arg this = <instance of Meta_Server>
arg name = 'scau'
arg addr = <instance of NetAddr>
arg options = nil
arg clientID = nil
var result = <instance of Server>

But options.protocol isn't called on the options object in 3.11.2: https://github.com/supercollider/supercollider/blob/Version-3.11.2/SCClassLibrary/Common/Control/Server.sc#L380-L385

It is after this commit on develop from a few months ago: https://github.com/supercollider/supercollider/commit/c1eb86075c77293c29b9cb6020f06d7e5132f9fb

If you want a stable build, and one that actually corresponds to an "official" release, build from a version tag. This is generally a good rule for compiling any git-managed project.

There are a few takeaways I see:
- the documentation could be clearer about how to make a stable build and what the difference is
- this is a bug in Server.remote that should be reported and fixed
- when asking / answering what version of SC someone is running, we should be very explicit and if the project was compiled on the user's machine, *always* use the commit hash -- there is too much room for confusion here otherwise. (This can be found in the IDE by opening the "about" dialog.)
- we should adopt the "coarse versioning" scheme in Marcin's RFC, which would have made it clear from the start that you are not running 3.11.2, but in fact "3.12.0-dev": https://github.com/supercollider/rfcs/blob/51f246cd6e820ab10161cd25f8a6876b9a91f15b/rfcs/0016-scversion-improvements.md

Regards,
Brian

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, March 30, 2021 3:15 PM, <[email protected]> wrote:

> Hello Brian,
>
> No, Server.defaultOptionsClass does not seem to be nil. If I just execute
> Server.defaultOptionsClass;
> it returns
> -> ServerOptions
>
> Server.all;
> returns
> -> Set[ localhost, internal ]
>
> -David
>
> On Tue, Mar 30, 2021 at 8:52 AM <[email protected]> wrote:
>
>> Is Server.defaultOptionsClass is nil for you after startup? I asked this in my previous email. I don't want to assert that what I say is the real problem without an answer to this.
>>
>> Regards,
>> Brian
>>
>> -------- Original Message --------
>> On Mar 30, 2021, 2:47 PM, < [email protected]> wrote:
>> Hello Christof and Brian,
>>
>> No errors on startup, and localhost server starts up normally with s.boot. No extensions installed at the moment and no special scripts in use. It's a fresh install, built from source. I don't even have any quarks installed yet - wanted to eliminate any variables while playing with SCAU.