Re: Talking to the Dock (Nooo - stop it!)
Re: Talking to the Dock (Nooo - stop it!)
- Subject: Re: Talking to the Dock (Nooo - stop it!)
- From: Tobias Klüpfel <email@hidden>
- Date: Tue, 29 Jul 2003 18:22:00 +0200
Hold on guys,
That's not what I meant. Uli's answer of 'Cocoa doesn't have it' is
absolutely sufficient. I personally use the Carbon way of just calling
GetNextProcess() until I have the one I want.
I'm beginning to suspect that maybe that doesn't get me *all* processes
running, but I am getting the one that I want (the Dock)
I'm much more interested in the answer to my second question (If, in
fact, there is one).
But, I don't mean to be rude and interrupt your discussion, so if you
do want to ccontinue it, please do. Just be advised that *my* curiosity
has been satisfied in that field.
Cheers,
Toby
On Dienstag, 29. Juli 2003, at 17:12PM, Sailor Quasar wrote:
On Tuesday, July 29, 2003, at 10:46 AM, M. Uli Kusterer wrote:
I'm reasonably sure there's no Cocoa wrapper around it, but it would
probably be simpler to use NSTask to shell out to the 'ps' command.
sysctl() is a complicated set of multi-level options and data
structures, but the output of ps can be parsed easily since it's
possible to request specific information from ps and the output can
be distilled further using pipes into awk and grep. The only reason
to use sysctl() directly would be if speed is critical to the code
in question.
Maybe I spend too much time implementing parsers and have thus grown
allergic to them, but I generally find it much more convenient (and
reliable) to call "real" APIs than to call through to a command-line
tool.
To a point, yes. It's certainly much easier to call gethostbyname()
than to shell out to 'dig' and parse it's output. On the other hand,
sysctl() in terms of the process list is a rather involved operation,
including authorizing yourself as root if you want the full process
list instead of only the things the current user started. 'ps' is
already known to be safe and is setuid root.
Not to mention that I'm of the faction that says that speed is always
critical in application software, at least where it doesn't make the
code unreadable. I wouldn't switch to inline-assembly if it's not
really necessary, but otherwise I see no point in needlessly hogging
the user's CPU needlessly. I have enough applications that hog the
CPU excessively and without which I can't do. So chances are that if
your app needs more CPU than is warranted by its function, I'll throw
it away.
I don't think there's been a computer since the beige G3's that would
take perceptibly longer to ps|awk|grep than to AuthServices|sysctl().
A macroscopic difference at the CPU level can be quite microscopic in
realtime.
But yes, if you don't care about subtle changes in the output of
"top" or "ps" screwing up your parsing, and you enjoy writing parsers
that take apart information that can be received already dissected
from a system API, and you don't care about it taking a little
longer, NSTask is a solution as well.
"Subtle changes" in the output of those commands would break a great
many more things than someone's use of NSTask. The output and options
of the BSD 'ps' command are well-known and long-standing. There have
been extensions, but never any that changed the basic structure of the
output. (Disclaimer: this is in my own knowledge only; someone more
versed in UNIX history may feel free to correct me :).
But if you want to see an example of a parser that isn't good enough,
check out the way PB doesn't report missing symbols. It simply says
"build failed" and leaves you to look in the raw gcc output what
actually went wrong...
That's Apple's sloppiness. I personally barely notice, since as a UNIX
junkie I'm always sifting through the raw build output anyway. I
recognize of course that some would be very put off by having to do
this (this is a shout-out to you, Larry! :). However, a little simple
care would easily prevent such a gross negligence.
On this same subject, I'm convinced Apple has no excuse for the bug
you mentioned. They've obviously learned how to pipe gcc's output into
PB, and the output of the ld subprocess is clearly defined and simple
to parse. At worst, they already added a great many extensions to gcc
for use of various mapfiles and such, if they were feeling really
silly they could have added another one to output an undefined symbol
list. Of course, on the flip side, I'm sure we'll all agree that PB is
not a finished product :).
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
-- Sailor Quasar, guardian of Leraz's memory
"A face of stone may hide a soul with the deepest Love of all"
Email: email@hidden
_______________________________________________
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.
_______________________________________________
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.