Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server-meter window errors #476

Closed
lijon opened this issue Sep 6, 2012 · 6 comments
Closed

Server-meter window errors #476

lijon opened this issue Sep 6, 2012 · 6 comments
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: class library SC class library
Milestone

Comments

@lijon
Copy link
Member

lijon commented Sep 6, 2012

When doing Server.default.meter without booting server first, I get:

ERROR: server failed to start
For advice: [http://supercollider.sf.net/wiki/index.php/ERROR:_server_failed_to_start]

(IMHO it should not try to start the server automatically.)

And then, when closing the meter window, I get:

ERROR: Message 'at' not understood.
RECEIVER:
nil
ARGS:
Instance of Server { (0xa654750, gc=EC, fmt=00, flg=00, set=06)
instance variables [47]
name : Symbol 'localhost'
addr : instance of NetAddr (0xa65a330, size=4, set=3)
clientID : Integer 0
isLocal : true
inProcess : false
sendQuit : nil
remoteControlled : true
serverRunning : false
serverBooting : false
bootNotifyFirst : false
options : instance of ServerOptions (0xa65a390, size=26, set=5)
latency : Float 0.200000 9999999A 3FC99999
dumpMode : Integer 0
notify : true
notified : false
nodeAllocator : instance of NodeIDAllocator (0xa65a630, size=6, set=3)
controlBusAllocator : instance of ContiguousBlockAllocator (0xa6585d0, size=5, set=3)
audioBusAllocator : instance of ContiguousBlockAllocator (0xa658030, size=5, set=3)
bufferAllocator : instance of ContiguousBlockAllocator (0xa658b70, size=5, set=3)
scopeBufferAllocator : instance of StackNumberAllocator (0xa658930, size=4, set=3)
syncThread : nil
syncTasks : nil
numUGens : Integer 0
numSynths : Integer 0
numGroups : Integer 0
numSynthDefs : Integer 0
avgCPU : nil
peakCPU : nil
sampleRate : nil
actualSampleRate : nil
alive : false
booting : false
aliveThread : instance of Routine (0xc626730, size=27, set=5)
aliveThreadPeriod : Float 0.700000 66666666 3FE66666
statusWatcher : instance of OSCFunc (0xc6a1a10, size=8, set=3)
tree : nil
window : instance of QWindow (0xb962fb0, size=5, set=3)
scopeWindow : nil
emacsbuf : nil
recordBuf : nil
recordNode : nil
recHeaderFormat : "aiff"
recSampleFormat : "float"
recChannels : Integer 2
volume : instance of Volume (0xa65ab10, size=19, set=5)
pid : nil
serverInterface : nil
}
CALL STACK:
DoesNotUnderstandError:reportError 0xcbf3110
arg this =
Nil:handleError 0xcbf5ef0
arg this = nil
arg error =
Thread:handleError 0xcbede50
arg this =
arg error =
Object:throw 0xcbefa30
arg this =
Object:doesNotUnderstand 0xcbef070
arg this = nil
arg selector = 'at'
arg args = [_1]
ServerMeterView:stop 0xcbf1eb0
arg this =
QObject:doFunction 0xcbf3b30
arg this =
arg f =
arg args = [_0]
^^ The preceding error dump is for ERROR: Message 'at' not understood.
RECEIVER: nil

@smrg-lm
Copy link
Contributor

smrg-lm commented Sep 6, 2012

the first error is because something is wrong in the condition of doWhenBooted

doWhenBooted { arg onComplete, limit=100, onFailure;
    var mBootNotifyFirst = bootNotifyFirst, postError = true;
    bootNotifyFirst = false;

    ^Routine({
        while({
            ((serverRunning.not
              or: (serverBooting and: mBootNotifyFirst.not))
             and: {(limit = limit - 1) > 0})
            and: { pid.tryPerform(\pidRunning) == true }
        },{
            0.2.wait;
        });

I think that Server method has the bug.

The second error is because serverCleanukpFuncs can be nil, fix:

stop{
    serverMeterViews[server].remove(this);

    if(serverMeterViews[server].size == 0 && serverCleanupFuncs.notNil){

@smrg-lm
Copy link
Contributor

smrg-lm commented Sep 6, 2012

And I'll bet it's because pid is nil

nil.tryPerform(\pidRunning) == true

is a lie

@smrg-lm
Copy link
Contributor

smrg-lm commented Sep 6, 2012

uf, I don't have all the pieces but that condition has to be broken (?)
if it waits for the server to be running it never passes because is called from .boot?
grrrr, I lost my bet.

@timblechmann
Copy link
Contributor

can someone have a look at #484? i think this should fix it, but i'd need another pair of eyes.

@timblechmann
Copy link
Contributor

merged my fix, as the use of doWhenBooted seems to be wrong anyway

@smrg-lm
Copy link
Contributor

smrg-lm commented Sep 11, 2012

Yes seems more clear this way.
El sep 11, 2012 8:55 a.m., "Tim Blechmann" notifications@github.com
escribió:

merged my fix, as the use of doWhenBooted seems to be wrong anyway


Reply to this email directly or view it on GitHubhttps://github.com//issues/476#issuecomment-8457124.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: class library SC class library
Projects
None yet
Development

No branches or pull requests

3 participants