Disable AppNap in QtCollider, sclang, and scsynth #1011

snickell · 2013-12-23T23:30:37Z

This PR should disable appnap for supercollider processes (in paritcular: QtCollider, sclang & scsynth) on OS X 10.9. It will also inform OS X that we require high-quality-and-frequency timers.

Should still compile against earlier OS X SDKs (tested against 10.8)
Uses runtime API detection, so it will still disable appnap on 10.9, even if you compile against 10.8

NOTE: to compile this PR, you'll need to first apply PR #994 , which fixes compilation against the 10.9 SDK.

snickell · 2013-12-23T23:35:14Z

Should we disable AppNap on the QtCollider process? It seems like nothing crucial should be happening on this process, so if its in the background, maybe its reasonable for OS X to allow it to nap, saving a little power.
I've heard a "supernova" process mentioned, but I don't know what it is. Should we disable AppNap for the supernova process?

jamshark70 · 2013-12-24T00:25:33Z

Supernova is a replacement for scsynth, that supports parallel processing of DSP on multi-core processors. If app nap is bad for scsynth, it's bad for supernova too.

timblechmann · 2013-12-24T09:33:57Z

QtCollider/QcApplication.cpp

+  // On Mac, we may need to disable "App Nap", so we aren't put to sleep unexpectedly
+  SC::Apple::disableAppNap();
+#endif
+


afaict, there is no need for this: QtCollider is part of sclang, so it does not need to disable app nap by itself.

timblechmann · 2013-12-24T09:42:57Z

@snickell regarding your questions:

QtCollider is part of sclang (running in the same process)
appnap should probably be also disabled for supernova (located in server/supernova/). but i wonder, do scsynth and supernova really benefit from it?

also a more general question: does appnap take process priorities into account? didn't look into it, but sclang threads run at a higher priority than normal processes ...

snickell · 2014-01-06T02:04:58Z

Unfortunately, AppNap's behavior is relatively undefined (the same way as the OS scheduler's behavior is relativey undefined) and subject to change behind the scenes on future OS updates. Its all hinting, no promises. The more accurately/profusely we hint, the less likely we are to get the rug pulled in the future. As apple releases future updates I suspect they will get more aggressive about power saving, and throttle things back more and more, so my philosophy here is "when in doubt, hint we are doing something that needs quality timers and scheduling".

Obviously the higher priority of sclang threads alone wasn't enough to disable appnap, since we were observing negative napping behavior there.

In any case, the calls we are making aren't strictly speaking "disabling AppNap", they are informing OS/X that "this process is performing a user-observable activity that should be kept responsive". Additionally, we are telling OS/X that we want the best timer-resolution it can provide (most relevant to scsynth).

scsynth /probably/ wont' get appnapped already, because OS/X is /likely/ to notice that its using CoreAudio, and guess that nappiong something actively using CoreAudio is a BadIdea(TM). While it may not get appnapped even without hinting, its possible scsynth will get higher precision timers if it asks for them though, and I think that's a positive thing.

If we wanted to get fancier, we could probably turn the activity on/off depending on whether any synths were running or not, so if you are just working on the IDE without any synths you get a longer battery life, but I think that's much more bug prone and not worth blocking on.

danstowell · 2014-09-06T18:29:00Z

Mac folks: any reason not to merge this?

Tim pointed out one bit of unneeded code https://github.com/supercollider/supercollider/pull/1011/files#r8541216 but that aside?

timblechmann · 2014-09-06T18:57:49Z

two points:

the API is only available with 10.9. maybe it compiles against 10.8, but as it uses obj-c: does it actually run on 10.8? without testing, i guess it will print a warning to the terminal as beginActivityWithOptions:reason: will be unknown to the obj-c runtime
the only process that could be compromised by timer coalescing is sclang, as the audio servers do not use timers. imho only the sclang process should be marked as latency-critical.

timblechmann · 2014-09-06T19:02:39Z

