thisProcess.nowExecutingPath remains nil

[LFSaw]

again trying Atom-SuperCollider as my primary IDE which means it has to work as a playground as well. It really (still and increasingly at the same time) looks amazing, a lot of features I really like, here.

However, I noticed that

thisProcess.nowExecutingPath

returns nil always. This is a feature I am heavily relying on to remotely load script files (with loadRelative )

I am guessing this is due to the absence of Document support for now?

let it shine on!

[woolgathering]

Unfortunately, .nowExecutingPath only works in the SC IDE...

See the docs: http://doc.sccode.org/Classes/Process.html#-nowExecutingPath

[LFSaw]

thanks, @woolgathering :) (and welcome to SC land! ) well, this is an issue then because it basically prevents other editors from working properly. There should be a proper interface for this.

[crucialfelix]

it does set nowExecutingPath when evaluating code on a document

https://github.com/crucialfelix/supercolliderjs/blob/develop/lib%2Fsc%2Finterpret.scd#L17

and then pops it back to its previous value after evaluating.

but you are doing a load and interpret file. can you post a code snippet ? its sclang that is loading the file, so it should set nowExecutingPath when it evaluates that file.

it is not in the hands of the SC IDE or of (atom)-supercollider-js

[crucialfelix]

Interpreter-executeFile claims to do set it. not sure why you are getting a nil

[LFSaw]

I'm sorry... I got fooled here... it works with saved files (not with untitled documents, of course...) However, there is something else strange:

Let's assume there's a fiel a.scd

"b.scd".loadRelative

and a corresponding file b.scd

"Hello".postln

• now, we evaluate the line in a.scd
• it returns [Hello] but the actual postln is omitted.

Also, my Atom-SuperCollider seem to not load the Quarks my SCIDE loads... how do I enable those? just like everything else via Quarks.gui ?

[LFSaw]

Further, Document.new returns

null
     Document.new

I guess because it is not properly implemented for sc.js?

[crucialfelix]

Document got hijacked. It is now only used by the ide for its own window management.

Thus broke it for all other uses outside of the ide.

On Sunday, October 11, 2015, LFSaw notifications@github.com wrote:

Further,

returns Th

null Document.new

I guess because it is not properly implemented for sc.js?

— Reply to this email directly or view it on GitHub https://github.com/crucialfelix/atom-supercollider/issues/49#issuecomment-147239264 .

[LFSaw]

via @danstowell and @muellmusik on the sc-dev list:

excuse my ignorance but is it possible to implement Document support (open, read, etc.) for non-SCide editors? Yes. How? Depends on the editor. Atom. Write a Document class which implements whatever communication is needed. So I guess, I have to implement Document (as I can find it in ScIDE.sc) and exclude the ScIDE.sc and include that one instead? The exclude/include can be done automatically. The reason that the ScIDE editor code is in a folder called "scide_scqt" is because there's a special flag for the sclang executable "-i" which tells it which IDE is being used. When you're using the standard QT IDE, it passes the flag "-i scqt" at runtime and this means the class code in "scidescqt" is included and any other "scide*" is ignored. So what you should do is put your Document implementation class code in a folder called "scide_atom" and then make sure atom invokes sclang using a flag "-i atom".

Any "already-done" implementations for scvim etc. somewhere? scvim never had full Document support. Nor did sced I think. scel has the file /editors/scel/sc/Document.sc but I'm no expert on it!

so, I'm guessing, we (I?) have to start implementing that :)

[crucialfelix]

what exactly do you need Document to do ? which methods ?