Le 20/06/2022 à 12:04, Jean-Yves Baudais a écrit :

Le 17/06/2022 à 23:45, Stephane Mottelet a écrit :
The buffer size is not set by Scilab and hence is always the default for a given platform (it can be different for macOS, Linux, Windows). I suppose you need to increase or decrease it for a given application?

It is just for convenience. Here a better explanation. During simulation, I write some variables on file (used latter for statistical analysis) and I use to prepare and test the post-processing using the partial output data. Scilab does not write the data one by one, but by block of size 4096. The following code shows this behaviour.

--> function stupidWrite(fd,n,a)
--> for i=1:n mfprintf(fd,"%d",a); end
--> endfunction
--> fd=mopen("test.am","a");
--> stupidWrite(fd,4096,1);
--> unix_g("cat test.am | wc ");
 ans  =
  "      0       0       0"
--> stupidWrite(fd,1,2);
--> unix_g("cat test.am | wc ");
 ans  =
  "      0       1    4096"
--> mclose(fd)
--> unix_g("cat test.am |wc ")
 ans  =
  "      0       1    4097"

With the C language, the size of the output buffer is managed using setvbuf. It seems that there is no interface for C-coded version of setvbuf (contrary to many input/output C function).

So my question is: "is it possible to manage the size of the output buffer in Scilab?"

The solution I found is to mopen and mclose the file each time I want to write something. Is there another solution?

To me, here the issue looks not so much about the size of the internal buffer, but about the inability to flush buffered data on request, whatever is the buffer size. For instance, we could simply hope that, for a text file, sending an ascii(12) form feed alone (*) would trigger flushing the buffer, in a trivial, documented, and straightforward way.

By the way, the current default buffering and buffer size of mfprintf() would deserve being documented.

My two cents


(*) easy to detect by the receiver: 1 byte, equal to ascii(12) => flush instead of writing.

users mailing list

Reply via email to