aja, it checks the obj-c runtime ... so disregard my first point

bagong · 2014-10-05T22:52:27Z

I am quite surprised we don't have more complaints about this issue... I usually integrate this pullrequest in my build. Today I made a build from clean master without this PR and immediately had serious trouble whith the server taking a looong time to boot (10 s) and sometimes not booting at all... This should not get lost, most people who run into this will not be able to find out the reason and loose a lot of time trying to find out what is going on.

danstowell · 2014-10-06T07:23:44Z

Well, I think it'd be good to add the feature to supernova, and remove the unneeded one in qtcollider. It'd be lovely if @snickell could update the patch, but if not then I don't see any harm in merging-and-tweaking it.

snickell · 2014-10-06T21:12:14Z

I'd love to update, but not really having the time right now, so probably
best not to block on me?

On Mon, Oct 6, 2014 at 12:23 AM, danstowell notifications@github.com
wrote:

Well, I think it'd be good to add the feature to supernova, and remove the
unneeded one in qtcollider. It'd be lovely if @snickell
https://github.com/snickell could update the patch, but if not then I
don't see any harm in merging-and-tweaking it.

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

@snickell

Disable AppNap in QtCollider, sclang, and scsynth - thanks @snickell

bagong · 2014-10-07T09:15:38Z

Just as for the record and to think about when 3.6.7-osx comes out. This patch doesn't compile in an old build environment (required for OSX-10.6/universal-build compatibility). I get:

Scanning dependencies of target scsynth
[ 18%] Building CXX object server/scsynth/CMakeFiles/scsynth.dir/scsynth_main.cpp.o
Linking CXX executable scsynth
Undefined symbols for architecture i386:
  "_objc_msgSend", referenced from:
      SC::Apple::disableAppNap()     in libscsynth.a(SC_Apple.mm.o)
  ".objc_class_name_NSProcessInfo", referenced from:
      pointer-to-literal-objc-class-name in libscsynth.a(SC_Apple.mm.o)
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Undefined symbols for architecture x86_64:
  "_objc_msgSend", referenced from:
      SC::Apple::disableAppNap()     in libscsynth.a(SC_Apple.mm.o)
  "_objc_msgSend_fixup", referenced from:
      l_objc_msgSend_fixup_respondsToSelector_ in libscsynth.a(SC_Apple.mm.o)
  "_OBJC_CLASS_$_NSProcessInfo", referenced from:
      objc-class-ref in libscsynth.a(SC_Apple.mm.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/Jl/Jly2uO1qHses1EAUutY9R++++TI/-Tmp-//cc9RDY8l.out (No such file or directory)

danstowell · 2014-10-07T12:17:30Z

@bagong thanks. It would be handy to avoid breakage if it's easy, so perhaps you could see if there's an appropriate #if we can add to SC_Apple.mm? I think 10.6 is not used by the mac devs now...?

bagong · 2014-10-07T16:16:42Z

Well, the easiest would be not to apply the patch to 3.6, or to split into two branches, one that still works for old systems and 32-bit macs, and one that could be built in a newer environment and work well in 10.9 upwards. But if 3.7 finally hits the world, that might not be necessary? :)

timblechmann · 2014-10-07T17:10:32Z

i'd recommend not to support more than 3 osx versions in one codebase: apple continuously changes its APIs and keeping compatibility with older osx versions is a great way to waste time.

snickell · 2014-10-07T17:11:29Z

Hm, something fishy here....

The code in SC_Apple.mm "should" compile against 10.0 (!) let alone 10.6.
It does a runtime check for the necessary APIs before using them.

This is a linker issue. Its not finding the NSProcessInfo class itself,
which has been in OSX 10.0. To me this says its not linking against
libobjc.dylib itself. In other words, its linking it like its C++, not ObjC.

On Tue, Oct 7, 2014 at 9:16 AM, Rainer Schütz notifications@github.com
wrote:

