* quiz for Sequential_IO Read @ 2017-09-03 11:01 Frank Buss 2017-09-03 11:40 ` Jeffrey R. Carter ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Frank Buss @ 2017-09-03 11:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 11:01 quiz for Sequential_IO Read Frank Buss @ 2017-09-03 11:40 ` Jeffrey R. Carter 2017-09-03 12:47 ` Frank Buss 2017-09-03 12:26 ` Dmitry A. Kazakov 2017-09-03 17:28 ` J-P. Rosen 2 siblings, 1 reply; 18+ messages in thread From: Jeffrey R. Carter @ 2017-09-03 11:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 11:40 ` Jeffrey R. Carter @ 2017-09-03 12:47 ` Frank Buss 2017-09-03 13:44 ` Jeffrey R. Carter 0 siblings, 1 reply; 18+ messages in thread From: Frank Buss @ 2017-09-03 12:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 12:47 ` Frank Buss @ 2017-09-03 13:44 ` Jeffrey R. Carter 2017-09-03 15:38 ` AdaMagica 0 siblings, 1 reply; 18+ messages in thread From: Jeffrey R. Carter @ 2017-09-03 13:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 13:44 ` Jeffrey R. Carter @ 2017-09-03 15:38 ` AdaMagica 0 siblings, 0 replies; 18+ messages in thread From: AdaMagica @ 2017-09-03 15:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 11:01 quiz for Sequential_IO Read Frank Buss 2017-09-03 11:40 ` Jeffrey R. Carter @ 2017-09-03 12:26 ` Dmitry A. Kazakov 2017-09-03 12:43 ` Frank Buss 2017-09-03 17:28 ` J-P. Rosen 2 siblings, 1 reply; 18+ messages in thread From: Dmitry A. Kazakov @ 2017-09-03 12:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 12:26 ` Dmitry A. Kazakov @ 2017-09-03 12:43 ` Frank Buss 2017-09-03 13:11 ` Dmitry A. Kazakov 0 siblings, 1 reply; 18+ messages in thread From: Frank Buss @ 2017-09-03 12:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 12:43 ` Frank Buss @ 2017-09-03 13:11 ` Dmitry A. Kazakov 2017-09-04 19:58 ` Frank Buss 0 siblings, 1 reply; 18+ messages in thread From: Dmitry A. Kazakov @ 2017-09-03 13:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 13:11 ` Dmitry A. Kazakov @ 2017-09-04 19:58 ` Frank Buss 2017-09-04 20:55 ` Dmitry A. Kazakov 0 siblings, 1 reply; 18+ messages in thread From: Frank Buss @ 2017-09-04 19:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-04 19:58 ` Frank Buss @ 2017-09-04 20:55 ` Dmitry A. Kazakov 2017-09-04 21:51 ` Frank Buss 0 siblings, 1 reply; 18+ messages in thread From: Dmitry A. Kazakov @ 2017-09-04 20:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-04 20:55 ` Dmitry A. Kazakov @ 2017-09-04 21:51 ` Frank Buss 2017-09-05 1:54 ` Dennis Lee Bieber 0 siblings, 1 reply; 18+ messages in thread From: Frank Buss @ 2017-09-04 21:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-04 21:51 ` Frank Buss @ 2017-09-05 1:54 ` Dennis Lee Bieber 0 siblings, 0 replies; 18+ messages in thread From: Dennis Lee Bieber @ 2017-09-05 1:54 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 11:01 quiz for Sequential_IO Read Frank Buss 2017-09-03 11:40 ` Jeffrey R. Carter 2017-09-03 12:26 ` Dmitry A. Kazakov @ 2017-09-03 17:28 ` J-P. Rosen 2017-09-03 20:10 ` Frank Buss 2017-09-03 20:17 ` Dennis Lee Bieber 2 siblings, 2 replies; 18+ messages in thread From: J-P. Rosen @ 2017-09-03 17:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 17:28 ` J-P. Rosen @ 2017-09-03 20:10 ` Frank Buss 2017-09-04 5:12 ` J-P. Rosen 2017-09-04 7:37 ` Dmitry A. Kazakov 2017-09-03 20:17 ` Dennis Lee Bieber 1 sibling, 2 replies; 18+ messages in thread From: Frank Buss @ 2017-09-03 20:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 20:10 ` Frank Buss @ 2017-09-04 5:12 ` J-P. Rosen 2017-09-04 7:37 ` Dmitry A. Kazakov 1 sibling, 0 replies; 18+ messages in thread From: J-P. Rosen @ 2017-09-04 5:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 20:10 ` Frank Buss 2017-09-04 5:12 ` J-P. Rosen @ 2017-09-04 7:37 ` Dmitry A. Kazakov 1 sibling, 0 replies; 18+ messages in thread From: Dmitry A. Kazakov @ 2017-09-04 7:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 17:28 ` J-P. Rosen 2017-09-03 20:10 ` Frank Buss @ 2017-09-03 20:17 ` Dennis Lee Bieber 2017-09-04 5:14 ` J-P. Rosen 1 sibling, 1 reply; 18+ messages in thread From: Dennis Lee Bieber @ 2017-09-03 20:17 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: quiz for Sequential_IO Read 2017-09-03 20:17 ` Dennis Lee Bieber @ 2017-09-04 5:14 ` J-P. Rosen 0 siblings, 0 replies; 18+ messages in thread From: J-P. Rosen @ 2017-09-04 5:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-09-05 1:54 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-03 11:01 quiz for Sequential_IO Read Frank Buss 2017-09-03 11:40 ` Jeffrey R. Carter 2017-09-03 12:47 ` Frank Buss 2017-09-03 13:44 ` Jeffrey R. Carter 2017-09-03 15:38 ` AdaMagica 2017-09-03 12:26 ` Dmitry A. Kazakov 2017-09-03 12:43 ` Frank Buss 2017-09-03 13:11 ` Dmitry A. Kazakov 2017-09-04 19:58 ` Frank Buss 2017-09-04 20:55 ` Dmitry A. Kazakov 2017-09-04 21:51 ` Frank Buss 2017-09-05 1:54 ` Dennis Lee Bieber 2017-09-03 17:28 ` J-P. Rosen 2017-09-03 20:10 ` Frank Buss 2017-09-04 5:12 ` J-P. Rosen 2017-09-04 7:37 ` Dmitry A. Kazakov 2017-09-03 20:17 ` Dennis Lee Bieber 2017-09-04 5:14 ` J-P. Rosen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox