0

I'm trying to debug a command line program I wrote. Specifically, the parts of it that prints to the terminal. It occurred to me that it could help if I somehow ran it slowly on the terminal.

I'd like to be able to see how to terminal would print in older/less capable systems or whether there is flicker effect or not.

Is there a way to run it slower? i.e. not insta-load it.

Program: Written in "C", prints almost instantly.

OS: MacOSX/Windows/Linux, Any would work for me.

Thanks.

  • Possible duplicate of [OSX/Linux, slow down the output from terminal](https://stackoverflow.com/questions/10573906/osx-linux-slow-down-the-output-from-terminal) – Pablo Jan 23 '18 at 21:51
  • Why not redirect the stream to/from file? – Eugene Sh. Jan 23 '18 at 21:52
  • I suppose that depends on exactly what you mean by "run slower", and how much older and less capable you're talking about. In the extreme case, you could mount a DosBox session and run it from there, but that is _seriously_ older/less capable. – Mark Benningfield Jan 23 '18 at 21:54
  • @Pablo Ah, no, I don't want slower printing. I'd like the program to execute slower. –  Jan 23 '18 at 21:55
  • 2
    Connecting with a debugger and single-stepping through the code is the conventional way to see what's going on in slow motion. (If you want the debugger to be on a different terminal than the one where the output goes, that's easily done -- see gdb's `attach` support). – Charles Duffy Jan 23 '18 at 21:56
  • @Maximus in that case, a debugger would be better suited. – Pablo Jan 23 '18 at 21:56
  • ...though of course some strategically-placed `sleep()`s may be an option as well. – Charles Duffy Jan 23 '18 at 21:57
  • That said, if this is emitting output **to a terminal**, any "flicker effect" is a consequence of how the terminal does rendering (and what exactly you're sending to it -- if your program sends CR sequences to go back to the beginning of a line and rewrite that line's contents, for example), more than it is a consequence of the program itself. Someone with a reasonable understanding of how the terminal you're using renders text could presumably read through the output of your program being run in `script` and tell you if there would be flickering if running more slowly just by that output. – Charles Duffy Jan 23 '18 at 21:58
  • Since you say it's written in C, I assume you have code. If that is the case: compile as an MSDOS program and run on a VM running MSDOS ;-) –  Jan 23 '18 at 21:59
  • ...so, the exact same program rendering to a terminal that does double-buffered rendering is going to behave differently (wrt. "flickering") than one that renders characters individually as soon as they're received. Similarly, the techniques used for scrolling &c. *by the terminal* (not by your program) will have impact, so there's no reason to believe that a test result you get with one terminal will reflect what happens with your same program running somewhere else. – Charles Duffy Jan 23 '18 at 22:00
  • ...bottom line: If what you care about is "flickering", analysis by someone who understands the problem space (and the specific hardware/software/terminals/etc. you're proposing deployment to) is liable to provide better results than a naively-performed experiment... unless of course you actually have samples of the target hardware and a high-speed camera on hand, in which case you can generate 100% perfect results experimentally. – Charles Duffy Jan 23 '18 at 22:02
  • There are lots of ways of making the computer run slower: All the links later in this comment are taken from https://www.google.co.nz/search?q=slowing+down+old+games These sites have multiple suggestions: http://www.gamepatchplanet.com/articles/slowing_down_older_pc_games_on_fast_modern_computers.php and http://www.sierrahelp.com/Utilities/SlowdownUtilities.html If DOSBox is an option this site tells how: https://www.gog.com/forum/theme_park/slowing_down_the_game_possible Here is another program I found that I remember using: http://www.hpaa.com/moslo/ – Jerry Jeremiah Jan 23 '18 at 22:08
  • Not for only slowing down, for going all the way to debugging, this might be helpful: https://stackoverflow.com/questions/2069367/how-to-debug-using-gdb – Yunnosch Jan 23 '18 at 22:15
  • Redirecting stdout to file and debugging can solve almost all of my problems. i.e. if the program was moving the cursor up and rewriting some lines. However, on slower systems, sending a write buffer to stdout byte by byte vs sending them in a whole buffer sometimes renders differently. I'm not quite sure if this is a terminal rendering problem or another process gains priority and hangs the application for an observable amount of time. It just makes the program seem like it's having a hard time loading. Not really important in the end but it would be nice if I could forsee it. –  Jan 23 '18 at 22:16
  • I will look into the solutions you all provided. Thanks. I'll report back as soon as possible. –  Jan 23 '18 at 22:19
  • Voting to close as **Too broad** : "Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the [How to Ask page](https://stackoverflow.com/help/how-to-ask) for help clarifying this question." And please read https://stackoverflow.com/help/on-topic , https://stackoverflow.com/help/dont-ask , https://stackoverflow.com/help/mcve and take the [tour](https://stackoverflow.com/tour) before posting more Qs here. Good luck. – shellter Jan 23 '18 at 23:46

1 Answers1

0

You can use the sleep function

#include <unistd.h>
//your code
sleep(1); // pauses for 1 second

by including many of those you get time to see what is happening with your program

M.Bris
  • 35
  • 1
  • 2
  • 8