Well, the easiest would be not to apply the patch to 3.6, or to split into
two branches, one that still works for old systems and 32-bit macs, and one
that could be built in a newer environment and work well in 10.9 upwards.
But if 3.7 finally hits the world, that might not be necessary? :)

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

snickell · 2014-10-07T17:13:16Z

Yeah, but this code SHOULD be 10.0 compatible, let alone 10.6. There's
something misconfigured with the way the file is being linked on the old
OSX version? The SC_Apple.o object isn't being linked against
libobjc.dylib, some Xcode setting on the file somewhere.

On Tue, Oct 7, 2014 at 10:10 AM, Tim Blechmann notifications@github.com
wrote:

i'd recommend not to support more than 3 osx versions in one codebase:
apple continuously changes its APIs and keeping compatibility with older
osx versions is a great way to waste time.

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

snickell · 2014-10-07T17:14:41Z

@bagong: are you compiling from within xcode?

On Tue, Oct 7, 2014 at 10:13 AM, Seth Nickell snickell@gmail.com wrote:

Yeah, but this code SHOULD be 10.0 compatible, let alone 10.6. There's
something misconfigured with the way the file is being linked on the old
OSX version? The SC_Apple.o object isn't being linked against
libobjc.dylib, some Xcode setting on the file somewhere.

On Tue, Oct 7, 2014 at 10:10 AM, Tim Blechmann notifications@github.com
wrote:

i'd recommend not to support more than 3 osx versions in one codebase:
apple continuously changes its APIs and keeping compatibility with older
osx versions is a great way to waste time.

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

bagong · 2014-10-07T17:18:05Z

No, just with cmake. Should I try? I am not sure how to go about... Create a xcode project file with cmake and then compile within XCode?

snickell · 2014-10-07T17:27:48Z

Still, with cmake it shouldn't make much difference.... maybe on 10.6 the
linker needs to be explicitly told to link Obj-C++ objects against libobjc?
Is your cmake reasonably up to date?

On Tue, Oct 7, 2014 at 10:18 AM, Rainer Schütz notifications@github.com
wrote:

No, just with cmake. Should I try? I am not sure how to go about... Create
a xcode project file with cmake and then compile within XCode?

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

bagong · 2014-10-07T17:30:16Z

Checking now...

timblechmann · 2014-10-07T17:32:04Z

The code in SC_Apple.mm "should" compile against 10.0 (!) let alone 10.6.
It does a runtime check for the necessary APIs before using them.

it compiles, but it does not link ...

apple likes to move around code among their frameworks ... maybe you
need to link against a different framework?

This is a linker issue. Its not finding the NSProcessInfo class itself,
which has been in OSX 10.0. To me this says its not linking against
libobjc.dylib itself. In other words, its linking it like its C++, not
ObjC.

snickell · 2014-10-07T17:45:20Z

@bagong is there a way you can get the "verbose" compile output from cmake?
If I could see the actual gcc calls I might be able to tell what's going
wrong..... I have absolutely zero cmake experience, I always use XCode's
build system on OSX.

AFAICT the foundation framework contains everything we need here, and has
since at least 10.6

On Tue, Oct 7, 2014 at 10:32 AM, Tim Blechmann notifications@github.com
wrote:

The code in SC_Apple.mm "should" compile against 10.0 (!) let alone
10.6.
It does a runtime check for the necessary APIs before using them.

it compiles, but it does not link ...

apple likes to move around code among their frameworks ... maybe you
need to link against a different framework?

This is a linker issue. Its not finding the NSProcessInfo class itself,
which has been in OSX 10.0. To me this says its not linking against
libobjc.dylib itself. In other words, its linking it like its C++, not
ObjC.

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

bagong · 2014-10-07T17:51:42Z

Yea, I can set verbosity up. I'm just updating macports. That link looked dead in the past, but they seem to have reactivated 10.6 support. I'll try to refresh the system and send the output of a verbose compile your way. Thanks for your support! Much appreciated!

