<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
----- Message d'origine ----- <br>
De : Pierre MARECHAL <br>
Date : 16/04/2009 15:24:
<blockquote cite="mid:49E7317A.6040500@scilab.org" type="cite">Hi,
<br>
<br>
This <a moz-do-not-send="true"
href="http://gitweb.scilab.org/?p=scilab;a=blob;f=SEP/SEP_23_extends_diary.odt;h=cc868007959fb1af8792f94de00fe7067a6a6318;hb=ba7faf634f2fd78dfae4891c10659bde55866699">SEP</a>
deals with the addition of new functionalities to the diary management
in Scilab.<br>
<br>
Comments and suggestions are welcome !
<br>
<br>
Best regards,
<br>
<br>
Pierre</blockquote>
Hi Pierre, hi everyone,<br>
<br>
There is another case that can be seen as as a drawback of the current
behaviour:<br>
When several Scilab sessions are simultaneously running in distinct
consoles on <br>
the same terminal, and then when diary(filename) is run with the same
filename <br>
in several sessions, the current behaviour is confused: The closure of
a diary overwrites<br>
the output of the previous one (starting from the beginning, but
keeping the trail<br>
of the previous one if this one was longer).<br>
<br>
So, yes, reviewing and improving diary() management is welcome.<br>
<br>
<b>Simultaneous sessions management(s)</b><br>
In the SEP, the checking of diary previously opened seems to be
restricted<br>
to the current session, with no "external" "file locking" . Am i right,
and if yes,<br>
would it be possible to implement an external Scilab file
locking/checking ?<br>
<br>
Another possibility for managing this kind of conflict could be the
following:<br>
When diary(filename) detects that filename already exists and is not
empty,<br>
then an effective filename base(filemane) + _# + extension(filename)<br>
is built, used, and returned by diary(filename) as a second output
argument<br>
(beside id). The rank # (integer with at least 2 digits: "01", "02",
etc) would <br>
be set as the smallest integer for which the resultant filename does
not yet <br>
exists.<br>
<br>
This behaviour could be the default. So no optional argument is (never)
needed <br>
for it (specifying the default through an option is quite puzzling
about what is <br>
the default...).<br>
Then, the "new" option would be a true option (or forget it).<br>
<br>
Because diary() seems to be bufferized with one buffer per diary()
session, <br>
would an implementation of an interlacing mode with session_id line
header <br>
be possible as another fixing alternative ? Then, reading of this kind
of diary <br>
would required filtering capability of the used editor, working on the
session_id <br>
header. What about the need of this kind of diary() e.g. for PVM
operations <br>
(i have still never used PVM. I am just wondering about), or other
comparable<br>
asynchronous operations that could need a "merged" log ?<br>
<br>
Some ideas for additional options:<br>
<br>
<b>Horodating</b><br>
What about an option <b>horodating=format</b> that would add the date
& hour as <br>
line header (or sub-header, whether a <i>session_id</i> header is
already written in the <br>
diary) to each logged command line. default format could be YY-MM-DD,
HH:MN:SS:<br>
<br>
<b>Depth of logging</b><br>
What about the optional possibility to restricted output logging to a
certain (absolute ?) <br>
depth, since diary() can be run inside functions.<br>
<br>
For contribution and discussion,<br>
<br>
Best regards<br>
Samuel<br>
<br>
</body>
</html>