From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:e113:: with SMTP id c19mr1831621qkm.329.1621284490997; Mon, 17 May 2021 13:48:10 -0700 (PDT) X-Received: by 2002:a25:6d02:: with SMTP id i2mr2508161ybc.309.1621284490828; Mon, 17 May 2021 13:48:10 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 17 May 2021 13:48:10 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=99.10.228.144; posting-account=AgomvAoAAAAj6rtZlNDUf1S1XVXbXDpg NNTP-Posting-Host: 99.10.228.144 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <11979adf-d841-4b67-8693-567e6fe8bc55n@googlegroups.com> Subject: Re: Better way to fill Storage_IO? From: Michael Hardeman Injection-Date: Mon, 17 May 2021 20:48:10 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:62002 List-Id: On Monday, May 17, 2021 at 4:20:14 PM UTC-4, Dmitry A. Kazakov wrote: > On 2021-05-17 21:14, Simon Wright wrote: > > Michael Hardeman writes: > > > >> So I've been messing around with the new Ada 2020 package > >> Ada.Streams.Storage.Bounded/Unbounded; and if I'm understand it > >> correctly it allows you to treat your program's memory like a stream > >> without having to open file descriptors (which should make it > >> faster?). That seems like a powerful abstraction to me and a great > >> addition to the language. > 1. It was always possible, since Ada 95, actually. So it is not that > great addition. > > 2. The package as described is not a replacement for I/O, because it > lacks blocking/synchronization and because it does not work between > processes. E.g. at the end of the stream Read must rather block for an > incoming Write. Both are quite possible to implement though. > > A great addition would be properly tagged protected objects and tasks. A > blocking stream cannot support timed entry call syntax like this: > > select > S := String'Input (Pipe'Access); -- This is not Ada! > or delay 1.0; > raise Timed_Out; > end select; > > And note another problem. Entries do not work with indefinite objects. > You cannot return String from an entry call. > > And yet another problem, you cannot use returned objects in many places, > like in an entry call above. > >> I was wondering if we could find a better way to fill the stream other > >> than writing the variables into it? Can anyone figure out a good way > >> to just stream a variable's bytes directly? > Allocators, of course. I am using both allocators and memory-mapped > streams (though of a greater variety, e.g. for blocked exchange, > encryption, interporcess communication). > > This *is* the way to just stream the variable's bytes directly. What > > sort of syntax were you hoping for? > Both allocators and streams require explicit specification of the type. > Clearly, that is a way around multiple dispatch, but it is way too > heavy. Access to stream is no more necessary in 'Input. It was not > necessary when it was introduced in Ada 95. The Rosen's trick allows > circumvent in- parameter modes, when necessary. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Hey Dmitry, > Allocators, of course. I am using both allocators and memory-mapped > streams (though of a greater variety, e.g. for blocked exchange, > encryption, interporcess communication). Could you show me an example of how I could do this with allocators?