After update to 0.3.2 server seems not to boot anymore

[bagong]

Hi,

I was just trying to work out how to use sc-atom and sc-ide togeter when you pushed the 0.3.2 update that allows for an independent use. That's very cool.

Unfortunately things don't work anymore. I can eval s.boot, or do postwindow-open and the classes will compile as expected - no life sign of the server, and after the end of this process key combinations like shift-enter or cmd-shift-k are dead. Cmd-shift-p still works, calling the help-system never works.

The startup-process posts this:

init_OSC
empty
compiling class library...
NumPrimitives = 704
compiling dir: '/Users/rainer/Library/Application Support/SuperCollider/Extensions'
excluding dir: '/Users/rainer/Library/Application Support/SuperCollider/Extensions/classes'
excluding dir: '/Users/rainer/Library/Application Support/SuperCollider/Extensions/quarks'
compiling dir: '/Users/rainer/Projects/supercollider/atom'
excluding dir: '/Users/rainer/Projects/supercollider/atom/ExtClasses/sc3-plugins/LadspaUGen'
compiling dir: '/Users/rainer/.atom/packages/supercollider/node_modules/supercolliderjs/lib/sc-classes'
pass 1 done
numentries = 1565340 / 26488640 = 0.059
7015 method selectors, 3776 classes
method table size 26189856 bytes, big table size 211909120
Number of Symbols 17608
Byte Code Size 591296
compiled 659 files in 1.79 seconds

Info: 15 methods are currently overwritten by extensions. To see which, execute:
MethodOverride.printAll

compile done
Class tree inited in 0.03 seconds
Cleaning up temp synthdefs...

*** Welcome to SuperCollider 3.7alpha0. *** For help type cmd-d.

My .supercollider.yaml looks like this:

sclang: /Users/rainer/Applications/SuperCollider/SuperCollider.app/Contents/Resources/sclang
scsynth: /Users/rainer/Applications/SuperCollider/SuperCollider.app/Contents/Resources/scsynth
debug: true
echo: true
stdin: true
langPort: 57120
serverPort: 57110
host: 127.0.0.1
protocol: udp
websocketPort: 4040
includePaths:
- ~/Projects/supercollider/atom
- ~/Library/Application Support/SuperCollider/Extensions/plugins
excludePaths:
- ~/Library/Application Support/SuperCollider/Extensions/classes
- ~/Library/Application Support/SuperCollider/Extensions/quarks
- ~/Library/Application Support/SuperCollider/Extensions/scide_scel
- ~/Applications/SuperCollider/SuperCollider.app/Contents/Resources/SCClassLibrary
- ~/Projects/supercollider/atom/ExtClasses/sc3-plugins/DEINDUGens/faust_src
- ~/Projects/supercollider/atom/ExtClasses/sc3-plugins/LadspaUGen
postInlineWarnings: false

Its on OSX 10.9.5

Best
.r.

[bagong]

• This also happens if I remove all extensions (and include/exclude-paths)
• sclang boots and plays fine on the command line
• a similar config works ok in scide

[crucialfelix]

Thanks for the report !

We can see that it boots up okay and compiles. So its something on the atom side.

run these in shift-cmd-P

• Window Toggle Developer Tools -option-I
• Key Binding Resolver - Toggle

That might post some errors.

after the end of this process key combinations like shift-enter or cmd-shift-k are dead. Cmd-shift-p still works, calling the help-system never works.

This means that it thinks its still not compiled. It will post "library not compiled" to the console. I will make it post that to the post-window instead.

are you running it in classic-repl mode ?

[crucialfelix]

Ah, its the ***

*** Welcome to SuperCollider 3.7alpha0. *** For help type cmd-d.

and my regex failed because of that. my sc is not up to date. the *** were added in april.
supercollider/supercollider@2f5ecfe#diff-739fd94795edb7ee57b1aa54f9ae855b

I did a fix for this and published it.

I have to rework the compile detection stuff. sc is very unstructured when it posts errors. I'm trying to read it and convert it into usable info without being too brittle and dependent on little things like a formatting change that can break it.

[bagong]

Okay, it's almost there now, looks very promising! I'll describe what I get now and follow your debug tips then.
If I open the postwindow at the beginning, I goes down to "SUPERCOLLIDERJS-interpreter-loaded", sort of a readline-prompt. If then I try to boot the server, "Library is not compiled is returned" (keys work now):

