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.8 required=3.0 tests=BAYES_00,PLING_QUERY autolearn=no autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: 2dsa | !2dsa ? Date: Mon, 11 Jan 2021 22:46:20 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2fa5a097-a0a6-4614-b990-ee70b89ab470n@googlegroups.com> <6fbef6e7-2144-4636-88a6-fcdacc327c8cn@googlegroups.com> NNTP-Posting-Host: 5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:61102 List-Id: On 2021-01-11 21:35, Shark8 wrote: > On Monday, January 11, 2021 at 8:32:25 AM UTC-7, Dmitry A. Kazakov wrote: >> On 2021-01-11 15:59, Shark8 wrote: >>> On Thursday, December 24, 2020 at 6:30:59 AM UTC-7, Dmitry A. Kazakov wrote: >>>> On 2020-12-24 13:02, Maxim Reznik wrote: >>>>> I forked a older (Garlic) GNAT DSA implementation and found it quite hackable. :) >>>>> My idea is to implement a WebSocket/WebRTC transport and compile it by GNAT-LLVM to WebAssembly to have distributed Ada applications in a browser. I have a working proof of concept demo already :) >>>>> >>>>> https://github.com/reznikmm/garlic/tree/web_socket >>>> My question is how to proceed without GLADE/Garlic etc. I have DSA >>>> implemented, e.g. System.RPC. I need GNAT to accept it as such. >>> What do you mean by this? >>> How is GNAT "not accepting" it? >> It does not invoke the provided DSA implementation for remote calls. > This is a dumb question, but did you remember to recompile the run-time library? No. Why should I? > https://www.cs.fsu.edu/~baker/ada/gnat/html/gnat_ugn_20.html#SEC230 > (I'm pretty sure you'd have to, to get a change into DSA behavior.) Do you mean that other implementations rebuild all RTL? That is a mess. Is it possible to fool GNAT using linker instead of breaking everything? >>> More, you mentioned the possibility of using a set of tagged-types, "like Storage_Pool", elsethread; is this how you implemented them, or a suggestion for a new standard interface? >> It was a suggestion. The current way is System.RPC see ARM E.5. It seems >> that merely replacing it is not enough for GNAT. > Given "The package System.RPC is a language-defined interface to the PCS" it seems like that there are two readings: > (1) System.RPC defines the forms with which remote-calls are done, and/or > (2) implements the actual communications. > As it is written, I would think that #1 is the proper interpretation, if this is the case than recompiling System.RPC is "mucking about with the interface" and not much else. My understanding is that the Do_RPC gets called with the parameters of the call written into the Params stream including the target function name. Then you do communication with the remote host associated with the Partition parameter. The communication basically reads the Params stream and sends read stuff to the other side. Then you sit and wait for the remote host to respond. If the response was success, you write its payload into the Result stream. If the response indicates remote exception you re-raise it locally. BTW, there is a lot of overhead there. The design support streams being actual communication streams. But for that, the partition would be set into the stream prior calling to the first Write. Furthermore, it is to tightly coupled. There is no indications where parameters start and end in the stream. The remote host needs to be able to say "cut that, I do not receive this call anyway", "I cannot parse parameters for this function" etc. >>>> In a more distant perspective I need a work-around of stream attributes. >>>> They are non-portable, so there must an option to replace them for DSA >>>> and/or provide a non-stream parameter marshaling when the transport is a >>>> higher-level protocol, e.g. CANopen, EtherCAT, ASN.1, AMQP etc. For >>>> these you must map Ada types into the types defined by the protocol. >>> I have some ideas on how this could be achieved. >>> I'll make a note for my To-Do list on Byron, but I was thinking that a good method to achieve this for an OS (WRT ASN.1) would be to have at the base a SOM-like system with the base meta-object having a serialize/deserialize pair of methods (with one parameter being the encoding scheme)... >> The problem is that >> >> 1. They must doubly dispatch on the object type and on the container >> type, since there could be any number of containers = encoding/decoding >> schema. > Why? > You could have the encoding/decoding method as a parameter. A scalar value is not enough. For one you need to enumerate all possible methods to build a case statement on them, which you cannot do as implementation must be located in different libraries. Then you need some context to encode/decode referential types. Imagine a parameter containing an access type, e.g. a node of a linked list. You cannot deep-copy everything with an infinite recursion on top. >> 2. They must support chunking. E.g. deserialize cannot be a function. > Why? Because it will block waiting all data read. So you will need an extra task for each transfer in order to accumulate all chuncks. >> This will get you a whole bunch of nasty problems with partial >> serialization and indefinite types. [I do not see these resolved without >> properly done constructors and co-routines.] > I don't see why the partial-serialization is a problem: if you have some type's value to serialize, you're already constrained. > If you're reading from a stream to initialize/reconstruct a type-value, then you're doing X'Stream'Input, right? Remember, it does not block. So when you call X'Stream'Input you may get 0 stream elements read at any point. E.g. you read a 4-octet Integer. You get only two octets, because the other two are not here. You cannot return Integer, it is not yet constructed. You cannot wait, because you are in the callback from the reader task. You must remember the state of partial deserialization and pass control back to the reader. This is what a co-routines are. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de