I created a repository and pushed files I have. GitHub - dmitry-kazakov/Interprocess-DSA: A distributed system annex for interprocess communication.
Nothing is tested because GNAT ignores System.RPC. So far it has the RPC implementation. Shared objects are to be seen. The interprocess communication has shared objects. A way to make GNAT aware of is to be seen.
I’ve cloned and look into your code a little. I haven’t been able to test any of it since I’m having trouble installing Simple_Components on my Arch system. Would it be possible for you to provide some instructions on how to build/install Simple_Components from source, perhaps in it’s README ?
One thing I can tell you is that ‘test_dsa_server_interface.ads’ is not needed (and should be removed). It has no body, which explains that error that it could not be compiled, which you were getting. It is identical to ‘test_dsa_server.ads’, whose spec is your real remote ‘interface’ (ie contains the subprograms which other partitions may call and which will be executed within your test_dsa_server partition.
I hope that clears up at least one issue. If I can get Simple_Components built/installed on Arch properly, I’ll hopefully be of more help.
Regards.
There is no installation. Just download the archive unpack it in the directory where other files are, that is. For Linux you need to set the project scenario variables like:
gprbuild -XTarget_OS=Linux …
You can also change the defaults in the file strings_edit.gpr.
How the compiler would know which subprograms are remote on the client side?
This is the server side where these subprograms are local.
P.S. I can invite you to the repository if you want.
Offtopic. I packaged the simple components for DEB and RPM and maintain repositories of, but did not do that for Arc. The instructions how to build a pacman package and the repository are very confusing to me. If you or anybody else have experience with, please, post a how-to. I think it would be interesting for many.
Ok, thanks, I’ll try this.
All subprograms in an RCI package are remote.
Yes, they are local to the server side, so if test_dsa_server_main were to call one, it would be a normal call as in any ada program. If one were to be called from test_dsa_client, any parameters would be marshaled on the client side, sent through the PCS to the server, have parameters un-marshaled and then the server-side would call the actual subprogram, with those parameters. Any ‘out’ params or function result or exception would then be sent back through the PCS to the client (with the usual marshaling/un-marshaling).
I realise that is probably not very clear. The polyorb user guide goes into great detail on nearly every aspect of DSA, and is much clearer than I can be. It is quite large but well worth the read (and indeed a second read, if all doesn’t make sense at 1st). You can find it here.
That would be very helpful. I can make some changes in a branch and hopefully make things a little clearer.
I maintain most of the Ada packages on Arch, so have some experience. In fact I added a package for your components a year or so ago … Here it is. You can view the PKGBUILD in the top right hand side. The package built and installed ok but I’ve not tested it til this morning and hit many cases of …
components.gpr:6:18: unit “generic_chebyshev_polynomials” cannot belong to several projects
components.gpr:6:18: project “components”, “/usr/include/kazakov/generic_chebyshev_polynomials.ads”
components.gpr:6:18: project “strings_edit”, “/usr/include/kazakov/generic_chebyshev_polynomials.ads”
… and many similar. So i’ve muffed the install somehow. I did update the version to the latest and added Target_OS=Linux scenario variable. Anyways, I’ll take another look tomorrow, if I can. Doing home renovations atm, and spent 4..5 hours of hard physical manual labour today. Made me recall why I went into software and not become a builder 
.
Great! I will take a look. Have you an Ada Arch policy document? I mean under Fedora and Debian there are specific directories where Ada *.gpr, *.ads, *.ali, *.a, *.so, documentation, tests must go. Packages are subdivided into
Then what about the repository? Where the package must be submitted? E.g. for Fedora/CentOS and Debian/Ubuntu I have my own repository.
What?
You’re smart, so I refuse to believe that you’re an idiot, incapable of understanding what I said.
No, it’s not ‘hacking’. It’s providing an implementation, within he compilation, of the DSA.
There’s no “hacking” needed, just an override for the default if there is an operation provided.
Done!
If anybody else is interested in the collaboration, please let me know.
Just on a totally useless side note, isn’t it cute how all the required files still follow the 8.3 file naming convention?
It’s bit more onerous than that even. GNAT requires that naming convention for the RTS (or at least it did 4 ish years ago, haven’t tested since then). I actually made an RTS using the more modern GNAT filename format and GNAT wouldn’t recognize it until I changed all the filenames that I called publicly into the krunch format.
Hopefully they have moved away from that requirement now or at least would consider it for the future.
8.3 is for vms (and older for dos).
What? No, even the older VMS has a filename+extension length of 39 (see here), with the new one being ay least 118 characters (depending on how many extended characters there are [eg UTF-8 encoding]).
I remember someone saying years ago it was also for vms.
Not as such. gpr’s usually go in ‘/usr/share/gpr’. Source files usually go in their own dir under ‘/usr/include’. *.ali, *.a, *.so go in their own dir under ‘/usr/lib’. Docs go in their own dir under ‘/usr/share/doc’. Tests/examples go under ‘/usr/share/examples’.
PKGBUILD’s go into the Arch User Repository (AUR). Users can also add their own pre-built packages to the users maintained unofficial repo such as these.
Sorry for the delay. I have a weeks more home renovations to help get done and then will be able to spend more time on the topic/project.
Thanks, I will package my stuff for Arch. One more question it seems that Arch consistently conflates run-time and developing packages. Normally you would have a run-time package xxx that contains only libxxx.so.n.m. and a link to libxxx.so to. Then the package xxx-devel would have the static library and includes (*.ali, *.ads, *.adb, *.gpr). It seems that most Arch packages simply do not do that. Is there a reason?
Take a look at GitHub - reznikmm/dsa_fs: Ada Distribution System Annex from scratch
I hope I’ll add server stub description latter and customize System.Partition_Interface package.
If there is a reason, then I don’t know it 
.
They do have *-debug packages which contain (and provide ‘automatically’) debug symbols and source lines to tools like GDB. I’m not certain of the exact mechanism but they appear to be auto-generated from existing packages PKGBUILD’s, if the ‘debug’ option is specified. I think ‘debuginfod’ is used by gdb to load the debug-enabled libs when gdb first starts up the program being debugged.
This, of course, isn’t quite what you were asking tho.
This looks great Max. Thanks very much.
I guess they strip the debug info from the binary and pack it into the debug package.
Yep, because normally when you deploy a project you need only the relocatable libraries.
P.S. Arch Linux leaves strange impression. In comparison to Debian, Fedora and their derivatives it has poor documentation, lacks proper installer, kind of hobby project. I wonder why it is so popular.
A bit out of topic, but I think I can answer this. Arch is meant to be “minimal” in the sense of number of packages, and then the rest are either installed by the package manager or compiled by the user (either manually or AUR). For that reason, the packages that are distributed come with all the files: runtime, executables, development, docs, etc. This is unlike other distros which tend to subpackage them. So in order to use or develop with a package, you just install a single package and you are done.
Whether this is something you or other people may like, it is up to you. I am nowadays using OpenSUSE Tumbleweed/Kalpa, but I ran Arch and its derivatives for years.
Best regards,
Fer