...
compile done
Class tree inited in 0.02 seconds
Cleaning up temp synthdefs...
ready


*** Welcome to SuperCollider 3.7alpha0. *** For help type cmd-d.
sc3> SUPERCOLLIDERJS-interpreter-loaded
-> SUPERCOLLIDERJS-interpreter-loaded
Library is not compiled

If then I recompile sc-classes using cmd-shift the server eventually boots (not the first time), but the postwindow-message contains a "[H�[2J". But hey, I got a tone :):

�[H�[2Jbooting 57110
SUPERCOLLIDERJS:84128dc0-4a13-11e4-8076-c5f550540284:START:Result
SUPERCOLLIDERJS:84128dc0-4a13-11e4-8076-c5f550540284:CHUNK:"localhost"
SUPERCOLLIDERJS:84128dc0-4a13-11e4-8076-c5f550540284:END:Results
SUPERCOLLIDERJS.interpreted
-> SUPERCOLLIDERJS.interpreted
sc3> �[H�[2J
Found 0 LADSPA plugins
Number of Devices: 5
   0 : "Built-in Microph"
   1 : "Built-in Output"
   2 : "Soundflower (2ch)"
   3 : "Soundflower (64ch)"
   4 : "MOTU MicroBook II"

"Built-in Microph" Input Device
   Streams: 1
      0  channels 2

"MOTU MicroBook II" Output Device
   Streams: 4
      0  channels 2
      1  channels 2
      2  channels 2
      3  channels 2

SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
SuperCollider 3 server ready.
Receiving notification messages from server localhost

=== Waiting for server shared memory interface ===

Seconds elapsed: 0 - 
Shared memory server interface initialized

The second time I tried unsucessfully to boot (after successfully starting the interpreter) the developer console opened and produced this message:

[39m{"debug":true,"echo":false,"stdin":false,"langPort":57120,"serverPort":57110,"host":"127.0.0.1","protocol":"udp","websocketPort":4040,"sclang":"/Users/rainer/Applications/SuperCollider/SuperCollider.app/Contents/Resources/sclang","scsynth":"/Users/rainer/Applications/SuperCollider/SuperCollider.app/Contents/Resources/scsynth","includePaths":["~/Projects/supercollider/atom","~/Library/Application Support/SuperCollider/Extensions/plugins"],"excludePaths":["~/Library/Application Support/SuperCollider/Extensions/classes","~/Library/Application Support/SuperCollider/Extensions/quarks","~/Library/Application Support/SuperCollider/Extensions/scide_scel","~/Applications/SuperCollider/SuperCollider.app/Contents/Resources/SCClassLibrary","~/Projects/supercollider/atom/ExtClasses/sc3-plugins/DEINDUGens/faust_src","~/Projects/supercollider/atom/ExtClasses/sc3-plugins/LadspaUGen"],"postInlineWarnings":false,"configPath":"/Users/rainer/Projects/supercollider/atom/.supercollider.yaml","errorsAsJSON":true}
�[90m  debug  - �[39mpath:/Users/rainer/Applications/SuperCollider/SuperCollider.app/Contents/Resources/sclang
�[90m  debug  - �[39mstate: booting
�[90m  debug  - �[39mstate: compiling
�[90m  debug  - �[39mstate: compiled
�[90m  debug  - �[39mstate: ready
Uncaught TypeError: Cannot read property 'chunks' of undefined /Users/rainer/.atom/packages/supercollider/node_modules/supercolliderjs/lib/nodejs/sclang.js:277

PS: if it's somehow possible / unproblematic to use your github repo directly rather than going through the atom-package update process, I am happy to do that so that you don't have to push a release each time you add a little fix.
As to "classical REPL"-mode, I am not sure yet what you mean :)

And as closing word: this project is very-very cool - can't wait to use sc in the Emacs of the future :)

[bagong]

Not to mention the cool concept of assembling everything you work within a single folder. Btw., I was wondering if it wouldn't be nice to offer the option of using the new sclang parameter -a (it's in master). It prevents sc from looking into any paths except the ones specified in the sclang_config.yaml (or, as it were, your "on the fly"-data).

[bagong]

Actually I get the "Library is not compiled" and "[H�[2J" each time I evaluate something (but it plays):

Library is not compiled
( 'instrument': default, 'msgFunc': a Function, 'amp': 0.1, 'sustain': 0.8,   'server': localhost, 'isPlaying': true, 'freq': 261.6255653006, 'hasGate': true, 'id': [ 1002 ] )
�[H�[2J

[crucialfelix]

those are terminal commands. seufz. sclang should not be emitting terminal commands unless it has determined that its talking to a terminal. that screws up all clients (emacs, supercoliderjs, sublime)

ESC[2J clears the whole screen

ESC[H means move the cursor to home

I'm filtering them out now. I should file an sclang bug on it too.

[crucialfelix]

I believe I've fixed this now.

It was posting not compiled because I left a debug statement in (before morning coffee).

Various cases where I needed a newline before the SUPERCOLLIDERJS commands because sclang was posting sc3> prompts

Filtered out any prompts and terminal escape codes.

Stopped the ugly color commands intended for the terminal from ending up in the Atom console. (these things: [90m debug - [39m

Fixed SyntaxError display

Try it out when you get a chance, thanks !

[crucialfelix]

-a (it's in master)

Didn't know about that one. I'll just forward any flags you set in the conf

Dan says to try setting -i to ''

sclangArgs:
     a: true
     r: true

or it could just be a raw string to pass on. I don't want to overengineer or complicate it.

 *   -d <path>                      Set runtime directory

• -D Enter daemon mode (no input)
• -g [km] Set heap growth (default 256k)
• -h Display this message and exit
• -l Set library configuration file
• -m [km] Set initial heap size (default 2m)
• -r Call Main.run on startup
• -s Call Main.stop on shutdown
• -u Set UDP listening port (default 57120)
• -i Specify IDE name (for enabling IDE-specific class code, default "none")
• -a Standalone mode

[bagong]

Very cool! I'll try it asap. At the moment npm is still giving an error, probably too early.
Thanks for this! I like that we can use sclang-arguments!

[crucialfelix]

try now, I forgot to publish

On Thu, Oct 2, 2014 at 5:39 PM, Rainer Schütz notifications@github.com
wrote:

Very cool! I'll try it asap. At the moment npm is still giving an error,
probably too early.
Thanks for this! I like that we can use sclang-arguments!

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[bagong]

Yess, it's there and looks clean now! Will start playing now. Thanks a lot!

[bagong]

This syntax seems not to work though:

sclangArgs:
     a: true
     r: true

I tried a few variants but none seemed to have any influence... Did you mean to say you had implemented passing on arguments? I thought so but not sure now...
There is also the question where to put things that would have usually landed in startup.scd. e.g. I used to set Server.supernova there (use supernova rather than scsynth as localhost).

[crucialfelix]

oh sorry ! I was proposing that, but I didn't do it yet.

I want to avoid having too many custom features that diverge from sc-ide.

but specifying sclang args seems appropriate.

adding includePaths: quarks to a project is be really nice.

people can install quarks with git, by downloading the source or by using
npm if the quark offer registers it.

a command in atom could take a quark name or git url and it would just
install it.
nobody would need to install anything extra.

its important to go slow with these decisions though.

On Thu, Oct 2, 2014 at 7:01 PM, Rainer Schütz notifications@github.com
wrote:

This syntax seems not to work though:

sclangArgs:
a: true
r: true

I tried a few variants but none seemed to have any influence... Did you
mean to say you had implemented passing on arguments? I thought so but not
sure now...
There is also the question where to put things that would have usually
landed in startup.scd. e.g. I used to set Server.supernova there (use
supernova rather than scsynth as localhost).

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[bagong]

• but specifying sclang args seems appropriate.
  Yes, that would be nice!
• adding includePaths: quarks to a project is be really nice.
  Certainly, and that's already possible - with one significant shortcoming: helpfiles in paths integrated that way aren't be found by scdoc.

[crucialfelix]

re: the help files. there might be a fix someday for that. but not too many devs have time

I want to make a function that dumps the whole class tree, methods, help file paths to a json file. there are many uses for a data set like that.

• autocomplete-plus
• cmd-J to open a class file immediately (or also ctrl-click on the class name)
• opening help files directly in atom

which would solve the helpfile problem.