planck

Planck ClojureScript REPL
johanatan 2016-06-10T02:54:15.000175Z

@mfikes: can you explain what happens on the JS side of the call (while the command is being executed) at this line: https://github.com/mfikes/planck/blob/c8f6eaad8e873ade136bf840d6b4e7b0ac64d256/planck-cljs/src/planck/shell.cljs#L41 ?

johanatan 2016-06-10T02:54:20.000177Z

Does it spin wait until the result is available? It appears so to me since there's no callback involved.

johanatan 2016-06-10T02:57:08.000180Z

So, I think the high CPU use could be coming from the JS side.

johanatan 2016-06-10T03:00:22.000181Z

I just added a [NSThread sleepForTimeInterval: 200.0f] to the Obj-C (which should definitely 'park' the thread rather than spin it) and I still saw the CPU use at 100%. So, I'm fairly well convinced that it is indeed the JS side which is spinning.

mfikes 2016-06-10T07:24:36.000183Z

@johanatan: I added a sleep and can’t reproduce what you are seeing. In activity monitor my planck process shows 0.0% CPU while sleeping. You can also pause it in the debugger and look at stacks, etc.

* frame #0: 0x00007fff93d3b10a libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff92f4ed17 libsystem_c.dylib`nanosleep + 199
    frame #2: 0x00007fff8e80cc65 Foundation`+[NSThread sleepForTimeInterval:] + 156
    frame #3: 0x0000000100014004 planck`cljs_shell(args=@"1 element", arg_in=0x0000000000000000, encoding_in=0x0000000000000000, encoding_out=0x0000000000000000, env=0x0000000000000000, dir=0x0000000000000000) + 4948 at PLKSh.m:117
    frame #4: 0x000000010002d40a planck`__160-[PLKClojureScriptEngine startInitializationWithSrcPaths:outPath:cachePath:verbose:staticFns:elideAsserts:boundArgs:planckVersion:repl:dumbTerminal:bundledOut:]_block_invoke_2.303(.block_descriptor=<unavailable>, ctx=0x00007fff5fbfcfc0, argc=6, argv=0x00007fff5fbfce70) + 874 at PLKClojureScriptEngine.m:634
    frame #5: 0x0000000100006e96 planck`BlockFunctionCallAsFunction(ctx=0x00007fff5fbfcfc0, function=0x000000010b05a220, thisObject=0x000000010586ecc0, argc=6, argv=0x00007fff5fbfce70, exception=0x00007fff5fbfce58) + 86 at ABYUtils.m:5
    frame #6: 0x00007fff8ffca63a JavaScriptCore`JSC::JSCallbackObject<JSC::JSDestructibleObject>::call(JSC::ExecState*) + 506
    frame #7: 0x00007fff8fb73f70 JavaScriptCore`JSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 528

johanatan 2016-06-10T07:27:45.000184Z

Can you try reproducing with my code? @mfikes https://github.com/johanatan/screencap You'll need to install a few dependencies

mfikes 2016-06-10T07:28:26.000186Z

Yeah. I’ll try it later on. 🙂

johanatan 2016-06-10T07:28:47.000187Z

imagemagick, and fdupes

johanatan 2016-06-10T07:28:57.000188Z

But you could comment out the fdupes call

johanatan 2016-06-10T07:29:03.000189Z

Cool, thx!

mfikes 2016-06-10T13:47:54.000190Z

@johanatan: With the patch in https://github.com/mfikes/planck/issues/296 I was able to run your screencap code with planck only using CPU when it is actually doing something. 🙂

mfikes 2016-06-10T14:16:38.000193Z

@johanatan: Fix pushed. It was a silly mistake—forgot to call the fn that initializes the NSCondition stuff, so it went into a busy loop. Sorry for the goose chase 😞

johanatan 2016-06-10T15:03:36.000194Z

Haha, no worries. Thx for the quick response!

johanatan 2016-06-10T17:21:15.000195Z

At least now my fan doesn't go crazy when running screencap lol 🙂

mfikes 2016-06-10T17:22:13.000196Z

Yep. Previously it was a pure busy loop, spinning as fast as it possibly could. 🙂