bagong · 2014-10-08T00:09:30Z

It took a while, sorry, came into trouble when trying to update via Macports. I switched to Homebrew, it seems to support 10.6 with universal builds well, now (and yes, purged MacPorts without trace :)).

Unfortunately the error is still the same. This is the verbose output:

[ 18%] Built target libscsynth
make -f server/scsynth/CMakeFiles/scsynth.dir/build.make server/scsynth/CMakeFiles/scsynth.dir/depend
cd /Users/rainer/Projects/supercollider/build && /usr/local/Cellar/cmake/3.0.2/bin/cmake -E cmake_depends "Unix Makefiles" /Users/rainer/Projects/supercollider/source /Users/rainer/Projects/supercollider/source/server/scsynth /Users/rainer/Projects/supercollider/build /Users/rainer/Projects/supercollider/build/server/scsynth /Users/rainer/Projects/supercollider/build/server/scsynth/CMakeFiles/scsynth.dir/DependInfo.cmake --color=
make -f server/scsynth/CMakeFiles/scsynth.dir/build.make server/scsynth/CMakeFiles/scsynth.dir/build
Linking CXX executable scsynth
cd /Users/rainer/Projects/supercollider/build/server/scsynth && /usr/local/Cellar/cmake/3.0.2/bin/cmake -E cmake_link_script CMakeFiles/scsynth.dir/link.txt --verbose=1
/usr/bin/c++    -msse -mfpmath=sse -O3 -DNDEBUG -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names   CMakeFiles/scsynth.dir/scsynth_main.cpp.o  -o scsynth  libscsynth.a /usr/lib/libpthread.dylib /usr/lib/libdl.dylib /Users/rainer/Projects/supercollider/source/cmake_modules/../platform/mac/lib/scUBlibsndfile.a -framework CoreAudio /usr/lib/libpthread.dylib -framework vecLib -framework CoreServices 
Undefined symbols for architecture i386:
  "_objc_msgSend", referenced from:
      SC::Apple::disableAppNap()     in libscsynth.a(SC_Apple.mm.o)
  ".objc_class_name_NSProcessInfo", referenced from:
      pointer-to-literal-objc-class-name in libscsynth.a(SC_Apple.mm.o)
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Undefined symbols for architecture x86_64:
  "_objc_msgSend", referenced from:
      SC::Apple::disableAppNap()     in libscsynth.a(SC_Apple.mm.o)
  "_objc_msgSend_fixup", referenced from:
      l_objc_msgSend_fixup_respondsToSelector_ in libscsynth.a(SC_Apple.mm.o)
  "_OBJC_CLASS_$_NSProcessInfo", referenced from:
      objc-class-ref in libscsynth.a(SC_Apple.mm.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/Jl/Jly2uO1qHses1EAUutY9R++++TI/-Tmp-//ccFeOPUy.out (No such file or directory)
make[2]: *** [server/scsynth/scsynth] Error 1
make[1]: *** [server/scsynth/CMakeFiles/scsynth.dir/all] Error 2
make: *** [all] Error 2

snickell · 2014-10-08T00:21:19Z

Can you run:
/usr/bin/c++ --version

-Seth

On Tue, Oct 7, 2014 at 5:09 PM, Rainer Schütz notifications@github.com
wrote:

It took a while, sorry, came into trouble when trying to update via
Macports. I switched to Homebrew, it seems to support 10.6 with universal
builds well, now (and yes, purged MacPorts without trace :)).

Unfortunately the error is still the same. This is the verbose output:

