[Openmcl-devel] Log messages

[Paul Krueger]

In the unlikely case that anyone is interested, I’ve discovered the (almost) root cause of this problem. It turns out that these CG log messages are always preceded by another logged error message:
12/2/14 10:18:26.468 AM dx86cl64[94101]: [QL] Can't get plugin bundle info at file:///Applications/Xcode.app/Contents/Library/QuickLook/SourceCode.qlgenerator

That is something of a known problem associated with quicklook when creating open panels and as far as I can tell there is no fix for it. It’s sort of harmless. If you check your log when you open a file in the CCL IDE you’ll see this message (at least I always do). That may be an artifact of something else in my system, but I haven’t been able to identify what that might be or what to do about it. If anyone DOES know, please contact me.

It turns out that if you #/retain an NSOpenPanel then you not only get that message, you also trigger whatever logging is causing those CG messages that I showed in my first email. I’ve verified that this happens if I do a (make-instance ns:ns-open-panel …) or (#/init (#/allocate ns:ns-open-panel)) or (#/retain (#/openPanel ns:ns-open-panel)). The only way to avoid the CG messages is to create a new temporary open panel each time I need it via (#/openPanel ns:ns-open-panel). Some day soon I’ll check in changes to my contrib that do that.

On Sep 15, 2014, at 6:41 PM, Paul Krueger <plkrueger at comcast.net> wrote:

> On Sep 15, 2014, at 6:00 PM, R. Matthew Emerson <rme at clozure.com> wrote:
> 
>> 
>> On Sep 15, 2014, at 5:01 PM, Paul Krueger <plkrueger at comcast.net> wrote:
>> 
>>> While doing Mac app development using 1.10-dev-r16162-trunk I noticed that there are a large number of messages logged that appear to be tracking Core Graphics lib calls. This doesn’t hurt anything, but I’m wondering if somebody turned on some sort of debugging code that is creating the log entries. I’m doing the same sort of thing in my own code, which is how I discovered this. Is there any way to turn off this output?
>>> 
>>> Log output looks like:
>>> 
>>> 9/15/14 3:46:02.032 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
>>> 9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSTranslatePointForWindow
>>> 9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowBounds
>>> 9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
>>> 9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSTranslatePointForWindow
>>> 9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSGetWindowBounds
>>> 
>>> with LOTS more of the same.
>> 
>> I don't think we did anything to turn on that sort of logging.  At least I don't remember doing anything like that myself.
>> 
>> You could attach the debugger to the lisp and set a breakpoint on NSLog.
>> 
>> With lldb you'd do:
>> 
>> $ lldb
>> attach <pid of ccl>
>> process handle --notify false --pass true --stop false SIGKILL SIGILL SIGSEGV SIGBUS SIGFPE SIGUSR1 SIGUSR2 SIGEMT
>> b NSLog
>> cont
>> 
>> and then wait for the NSLog breakpoint to be hit.  The "bt" command will show a backtrace.  If the NSLog was called from lisp, you'll just see SPffcall as the caller.  Otherwise, maybe the backtrace will give you a clue where the log message is coming from.
> 
> No break was taken and the log messages kept coming, which I suppose tells us that they’re not coming from an NSLog call, but rather from something down lower. I’ll do a little research to see if I can discover anything on the web anywhere.
> 
> Thanks for the help.
> 
> By the way, I’ve discovered more problems with my contrib, but I haven’t resolved them all yet and don’t expect you to hold up the release for my fixes. Bummer. 
>