Checking Process Status

Checking Process Status

[CarlC]

I am trying to make "compile" synchronous. I am defining a function that
does a compile and looks at the *compilation* buffer. I need to wait until
the compile is finished before looking at this buffer. I think that my
problem is not knowing how to check the return of process-status. If I do
(setq stat (process-status "compilation")) right after the compile, it gets
set to a value "run". I don't know if this is a string or other type of
value. These are a couple of things that I have tried:

(while (equal (process-status "compilation") "run") (sleep-for .5))

(while (process-status "compilation") (sleep-for .5))

The first one fails the first time through, before the compile has finished.
The second one never finishes until I C-g, even though (process-status
"compilation") seems to return nil after the compilation finishes.

Does anybody have an idea of what I need to do here? Or is there a better
way of accomplishing this. The compiles normally take a fraction of a second
to complete, so this isn't going to cause the user any problem to have emacs
wait. I would hate to hardcode a delay. Thanks.

Re: Checking Process Status

[David Kastrup]

"CarlC" <carlc@snowbd.com> writes:

> I am trying to make "compile" synchronous. I am defining a function that
> does a compile and looks at the *compilation* buffer. I need to wait until
> the compile is finished before looking at this buffer. I think that my
> problem is not knowing how to check the return of process-status. If I do
> (setq stat (process-status "compilation")) right after the compile, it gets
> set to a value "run". I don't know if this is a string or other type of
> value. These are a couple of things that I have tried:
> 
> (while (equal (process-status "compilation") "run") (sleep-for .5))
> 
> (while (process-status "compilation") (sleep-for .5))
> 
> The first one fails the first time through, before the compile has finished.
> The second one never finishes until I C-g, even though (process-status
> "compilation") seems to return nil after the compilation finishes.
> 
> Does anybody have an idea of what I need to do here?

Save the old value of the process' sentinel, enter your own function
there, and have that do its work as well as calling the saved
sentinel.

Look up the appropriate keywords in the Elisp manual.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Checking Process Status

[Kevin Rodgers]

David Kastrup wrote:

> Save the old value of the process' sentinel, enter your own function
> there, and have that do its work as well as calling the saved
> sentinel.

The right way to do that in general is to advise the original function.  See

lisp/emacs-lisp/advice.el.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Checking Process Status

[CarlC]

"Kevin Rodgers" <kevin.rodgers@ihs.com> wrote in message
news:3E3EABC2.9000900@ihs.com...
> The right way to do that in general is to advise the original function.
See
>
> lisp/emacs-lisp/advice.el.

Kevin, I appreciate you pointing me to this library. I can see using it to
process my code after the compile function runs. I don't see how this solves
my issue of checking that the compile process has finished. Is there another
inside function that I could use defadvice on?

Re: Checking Process Status

[CarlC]

"David Kastrup" <dak@gnu.org> wrote in message
news:x5wukhv20i.fsf@lola.goethe.zz...
> Save the old value of the process' sentinel, enter your own function
> there, and have that do its work as well as calling the saved
> sentinel.

Thanks for the quick response, David. I guess I need to know why this is the
case. If I can get a process-status, why do I need to modify the compile
sentinel. Does the existing sentinel wrap it up so that I can't access it's
status? This doesn't appear to be the case when I am debugging. I can set a
variable and view its status as "run". If I can do this, why can't I add a
conditional to check this status outside of the sentinel? I just want to
know if the compilation process is running. Thanks, again.

Re: Checking Process Status

[David Kastrup]

"CarlC" <carlc@snowbd.com> writes:

> "David Kastrup" <dak@gnu.org> wrote in message
> news:x5wukhv20i.fsf@lola.goethe.zz...
> > Save the old value of the process' sentinel, enter your own function
> > there, and have that do its work as well as calling the saved
> > sentinel.
> 
> Thanks for the quick response, David. I guess I need to know why
> this is the case. If I can get a process-status, why do I need to
> modify the compile sentinel. Does the existing sentinel wrap it up
> so that I can't access it's status? This doesn't appear to be the
> case when I am debugging. I can set a variable and view its status
> as "run". If I can do this, why can't I add a conditional to check
> this status outside of the sentinel? I just want to know if the
> compilation process is running. Thanks, again.

Your code programmed a busy wait.  That's ugly, butt-ugly.  Instead
just let your code be run when the process has finished.  Anyhow, if
at all, you would need to compare to symbols 'run and 'exit, not
strings.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Checking Process Status

[CarlC]

"David Kastrup" <dak@gnu.org> wrote in message
news:x565s1ro9r.fsf@lola.goethe.zz...
> Your code programmed a busy wait.  That's ugly, butt-ugly.  Instead
> just let your code be run when the process has finished.  Anyhow, if
> at all, you would need to compare to symbols 'run and 'exit, not
> strings.

