119 lines
6.1 KiB
Markdown
119 lines
6.1 KiB
Markdown
---
|
|
title: OpenFrameworks, try 1...
|
|
date: June 13, 2011
|
|
author: Chris Hodapp
|
|
tags:
|
|
- Technobabble
|
|
- rant
|
|
---
|
|
|
|
My attempts at doing things with
|
|
[OpenFrameworks](http://openframeworks.cc/) on MacOS X have been
|
|
mildly disastrous. This is a bit of a shame, because I was really
|
|
starting to like OpenFrameworks and it was not tough to pick up after
|
|
being familiar with [Processing](https://processing.org/).
|
|
|
|
I'm pretty new to XCode, but it's the "official" environment for
|
|
OpenFrameworks on OS X, so it's the first thing I tried. The first few
|
|
attempts at things (whether built-in examples, or my own code) went
|
|
just fine, but today I started trying some things that were a little
|
|
more complex - i.e. saving the last 30 frames from the camera and
|
|
using them for some filtering operations. My code probably had some
|
|
mistakes in it, I'm sure, and that's to be expected. The part where
|
|
things became incredibly stupid was somewhere around when the mistakes
|
|
caused the combination of XCode, GDB, and OpenFrameworks to hose the
|
|
system in various ways.
|
|
|
|
First, it was the Dock taking between 15 and 30 seconds to respond
|
|
just so I could force-quit the application. Then it was the debugger
|
|
taking several seconds to do 100 iterations of a loop that had nothing
|
|
more than an array member assignment inside of it (and it had
|
|
640x480x3 = 921,600 iterations total) if I tried to set breakpoints,
|
|
thus basically making interactive debugging impossible. The debugging
|
|
was already a pain in the ass; I had reduced some code down to
|
|
something like this:
|
|
|
|
```c
|
|
int size = cam_width * cam_height * 3;
|
|
for(int i = 0; i < frame_count; ++i) {
|
|
unsigned char * blah = new unsigned char[size];
|
|
for(int j = 0; j < size; ++j) blah[j] = 0;
|
|
}
|
|
```
|
|
|
|
...after a nearly identical `memset` call was smashing the stack and
|
|
setting `frame_count` to a value in the billions, so I was really
|
|
getting quite frazzled at this.
|
|
|
|
Running it a few minutes ago without breakpoints enabled led to a
|
|
bunch of extreme sluggishness, then flickering and flashing on the
|
|
monitor and I was not able to interact with anything in the GUI (which
|
|
was the 3rd or 4th time this had happened today, with all the
|
|
Code::Blocks nonsense below). I SSHed in from another machine and
|
|
killed XCode, but the monitor just continued to show the same image,
|
|
and it appeared that the GUI was completely unresponsive except for a
|
|
mouse cursor. I had to hold the power button to reboot, and saw this
|
|
in the Console but nothing else clear before it:
|
|
|
|
```
|
|
6/13/11 1:11:19 AM [0x0-0x24024].com.google.Chrome[295] [463:24587:11560062687119:ERROR:gpu_watchdog_thread.cc(236)] The GPU process hung. Terminating after 10000 ms.
|
|
```
|
|
|
|
A little before trying XCode for a 2nd time, I had also attempted to
|
|
set up Code::Blocks since it's OpenFrameworks' "official" IDE for
|
|
Linux and Windows and XCode was clearly having . First I painstakingly
|
|
made it built from an SVN copy and finally got it to run (had to
|
|
disable FileManager and NassiShneiderman plugins which would not build
|
|
and make sure it was building for the same architecture as wxWidgets
|
|
was built for). As soon as I tried to quit it, the Dock became totally
|
|
unresponsive, then Finder itself followed along with the menu bar for
|
|
the whole system. I was not able to SSH in. Despite the system being
|
|
mostly responsive, I had to hard reset. I found a few things in the
|
|
console:
|
|
|
|
```
|
|
6/12/11 9:43:54 PM com.apple.launchd[1] (com.apple.coreservicesd[66]) Job appears to have crashed: Segmentation fault
|
|
6/12/11 9:43:54 PM com.apple.audio.coreaudiod[163] coreaudiod: CarbonCore.framework: coreservicesd process died; attempting to reconnect but future use may result in erroneous behavior
|
|
6/12/11 9:43:55 PM com.apple.ReportCrash.Root[18181] 2011-06-12 21:43:55.011 ReportCrash[18181:2803] Saved crash report for coreservicesd[66] version ??? (???) to /Library/Logs/DiagnosticReports/coreservicesd_2011-06-12-214355_localhost.crash
|
|
6/12/11 9:44:26 PM com.apple.Dock.agent[173] Sun Jun 12 21:44:26 hodapple2.local Dock[173] Error: kCGErrorIllegalArgument: CGSSetWindowTransformsAtPlacement: Singular matrix at index 2: [0.000 0.000 0.000 0.000]
|
|
```
|
|
|
|
It started up properly after a reset, but I couldn't do anything
|
|
useful with it because despite there being a script that was supposed
|
|
to take care of this while building the bundle the application was not
|
|
able to see any of its plugins, which included a compiler plugin. I
|
|
attempted a binary OS X release which had a functioning set of
|
|
plugins, but was missing other dependencies set in the projects, which
|
|
were Linux-specific. I could probably put together a working
|
|
configuration if I worked in Code::Blocks a bit, but I have not tried
|
|
yet.
|
|
|
|
This is all incredibly annoying. There is no reason a user process
|
|
should be capable of taking down the whole system like this,
|
|
especially inside of a debugger, yet apparently it's pretty trivial to
|
|
make this happen. I've written more than enough horrible code in
|
|
various different environments (CUDA-GDB on a Tesla C1060, perhaps?)
|
|
to know what to expect. I guess I can try developing on Linux instead,
|
|
and/or using Processing. I know it's not quite the same, but I've
|
|
never had a Processing sketch hose the whole system at least.
|
|
|
|
*Later addition (2011-06-20, but not written here until November because I'd buried the notes somewhere):*
|
|
|
|
I attempted to make an OpenFrameworks project built with Qt Creator
|
|
(which of course uses
|
|
[QMake](http://doc.qt.nokia.com/latest/qmake-manual.html). OpenFrameworks
|
|
relies on QuickTime, and as it happens, QuickTime is 32-bit only. If
|
|
you take a look at some of the headers, the majority of it is just
|
|
#ifdef'ed away if you try to build 64-bit and this completely breaks
|
|
the OpenFrameworks build.
|
|
|
|
Ordinarily, this would not be an issue as I would just do a 32-bit
|
|
build of everything else too. However, QMake refuses to do a 32-bit
|
|
build on OS X for some unknown reason (and, yes, I talked to some Qt
|
|
devs about this). It'll gladly do it on most other platforms, but not
|
|
on OS X. Now, GCC has no problems building 32-bit, but this does no
|
|
good when QMake keeps adding `-arch x86_64` no matter what. I
|
|
attempted all sorts of options such as `CONFIG += x86`, `CONFIG -=
|
|
x86_64`, `QMAKE_CXXFLAGS -= -arch x86_64`, or `+= -m32`, or `+= -arch i386`...
|
|
but none of them to any avail.
|