Re: [Gbootroot-devel] Verbosity Logging

[Jonathan R. <mtt...@ac...>]

> > I am glad you brought this up.  First I think we should consider using the
> > sys function found in Yard:
> > 
> > sub sys {                                                                       
> >   open(SYS, "@_ 2>&1 |") or die "open on sys(@_) failed: $!";                   
> >   while (<SYS>) {                                                               
> >     print LOGFILE;                                                              
> >     print if $CFG::verbosity > 0;                                               
> >   }                                                                             
> >   close(SYS) or die "Command failed: @_\nSee logfile for error
> > message.\n";     
> >   0;                            # like system()                                 
> > } 
> > 
> > package CFG;                                                                    
> >                                                                                 
> > #  $verbosity: 1 or 0                                                           
> > #                                                                               
> > #  This controls only what is printed to the screen.                            
> > #  0 --> only the important messages.                                           
> > #  1 --> all messages.                                                          
> > #  All messages will be written to the log file regardless of the setting.      
> > #                                                                               
> > $verbosity = 0;
> > 
> > The error parts would be modified to feed the users chosen level of
> > verbosity to a viewable widget.  This would be a good way to handle system
> > calls.  We may also consider getting rid of as many sys() as possible and
> > use Perl functions whenever we can.  But one way or the other there should
> > be a verbosity option which brings up a text widget to show things as they
> > happen.  And perhaps another option which allows the user to log stuff to
> > a file, ofcourse things could be cut and pasted, too.
> > 
> > Tell me what you think? 
> 
> This is good. Clean and proper.
> 
> Error handling is probably one of the more difficult things. That said,
> this idea is what I think:
> 
> a. FATAL stops the execution (perl: die) and throws you out

I think it would be better to just log the FATAL error, then the user can
make corrections, and resubmit.  FATAL errors are caused by things like
running out of disk space.  I've been avoiding dies or croaks for most
cases deliberately, on the other hand, if the system doesn't have init,
the person is really in trouble.  The majority of things which stop
execution can be corrected by the user without killing the program. 

> b. ERROR stops the execution cleans up and brings you back to some safe,
>    previous stage; keeps as much as possible of the entered data and gives
>    some indication on what the problem is

This is already built into the program at least for the present
capabilities. 
 
> These two cover the verbosity level 0, above.

Sounds right, basically in most cases this would be the error output from
system calls .. the 2> thing. 
 
> 3. WARM indicates that something didn't work out but the program can
>    continue

Distinguishing between WARM and FATAL will be difficult and impressive
thing to do. I leave this to you for figuring out. :) 

> This would be verbositi level 1, above.
> 
> 4. INFO would give something like a trace (debug level)

I am kind of turning your approach of INFO inside out, but here is my
idea, though it isn't necessary right:

FATAL is -v .. WARM & FATAL is -vv , INFO can be -vvv and -vvvv

INFO can be STDOUT -> -vvv
INFO can be written description -> -vvvv  Throughout the program I have
commented out written descriptions I used in BootRoot with #V#

We may ditch a -v because WARM & FATAL may be difficult to establish.

> Not everything executed is a shell command, so there's need for a function
> to do that too.
> 
> Maybe '--verbosity <level>' may be a command line option?

No, I've written too many command line programs. :)  And there is really
no advantage doing this with gBootRoot because it is designed to be a
button pushing program.
 
> Another way to specify it could be some button(s) on the main window?

I think a spin button like what is being used for device size will be
used.  This will have different levels of verbosity .. nothing .. 1 .. 4 

I think setting up a collapsable/expandable advanced section may be kind
of cool, then verbosity, initrd setting and the like can be included
there.  Alternatively, maybe a popup menu .. there many ways of doing
this. 

> The results can stay in a log file (like it's done now) or showed 'live'
> in another window.

There will be a SAVE button on the visible log.  I'll create some
functions to do this, and then you do the fine tuning.  We will be
converting to sys(), too. 

What do you think?