<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Pierre,<br>
<br>
----- Message d'origine ----- <br>
De : Pierre MARECHAL <br>
Date : 20/04/2009 11:30:
<blockquote cite="mid:49EC40C3.1090903@scilab.org" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
.../...
  <blockquote type="cite">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.</blockquote>
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.<br>
</blockquote>
If you feel that default numbering should go with 3 or 4 digits, why
not.<br>
If the standard  maximal number is reached (say with 2 digits, so 100
is <br>
reached), then either this would yield an error, or in a more
comprehensive <br>
way, a digit would naturally be added, and so on.<br>
i am not convinced that proposing the wished number of digits as a new <br>
input option would be really useful.<br>
<br>
<blockquote cite="mid:49EC40C3.1090903@scilab.org" type="cite">
  <blockquote type="cite"><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</blockquote>
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 <a moz-do-not-send="true"
 href="http://php.net/manual/en/function.date.php">date</a> php
function). Why ? because,  Date and time formats are different
according to countries : <br>
    <br>
USA : MM-DD-YYYY <br>
France : DD-MM-YYYY <br>
German : DD.MM.YYYY<br>
...<br>
  <br>
Again, this functionality (formating time and date) should be useful
for other functions than diary and described in a separate SEP. <br>
</blockquote>
I agree with Bernard about standard as the default, and to the
customization possibility.<br>
I have proposed YY-MM-DD, HH:MN:SS as a default near to the DATETIME
MySQL <br>
format YYYY-MM-DD HH:MN:SS, that may be the standard. ":" separator is
preferable <br>
to "-" for the TIME part (as you stated in a part of the SEP example)<br>
I tend to remove de first 2 digits of the century, since there is not
really<br>
information in them (i mean, what will be the world by 91 years... :-).<br>
<br>
I am strongly favorable to set the <b>"prefix-only-command" as the
default,</b><br>
instead to time-stamping every output line (is there any acute need for
such<br>
a flow, with respect to increase of file weight and decrease of diary
readability ?<br>
It is always possible to use tic & toc outputs only when really
needed).<br>
Moreover, for the same reason, in prefix-only-command mode, no wide
white <br>
margin should be introduced. <br>
To facilitate post-processing of diaries with a parser and isolate
time-stamps,<br>
what about introducing every time-stamp with a mark (say "@")(instead
of <br>
reserve the 20 first columns). <br>
Example (reshaping the one given in the SEP):<br>
<br>
<font face="Courier New, Courier, monospace">@2009-04-19 10:15:00<br>
--> a = rand(3,3)<br>
  ans =<br>
<br>
   0.2113249 0.3303271 0.8497452<br>
   0.7560439 0.6653811 0.6857310<br>
   0.0002211 0.6283918 0.8782165<br>
<br>
@2009-04-19 10:15:09 <br>
--> diary(0);<br>
</font><br>
may be used instead, in order to keep a sober diary output. <br>
<br>
<blockquote cite="mid:49EC40C3.1090903@scilab.org" type="cite"><b>Depth
of logging</b><br>
  <blockquote type="cite">What about the optional possibility to
restricted output logging to a
certain (absolute ?) <br>
depth, since diary() can be run inside functions.</blockquote>
I'am not sure to understand your request : can you give an example ?<br>
</blockquote>
This was no more than an opened idea, instead of a request:<br>
if in a function one has<br>
<br>
   pause<br>
   diary(... maxdepth=3, ...)<br>
<br>
yielding<br>
<br>
-4-><br>
<br>
then no diary would be opened after entering <return><br>
<br>
<blockquote cite="mid:49EC40C3.1090903@scilab.org" type="cite">Two new
sections has been added<br>
    - pause/resume a diary session<br>
</blockquote>
if no file identifier is provided, pause & resume commands might <br>
usefully be understood as to be applied to the last opened diary.<br>
<br>
Regards<br>
<br>
Samuel<br>
<br>
</body>
</html>