So, looks like it's failing because ScIDE is not connected yet - before ScIDE.connect is called. Specifically, you shouldn't EVER get the "ScIDE not connected" error if ScIDE.connect has been called, EVEN if the connection failed, so I don't think it's a case of the connection not being made.... ScIDE.connect is called in ScProcess::onStart, which doesn't SEEM to occur at any particularly rigorous time - possibly the request to open a help file is just getting executed first?

I suppose a workaround fix would be to check whether the IDE is connected (ScIDE.connected) when opening a help file is requested, and defer for some small amount of time if it isn't... That should at least fix this case.

I have not seen this since then. Opening help files immediately after startup is no longer a problem.

Seeing this all the time now, also with closed hep browser.

@telephon Can you give a detailed reproducer & environment details please? Never seen this before so I want to try to recreate.

@telephon Also it might be helpful to verify that the call stack is exactly the same as above. If the help browser is closed, I guess at the very least you won't see openHelpUrl in it. I'm curious what else is different.

OK; slowly making a few tests. I'm on the latest master, fresh build on macos 10.11.

It appears to be connected to an extension, I'm digging on.

Here is another post for comparison:

*** Welcome to SuperCollider 3.9dev. *** For help press Cmd-D.
ERROR: ScIDE not connected
ERROR: Primitive '_ScIDE_Send' failed.
Failed.
RECEIVER:
class ScIDE (0x1101587c0) {
  instance variables [19]
    name : Symbol 'ScIDE'
    nextclass : instance of Meta_Scale (0x1104b67c0, size=19, set=5)
    superclass : Symbol 'Object'
    subclasses : nil
    methods : nil
    instVarNames : nil
    classVarNames : instance of SymbolArray (0x110158940, size=7, set=2)
    iprototype : nil
    cprototype : instance of Array (0x110158a00, size=7, set=3)
    constNames : nil
    constValues : nil
    instanceFormat : Integer 0
    instanceFlags : Integer 0
    classIndex : Integer 985
    classFlags : Integer 0
    maxSubclassIndex : Integer 985
    filenameSymbol : Symbol '/Volumes/data/sc/supercollider/SCClassLibrary/scide_scqt/ScIDE.sc'
    charPos : Integer 0
    classVarIndex : Integer 89
}

PROTECTED CALL STACK:
	Meta_MethodError:new	0x110504980
		arg this = PrimitiveFailedError
		arg what = Failed.
		arg receiver = ScIDE
	Meta_PrimitiveFailedError:new	0x11050bf40
		arg this = PrimitiveFailedError
		arg receiver = ScIDE
	Object:primitiveFailed	0x10f9d84c0
		arg this = ScIDE
	Meta_ScIDE:prSend	0x110171900
		arg this = ScIDE
		arg id = enableDocumentGlobalKeyDownAction
		arg data = [ true ]
	Function:defer	0x1107e8040
		arg this = a Function
		arg delta = nil
	Meta_ScIDE:send	0x110171180
		arg this = ScIDE
		arg id = enableDocumentGlobalKeyDownAction
		arg data = [ true ]
	Meta_ScIDE:setDocumentGlobalKeyDownEnabled	0x11016f200
		arg this = ScIDE
		arg bool = true
	Meta_Document:globalKeyDownAction_	0x111020b80
		arg this = Document
		arg action = a Function
	Meta_DDWSnippets:enable	0x1114e7080
		arg this = DDWSnippets
		var temp = nil
	a FunctionDef	0x111f41ac0
		sourceCode = "<an open Function>"
	Function:prTry	0x1107eb800
		arg this = a Function
		var result = nil
		var thread = a Thread
		var next = nil
		var wasInProtectedFunc = false
	
