[Scilab-Dev] Re: SEP 23 : Extend diary : Simultaneous sessions. Horodating. Logging depth

[Samuel GOUGEON]

Hello Pierre,

----- Message d'origine -----
De : Pierre MARECHAL
Date : 20/04/2009 11:30:
> .../...
>> Another possibility for managing this kind of conflict could be the 
>> following:
>> When diary(filename) detects that filename already exists and is not 
>> empty,
>> then an effective filename base(filemane) + _# + extension(filename)
>> is built, used, and returned by diary(filename) as a second output 
>> argument
>> (beside id). The rank #  (integer with at least 2 digits: "01", "02", 
>> etc) would
>> be set as the smallest integer for which the resultant filename does 
>> not yet
>> exists.
> Good idea, I ve added this to the SEP. Just a little remark : I'am 
> sure for the 2 digits : what do we do if # > 100.
If you feel that default numbering should go with 3 or 4 digits, why not.
If the standard  maximal number is reached (say with 2 digits, so 100 is
reached), then either this would yield an error, or in a more comprehensive
way, a digit would naturally be added, and so on.
i am not convinced that proposing the wished number of digits as a new
input option would be really useful.

>> *Horodating*
>> What about an option *horodating=format* that would add the date & 
>> hour as
>> line header (or sub-header, whether a /session_id/ header is already 
>> written in the
>> diary) to each logged command line. default format could be YY-MM-DD, 
>> HH:MN:SS
> Added to the SEP (See diary & time-stamp section). For the moment, 
> only few formats will be supported but ideally, It should be useful 
> the user can build himself the format (As the date 
> <http://php.net/manual/en/function.date.php> php function). Why ? 
> because,  Date and time formats are different according to countries :
>    
> USA : MM-DD-YYYY
> France : DD-MM-YYYY
> German : DD.MM.YYYY
> ...
>
> Again, this functionality (formating time and date) should be useful 
> for other functions than diary and described in a separate SEP.
I agree with Bernard about standard as the default, and to the 
customization possibility.
I have proposed YY-MM-DD, HH:MN:SS as a default near to the DATETIME MySQL
format YYYY-MM-DD HH:MN:SS, that may be the standard. ":" separator is 
preferable
to "-" for the TIME part (as you stated in a part of the SEP example)
I tend to remove de first 2 digits of the century, since there is not really
information in them (i mean, what will be the world by 91 years... :-).

I am strongly favorable to set the *"prefix-only-command" as the default,*
instead to time-stamping every output line (is there any acute need for such
a flow, with respect to increase of file weight and decrease of diary 
readability ?
It is always possible to use tic & toc outputs only when really needed).
Moreover, for the same reason, in prefix-only-command mode, no wide white
margin should be introduced.
To facilitate post-processing of diaries with a parser and isolate 
time-stamps,
what about introducing every time-stamp with a mark (say "@")(instead of
reserve the 20 first columns).
Example (reshaping the one given in the SEP):

@2009-04-19 10:15:00
--> a = rand(3,3)
  ans =

   0.2113249 0.3303271 0.8497452
   0.7560439 0.6653811 0.6857310
   0.0002211 0.6283918 0.8782165

@2009-04-19 10:15:09
--> diary(0);

may be used instead, in order to keep a sober diary output.

> *Depth of logging*
>> What about the optional possibility to restricted output logging to a 
>> certain (absolute ?)
>> depth, since diary() can be run inside functions.
> I'am not sure to understand your request : can you give an example ?
This was no more than an opened idea, instead of a request:
if in a function one has

   pause
   diary(... maxdepth=3, ...)

yielding

-4->

then no diary would be opened after entering <return>

> Two new sections has been added
>     - pause/resume a diary session
if no file identifier is provided, pause & resume commands might
usefully be understood as to be applied to the last opened diary.

Regards

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090421/256f13bc/attachment.htm>