I haven't been able to run niced background jobs, and I think I finally know why, because `time' wants to print to the console which no longer exists. But I'm not quite there yet:
The Gambit manual says `time' uses the interaction channel:
- special form: time EXPR The `time' special form evaluates EXPR and returns the result. As a side effect it displays a message on the interaction channel which indicates how long the evaluation took (in real time and cpu time), how much time was spent in the garbage collector, how much memory was allocated during the evaluation and how many minor and major page faults occured (0 is reported if not running under UNIX).
Now the node "Runtime options" says I can change the interaction channel:
Both `gsi' and `gsc' as well as executable programs compiled and linked using `gsc' take a `-:' option which supplies parameters to the runtime system.
`-' The REPL interaction channel will be standard input and standard output.
I have a 1-line file "6.scm" (time (pretty-print 6))
So to me, the manual says that
% gsi -:- 6.scm > six-out
should print the time info as well as the output 6 to the file "six-out". But it doesn't:
(banach)PolyTree> gsi -:- 6.scm > six (time (pretty-print 6)) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections 104 bytes allocated no minor faults 5 major faults (banach)PolyTree> more six-out 6
Now it doesn't make much difference where the time info goes, unless I'm running a job overnight, nice-ed in the bg. These nice-ed bg jobs of mine hang, run for days, and I think because they want to print to the console, which no longer exists. So people must know how to solve this problem. Help!
Afficher les réponses par date
On Feb 21, 2005, at 12:21 AM, Bill Richter wrote:
So to me, the manual says that
% gsi -:- 6.scm > six-out
should print the time info as well as the output 6 to the file "six-out". But it doesn't:
(banach)PolyTree> gsi -:- 6.scm > six (time (pretty-print 6)) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections 104 bytes allocated no minor faults 5 major faults (banach)PolyTree> more six-out 6
I think the manual may be in error; I think the time info goes to stderr, not stdout. If you're using csh or tcsh, you can try
gsi -:- 6.scm >& six
I don't know how to do it with bash or /bin/sh.
Brad
It's not going to stderr either. Must be directly to the tty.
steve@ruby2 ~ $ gsi 6.scm >out 2>err & [3] 26006 steve@ruby2 ~ $
[3]+ Stopped gsi 6.scm >out 2>err steve@ruby2 ~ $ cat out steve@ruby2 ~ $ cat err steve@ruby2 ~ $ fg gsi 6.scm >out 2>err (time (pretty-print 6)) 0 ms real time 1 ms cpu time (1 user, 0 system) no collections 104 bytes allocated 7 minor faults no major faults
Using nohup doesn't help.
Now the node "Runtime options" says I can change the interaction channel:
Both `gsi' and `gsc' as well as executable programs compiled and linked using `gsc' take a `-:' option which supplies parameters to the runtime system.
`-' The REPL interaction channel will be standard input and standard output.
The correct option is
gsi -:d-
The Gambit manual says
The @samp{d} option sets various debugging options. The letter @samp{d} is followed by a sequence of letters indicating suboptions.
I'll use better wording in the manual.
Marc
The correct option is
gsi -:d-
Thanks, Marc, and I see it's in the Gambit manual, clearly enough:
The `d' option sets various debugging options. The letter `d' is followed by a sequence of letters indicating suboptions. [...]
`i' The REPL interaction channel will be the IDE REPL window (if the IDE is available).[...]
`-' The REPL interaction channel will be standard input and standard output.[...]
The default debugging options are equivalent to `-:dpqi1'
But as I usual I'll carp that something this important should be explained at top level. Or is it not important? Don't folks `time' their long bg jobs?
Anyway, I can't get it to work for gsc/gcc. This works fine:
% m six.scm (time (pretty-print 6))
% export GAMBCOPT=d-
% gsi six.scm > 13-73put
% more 13-73put 6 (time (pretty-print 6)) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections 104 bytes allocated no minor faults 5 major faults
But I lose the `time' info with gsc/gcc:
% gsc six % gcc -O2 -L. -I. six.c six_.c -lgambc % ./a.out > 13-73put % more 13-73put
Now Brad, I think this is wrong:
I think the manual may be in error; I think the time info goes to stderr, not stdout. If you're using csh or tcsh, you can try
gsi -:- 6.scm >& six
I don't know how to do it with bash or /bin/sh.
Yeah, >& redirects both stderr & stdout in bash, and I tried that. But the local hotshot here said it was a stdin problem. Note how he realized it was a runtime problem, which I hadn't mentioned:
FYI, the "Stopped" message in the line
[1]+ Stopped nice ./73a.out 1>&13-73put
means the process is trying to read, or otherwise access, stdin while detached. In a high-level language like Scheme, this can be reflect internal workings of the runtime support, rather than explicit instructions of your program.
Thanks, Rico!
Marc, I think my time/background-job bug didn't get fixed in beta 13. In lieu of a fix, I would accept information: how do you get time info on compiled background jobs? Here a new version of my bug report:
% export GAMBCOPT=d-
% cat six.scm (define outport (open-output-file "six")) (time (pretty-print 6 outport)) (close-output-port outport)
% gsi six.scm > time-out
% cat six 6
% cat time-out (time (pretty-print 6 outport)) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections 104 bytes allocated no minor faults 6 major faults
So gsi works fine. But I lose the `time' info with gsc/gcc:
% gsc six % gcc -O2 -L. -I. six.c six_.c -lgambc % ./a.out > time-out
% cat six 6 % cat time-out
% ls -l time-out -rw-r--r-- 1 richter users 0 May 21 20:54 time-out
-
Bill Richter -
Bradley Lucier -
Marc Feeley -
Steven Shaw