CALL STACK:
	MethodError:reportError   0x113450ab8
		arg this = <instance of PrimitiveFailedError>
	< closed FunctionDef >   0x1609f1c98
		arg error = <instance of PrimitiveFailedError>
	Integer:forBy   0x161011fa8
		arg this = 0
		arg endval = 0
		arg stepval = 2
		arg function = <instance of Function>
		var i = 0
		var j = 0
	SequenceableCollection:pairsDo   0x113b7a128
		arg this = [*2]
		arg function = <instance of Function>
	Scheduler:seconds_   0x1134dc8e8
		arg this = <instance of Scheduler>
		arg newSeconds = 4.715716493
	Meta_AppClock:tick   0x112ff8008
		arg this = <instance of Meta_AppClock>
		var saveClock = <instance of Meta_SystemClock>
	Process:tick   0x1128a7458
		arg this = <instance of Main>
^^ The preceding error dump is for ERROR: Primitive '_ScIDE_Send' failed.
Failed.
RECEIVER: ScIDE

Ah ok, I found which extension, it's ddwSnippets.

enable triggers it in initClass. I tried to add Class.initClassTree(ScIDE); but that doesn't help.

Commenting out this part:

AppClock.sched(1.0, {
			// allows time for user to reset the path in startup.scd
			this.read(path, false);
			if(autoEnable) {
				this.enable;
			};
		});

gets rid of the issue.

Enabling it later "by hand" has no such issue.

What is really irritating is that setting autoEnable = false, it still is there!

Are you setting autoEnable = false in your startup.scd file? The setting must be made in within the 1 second between class tree init and the AppClock-scheduled function running.

The setting is, of course, not persisted through library recompilation. It's just a normal class, no magic like Process.tailCallOptimize.

Come to think of it, I've seen this myself, when launching the IDE under higher system load (like, when I'm writing something, so I have a virtual machine running with dictation software, web browser with articles open, and then I need to check some behavior in SC).

If it really can take longer than a second for the IDE to connect, maybe we need a callback function for ideConnected?

Oh wait, I see, it's persisted in the DDWSnippets file, and this overrides the setting from startup.

I'll push a fix in an hour or two. In the meantime, you can edit the config file by hand - DDWSnippets.path.openDocument

Fixed in ddwSnippets.

Turning now to the startup sequence:

As far as I can see, the IDE is supposed to be "magically" connected -- by which I mean, if I put a debugging post into ScIDE:connect, nothing is printed -- *connect is never called, but the connection is made somewhere. ScIDE:handshake is called by a function added to StartUp:

		StartUp.add {
			if (ScIDE.connected) {
				this.handshake
			};
		}

So there is something fragile here. We are assuming that the IDE will be connected before the class library startup sequence -- but if this doesn't happen, there's no failsafe. We just check the one time, and if ScIDE.connected is false, we ignore the rest of IDE initialization, and after that, a whole bunch of stuff isn't going to work.

I don't think I can go much further with this, but it would seem there's some kind of race condition where we expect the sequence to be "connect, then initialize" but sometimes it happens out of order.

As far as I can see, the IDE is supposed to be "magically" connected -- by which I mean, if I put a debugging post into ScIDE:connect, nothing is printed -- *connect is never called, but the connection is made somewhere.

No magic. It happens here:

void ScProcess::onStart()
{
    if(!mIpcServer->isListening()) // avoid a warning on stderr
        mIpcServer->listen(mIpcServerName);

    QString command = QStringLiteral("ScIDE.connect(\"%1\")").arg(mIpcServerName);
    evaluateCode ( command, true );
    Main::documentManager()->sendActiveDocument();
}

Ok, I see how I missed it before.

Hm, onStart... is it possible that sclang might charge ahead with class library init, while the signal back to the IDE could be delayed?

Just happened again, to me -- same callstack as Julian's.

Another possibility: the IDE tries to call connect prematurely, before the library has initialized.

I don't know how to debug this.

I am now encountering this sync problem almost daily.

This error on startup is a multiple-times-daily occurrence now.

This user's experience is that, in the past, it was occasional. Now, it's frequent. Almost every time I launch the IDE, I have to compile the library a second time.

Something has changed in the software ecosystem to degrade the behavior of our startup process. If we could, once upon a time, get away with leaving an unhandled race condition in place, I think we can't get away with it anymore.