Ticket #1130 (closed enhancement: fixed)

Opened 7 years ago

Last modified 7 years ago

Log shown in show log is very cluttered

Reported by: leonwlaw Owned by: leonwlaw
Priority: minor Milestone:
Component: repy Version: 0.1t
Severity: Low Keywords:
Cc: justinc, albert.rafetseder@… Blocking:
Blocked By:

Description

When running repy programs via seash, the logfile gets cluttered easily when running the program multiple times. There is no visual indication where the output from the last program ended, nor where output from the next program starts.

Change History

Changed 7 years ago by leonwlaw

My proposed fix is to add the separators within repy. I believe this is a better location to add the separators (as opposed to the node manager) is because sometimes while writing repy programs, I forget that the program is run twice; once during initialization and once while exiting. This fix would also reinforce the idea that we run each program twice. Assuming the program runs successfully, the logfile created should then look something like this:

 -- Starting Program --
...
Normal execution output
...
 -- Exiting Program --
...
Normal termination output
...
 -- Program Terminated --
 -- Starting Program --
...

I also notice a simple flag for repy. In that case, we can simply omit the " -- Exiting Program -- " section and skip directly to " -- Program Terminated -- "

Changed 7 years ago by justinc

Hmm. Should we say what the arguments, etc. were?

Also, I'm not 100% about the -- Exiting Program -- part. I believe this will be confusing, but try it and let us know.

Changed 7 years ago by leonwlaw

This is the output for the new version. I've changed some of the text to be more meaningful. Displaying the arguments makes sense, I don't know about some of the other arguments that can be passed into repy. Those arguments are only accessible via running repy directly, so the user would be completely aware of those options when they use it. I imagine that the arguments to pass to the actual program would be more important to the user instead.

========================================
Starting program: printstuff.repy
Callfunc: initialize
Arguments: ['these', 'arguments', 'arent', 'used']
========================================
This program is being run in the init phase.
========================================
Starting program: printstuff.repy
Callfunc: exit
Arguments: ['these', 'arguments', 'arent', 'used']
========================================
This program is currently shutting down!
========================================
Execution complete.
========================================
Starting program: printstuff.repy
Callfunc: initialize
Arguments: []
========================================
This program is being run in the init phase.
========================================
Starting program: printstuff.repy
Callfunc: exit
Arguments: []
========================================
This program is currently shutting down!
========================================
Execution complete.

Changed 7 years ago by justinc

My honest opinion is to drop the init / exit printing code. However, feel free to send it to the list and see what others say.

Definitely drop the exit args output.

Thanks,
Justin

Changed 7 years ago by leonwlaw

After talking with Vijay about it, it made sense to drop the init/exit code. I believe this is how we should handle output. We only print the program name and arguments (or, if in simple execution mode, we simply state this) at the start of the program run, and that's it.

Log from '128.238.162.130:1224:v1':
========================================
Running: printstuff.repy
Arguments: []
========================================
This program is being run in the init phase.
This program is currently shutting down!
========================================
Running: printstuff.repy
Arguments: []
========================================
This program is being run in the init phase.
This program is currently shutting down!
========================================
Running: printstuff.repy
Arguments: ['hello', 'world']
========================================
This program is being run in the init phase.
This program is currently shutting down!

And if we're running in simple execution mode:

========================================
Running: printstuff.repy
(simple execution mode)
========================================
This program is being run in the init phase.
This program is currently shutting down!

Changed 7 years ago by leonwlaw

I've added a --verbose flag so that the existing unit tests that use repy don't break. The nodemanager utilizes this field to produce the output above.

Changed 7 years ago by leonwlaw

  • status changed from new to closed
  • resolution set to fixed

I'm opting for --execinfo instead of --verbose for better clarification on what is supposed to happen.

Changed 7 years ago by albert

  • cc albert.rafetseder@… added

Sorry for chiming in late in the discussion, but why do you need to solve this inside the Seattle platform, rather than in the Repy program itself? I run into the "log clutter" problem too, but I think an easy-to-use library can achieve the same thing in a less disruptive way:

include execinfo, preprocess the Repy file, done! The hypothetical execinfo library could then gather NTP timestamps if needed, print callargs and what phase the program is in, etc.

A clear log command for seash would be very helpful though. (Alternatively, you can print a few thousand newlines to force the vessel log to roll over).

Changed 7 years ago by justinc

There is a way to clear the log (the reset command).

I think part of the reason to do this is to make the common case understandable.

Of course, this bloats the TCB by a ~5 lines of code, but I think this may be a good tradeoff.

Changed 7 years ago by albert

reset clears the log, but also stops programs, and deletes all files. I usually don't want my files deleted, as they contain measurement data.

I'm not too worried about the size of the change you proposed, but I think it's functionality trivially added to an application.

Note: See TracTickets for help on using tickets.