[ 18%] Built target libscsynth
make -f server/scsynth/CMakeFiles/scsynth.dir/build.make server/scsynth/CMakeFiles/scsynth.dir/depend
cd /Users/rainer/Projects/supercollider/build && /usr/local/Cellar/cmake/3.0.2/bin/cmake -E cmake_depends "Unix Makefiles" /Users/rainer/Projects/supercollider/source /Users/rainer/Projects/supercollider/source/server/scsynth /Users/rainer/Projects/supercollider/build /Users/rainer/Projects/supercollider/build/server/scsynth /Users/rainer/Projects/supercollider/build/server/scsynth/CMakeFiles/scsynth.dir/DependInfo.cmake --color=
make -f server/scsynth/CMakeFiles/scsynth.dir/build.make server/scsynth/CMakeFiles/scsynth.dir/build
Linking CXX executable scsynth
cd /Users/rainer/Projects/supercollider/build/server/scsynth && /usr/local/Cellar/cmake/3.0.2/bin/cmake -E cmake_link_script CMakeFiles/scsynth.dir/link.txt --verbose=1
/usr/bin/c++ -msse -mfpmath=sse -O3 -DNDEBUG -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/scsynth.dir/scsynth_main.cpp.o -o scsynth libscsynth.a /usr/lib/libpthread.dylib /usr/lib/libdl.dylib /Users/rainer/Projects/supercollider/source/cmake_modules/../platform/mac/lib/scUBlibsndfile.a -framework CoreAudio /usr/lib/libpthread.dylib -framework vecLib -framework CoreServices
Undefined symbols for architecture i386:
"_objc_msgSend", referenced from:
SC::Apple::disableAppNap() in libscsynth.a(SC_Apple.mm.o)
".objc_class_name_NSProcessInfo", referenced from:
pointer-to-literal-objc-class-name in libscsynth.a(SC_Apple.mm.o)
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Undefined symbols for architecture x86_64:
"_objc_msgSend", referenced from:
SC::Apple::disableAppNap() in libscsynth.a(SC_Apple.mm.o)
"objc_msgSend_fixup", referenced from:
l_objc_msgSend_fixup_respondsToSelector in libscsynth.a(SC_Apple.mm.o)
"OBJC_CLASS$_NSProcessInfo", referenced from:
objc-class-ref in libscsynth.a(SC_Apple.mm.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/Jl/Jly2uO1qHses1EAUutY9R++++TI/-Tmp-//ccFeOPUy.out (No such file or directory)
make[2]: *** [server/scsynth/scsynth] Error 1
make[1]: *** [server/scsynth/CMakeFiles/scsynth.dir/all] Error 2
make: *** [all] Error 2

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

bagong · 2014-10-08T00:27:33Z

i686-apple-darwin10-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I just checked XCode and found that I could download (and update) Mac OSX 10.6 core library and developer library. Might that contain the missing symbols? It'll be done in 10 mins, I'll tell you if it changes anything...

bagong · 2014-10-08T00:31:33Z

No, still the same error... I'll try with an XCode-Generator now...

snickell · 2014-10-08T00:32:03Z

I think I'm on to the problem, hold on a sec....

On Tue, Oct 7, 2014 at 5:31 PM, Rainer Schütz notifications@github.com
wrote:

No, still the same error... I'll try with an XCode-Generator now...

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

bagong · 2014-10-08T00:32:23Z

Okay, great!

snickell · 2014-10-08T00:34:58Z

OK, try running this command:

 cd /Users/rainer/Projects/supercollider/build/server/scsynth ; /usr/bin/c++    -msse -mfpmath=sse -O3 -DNDEBUG -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names   CMakeFiles/scsynth.dir/scsynth_main.cpp.o  -o scsynth  libscsynth.a /usr/lib/libpthread.dylib /usr/lib/libdl.dylib /Users/rainer/Projects/supercollider/source/cmake_modules/../platform/mac/lib/scUBlibsndfile.a -framework CoreAudio /usr/lib/libpthread.dylib -framework vecLib -framework CoreServices -framework Foundation

This is exactly the command your cmake is running to link, but with "-framework Foundation" tacked to the end. If this works, the next question is why "-framework Foundation" isn't making it into the link command.

bagong · 2014-10-08T00:52:41Z

Hm, not sure if I understood what I should do, but something changed:

I did make as usual.
At the error I executed the command you sent - nothing happened
Then I "make"d again and it finished "target scsynth"
Then I went back to the parent build folder and "make"d again

It went right past that point quite a while, but then broke here:

[ 33%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/PyrParseNode.cpp.o
[ 33%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/PyrSignal.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/PyrSymbolTable.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/SC_LanguageClient.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/SC_LanguageConfig.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/SC_TerminalClient.cpp.o
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp: In function ‘SC_LanguageClient* createLanguageClient(const char*)’:
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected type-specifier before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: cannot convert ‘int*’ to ‘SC_LanguageClient*’ in return
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected ‘;’ before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: ‘QtCollider’ has not been declared
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp: In function ‘SC_LanguageClient* createLanguageClient(const char*)’:
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected type-specifier before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: cannot convert ‘int*’ to ‘SC_LanguageClient*’ in return
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected ‘;’ before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: ‘QtCollider’ has not been declared
lipo: can't figure out the architecture type of: /var/folders/Jl/Jly2uO1qHses1EAUutY9R++++TI/-Tmp-//cc0eQKAP.out
make[2]: *** [lang/CMakeFiles/libsclang.dir/LangSource/SC_TerminalClient.cpp.o] Error 1
make[1]: *** [lang/CMakeFiles/libsclang.dir/all] Error 2
make: *** [all] Error 2

snickell · 2014-10-08T01:00:47Z

Is this a clean checkout? Its weird that the "-framework Foundation" wasn't
in your link arguments to start with... its there in the cmake file. I'm
wondering if its possible there's a crufty piece of an old build
interfering??? Otherwise, I'm pretty much stumped.

-Seth

On Tue, Oct 7, 2014 at 5:52 PM, Rainer Schütz notifications@github.com
wrote:

Hm, not sure if I understood what I should do, but something changed:

I did make as usual.

At the error I executed the command you sent - nothing happened

Then I "make"d again and it finished "target scsynth"

Then I went back to the parent build folder and "make"d again

It went right past that point quite a while, but then broke here:

[ 33%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/PyrParseNode.cpp.o
[ 33%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/PyrSignal.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/PyrSymbolTable.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/SC_LanguageClient.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/SC_LanguageConfig.cpp.o
[ 34%] Building CXX object lang/CMakeFiles/libsclang.dir/LangSource/SC_TerminalClient.cpp.o
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp: In function ‘SC_LanguageClient* createLanguageClient(const char_)’:
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected type-specifier before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: cannot convert ‘int_’ to ‘SC_LanguageClient_’ in return
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected ‘;’ before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: ‘QtCollider’ has not been declared
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp: In function ‘SC_LanguageClient_ createLanguageClient(const char_)’:
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected type-specifier before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: cannot convert ‘int_’ to ‘SC_LanguageClient_’ in return
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: expected ‘;’ before ‘QtCollider’
/Users/rainer/Projects/supercollider/source/lang/LangSource/SC_TerminalClient.cpp:879: error: ‘QtCollider’ has not been declared
lipo: can't figure out the architecture type of: /var/folders/Jl/Jly2uO1qHses1EAUutY9R++++TI/-Tmp-//cc0eQKAP.out
make[2]: *_* [lang/CMakeFiles/libsclang.dir/LangSource/SC_TerminalClient.cpp.o] Error 1
make[1]: *** [lang/CMakeFiles/libsclang.dir/all] Error 2
make: *** [all] Error 2

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

bagong · 2014-10-08T01:16:26Z

Are you referring to CMakeList.txt in servers/scsynth? -framework Foundation is in is there in the master-branch but not in the 3.6 branch.
master: target_link_libraries(libscsynth "-framework Accelerate -framework CoreServices -framework Foundation")
3.6: target_link_libraries(libscsynth "-framework vecLib -framework CoreServices")
I'll make a fresh checkout now...

bagong · 2014-10-08T01:31:44Z

Okay, it is not in 3.6, I'll add it. As to the SC_TerminalClient error, I'll check on readline. Maybe after all homebrew does not provide a universal binary. I'll let you know, if you're still willing to listen :)

bagong · 2014-10-08T02:39:20Z

I verified that readline is a universal binary
I can build with vanilla 3.6 and the new build-system, so it's somewhere in the additions. I'll pin it down.

bagong · 2014-10-08T12:05:39Z

@Snickel, I am pretty sure my problem is where (or if) to put the

+#ifdef __APPLE__
+   printf("Calling disableAppNap for sclang...\n");
+   SC::Apple::disableAppNap();
+#endif
+

in the old SC_Terminal_Client.cpp. It differs substantially from the one in the 3.7 branch. There is no SC_DLLEXPORT SC_LanguageClient ...

Could you spare a minute to have a look? It's here:

https://github.com/supercollider/supercollider/blob/3.6/lang/LangSource/SC_TerminalClient.cpp

bagong · 2014-10-08T12:17:36Z

On a more general line: There is a current thread on SC-Users where Arthur Sauer describes pretty frustrating experiences after force moving to 10.9 with a given project developed in 3.6.6. Seems likely this is AppNap-related although his findings are not unambiguous yet:

http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SERVER-FAILURE-with-SC-3-6-6-on-OSX-10-9-5-tt7613700.html

I have invited him to this thread. Hopefully he can provide some real world experiences. His findings (nested in two ifs) would mean there is another process affected by AppNap that might be relevant when communicating with SC from another Application (where all of SC goes to the background).

Disable AppNap in QtCollider, sclang, and scsynth

b9e8bd0

snickell added 2 commits December 23, 2013 15:43

Add files I forgot to add in the initial commit.

2ca7bd2

Remove debug printf()s.

6eff81f

timblechmann reviewed Dec 24, 2013
View reviewed changes

danstowell added the os: Mac OS X label Sep 6, 2014

danstowell added a commit that referenced this pull request Oct 6, 2014

Merge pull request #1011 from snickell/DisableAppNap

d1d289d

Disable AppNap in QtCollider, sclang, and scsynth - thanks @snickell

danstowell merged commit d1d289d into supercollider:master Oct 6, 2014

Disable AppNap in QtCollider, sclang, and scsynth #1011

Disable AppNap in QtCollider, sclang, and scsynth #1011

Conversation

snickell commented Dec 23, 2013

snickell commented Dec 23, 2013

jamshark70 commented Dec 24, 2013

timblechmann Dec 24, 2013

Choose a reason for hiding this comment

timblechmann commented Dec 24, 2013

snickell commented Jan 6, 2014

danstowell commented Sep 6, 2014

timblechmann commented Sep 6, 2014

timblechmann commented Sep 6, 2014

bagong commented Oct 5, 2014

danstowell commented Oct 6, 2014

snickell commented Oct 6, 2014

bagong commented Oct 7, 2014

danstowell commented Oct 7, 2014

bagong commented Oct 7, 2014

timblechmann commented Oct 7, 2014

snickell commented Oct 7, 2014

snickell commented Oct 7, 2014

snickell commented Oct 7, 2014

bagong commented Oct 7, 2014

snickell commented Oct 7, 2014

bagong commented Oct 7, 2014

timblechmann commented Oct 7, 2014

snickell commented Oct 7, 2014

bagong commented Oct 7, 2014

bagong commented Oct 8, 2014

snickell commented Oct 8, 2014

bagong commented Oct 8, 2014

bagong commented Oct 8, 2014

snickell commented Oct 8, 2014

bagong commented Oct 8, 2014

snickell commented Oct 8, 2014

bagong commented Oct 8, 2014

snickell commented Oct 8, 2014

bagong commented Oct 8, 2014

bagong commented Oct 8, 2014

bagong commented Oct 8, 2014

bagong commented Oct 8, 2014

bagong commented Oct 8, 2014