SEP 23 : Extend diary : Simultaneous sessions. Horodating. Logging depth

[Samuel GOUGEON]

----- Message d'origine -----
De : Pierre MARECHAL
Date : 16/04/2009 15:24:
> Hi,
>
> This SEP 
> <http://gitweb.scilab.org/?p=scilab;a=blob;f=SEP/SEP_23_extends_diary.odt;h=cc868007959fb1af8792f94de00fe7067a6a6318;hb=ba7faf634f2fd78dfae4891c10659bde55866699> 
> deals with the addition of new functionalities to the diary management 
> in Scilab.
>
> Comments and suggestions are welcome !
>
> Best regards,
>
> Pierre
Hi Pierre, hi everyone,

There is another case that can be seen as as a drawback of the current 
behaviour:
When several Scilab sessions are simultaneously running in distinct 
consoles on
the same terminal, and then when diary(filename) is run with the same 
filename
in several sessions, the current behaviour is confused: The closure of a 
diary overwrites
the output of the previous one (starting from the beginning, but keeping 
the trail
of the previous one if this one was longer).

So, yes, reviewing and improving  diary() management is welcome.

*Simultaneous sessions management(s)*
In the SEP, the checking of diary previously opened seems to be restricted
to the current session, with no "external" "file locking" . Am i right, 
and if yes,
would it be possible to implement an external Scilab file locking/checking ?

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.

This behaviour could be the default. So no optional argument is (never) 
needed
for it (specifying the default through an option is quite puzzling about 
what is
the default...).
Then, the "new" option would be a true option (or forget it).

Because diary() seems to be bufferized with one buffer per diary() session,
would an implementation of an interlacing mode with session_id line header
be possible as another fixing alternative ? Then, reading of this kind 
of diary
would required filtering capability of the used editor, working on the 
session_id
header. What about the need of this kind of diary() e.g. for PVM operations
(i have still never used PVM. I am just wondering about), or other 
comparable
asynchronous operations that could need a "merged" log ?

Some ideas for additional options:

*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:

*Depth of logging*
What about the optional possibility to restricted output logging to a 
certain (absolute ?)
depth, since diary() can be run inside functions.

For contribution and discussion,

Best regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090416/4c899acb/attachment.htm>