Sill issues with Better CommandLineTool 'DeeToXed'

mc's picture

Sorry for reissuing that old CommandLineTool problem.

Though the 'deeToX-ified' version pointed to again recently

(see: CommandLineTool strange 'zoom artefact')

works way better than the original one from Apple, there are still problems if cascading them, that is, using 'Standard In' for 'piping'.

The simple patch below checks the number of certain processes running every second.

It works a while but then the screen turns transparent, or shows similar 'artefacts' as described in the last thread.

QC-Editor only says:

22.06.12 15:11:49,208 Quartz Composer: *** EXCEPTION IGNORED: *** -[NSConcreteTask terminationStatus]: task still running

Could this be due to a memory leek?

Thank you all for looking at this once more!

PreviewAttachmentSize
cmdLineDeeToX_test.zip21.07 KB

mc's picture
Re: Sill issues with Better CommandLineTool 'DeeToXed'

After lots of testing, i could further isolate and narrow the current issue down to a very simple patch that seems to touch the heart of the problem.

It simply uses the 'sleep' cmd. As the CommandLineTool does employs synchronous execution, 'sleep' pauses the whole composition for the time specified (nice side-effect btw ;-) and then continuous until the command is triggered again.

This runs for a while (especially in QC-editor on fast machines), but then crashes at some point. Crashes are more obvious when compositions are built into apps. Therefore, the zip below also contains the test-patch as an app. On my older McBookPro this app crashes after about 3-5 'pauses', my imac runs it for a much longer time.

However, most important for those who can make sense of that behaviour will probably be the crash-post, put in the zip as well.

Hope things do reproduce at your side and that there possibly is a solution to use the cmd-line with QC.

bst, mc

PreviewAttachmentSize
sleepTesterDeeToX.zip227.06 KB

gtoledo3's picture
Re: Sill issues with Better CommandLineTool 'DeeToXed'

I took about 10 minutes last night to try a couple of things with this project... it really looks like the stock project should work right, and that what is happening is a legitimate bug.

I have tended now to do stuff like this with more forward leaning API's, vs. apple script/commandline type stuff, because it seems less frocked with hassle aside from this issue. It also feels more likely to work stably and in to the future as sandboxing and other stuff takes shape.

A good example, though not in plugin, would be something I setup recently to open up some helper apps via a menu in Cocoa. I could have used AppleEvent/commandline stuff, but it was really much easier to find the more modern api variant that amounts to " [[NSWorkspace sharedWorkspace] launchApplication:helperAppPath];" , whereas the AppleEvent version was a bit more complicated. Stuff like that would integrate well into a QCPlugin or Patch.

I'd be curious to reformat the CommandLineTool as a skankySDK patch, or a consumer in either format.

Whatever it's doing to the projection matrix seems unexpected for a processor patch, or any patch. I setup a standard projection matrix and did a couple of other things that I felt were stupid to try, especially for a processor (kinda anticipating that QCPlugin might be wrongly expecting stuff), and it worked around the side effect I get of the object getting "bigger" again and again, but the aspect ratio and initial size is still wrong.

I've seen another post recently, outside of the QC realm and dealing with OpenGL that makes me think this is an issue that may be a non QC bug. Sorry for being vague, I can't remember more details of the developer post at the moment.

mc's picture
Re: Sill issues with Better CommandLineTool 'DeeToXed'

Thanx for investing your time into this -- obviously rather basic -- problem.

gtoledo3 wrote:
I'd be curious to reformat the CommandLineTool as a skankySDK patch, or a consumer in either format.

That would be awesome, yes! Any idea how we get along this way?

gtoledo3 wrote:
A good example, though not in plugin, would be something I setup recently to open up some helper apps via a menu in Cocoa. I could have used AppleEvent/commandline stuff, but it was really much easier to find the more modern api variant that amounts to " [[NSWorkspace sharedWorkspace] launchApplication:helperAppPath];" , whereas the AppleEvent version was a bit more complicated. Stuff like that would integrate well into a QCPlugin or Patch.

Could you elaborate on this -- possibly alternative -- approach of yours a bit? Can it be considered a workaround to get information of other apps into QC? Would that way still be synchronous, like the AppleEvent/commandline?

Eager to learn more, mc

gtoledo3's picture
Re: Sill issues with Better CommandLineTool 'DeeToXed'

What specifically are you trying to accomplish from the command line? I got something about sleep, but I don't fully understand. I can't answer ( or say that I don't know how to answer ), without that info :-)

Generally, I'm just talking about issuing the "commands" using the cocoa api methods, or getting info from them, instead of applescript or commandline stuff. What's involved really depends on what is being attempted.

In most cases this is a much better approach, mainly because the api's have some stuff occasionally to make sure things do what you expect in edge cases.

As far as setting it up as a skanky plugin - it looks like it would be pretty straightforward, but there's not necessarily a guarantee that it would fix the problem. It would show that maybe there's something wrong with the QCPlugin wrapper.

mc's picture
Re: Sill issues with Better CommandLineTool 'DeeToXed'

OK fine, let's get as specific and detailed as you like.

But let me state first that i love the generality of the commandline and it would just be so GREAT, if we could get that thing to work!

Yes, i see the risk of hitting on a deeper API problem, if one 'translates' the code of Apple and DeeToX for the skankySDK, but if it really is "straightforward", one hero experienced with the skankySDK might want to try it, still?!


Now, current my urgent problem is to find out, how many user processes of a specific name pattern are actually running at the moment of interest, that is, at the time of executing that tiny commandline pipe of my first post with attached examples above. Meanwhile i also tried to get rid of the 'piping' in QC and wrote a one-line-shell-script and then point the CommandLineTool 'Path' to it. This simplifies the patch, works for a while, but does not solve the problems and crashes reported here. So, most specifically, i need this information (where 'mcLib' is the process name pattern):

!/bin/bash

ps acx | grep -i "mcLib" | awk END{'print NR'}

How could i get hold of this information outherwise? Possibly via "cocoa api methods"?

Best, mc