Re: Process table information

2002-12-04 Thread Chris Devers
On Wed, 4 Dec 2002, Ken Williams wrote:

 Maybe the 'gcc_select 2' command would be a relatively easy way to
 test/debug it?  I hadn't known about that command until Paul pointed it
 out.

FYI, last I checked, all that command did was update a symlink so that
(from memory, not on a Mac right now) /usr/bin/gcc was a symlink to one
or the other of /usr/bin/gcc2 or /usr/bin/gcc3. Given that both binaries
should be available regardless of where the symlink is pointing, maybe
any tests could work directly with the files rather than the link.



-- 
Chris Devers[EMAIL PROTECTED]



Re: Process table information

2002-12-03 Thread Kris Wolff
On 03.12.2002 9:09 Uhr, Ken Williams [EMAIL PROTECTED] wrote:

 Hey,
 
 I was thinking about working on Proc::ProcessTable to get support for OS
 X.  But after a little effort, it occurred to me that I have no clue how
 to access process table information.  Anyone know this kind of thing, or
 could tell me what docs to look at?
 
 Thanks.
 
 -Ken
 

Hm, maybe its not a good idea but a start to parse ps -ax ??




Re: Process table information

2002-12-03 Thread Chris Nandor
In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] (Ken Williams) wrote:

 I was thinking about working on Proc::ProcessTable to get support for OS 
 X.  But after a little effort, it occurred to me that I have no clue how 
 to access process table information.  Anyone know this kind of thing, or 
 could tell me what docs to look at?

Mac::Processes can give you much of the information you could want.  It 
provides a PSN instead of a PID, but I could add GetProcessPID() and 
GetProcessForPID() to Mac::Processes, which maps between the two.  Take a 
look at the module and see if there's anything else there you need that it 
doesn't provide.  :-)  Let me know, or file a report on SourceForge.net.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/



Re: Process table information

2002-12-03 Thread Chris Nandor
In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] (Chris Nandor) wrote:

 Mac::Processes can give you much of the information you could want.  It 
 provides a PSN instead of a PID, but I could add GetProcessPID() and 
 GetProcessForPID() to Mac::Processes, which maps between the two.  Take a 
 look at the module and see if there's anything else there you need that it 
 doesn't provide.  :-)  Let me know, or file a report on SourceForge.net.

I don't know how much use Mac::Processes will be to you for this, but I went 
ahead and added the two functions for the next release.  I know I've wanted 
the functionality before.

  $ perl -MMac::Processes -e '$psn = GetCurrentProcess(); printf %d == %d, 
  %08X == %08X\n, GetProcessPID($psn), $$, $psn, GetProcessForPID($$)'

  1862 == 1862, 015A0001 == 015A0001

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/



Re: Process table information

2002-12-03 Thread Jerry LeVan
Well, If we were running linux we could look in /proc.
 
Possible solutions:

   1) Get the source for darwin and study the code for the ps command.

   2) Study the header files to find the format for the proc table, examine
the kernel symbol table to get the start address of the proc table. Write
code that fetches the table from /dev/kmem and parses it. ( I have done this
with some other unix systems...). proc.h might be a good starting point.

Regrettably sysctl does not give access to table info in the kernel.

--Jerry

 Hey,
 
 I was thinking about working on Proc::ProcessTable to get support for OS
 
 X.  But after a little effort, it occurred to me that I have no clue how
 
 to access process table information.  Anyone know this kind of thing, or
 
 could tell me what docs to look at?
 
 Thanks.
 
 -Ken
 




Re: Process table information

2002-12-03 Thread Chris Nandor
In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] (Jerry Levan) wrote:

 Regrettably sysctl does not give access to table info in the kernel.

Source code and commentary:

   http://developer.apple.com/qa/qa2001/qa1123.html

You can get a list of all BSD processes, which includes daemon processes, 
using the BSD sysctl  routine. Code for doing this is shown in Listing 1. 
When using this code you should note the following.

* The returned kinfo_proc structures contain a huge amount of 
information about the process, including the process ID (in kp_proc.p_pid) 
and the process name (in kp_proc.p_comm).
* As far as BSD is concerned all Classic applications run within a 
single process.
* You do not need any special privileges to make this sysctl; any user 
can get a list of all processes on the system.
* The UNIX Programming FAQ lists a number of alternative ways to do 
this. Of these, the only approach that works on Mac OS X is exec'ing the ps 
command line tool. exec'ing ps will require parsing the tool's output and 
will not use system resources as efficiently as Listing 1.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/



Re: Process table information

2002-12-03 Thread Ken Williams

