Small Nuitka Progress; More on Webkit messages

As mentioned yesterday, the Nuitka compile ended with a futile search for "ldd" on Mac OS. Kay quickly replied with a one-line fix to repair a regression introduced recently. I applied it and reran the compile. This time it got much further still, producing the rather jaw-dropping message,

Total memory usage before running scons: 175.18 GB (188101951488 bytes)

Some seconds later it died on a failure to find '/Library/Frameworks/Tk.framework/Versions/8.5/Tk'. It already has found and collected _tkinter.so from the Python 3.4 framework. The problem seems to be that the full Tk.framework is not in /Library/Frameworks; it is in /System/Library/Frameworks. However, that is not what the otool command reports:

 otool -L ./lib/python3.4/lib-dynload/_tkinter.so
./lib/python3.4/lib-dynload/_tkinter.so:
 /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.15)
 /Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.15)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

Why would otool tell this fib?

Setting that aside, I ran cobro from source again and observed the nuisance messages more closely, and tried to relate them to what the browser was doing.

The first two messages—one about cannot find Plug-Ins/DjVu, and one about cannot perform a dlopen of the QuickTime Plugin—come out instantly when I click to load the first comic, XKCD. That is quite a simple page with no obvious ads or other plug-in-requiring content.

Then I browse several comics down to Questionable Content. It fully loads (per the progress bar) and I am quietly scrolling it when there is a burst of 20 repetitions of this one: ": CGContextRestoreGState: invalid context 0x1292d1c80. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update."

I shan't reiterate how offensive I find this text to be. The point is, there is absolutely nothing I can do to control or prevent it. The fact that it happened several seconds after the page had completed loading strongly indicates that the fault is in some content loaded by an ad on the page. The comic image just sits there, but ad frames often roll through animated sequences of content. At some point, an ad pulled in something that triggered these messages.

I can't stop a webcomic from loading ads, indeed I don't want to do so. I designed Cobro as a full browser, and not as a simple image scraper like ComicTastic whose UI I have copied, precisely because I did not want to deprive comic artists of their livelihood. And I can't censor the content the ads load. Can I? I doubt much whether I could insert something like adblock into the Webkit (or WebEngine) browser.

So these bursts of pointless and offensive messages will come out on the console and I have no way to prevent them and cannot possibly respond to them.

After I had browsed several more comics, while Stone Soup (from comics.com) was still (slowly) loading, a new message appeared:

"vtDecompressionDuctCreate signalled err=-8973 (err) (Could not select and open decoder instance) at /SourceCache/CoreMedia_frameworks/CoreMedia-1562.19/Sources/VideoToolbox/VTDecompressionSession.c line 1181 slow render still not complete"

It was followed by 19 more repetitions of the CGContextRestoreGState one.

Alright now, David, start thinking constructively instead of just bitching! These messages are streaming out from the browser code but they are, one supposes, directed to stderr. Surely there is some way to take control of stderr? After all, if this was a GUI app (which it should be) it would not have a stderr and presumably these messages would "fade, unseen by any human eye" (Wordsworth), and serves them right.

I must look into this.