Understood. My concern is that this routine is going to possibly open a new
buffer, and change point. I didn't want the user to wander around during the
compile and then have emacs zap him a new screen. I will take your advice
into consideration.

Re: Checking Process Status

[Kevin Rodgers]

CarlC wrote:

> Understood. My concern is that this routine is going to possibly open a new
> buffer, and change point. I didn't want the user to wander around during the
> compile and then have emacs zap him a new screen. I will take your advice
> into consideration.

Then force M-x compile to run the command synchronously:

(fmakunbound 'start-process)

Note: This may have other, undesirable consequences.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Checking Process Status

[Jay Belanger]

Kevin Rodgers <kevin.rodgers@ihs.com> writes:

> CarlC wrote:
>
>> Understood. My concern is that this routine is going to possibly open a new
>> buffer, and change point. I didn't want the user to wander around during the
>> compile and then have emacs zap him a new screen. I will take your advice
>> into consideration.
>
> Then force M-x compile to run the command synchronously:
>
> (fmakunbound 'start-process)

If I try that here (not with M-x compile), I get the message
"Multi-processing is not supported for this system"
(RedHat 8.0 with CVS emacs)

I have problem slightly similar to CarlC's, though.
I need a program to stop at a certain point, and wait until a
comint-process gives some output, and then and only then continue.
(Also, the user shouldn't be able to move the point...)
I thought accept-process-output would do that, but that doesn't seem
to work.  What should work?

Thanks,
Jay

Re: Checking Process Status

[Kevin Rodgers]

Jay Belanger wrote:

> Kevin Rodgers <kevin.rodgers@ihs.com> writes:
>>CarlC wrote:
>>>Understood. My concern is that this routine is going to possibly open a new
>>>buffer, and change point. I didn't want the user to wander around during the
>>>compile and then have emacs zap him a new screen. I will take your advice
>>>into consideration.
>>>
>>Then force M-x compile to run the command synchronously:
>>
>>(fmakunbound 'start-process)
> 
> If I try that here (not with M-x compile), I get the message
> "Multi-processing is not supported for this system"
> (RedHat 8.0 with CVS emacs)


That is one of the undesirable consequences I alluded to.


> I have problem slightly similar to CarlC's, though.
> I need a program to stop at a certain point, and wait until a
> comint-process gives some output, and then and only then continue.
> (Also, the user shouldn't be able to move the point...)
> I thought accept-process-output would do that, but that doesn't seem
> to work.  What should work?

Is a nil TIMEOUT interpreted by accept-process-output as 0 or infinity?  If
it's 0, try specifying a really large value (like most-positive-fixnum), or
calling it in a loop.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Checking Process Status

[Eli Zaretskii]

On Mon, 10 Feb 2003, Kevin Rodgers wrote:

> >>Then force M-x compile to run the command synchronously:
> >>
> >>(fmakunbound 'start-process)
> > 
> > If I try that here (not with M-x compile), I get the message
> > "Multi-processing is not supported for this system"
> > (RedHat 8.0 with CVS emacs)
> 
> That is one of the undesirable consequences I alluded to.

Might as well be a bug in compile.el: sounds like some of its condition 
to run the synchronous path are based on system-type, not on 
start-process being not fboundp.  Perhaps this should be reported as a 
bug.

Re: Checking Process Status

[CarlC]

"Kevin Rodgers" <kevin.rodgers@ihs.com> wrote in message
news:3E3F019E.8060308@ihs.com...
> Then force M-x compile to run the command synchronously:
>
> (fmakunbound 'start-process)
>
> Note: This may have other, undesirable consequences.

This code has worked for me. To do away with the "undesirable consequences",
I make this temporary in the compile function:

(defadvice compile (before cobol-compile activate)
  "Set compile-command and make compile syncronous"
  (fset 'save-start-process (symbol-function 'start-process))
  (fmakunbound 'start-process))

(defadvice compile (after cobol-compile activate)
  "Process cobol error listing."
  (fset 'start-process 'save-start-process)
...

Thanks to all who helped me.

Re: Checking Process Status

[David Kastrup]

"CarlC" <carlc@snowbd.com> writes:

> "CarlC" <carlc@snowbd.com> wrote in message
> news:Ewz2a.39752$yn1.1662533@twister.austin.rr.com...
> > This code has worked for me. To do away with the "undesirable
> consequences",
> > I make this temporary in the compile function:
> >
> > (defadvice compile (before cobol-compile activate)
> >   "Set compile-command and make compile syncronous"
> >   (fset 'save-start-process (symbol-function 'start-process))
> >   (fmakunbound 'start-process))
> >
> > (defadvice compile (after cobol-compile activate)
> >   "Process cobol error listing."
> >   (fset 'start-process 'save-start-process)
> > ...
> 
> Spoke too soon. This code breaks with "Symbol's chain of function
> indirections contains a loop: start-process" if I run a compile more than
> once and then try to open a shell buffer. Anyone know the proper way to
> accomplish this?

You do it right the first time, wrong the second time.  But it is not
really necessary to save in a global variable, and you want stuff to
get restored in any case.

I'd use
(defadvice compile (around cobol-compile activate)
  "Set ...."
  (let ((saved-start-process (symbol-function 'start-process)))
       (unwind-protect
         (progn (fmakunbound 'start-process) ad-to-it)
         (fset 'start-process saved-start-process))))

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Checking Process Status

[CarlC]

"David Kastrup" <dak@gnu.org> wrote in message
news:x5wuk52k8v.fsf@lola.goethe.zz...
> I'd use
> (defadvice compile (around cobol-compile activate)
>   "Set ...."
>   (let ((saved-start-process (symbol-function 'start-process)))
>        (unwind-protect
>          (progn (fmakunbound 'start-process) ad-to-it)
>          (fset 'start-process saved-start-process))))

I haven't taken the time to figure out the "around" command. Is this like an
"if", where the first function goes before and all others go after the
compile function? The main part of my need is to add stuff after the
compilation has finished, but I also do some things prior to compiling.

Re: Checking Process Status

[David Kastrup]

"CarlC" <carlc@snowbd.com> writes:

> "David Kastrup" <dak@gnu.org> wrote in message
> news:x5wuk52k8v.fsf@lola.goethe.zz...
> > I'd use
> > (defadvice compile (around cobol-compile activate)
> >   "Set ...."
> >   (let ((saved-start-process (symbol-function 'start-process)))
> >        (unwind-protect
> >          (progn (fmakunbound 'start-process) ad-to-it)
> >          (fset 'start-process saved-start-process))))
> 
> I haven't taken the time to figure out the "around" command. Is this like an
> "if", where the first function goes before and all others go after the
> compile function? The main part of my need is to add stuff after the
> compilation has finished, but I also do some things prior to compiling.

It will take you much shorter to read the existing documentation for
the advice command in the Emacs Lisp manual than it would take me to
type it up again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Checking Process Status

[Kai Großjohann]

"CarlC" <carlc@snowbd.com> writes:

> I haven't taken the time to figure out the "around" command. Is this like an
> "if", where the first function goes before and all others go after the
> compile function? The main part of my need is to add stuff after the
> compilation has finished, but I also do some things prior to compiling.

No, the original function is run where the advice contains ad-do-it.
(Typo alert in David's message: he used ad-to-it instead of ad-do-it.)
-- 
A turnip curses Elvis

Re: Checking Process Status

[Kevin Rodgers]

Eli Zaretskii wrote:

> On Mon, 10 Feb 2003, Kevin Rodgers wrote:
>>Jay Belanger wrote:
>>>Kevin Rodgers wrote:

>>>>Then force M-x compile to run the command synchronously:
>>>>
>>>>(fmakunbound 'start-process)
>>>>
>>>If I try that here (not with M-x compile), I get the message
>>>"Multi-processing is not supported for this system"
>>>(RedHat 8.0 with CVS emacs)
>>>
>>That is one of the undesirable consequences I alluded to.
> 
> Might as well be a bug in compile.el: sounds like some of its condition 
> to run the synchronous path are based on system-type, not on 
> start-process being not fboundp.  Perhaps this should be reported as a 
> bug.

I thought that when Jay wrote "not with M-x compile", he meant that some other
package that _requires_ asynchronous subprocess support had signalled the error.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Checking Process Status

[Jay Belanger]

Kevin Rodgers <kevin.rodgers@ihs.com> writes:

> Eli Zaretskii wrote:
>
>> On Mon, 10 Feb 2003, Kevin Rodgers wrote:
>>>Jay Belanger wrote:
>>>>Kevin Rodgers wrote:
>
>>>>>Then force M-x compile to run the command synchronously:
>>>>>
>>>>>(fmakunbound 'start-process)
>>>>>
>>>>If I try that here (not with M-x compile), I get the message
>>>>"Multi-processing is not supported for this system"
>>>>(RedHat 8.0 with CVS emacs)
>>>>
>>>That is one of the undesirable consequences I alluded to.
>> Might as well be a bug in compile.el: sounds like some of its
>> condition to run the synchronous path are based on system-type, not
>> on start-process being not fboundp.  Perhaps this should be reported
>> as a bug.
>
> I thought that when Jay wrote "not with M-x compile", he meant that some other
> package that _requires_ asynchronous subprocess support had signalled the error.

Yeah, that's what I meant.
It was probably a dissimilar enough situation that that 
(fmakunbound 'start-process)
wasn't supposed to apply.
At any rate, Kevin's advice
> Is a nil TIMEOUT interpreted by accept-process-output as 0 or infinity?  If
> it's 0, try specifying a really large value (like most-positive-fixnum), or
> calling it in a loop.
seems to work, using
(accept-process-output myprocess 1000)
instead of
(accept-process-output myprocess)
seems to work.  
Thanks!

Jay