On Wednesday, December 4, 2002, at 05:04  AM, Chris Nandor wrote:


In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] (Ken Williams) wrote:


I was thinking about working on Proc::ProcessTable to get 
support for OS
X.  But after a little effort, it occurred to me that I have 
no clue how
to access process table information.  Anyone know this kind of 
thing, or
could tell me what docs to look at?

Mac::Processes can give you much of the information you could want.


Yeah, that looks like exactly what I want.  Now if I can just 
get Mac::Carbon working under 10.1.5! =)  Still haven't had any 
luck with that, it looks like a gcc 2/3 issue to me.

 -Ken



Re: Process table information

2002-12-03 Thread Paul McCann
Chris Nandor wrote:
  [EMAIL PROTECTED] (Ken Williams) wrote:
 
  Yeah, that looks like exactly what I want.  Now if I can just 
  get Mac::Carbon working under 10.1.5! =)  Still haven't had any 
  luck with that, it looks like a gcc 2/3 issue to me.
 
 Yeah, I dunno.  :/  I've not had any opportunity to even test it.  What I 
 could try to do is release binaries next time, putting them on 
 SourceForge.net (I won't bother putting them on the CPAN).  I think those 
 should work on 10.1.5.  Let me know if you want me to try (I am aiming for a 
 0.02 release of Mac::Carbon in the next 2 weeks).

For what it's worth, I had to sudo gcc_select 3 to get Mac::Carbon to
compile under 10.2.2. Having changed gcc to 2 in order to get
curses.pm to work properly I was head-scratching for a couple of minutes
when Mac::Carbon wouldn't compile; then I noticed the 2.95.2 in the
output. So I think Ken's on the money here. 

I guess I could be a *little* more precise here... here's how the dummy
is spat when using gcc 2.95.2 

Cheers,
Paul
---
~/src/Mac-Carbon-0.01 % sudo gcc_select 2
Current default compiler is now gcc2.

~/src/Mac-Carbon-0.01 % perl Makefile.pl
Writing Makefile for Mac::Components
Writing Makefile for Mac::Files
Writing Makefile for Mac::Gestalt
Writing Makefile for MacPerl
Writing Makefile for Mac::Memory
Writing Makefile for Mac::MoreFiles
Writing Makefile for Mac::Notification
Writing Makefile for Mac::Processes
Writing Makefile for Mac::Resources
Writing Makefile for Mac::Sound
Writing Makefile for Mac::Speech
Writing Makefile for Mac::Types
Writing Makefile for Mac::Carbon
~/src/Mac-Carbon-0.01 % make
cc -c -I/Developer/Headers/FlatCarbon/ -g -pipe -pipe -fno-common
-no-cpp-precomp -flat_namespace -DHAS_TELLDIR_PROTOTYPE
-fno-strict-aliasing -Os -DVERSION=\1.01\ -DXS_VERSION=\1.01\
-I/System/Library/Perl/darwin/CORE  Components.c
In file included from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:13,
 from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:5,
 from
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,
 from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,
 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from /Developer/Headers/FlatCarbon/Events.h:1,
 from ../Carbon.h:23,
 from Components.xs:32:
/usr/include/gcc/darwin/2.95.2/g++/../stdbool.h:10: warning: empty
declaration
In file included from Components.xs:32:
.../Carbon.h: In function `GUSIPath2FSp':
.../Carbon.h:168: parse error before `path'
.../Carbon.h:169: `path' undeclared (first use in this function)
.../Carbon.h:169: (Each undeclared identifier is reported only once
.../Carbon.h:169: for each function it appears in.)
make[1]: *** [Components.o] Error 1
make: *** [subdirs] Error 2



Re: Process table information

2002-12-03 Thread Ken Williams

On Wednesday, December 4, 2002, at 11:41  AM, Chris Nandor wrote:


In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] (Ken Williams) wrote:


Yeah, that looks like exactly what I want.  Now if I can just
get Mac::Carbon working under 10.1.5! =)  Still haven't had any
luck with that, it looks like a gcc 2/3 issue to me.


Yeah, I dunno.  :/  I've not had any opportunity to even test it.  
What I
could try to do is release binaries next time, putting them on
SourceForge.net (I won't bother putting them on the CPAN).  I think 
those
should work on 10.1.5.  Let me know if you want me to try (I am aiming 
for a
0.02 release of Mac::Carbon in the next 2 weeks).

Maybe the 'gcc_select 2' command would be a relatively easy way to 
test/debug it?  I hadn't known about that command until Paul pointed it 
out.

Failing that, a binary would be good if it worked.

 -Ken