Getting the PID in CLISP
Marc Mertens
I run CLISP in unix,linux or solaris and wants to get the process id of
the running lisp process. Can someone tell me how I can do this.
Thanks a lot in advance.
Marc Mertens
Chris Beggy
> I run CLISP in unix,linux or solaris and wants to get the process id of
> the running lisp process. Can someone tell me how I can do this.
In clisp under linux, try:
(run-program "/sbin/pidof" :arguments '( "lisp.run") :output "lisp.pid")
The argument of pidof will depend on how clisp is invoked on your system.
For cmucl, it is:
(run-program "/sbin/pidof" '( "lisp") :output "lisp.pid")
HTH,
Chris
Barry Margolin
Chris Beggy <chr...@kippona.com> wrote:
>Marc Mertens <mmer...@vt4.net> writes:
>
>> I run CLISP in unix,linux or solaris and wants to get the process id of
>> the running lisp process. Can someone tell me how I can do this.
>
>In clisp under linux, try:
>
> (run-program "/sbin/pidof" :arguments '( "lisp.run") :output "lisp.pid")
This assumes there's only one Lisp running on the system at a time.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Tim Bradshaw
> (run-program "/sbin/pidof" :arguments '( "lisp.run") :output
> "lisp.pid")
This can't work - in particular it can't work if there is more than
one image running. You need, somehow, to ask the process itself what
its PID is. A horrible hack would be to spawn a bash and ask it for
the value of $PPID, which will be its parent, and therefore, you.
Better would be to compile some foreign call to getpid...
--tim
Chris Beggy
> In article <874rbet...@lackawana.kippona.com>,
> Chris Beggy <chr...@kippona.com> wrote:
>>Marc Mertens <mmer...@vt4.net> writes:
>>
>>> I run CLISP in unix,linux or solaris and wants to get the process id of
>>> the running lisp process. Can someone tell me how I can do this.
>>
>>In clisp under linux, try:
>>
>> (run-program "/sbin/pidof" :arguments '( "lisp.run") :output "lisp.pid")
>
> This assumes there's only one Lisp running on the system at a time.
I know it's not perfect, but is this any better:
(run-program "/sbin/pidof" :arguments '( "<programname>") :output "lisp.pid")
Chris
Erik Naggum
| I run CLISP in unix,linux or solaris and wants to get the process id of
| the running lisp process. Can someone tell me how I can do this.
Have you tried (apropos "pid")?
(Curiously, the only Common Lisp implementation I have here that does
/not/ accept the above is Allegro CL in their "ansi mode", in which they
force you to write (apropos "pid" nil nil t) if you want case-insensitive
matches -- there is no way to make the last argument default to true!
No wonder case-sensitivity hurts more than it should.)
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum
| Better would be to compile some foreign call to getpid...
I have never seen a Common Lisp under Unix that did /not/ have a getpid
function already available under that name ± some adornments.
Chris Beggy
> * Marc Mertens
> | I run CLISP in unix,linux or solaris and wants to get the process id of
> | the running lisp process. Can someone tell me how I can do this.
>
> Have you tried (apropos "pid")?
in ilisp, C-c i on pid gives:
PID is the symbol PID, lies in #<PACKAGE COMMON-LISP-USER>, is accessible in the package COMMON-LISP-USER.
#<PACKAGE COMMON-LISP-USER> is the package named COMMON-LISP-USER. It has the nicknames CL-USER, USER.
It imports the external symbols of the packages COMMON-LISP, EXT
and exports no symbols, but no package uses these exports.
Chris
Erik Naggum
| Have you tried (apropos "pid")?
* Chris Beggy
| in ilisp, C-c i on pid gives:
HAVE YOU TRIED (APROPOS "PID")?
Donald Fisk
>
> * Marc Mertens
> | I run CLISP in unix,linux or solaris and wants to get the process id of
> | the running lisp process. Can someone tell me how I can do this.
>
> Have you tried (apropos "pid")?
Command: clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999
[1]> (apropos "pid")
[nothing output]
Yes, and it did not find anything on my version of CLisp.
Does it work on the most recent version?
Tim's "horrible hack" works fine:
[10]> (let ((p (make-pipe-input-stream "echo $PPID"))) (prog1 (read p)
(close p)))
31345
[11]>
can be wrapped up into a function, and is preferable to
grepping ps and keeping your fingers crossed it doesn't
pick up someone else's CLisp process.
> Erik Naggum, Oslo, Norway
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Marcus Breiing
> HAVE YOU TRIED (APROPOS "PID")?
(SYSTEM::PROGRAM-ID) seems to do the trick. Does CLISP have a
non-Unix heritage to account for that name?
--
Marcus Breiing
mailto:news-g...@breiing.com (will expire)
Erik Naggum
| Yes, and it did not find anything on my version of CLisp.
| Does it work on the most recent version?
Well, I am just shocked. (APROPOS "PID") has produced useful functions
on all the Common Lisp environments I have used under all the Unices I
have used Common Lisp on, including all versions of CLISP. (I am in the
process of becoming Certified Microsoft-Free, so if I admit to knowing
anything about what happens in The Other Realm, my certification may be
in jeopardy.)
Chris Beggy
> * Erik Naggum
> | Have you tried (apropos "pid")?
>
> * Chris Beggy
> | in ilisp, C-c i on pid gives:
>
> HAVE YOU TRIED (APROPOS "PID")?
I should have passed on the results rather than obscurly jumping
ahead to other results.
In my case:
clisp prompt> (apropos "pid")
returns nothing
My clisp version is:
bash prompt%% clisp --version
GNU CLISP 2.28 (released 2002-03-03) (built 3228004349) (memory 3228005268)
Features:
(CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT
UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
And the platform is gnu/linux on x86 with clisp linked to the
following libraries:
bash prompt%% ldd /usr/bin/clisp
libc.so.6 => /lib/libc.so.6 (0x40019000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Chris
Vassil Nikolov
[...]
EN> write (apropos "pid" nil nil t) if you want case-insensitive
EN> matches -- there is no way to make the last argument default to true!
Or maybe the last argument should have been CASE-SENSITIVE-P,
still defaulting to NIL...
(I'm saying this because I prefer default values of NIL, unless
there is a good reason to pick up a non-NIL default value.)
---Vassil.
--
Non-googlable is googlable.
Carl Shapiro
> (Curiously, the only Common Lisp implementation I have here that does
> /not/ accept the above is Allegro CL in their "ansi mode", in which they
> force you to write (apropos "pid" nil nil t) if you want case-insensitive
> matches -- there is no way to make the last argument default to true!
> No wonder case-sensitivity hurts more than it should.)
Well, Lucid also chose the wrong default for APROPOS and APROPOS-LIST.
It is trivial for a user of LCL to patch these functions to call the
underlying LCL:APROPOS-DRIVER subroutine (where the real action
happens) selecting the correct behavior, but these functions really
ought to have had the more intuitive behavior out-of-the-box.
Lucid also dropped the ball by not having LCL startup in an ANSI
compatible mode by default. To this day, one has to load an optional
submodule in Xanalys Liquid Common Lisp to create the COMMON-LISP and
COMMON-LISP-USER packages with ANSI symbols.
Donald Fisk
>
> * Donald Fisk
> | Yes, and it did not find anything on my version of CLisp.
> | Does it work on the most recent version?
>
> Well, I am just shocked. (APROPOS "PID") has produced useful functions
> on all the Common Lisp environments I have used under all the Unices I
> have used Common Lisp on, including all versions of CLISP. (I am in the
> process of becoming Certified Microsoft-Free, so if I admit to knowing
> anything about what happens in The Other Realm, my certification may be
> in jeopardy.)
I use:
Command: clisp --version
CLISP 1999-07-22 (July 1999)
Running on SuSE Linux.
Erik Naggum
| I use:
|
| Command: clisp --version
| CLISP 1999-07-22 (July 1999)
The crucial element appears to be whether you compile with exported
syscalls or not. I have just tried to build 2.27, 2.28, 2.29, and 2.30
from the distributed tarballs, but all of them bomb during building, so I
gave up on recovering the configuration options necessary to get `getpid´
in, e.g., the LINUX package. My heartfelt thanks go out to the people
who take time out of their lives to build CLISP into Debian packages.
Erik Naggum
| I should have passed on the results rather than obscurly jumping
| ahead to other results.
That would have helped.
| In my case:
|
| clisp prompt> (apropos "pid")
|
| returns nothing
Absolutely fascinating.
| My clisp version is:
|
| bash prompt%% clisp --version
|
| GNU CLISP 2.28 (released 2002-03-03) (built 3228004349) (memory 3228005268)
| Features:
(CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS
GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE
BASE-CHAR=CHARACTER PC386 UNIX)
Mine does
GNU CLISP 2.30 (released 2002-09-15) (built 3241717887) (memory 3244300085)
Features:
(ASDF MK-DEFSYSTEM COMMON-LISP-CONTROLLER CLX-MIT-R5 CLX-MIT-R4 XLIB CLX
CLX-LITTLE-ENDIAN HAVE-WITH-STANDARD-IO-SYNTAX HAVE-CLCS HAVE-DECLAIM
HAVE-PRINT-UNREADABLE-OBJECT CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP
LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
UNICODE BASE-CHAR=CHARACTER SYSCALLS PC386 UNIX)
Using `set-differenceด on these values, yours-mine yields (gettext) while
mine-yours yields (asdf mk-defsystem common-lisp-controller clx-mit-r5
clx-mit-r4 xlib clx clx-little-endian have-with-standard-io-syntax
have-clcs have-declaim have-print-unreadable-object syscalls)
The crucial difference is `syscallsด. It appears to be a build option.
Marc Mertens
I was actually using the following :
(defun get-process-id ()
(read (ext:run-shell-command "echo $PPID" :output :stream)))
and this works in Linux but fails in Solaris the result of
(ext:run-shell-command "echo $PPID") is
[4]> (ext:run-shell-command "echo $PPID")
0
on Solaris.
I have tried (apropos 'pid) and its variants but my CLISP does not seems
to support it (searching the CLISP documentation on pid or process did
not revail anything usefull either).
Marc
Erik Naggum
| I have tried (apropos 'pid) and its variants but my CLISP does not seems
| to support it (searching the CLISP documentation on pid or process did
| not revail anything usefull either).
If you can get CLISP to compile, build it with --with-exported-syscalls.
(Note that building from the last four available tarballs all bomb on a
stock Debian 3.0 system, so it may not be your fault if you cannot build.)
Alan S. Crowe
> * Tim Bradshaw
> | Better would be to compile some foreign call to getpid...
>
> I have never seen a Common Lisp under Unix that did /not/ have a getpid
> function already available under that name ± some adornments.
>
It is important for beginners to realise that Erik has given
away the store here. It goes like this:
shell-prompt$ lisp
CMU Common Lisp 18d,...
* (apropos "getpid")
UNIX:UNIX-GETPID (defined)
* (unix:unix-getpid)
29312
And in another window:
shell-prompt$ ps | grep lisp
29312 p5 S+ 0:00.50 lisp
29367 p6 R+ 0:00.00 grep lisp (bash)
Meanwhile, back in CMUCL
* (describe 'unix:unix-getpid)
UNIX-GETPID is an external symbol in the UNIX package.
Function: #<Function UNIX:UNIX-GETPID {1029C9E9}>
Function arguments:
There are no arguments.
Function documentation:
Unix-getpid returns the process-id of the current process.
Its defined argument types are:
NIL
Its result type is:
(SIGNED-BYTE 32)
On Wednesday, 4/10/02 01:25:46 pm [+1] it was compiled from:
target:code/unix.lisp
Created: Saturday, 3/23/02 06:50:14 pm GMT
Comment: $Header: /home/CVS-cmucl/src/code/unix.lisp,v 1.48.2.8 2002/03/23 18:50:14 pw Exp $
With apropos and describe, one can go hunting for cool
functions in one's lisp image all on one's own :)
Alan Crowe
Barry Margolin
Marc Mertens <mmer...@vt4.net> wrote:
>I was actually using the following :
>
>(defun get-process-id ()
> (read (ext:run-shell-command "echo $PPID" :output :stream)))
>
>
>and this works in Linux but fails in Solaris the result of
>
>(ext:run-shell-command "echo $PPID") is
>
>[4]> (ext:run-shell-command "echo $PPID")
>
>0
>
>on Solaris.
On Linux, /bin/sh is really bash, which has the built-in $PPID variable.
On Solaris, /bin/sh is Bourne shell, which doesn't.
Tim Bradshaw
> and this works in Linux but fails in Solaris the result of
> (ext:run-shell-command "echo $PPID") is
> [4]> (ext:run-shell-command "echo $PPID")
> 0
> on Solaris.
Yes, this is because Solaris's default shell is actually a Bourne
Shell, not bash dressed up (or something), and PPID is something that
bash invented (or maybe some other sh derivative that got inherited by
bash...).
In any case this is a *really* bad way of getting the pid of a
process...
--tim
Johannes Grødem
> (Note that building from the last four available tarballs all bomb on a
> stock Debian 3.0 system, so it may not be your fault if you cannot build.)
That's odd. Both 2.30 and the CVS-version builds just fine for me on
Debian 3.0. Maybe "apt-get build-dep clisp" will fix it for you.
--
Johannes Grødem <OpenPGP: 5055654C>
Raymond Toy
Marc> and this works in Linux but fails in Solaris the result of
Marc> (ext:run-shell-command "echo $PPID") is
Marc> [4]> (ext:run-shell-command "echo $PPID")
Marc> 0
Marc> on Solaris.
Perhaps a bashism? PPID is defined for me when my shell is bash.
When I use /bin/sh, PPID doesn't exist.
Ray
Will Deakin
> (or maybe some other sh derivative that got inherited by
> bash...).
> In any case this is a *really* bad way of getting the pid of a
> process...
There must be worse, it's just I can't think of any at the moments...
;)w
Erik Naggum
| That's odd. Both 2.30 and the CVS-version builds just fine for me on
| Debian 3.0.
This had to happen. As instructed, I did the following:
tar --gzip --extract --file=/home/gnu/clisp/release/clisp-2.30.tar.gz
CC="gcc-3.2 -ansi" configure --quiet --build gcc-3.2-sans-syscalls
At the end of a really logorrheic display we find some real meat:
gcc-3.2 -ansi -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -c spvw.c
In file included from unix.d:163,
from lispbibl.d:1754,
from spvw.d:22:
/usr/include/sys/ipc.h:25:3: warning: #warning "Files using this header must be compiled with _SVID_SOURCE or _XOP
EN_SOURCE"
In file included from lispbibl.d:1754,
from spvw.d:22:
unix.d:244: warning: type defaults to `int' in declaration of `sigset_t'
unix.d:244: parse error before '*' token
unix.d:246: parse error before '*' token
unix.d:249: parse error before '*' token
In file included from lispbibl.d:1754,
from spvw.d:22:
unix.d:651: parse error before "caddr_t"
In file included from spvw.d:22:
lispbibl.d:7183: warning: register used for two global register variables
In file included from spvw.d:521:
spvw_sigsegv.d: In function `stackoverflow_handler':
spvw_sigsegv.d:75: dereferencing pointer to incomplete type
In file included from spvw.d:524:
spvw_sigint.d: In function `react_on_sigint':
spvw_sigint.d:61: `SIG_UNBLOCK' undeclared (first use in this function)
spvw_sigint.d:61: (Each undeclared identifier is reported only once
spvw_sigint.d:61: for each function it appears in.)
In file included from spvw.d:525:
spvw_sigwinch.d: In function `update_linelength':
spvw_sigwinch.d:35: `caddr_t' undeclared (first use in this function)
In file included from spvw.d:530:
spvw_garcol.d: In function `gar_col_normal':
spvw_garcol.d:1595: `SIG_BLOCK' undeclared (first use in this function)
spvw_garcol.d:2097: `SIG_UNBLOCK' undeclared (first use in this function)
In file included from spvw.d:530:
spvw_garcol.d: In function `gar_col_compact':
spvw_garcol.d:2359: `SIG_BLOCK' undeclared (first use in this function)
spvw_garcol.d:2437: `SIG_UNBLOCK' undeclared (first use in this function)
make: *** [spvw.o] Error 1
Please note that I have /zero/ interest in figuring out what went wrong.
If you have any interest in making it work, let me know, and I can send
you the entire output and all constructed files. I maintain that if you
release something as open source, making use of existing facilities to
configure, build, and install it is the baseline for comparisons.
| Maybe "apt-get build-dep clisp" will fix it for you.
I am not interested in help on building it. Christ, I thanked the people
who took time out of their lives to build Debian packages. What I wanted
to do was to build the packages from scratch so I had some control over
the build parameters. You may have noticed that the CLISPs I have used
have included a getpid function and others have not been so fortunate.
So building the packages like the Debian maintainer does would obviously
not help me understand what others would /not/ get.
However, each of 2.27, 2.28, 2.29, and 2.30 bombed in various ways when
the tarball was unrolled and the configure script was run in prescribed
ways. When all four releases refused to build out of the box, my SIGWTF
had maintained a steady high throughout and the only way to get rid of it
was to scrap the "build from scratch to see what happened" project.
Others have reported to me by mail that they had given up on CLISP for
similar reasons and were relieved that it was not their fault they could
not make it work. This should be taken seriously by the CLISP gang.
Johannes Grødem
> I am not interested in help on building it. [...]
Yes, I understand, but I replied anyway in case someone else needed a
hint.
(FWIW, I used gcc 2.95.4. Maybe there is an issue with gcc 3.2 and
CLISP.)
Barry Margolin
I think the earlier suggestion to run something like "/sbin/pidof lisp" was
worse, I think. This command doesn't even exist on my Solaris 2.6 system.
Johannes Grødem
> I am not interested in help on building it. [...]
Yes, I understand, but I replied anyway in case someone else needed a
hint.
I investigated a bit, by the way, and it seems the -ansi-option to gcc
is what makes the build break.
Erik Naggum
| I investigated a bit, by the way, and it seems the -ansi-option to gcc
| is what makes the build break.
That is specifically suggested in the instructions you get when you ask
configure for help.
Tim Bradshaw
> I think the earlier suggestion to run something like "/sbin/pidof lisp" was
> worse, I think. This command doesn't even exist on my Solaris 2.6 system.
pgrep does pretty much the same thing as far as I can see, though it
doesn't have the `convenient' `return only a single PID (even if it's
not the right one) option'.
--tim
Ingvar Mattsson
I think it's a ksh-ism, really. So, possibly cooking up something
using exec, /usr/bin/ksh and stuff would... Much easier having access
to getpid(2).
//Ingvar
--
A routing decision is made at every routing point, making local hacks
hard to permeate the network with.
Sam Steingold
> * On the subject of "Getting the PID in CLISP"
> * Sent on Tue, 22 Oct 2002 20:27:16 +0000
> * Honorable Marc Mertens <mmer...@vt4.net> writes:
>
> I run CLISP in unix,linux or solaris and wants to get the process id
> of the running lisp process. Can someone tell me how I can do this.
On a UNIX system, CLISP has SYS::PROGRAM-ID for that.
What do you need it for? (It is not exported because we did not think a
user would need it directly.)
If you tell us how to get the PID on win32, we will support that on
win32 also.
Note that you would have received a speedier reply if you asked
CLISP-specific questions on the <clisp-list> mailing list.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Type louder, please.
Tim Bradshaw
> What do you need it for? (It is not exported because we did not think a
> user would need it directly.)
The classic reason for wanting this on Unix is so you can write it to
a file which can then be used by programs that want to talk to you by
signals. BIND is a classic example of a program that does this, but I
suspect things like apache do this as well (HUP typically meaning
`reread the config file'). Of course this being useful depends on
being able to define signal handlers, and I have no idea if that's
possible in CLISP. Even if it isn't possible, it can be useful if the
only requirement is to unambiguously kill a daemon, say (and yes,
there are risks if the pid file doesn't correspond to the running
daemon, but this is Unix, these risks are things we accept...).
--tim
Erik Naggum
| On a UNIX system, CLISP has SYS::PROGRAM-ID for that.
Why is it called `program-id´ when it returns the process-id?
| Note that you would have received a speedier reply if you asked CLISP-
| specific questions on the <clisp-list> mailing list.
The point with a general forum is that people who live in their own
little caves actually get out in the open to share information that is
pertinent to all users. But perhaps CLISP is better off hiding away in a
mailing list? From my vantage point, hiding away in a mailing list and
constantly urging people not to share information about CLISP experiences
suggests that you do, indeed, have somthing to hide. You also imply that
the CLISP community believes that what goes on in public is not of
interest to its members. I always find arrogance fascinating and try to
deconstruct it, because sometimes, people have good reason to be
arrogant, but mostly they are only insecure and prefer isolation from a
reality that can test their convictions.
Marc Mertens
thanks for all the replies I did get, I think 'PROGRAM-ID' is dooing
what I want. As for the raison I want to do this, I start a LISP session
from a java program and want to send signals to the LISP program from
within java. Java has no direct way to get at the process id of a program
it starts so I need the Lisp process to tell me its process id.
Concerning the CLISP-LIST discussion list, I'm actually subscribed to it
but for some raison I don't seem to get any mail from this list (if I
resubscribe it tells me I'm already subscribed).
Marc Mertens
mmer...@vt4.net
Sam Steingold
> * On the subject of "Re: Getting the PID in CLISP"
> * Sent on 24 Oct 2002 15:06:09 +0000
> * Honorable Erik Naggum <er...@naggum.no> writes:
>
> * Sam Steingold <s...@gnu.org>
> | On a UNIX system, CLISP has SYS::PROGRAM-ID for that.
>
> Why is it called `program-id´ when it returns the process-id?
I have no idea - this name predates my involvement.
Might it be because CLISP was originally written for AMIGA?
Now we will probably export it (thanks to Tim Bradshaw and Marc
Mertens for explaining how it can be generally useful).
What name do people prefer?
GETPID? PROCESS-ID? PID? ID? #:G123?
> | Note that you would have received a speedier reply if you asked CLISP-
> | specific questions on the <clisp-list> mailing list.
>
> The point with a general forum is that people who live in their own
> little caves actually get out in the open to share information that
> is pertinent to all users.
How is this question pertinent to non-CLISP-users?
See <http://clisp.cons.org/faq.html#help> for details.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Old Age Comes at a Bad Time.
Tim Bradshaw
> Now we will probably export it (thanks to Tim Bradshaw and Marc
> Mertens for explaining how it can be generally useful).
> What name do people prefer?
> GETPID? PROCESS-ID? PID? ID? #:G123?
GETPID, since it's the name of the Unix system call to which it's an
interface.
--tim
Will Deakin
> GETPID, since it's the name of the Unix system call to which it's an
> interface.
:)w
Paolo Amoroso
> The crucial element appears to be whether you compile with exported
> syscalls or not. I have just tried to build 2.27, 2.28, 2.29, and 2.30
> from the distributed tarballs, but all of them bomb during building, so I
> gave up on recovering the configuration options necessary to get `getpid´
> in, e.g., the LINUX package. My heartfelt thanks go out to the people
The relevant CLISP configure options should be:
--with-export-syscalls --with-module=bindings/linuxlibc6
Since I don't have the configure help handy, I don't remember whether both
of them are required, or just the former. The function for getting a
process pid is then accessible as `LINUX:getpid'.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Erik Naggum
| Now we will probably export it (thanks to Tim Bradshaw and Marc
| Mertens for explaining how it can be generally useful).
| What name do people prefer?
| GETPID? PROCESS-ID? PID? ID? #:G123?
My vote goes to both `process-id´ and `getpid´, which would be the names
people would look for it under.
| How is this question pertinent to non-CLISP-users?
If you do not understand that, I have to explain the value of society to
human beings to you. But I assume you are just obnoxious and that it
should suffice to say that it is helpful to know by what name functions
that should be available to all environments will be known. It is part
of the community standards development process to share information.
Rob Warnock
+---------------
| Erik Naggum <er...@naggum.no> wrote:
| > The crucial element appears to be whether you compile with exported
|
| The relevant CLISP configure options should be:
|
| --with-export-syscalls --with-module=bindings/linuxlibc6
|
| Since I don't have the configure help handy, I don't remember whether both
| of them are required, or just the former. The function for getting a
| process pid is then accessible as `LINUX:getpid'.
Guys, this is all very well and good if one wants *all* the syscalls
in that package to be accessible with their Unix names, but in the case
of the original poster's question the following might be a lot simpler:
#+clisp (setf (symbol-function 'getpid) ; in the using package
(symbol-function 'system::program-id))
[I apologize if this isn't the "proper" way to do that, but after a
half-hour of wandering around in the PACKAGE & SYMBOL dictionaries
in the CLHS looking for "RENAMING-IMPORT" or equiv., I gave up and
went with the brute-force approach.]
Or perhaps even:
#+clisp (defun getpid () (system::program-id))
Since one never needs to call it more than *once* per process,
the overhead of the extra subroutine won't matter.
What am I missing here?
-Rob
-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Erik Naggum
| Since one never needs to call it more than *once* per process,
| the overhead of the extra subroutine won't matter.
That would imply that the value would be in a global constant, which is
probably just as practical in many cases, but if you do not know whether
someone had forked on you since last time, you need to call the system
function each time you need the value. It is like asking the system for
the time of day and hoping to finish your calculation before it changes.
Chris Beggy
> #+clisp (setf (symbol-function 'getpid) ; in the using package
> (symbol-function 'system::program-id))
What's the #+clisp notation?
Thanks.
Chris
Jeremy Yallop
'#+' is a reader macro to test whether a feature is present. See
http://www.lispworks.com/reference/HyperSpec/Body/24_ab.htm
Jeremy.
Geoffrey Summerhayes
"Chris Beggy" <chr...@kippona.com> wrote in message news:87smyvs...@lackawana.kippona.com...
>
> What's the #+clisp notation?
>
In the HS, see 24.1.2.1 Feature Expressions
#+ and #- are conditionals for the reader, somewhat akin
to #ifdef and #ifndef in a C pre-processor if you're familiar
with that particular beast. :-)
--
Geoff
Rob Warnock
+---------------
Also see <URL:http://www.lispworks.com/reference/HyperSpec/Body/02_dhq.htm>