quiz for Sequential_IO Read

quiz for Sequential_IO Read

[Frank Buss]

What does this program output?


with Ada.Sequential_IO;
with Ada.Text_IO; use Ada.Text_IO;

procedure Hello is

    type Byte is range 0..255;

    package Byte_IO is new Ada.Sequential_IO(Byte);
    A : Byte;
    B : Byte;
    C : Byte;
    File : Byte_IO.File_Type;

begin
    Byte_IO.Open(File, Byte_IO.In_File, "test.txt");
    Byte_IO.Read(File, A);
    Put_Line(Byte'Image(A));
    Byte_IO.Read(File, B);
    Put_Line(Byte'Image(B));
    C := (A mod 2) + (B mod 2);
    Put_Line(Byte'Image(C));
    Byte_IO.Close(File);
end;


The content of test.txt is just the ASCII string "hello":

hexdump -C test.txt:
00000000  68 65 6c 6c 6f                                    |hello|
00000005

Answer without compiling and running it! A hex calculator is allowed. 
Extra brownie point if you can explain the result :-)

Don't know if it matters, compiled with "gnatgcc (Debian 6.3.0-18) 6.3.0 
20170516", 64 bit version, and "-g -O2" command line options.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Re: quiz for Sequential_IO Read

[Jeffrey R. Carter]

On 09/03/2017 01:01 PM, Frank Buss wrote:
>     type Byte is range 0..255;

Note that Byte is a signed type, so Byte'Base will have a range that includes 
-255, and Byte'Base'Size will probably be 16. So I'd expect it to read 16 bits 
at a time. That is

A = 16#6568# = 25960, and
B = 16#6C6C# = 27756

C would then be zero.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: quiz for Sequential_IO Read

[Dmitry A. Kazakov]

On 2017-09-03 13:01, Frank Buss wrote:
> What does this program output?

Garbage.

> with Ada.Sequential_IO;
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure Hello is
> 
>     type Byte is range 0..255;
> 
>     package Byte_IO is new Ada.Sequential_IO(Byte);

Ada.Streams.Stream_IO is for the purpose.

(Sequential_IO is practically never used)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: quiz for Sequential_IO Read

[Frank Buss]

On 09/03/2017 02:26 PM, Dmitry A. Kazakov wrote:
> On 2017-09-03 13:01, Frank Buss wrote:
>> What does this program output?
>
> Garbage.
>
>> with Ada.Sequential_IO;
>> with Ada.Text_IO; use Ada.Text_IO;
>>
>> procedure Hello is
>>
>>     type Byte is range 0..255;
>>
>>     package Byte_IO is new Ada.Sequential_IO(Byte);
>
> Ada.Streams.Stream_IO is for the purpose.
>
> (Sequential_IO is practically never used)

I started learning Ada today, where can I read about good coding 
practice, and how would the example look like with Stream_IO, and maybe 
even a correct version?

I read about Sequential_IO in the Ada Programming wikibook, where it is 
recommended for homogeneous binary data:

https://en.wikibooks.org/wiki/Ada_Programming/Input_Output

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Re: quiz for Sequential_IO Read

[Frank Buss]

On 09/03/2017 01:40 PM, Jeffrey R. Carter wrote:
> On 09/03/2017 01:01 PM, Frank Buss wrote:
>>     type Byte is range 0..255;
>
> Note that Byte is a signed type, so Byte'Base will have a range that
> includes -255

Why is it a signed type? The range says only 0..255, and in fact, I can 
write this:

type Byte is range 0..255; for Byte'Size use 8;

and it works as expected.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Re: quiz for Sequential_IO Read

[Dmitry A. Kazakov]

On 2017-09-03 14:43, Frank Buss wrote:
> On 09/03/2017 02:26 PM, Dmitry A. Kazakov wrote:
>> On 2017-09-03 13:01, Frank Buss wrote:
>>> What does this program output?
>>
>> Garbage.
>>
>>> with Ada.Sequential_IO;
>>> with Ada.Text_IO; use Ada.Text_IO;
>>>
>>> procedure Hello is
>>>
>>>     type Byte is range 0..255;
>>>
>>>     package Byte_IO is new Ada.Sequential_IO(Byte);
>>
>> Ada.Streams.Stream_IO is for the purpose.
>>
>> (Sequential_IO is practically never used)
> 
> I started learning Ada today,

Great!

> where can I read about good coding 
> practice, and how would the example look like with Stream_IO, and maybe 
> even a correct version?
> 
> I read about Sequential_IO in the Ada Programming wikibook, where it is 
> recommended for homogeneous binary data:
> 
> https://en.wikibooks.org/wiki/Ada_Programming/Input_Output

Well, Sequential_IO is not recommended because:

1. It would make your program non-portable;
2. It would hinder interoperability with programs written on other 
languages;
3. It requires homogeneous data, which is never the case in real life
4. It limits I/O to files

In practice Stream I/O is a better choice. You also should not use 
compiler-generated serialization attributes (see T'Read, T'Write, 
T'Input, T'Output attributes). These are not portable either. You should 
always replace them with your own.

P.S. Sequential_IO was introduced in Ada 83. A lot of things changed 
since then.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: quiz for Sequential_IO Read

[Jeffrey R. Carter]

On 09/03/2017 02:47 PM, Frank Buss wrote:
> 
> Why is it a signed type? The range says only 0..255, and in fact, I can write this:
> 
> type Byte is range 0..255; for Byte'Size use 8;
> 
> and it works as expected.

It's signed because the language definition says it's signed. All types declared 
with range are signed. See ARM 3.5.4

http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-3-5-4.html

for the gory details.

If you don't specify 'Size, then the compiler uses the 'Size for the base type. 
If you specify the size it will use that instead. Realistically, stand-alone 
objects will always use complete bytes to store a value, and Sequential_IO will 
read and write that number of bytes. So without a Size clause, Sequential_IO 
read 2 bytes, and with it, only 1.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: quiz for Sequential_IO Read

[AdaMagica]

Use type Byte is mod 256; which is an unsigned integer.

Dmitry's reasons not use Sequential_IO may be valid, but it will work here.

Re: quiz for Sequential_IO Read

[J-P. Rosen]

Le 03/09/2017 à 13:01, Frank Buss a écrit :
> The content of test.txt is just the ASCII string "hello":
If it is a text file, it is not appropriate for Sequential_IO which
requires a binary file.

In every language, the format of a binary file is known only to the
compiler (I remember having been warned about this when I learned
FORTRAN - a long time ago); the purpose of these files is to save data,
then reread them from the same program, or at least the same language
with the same compiler.

It may happen that the compiler just outputs the raw binary
representation, but you have absolutely no guarantee about that.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: quiz for Sequential_IO Read

[Frank Buss]

On 09/03/2017 07:28 PM, J-P. Rosen wrote:
> Le 03/09/2017 à 13:01, Frank Buss a écrit :
>> The content of test.txt is just the ASCII string "hello":
> If it is a text file, it is not appropriate for Sequential_IO which
> requires a binary file.

It was just an example, and I posted the binary content of the file for 
clarification as well.

> In every language, the format of a binary file is known only to the
> compiler (I remember having been warned about this when I learned
> FORTRAN - a long time ago); the purpose of these files is to save data,
> then reread them from the same program, or at least the same language
> with the same compiler.

This is nonsense. There are a lot of binary file specifications and of 
course it should be possible to read and write these files, independent 
of the programming language or the compiler. Imagine files like PNG 
would only work, if you write/read them with a program, which was 
compiled with exact the same compiler.

> It may happen that the compiler just outputs the raw binary
> representation, but you have absolutely no guarantee about that.

Any programming language implementation which doesn't provide exact 
binary input/output is unusable. It might be fine for some rare cases, 
where you need it only in the same program that the binary 
representation doesn't matter (e.g. temporary cache files etc.), but 
usually you want to have control over the format and you want to know 
the format.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Re: quiz for Sequential_IO Read

[Dennis Lee Bieber]

On Sun, 3 Sep 2017 19:28:14 +0200, "J-P. Rosen" <rosen@adalog.fr> declaimed
the following:

>Le 03/09/2017 à 13:01, Frank Buss a écrit :
>> The content of test.txt is just the ASCII string "hello":
>If it is a text file, it is not appropriate for Sequential_IO which
>requires a binary file.
>
>In every language, the format of a binary file is known only to the
>compiler (I remember having been warned about this when I learned
>FORTRAN - a long time ago); the purpose of these files is to save data,
>then reread them from the same program, or at least the same language
>with the same compiler.
>

	Record Management Services (RMS) were the common underlying record
handling system in the VMS operating system. It was responsible for
allowing practically any language on the system to read files created by
any other language. Whether fixed-length sequential, variable-length
sequential, direct access, and keyed access.

	Though I will admit that DEC F77 did complicate it somewhat by using a
segmented record scheme for the default -- in which, as I recall, the first
byte encoded a length and 1-bit first segment, 1-bit last segment indicator
(if both set, the segment is the entire record, neither set meant the
segment is intermediate).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: quiz for Sequential_IO Read

[J-P. Rosen]

Le 03/09/2017 à 22:10, Frank Buss a écrit :
>> In every language, the format of a binary file is known only to the
>> compiler (I remember having been warned about this when I learned
>> FORTRAN - a long time ago); the purpose of these files is to save data,
>> then reread them from the same program, or at least the same language
>> with the same compiler.
> 
> This is nonsense. There are a lot of binary file specifications and of
> course it should be possible to read and write these files, independent
> of the programming language or the compiler. Imagine files like PNG
> would only work, if you write/read them with a program, which was
> compiled with exact the same compiler.

I was talking about binary files defined by the language; if you use an
external binary file (like .PNG), you need to use streams, whose format
is well defined.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: quiz for Sequential_IO Read

[J-P. Rosen]

Le 03/09/2017 à 22:17, Dennis Lee Bieber a écrit :
>> In every language, the format of a binary file is known only to the
>> compiler (I remember having been warned about this when I learned
>> FORTRAN - a long time ago); the purpose of these files is to save data,
>> then reread them from the same program, or at least the same language
>> with the same compiler.
>>
> 	Record Management Services (RMS) were the common underlying record
> handling system in the VMS operating system. It was responsible for
> allowing practically any language on the system to read files created by
> any other language. Whether fixed-length sequential, variable-length
> sequential, direct access, and keyed access.

But in VMS, everything was standardized and compatible (sigh...).
However, a VMS binary file was not necessary compatible with a compiler
for a different OS.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: quiz for Sequential_IO Read

[Dmitry A. Kazakov]

On 03/09/2017 22:10, Frank Buss wrote:
> On 09/03/2017 07:28 PM, J-P. Rosen wrote:
>> Le 03/09/2017 à 13:01, Frank Buss a écrit :
>>> The content of test.txt is just the ASCII string "hello":
>> If it is a text file, it is not appropriate for Sequential_IO which
>> requires a binary file.
> 
> It was just an example, and I posted the binary content of the file for 
> clarification as well.
> 
>> In every language, the format of a binary file is known only to the
>> compiler (I remember having been warned about this when I learned
>> FORTRAN - a long time ago); the purpose of these files is to save data,
>> then reread them from the same program, or at least the same language
>> with the same compiler.
> 
> This is nonsense. There are a lot of binary file specifications and of 
> course it should be possible to read and write these files, independent 
> of the programming language or the compiler. Imagine files like PNG 
> would only work, if you write/read them with a program, which was 
> compiled with exact the same compiler.

That is not same. You can have OS/platform/application-specific format 
and you can have a universal one. Taking your example, imagine a JPEG 
file in place of PNG. Even if the object type is same (image) the binary 
format may be any.

Ada's implementation of sequential I/O is not required to be portable. 
An implementation is free to choose whatever it considers suitable. In 
must cases it would just be the memory representation, maybe, aligned to 
external storage elements margin. In terms of images, it is like storing 
image the way it is kept in the video memory.

>> It may happen that the compiler just outputs the raw binary
>> representation, but you have absolutely no guarantee about that.
> 
> Any programming language implementation which doesn't provide exact 
> binary input/output is unusable. It might be fine for some rare cases, 
> where you need it only in the same program that the binary 
> representation doesn't matter (e.g. temporary cache files etc.), but 
> usually you want to have control over the format and you want to know 
> the format.

That is the point. Ada has no control on whatever binary formats. So 
whatever representation it might mandate for sequential I/O that would 
not fit anyway. So a pragmatic decision was made not to require anything.

If you want to implement some specific format then stream I/O is the 
best available choice. You may still have issues on strange platforms 
where Stream_Element is not octet, but these are rare.

In days before stream I/O sequential I/O was used in a way that blocks 
of octets were the elements and the actual types were encoded into these 
blocks to make the format portable. That is not very different from how 
you would use stream I/O, but the latter is far more comfortable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: quiz for Sequential_IO Read

[Frank Buss]

On 09/03/2017 03:11 PM, Dmitry A. Kazakov wrote:
>
> In practice Stream I/O is a better choice. You also should not use
> compiler-generated serialization attributes (see T'Read, T'Write,
> T'Input, T'Output attributes). These are not portable either. You should
> always replace them with your own.

Ok, I wrote my program with Stream_IO. It will be reading from a FIFO 
file for receiving MIDI signals, and then write to a sound device 
continuously. I found a convenient package which defines low-level types 
of fixed size, same as stdint.h in C. See below for the code. Would this 
be portable on all systems (assuming they provide FIFO files) ? At least 
it works on my Debian system so far.


with Ada.Streams.Stream_IO; use Ada.Streams.Stream_IO;
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces; use Interfaces;

procedure Hello is

    Data : Unsigned_8;
    Input_File : Ada.Streams.Stream_IO.File_Type;
    Input_Stream : Ada.Streams.Stream_IO.Stream_Access;

    task Main_Task is
       entry Data_Received(Data : in Unsigned_8);
    end Main_Task;

    task body Main_Task is
    begin
       loop
          select
             accept Data_Received(Data : in Unsigned_8) do
                Put("test: " & Unsigned_8'Image(Data));
                New_Line;
             end Data_Received;
          else
             delay 0.1;
             -- TODO: create continuous sound output here
          end select;
       end loop;
    end Main_Task;

begin
    Open(Input_File, In_File, "/home/frank/midi");
    Input_Stream := Stream(Input_File);
    loop
       Unsigned_8'Read(Input_Stream, Data);
       Main_Task.Data_Received(Data);
    end loop;
end;


-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Re: quiz for Sequential_IO Read

[Dmitry A. Kazakov]

On 2017-09-04 21:58, Frank Buss wrote:
> On 09/03/2017 03:11 PM, Dmitry A. Kazakov wrote:
>>
>> In practice Stream I/O is a better choice. You also should not use
>> compiler-generated serialization attributes (see T'Read, T'Write,
>> T'Input, T'Output attributes). These are not portable either. You should
>> always replace them with your own.
> 
> Ok, I wrote my program with Stream_IO. It will be reading from a FIFO 
> file for receiving MIDI signals, and then write to a sound device 
> continuously. I found a convenient package which defines low-level types 
> of fixed size, same as stdint.h in C. See below for the code. Would this 
> be portable on all systems (assuming they provide FIFO files) ?

You probably mean a pipe here?

> At least 
> it works on my Debian system so far.
> 
> 
> with Ada.Streams.Stream_IO; use Ada.Streams.Stream_IO;
> with Ada.Text_IO; use Ada.Text_IO;
> with Interfaces; use Interfaces;
> 
> procedure Hello is
> 
>     Data : Unsigned_8;
>     Input_File : Ada.Streams.Stream_IO.File_Type;
>     Input_Stream : Ada.Streams.Stream_IO.Stream_Access;
> 
>     task Main_Task is
>        entry Data_Received(Data : in Unsigned_8);
>     end Main_Task;
> 
>     task body Main_Task is
>     begin
>        loop
>           select
>              accept Data_Received(Data : in Unsigned_8) do
>                 Put("test: " & Unsigned_8'Image(Data));
>                 New_Line;
>              end Data_Received;
>           else
>              delay 0.1;

To avoid biased time error you should use "delay until" instead:

    delay until Last_Time + 0.1;
    Last_Time := Last_Time + 0.1;

And it is not a good idea to pass each octet to the task. A better 
design is to have a FIFO (ring buffer) to be filled by one task and read 
by another. It can be the same task as well.

>              -- TODO: create continuous sound output here
>           end select;
>        end loop;
>     end Main_Task;
> 
> begin
>     Open(Input_File, In_File, "/home/frank/midi");
>     Input_Stream := Stream(Input_File);
>     loop
>        Unsigned_8'Read(Input_Stream, Data);

Then you can read stream by pieces rather element by element. E.g.

    Buffer : Stream_Element_Array (1..Buffer_Size);
    Last   : Stream_Element_OFfset;
    ...

    Input_Stream.Read (Buffer, Last); -- Read available data
                                      -- Buffer (1..Last) is
                                      -- the data read

If you have FIFO to communicate with the task. It also can server as 
the input buffer. And you will simply read into the space between 
In_Index of the FIFO and either the FIFO's end index or Out_Index - 1, 
assuming FIFO is a ring buffer. You can use slice to do this:

    FIFO      : Stream_Element_Array (1..Buffer_Size);
    In_Index  : Stream_Element_Offset := 1; -- The index to write at
    Out_Index : Stream_Element_Offset := 1; -- The index to get data at

    ...
    if In_Index < Out_Index then
       Input_Stream.Read (FIFO (In_Index..Out_Index - 1), Last);
       In_Index := Last + 1;
    else
       Input_Stream.Read (FIFO (In_Index..FIFO'Last), Last);
       if Last = FIFO'Last then -- wrap
          In_Index := FIFO'First;
       else
          In_Index := Last + 1;
       end if;
    end if;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: quiz for Sequential_IO Read

[Frank Buss]

On 09/04/2017 10:55 PM, Dmitry A. Kazakov wrote:
> On 2017-09-04 21:58, Frank Buss wrote:
>> Would this be portable on all systems (assuming they provide FIFO
>> files) ?
>
> You probably mean a pipe here?

No, I'm using a FIFO file, created like this in Linux:

mkfifo a=rw midi

I need this, because I use the program "amdidi" to receive data from the 
MIDI port.

It makes the whole process really easy, without the need for the Ada 
program to interface to any special sound driver library. With "amidi 
-l" you get a list of available MIDI interfaces, and then you can let it 
write data to the FIFO file like this:

amidi -p "hw:2,0,0" -r midi

Any other program can read from it, as if it were a normal file.

> And it is not a good idea to pass each octet to the task. A better
> design is to have a FIFO (ring buffer) to be filled by one task and read
> by another.

Thanks, this looks interesting for more data, like audio input. The MIDI 
input is just some piano key presses and rotary encoder changes, max a 
few bytes per seconds, depending on how fast I can play :-) so I think 
not that many messages that it would justify the more complicated usage 
of an Ada FIFO buffer.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Re: quiz for Sequential_IO Read

[Dennis Lee Bieber]

On Mon, 4 Sep 2017 23:51:55 +0200, Frank Buss <fb@frank-buss.de> declaimed
the following:

>On 09/04/2017 10:55 PM, Dmitry A. Kazakov wrote:
>> On 2017-09-04 21:58, Frank Buss wrote:
>>> Would this be portable on all systems (assuming they provide FIFO
>>> files) ?
>>
>> You probably mean a pipe here?
>
>No, I'm using a FIFO file, created like this in Linux:
>
>mkfifo a=rw midi
>
>I need this, because I use the program "amdidi" to receive data from the 
>MIDI port.
>

	Based on https://linux.die.net/man/3/mkfifo , there is very little
difference... Other entries from Google use the term "named pipe":
https://en.wikipedia.org/wiki/Named_pipe
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/