Re: OmniObjectMeter and PB/gdb
Re: OmniObjectMeter and PB/gdb
- Subject: Re: OmniObjectMeter and PB/gdb
- From: "Timothy J. Wood" <email@hidden>
- Date: Wed, 7 Aug 2002 09:28:40 -0700
On Wednesday, August 7, 2002, at 01:20 AM, Paul Williamson wrote:
Second, I didn't realize that OOM can't run, not even its UI, when the
target program isn't running.
Yes, this is a design issue in the current OOM. The main app polls
the target every two seconds by default. Additionally, various other
requests go across the MiG IPC channel to the target as you click around
looking at stuff.
It would be nice to have OOM usable while your program is stopped for
some reason. The big problem is that OOM stores as little information
as possible (since there can be a ton of it). Thus, if you manipulate
the view (say, select a different object), then OOM may need to talk to
the target process in order to resolve that operation.
Maybe in the future I could build a shared memory segment with locking
so that both processes would have equal access to the information in
question (via a lock residing in kernel space or shmem space). This
would take quite a bit of work, though :)
This makes OOM+gdb a much less appealing combination that I had hoped.
I wanted to paw around in the OOM displays while my program sat at a
breakpoint, so I could carefully step through the consequences of each
part of the program.
As a terrible hack, you could do:
(gdb) p sleep(3600)
assuming your program is single-threaded. This would allow the
background OOM service thread to run. You could then hit ctrl-c to
break out of this and should be able to continue stepping through your
program.
Yes, yuck, but hopefully it will work.
First, there's an error in the help file. It says to include
<OmniObjectMeterFramework/OOMPublic>, but that doesn't exist. It's
actually <OmniObjectMeterFramework/OOMPublic.h>.
Oops.
Third, the alias doesn't work. The build fails, complaining that it
can't open the framework. Getting rid of the alias and creating an
actual link (from Terminal with "ln -s") allows the program to find the
framework and run. (Disclaimer: maybe I'm confused about the alias and
the link, too. I'm a refugee from embedded systems and this is the
first Mac OS alias I've ever created.)
Actually, you wanted a symlink -- I sure thought I tested these exact
instructions. Did they switch from creating symlinks to aliases for
cmd-option-drag at some point and I just didn't notice? Or, maybe I'm
just silly.
At any rate, the longer term goal was to have OOM check whether this
link was already set up when it launches (and points to the framework
inside itself). It could then ask you if you want to set it up (or
maybe I'd add a preference panel setting to 'Enable direct linking' that
would establish the link). I didn't think about adding this until too
close to the release, but having OOM manage this would be much simpler
for the user.
-tim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.