Ah! Needed to be NSUInteger. Sorry for all the wasted time, and thanks for all your help!
-- Rick On Apr 27, 2010, at 01:18:13, Rick Mann wrote: > Yep, Xcode seems to refuse to build the 64-bit version of my plugin. Which is > weird, 'cause it's definitely putting all the archs in there: > > $ file > /Users/rmann/LZRepo/SatTrack/MCOverlay/trunk/MCOverlay/build/Debug/MCOverlay.plugin/Contents/MacOS/MCOverlay > > /Users/rmann/LZRepo/SatTrack/MCOverlay/trunk/MCOverlay/build/Debug/MCOverlay.plugin/Contents/MacOS/MCOverlay: > Mach-O universal binary with 3 architectures > /Users/rmann/LZRepo/SatTrack/MCOverlay/trunk/MCOverlay/build/Debug/MCOverlay.plugin/Contents/MacOS/MCOverlay > (for architecture x86_64): Mach-O 64-bit bundle x86_64 > /Users/rmann/LZRepo/SatTrack/MCOverlay/trunk/MCOverlay/build/Debug/MCOverlay.plugin/Contents/MacOS/MCOverlay > (for architecture i386): Mach-O bundle i386 > /Users/rmann/LZRepo/SatTrack/MCOverlay/trunk/MCOverlay/build/Debug/MCOverlay.plugin/Contents/MacOS/MCOverlay > (for architecture ppc7400): Mach-O bundle ppc > > > Hmm...I think I know what it might be. > > The output in question is defined as a "uint32_t". Works fine in 32-bit, but > maybe something's choking on that in 64-bit? > > Nope. I changed it to NSNumber*, same problem. > > I threw the Xcode build folder away, too. No idea what's going on. > > > On Apr 26, 2010, at 23:21:19, Rick Mann wrote: > >> >> On Apr 26, 2010, at 22:51:41, George Toledo wrote: >> >>> The "_1" should just refer to the instance of the plugin in your >>> composition (if there were multiple, you would see _2, _3 and so on, if >>> there were connections that weren't restoring to them...). >> >> That makes sense. I thought perhaps it was how it named it when it found two >> plugins of the same name. >> >>> There's something weird, in that, it sounds like you had the output working >>> and connected in a previous build, and a new build doesn't have the output >>> going correctly? How did you get an output to input connection going to >>> begin with, in the qtz you're trying to re-open, if it's only the newer >>> build that you haven't been able to load yet, that actually has an output? >>> >>> I may have missed something in the rundown of the scenario... >> >> In the course of developing the plugin to this point, I added a new output. >> I ran under the debugger which launched QC, which auto-opened the .qtz I had >> open before. In there, I saw my new output in the already-instantiated >> plugin. I connected that up to some other stuff, and everything was great. >> >> When I then quit QC, and relaunch QC directly from the Dock (rather than >> Debugging in Xcode), it auto-opens the same .qtz, but complains. When I >> continue past the complaint, I see my plugin instance there, but that newest >> output (the one it complained about) is missing. >> >> This is what makes me think it's still re-loading an old plugin. >> >> I even used lsof to see what files it has open; it only has the current >> build of my plugin open. >> >> If I create a new composition and instantiate my plugin, it is the old one >> (the one without the new output). >> >> There are no dynamic ports. >> >> I just used find to search the entire disk. It only found the one in >> ~/Library, and the two in Xcode's build dir (Debug and Release). >> >> Okay, I just figured it out. Well, partly. Under the debugger, it's >> launching 32-bit. From the dock, it launches 64-bit. My build is set to make >> a universal build, and if I run "file <my plugin executable>", it shows up >> as having all three architectures. Clearly, though, it's not actually >> building all three. >> >> I cleaned my project more than once, too. >> >>> >>> So, you've eradicated the plugin, at some point, definitely? >>> >>> You open some old qtz, and it doesn't restore? (The old plugin version that >>> you're attempting to erase?) >>> >>> At any point, have you tried seeing if it's in the patch list, instead of >>> having the opening of the old qtz be a litmus? Does it have the output >>> you've added? >>> >>> BTW, that kind of message doesn't get recorded in Console (probably at >>> all), but holding Option down while you select QC preferences should lead >>> you to the GFLogErrors, GFLogWarnings, and GFLogWindow options under >>> (System). That will lead you to a nifty cut and paste-able window that will >>> usually have whatever info pops up in exception window (and more). >>> >>> -George >>> >>>> >>>> Best, >>>> George Toledo >>>> >>>> On Tue, Apr 27, 2010 at 12:12 AM, Rick Mann <[email protected]> wrote: >>>> >>>> On Apr 26, 2010, at 20:44:37, vade wrote: >>>> >>>>> Are you making sure your plugin is compiling in both 32 and 64 bit? I've >>>>> seen XCode launch QC with a different architecture than what is selected >>>>> in the XCode get pulldown, vs what is selected in the get info pane on >>>>> QCs app. >>>>> >>>>> Also, are you using any frameworks in your QCPlugin that use @rpath >>>>> linker? I've also seen instances where XCode will load libraries that may >>>>> not load when you launch the app, do you get any other errors in the log >>>>> window, or in Console.app (Applications/Utilities/Console.app). >>>> >>>> Good suggestions, but I don't think that's it. Both Debug and Release >>>> configs are 64/32-bit universal, and in any case, I'm running the Debug >>>> build for both. >>>> >>>> I don't have any private frameworks. >>>> >>>>> >>>>> >>>>> >>>>> On Apr 26, 2010, at 11:26 PM, Rick Mann wrote: >>>>> >>>>>> I'm trying to verify that my QC custom patch runs correctly when >>>>>> launching QC directly, rather than as a result of "Debug" from within my >>>>>> patch's Xcode project. When I Debug, everything is fine. When I simply >>>>>> launch QC, it complains about not being able to restore the document, >>>>>> and you can see that the output I just added to my plugin isn't there, >>>>>> implying that an older version of the plugin is being fetched. >>>>>> >>>>>> But I've deleted every copy of my plugin that I can find, and it's still >>>>>> not working. I can see that the plugin in ~/Library/Graphics/Quartz >>>>>> Composer Plug-Ins gets replaced when I build, but I don't see any way to >>>>>> verify which plugin QC thinks it's using. >>>>>> >>>>>> Any suggestions? >>>>>> >>>>>> TIA, >>>>>> Rick >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Quartzcomposer-dev mailing list ([email protected]) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com >>>>>> >>>>>> This email sent to [email protected] >>>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Quartzcomposer-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com >>>> >>>> This email sent to [email protected] >>>> >>> >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Quartzcomposer-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/quartzcomposer-dev/rmann%40latencyzero.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/rmann%40latencyzero.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
