I don’t know which of these might exist, I have some parts of these in progress. Most of what I do in Ada is desktop applications and tools, not embedded, but that doesn’t seem to be a category of software that the community is very interested in.
Backing for memory allocators (stack, page allocator w/ mmap, etc.)
Scope-based files (controlled-type files), that close when they go out of scope
Smart pointers - (atomic/non-atomic) reference counted, something analogous to std::unique_ptr
Memory mapped loading of files
Monitoring files for changes
“Is this file binary?” - e.g. Examine first 4 KiB of a file for a null byte
UTF-8 helpers to operate on String types - painful especially is grapheme cluster iteration. A lot of tools use UTF-8 or ASCII so I don’t want to move over to Wide_String or Wide_Wide_String.
That would be fantastic especially it it is more portable than AWS that needs some tweaks to compile on OpenBSD. I haven’t tried AWS yet but it’s API looks quite nice. Maybe nicer than Go’s.
Edit: I have changed my mind. I do not need tasking on a microcontroller. A podcast got me thinking I should use them but thinking it through. I have never needed them on a single core and IMO they may actually be detrimental in that case. After all, you should avoid coroutines on Go unless really needed for multicore.
I wonder as an alternative to depending on OpenSSL or LibreSSL. Whether there is any possibiity of wrapping Gos web server into an API that Ada code can use directly, then you would get Gos ASN parsing. Http2/3 etc. that Google are spending considerable dollars? Though perhaps that is just part of BoringSSL. I am unsure. I know LibreSSL took some inspiration from Gos ASN parsing.
Additionally a simple http web server might be useful where end to end crypto can be used like the Spark NACL library and potentially where the Go server is too large?
This might be not what you’re seeking, but besides AWS, you also have EWS and one I recently stumbled upon, ash. Both are server-only, according to the documentation. There are also two libraries based on curl: CurlAda and ada-util (among other stuff).
With stack allocation of Real_Vector ( 1 … N ) when N >= 100,000 I get STACK_OVERFLOW ERROR while trying to check how fast operator overloading is working for an expression
X := A + B + C + C + A + B, where
A,B,C,X are all Real_Vector ( 1 … N ).
So my only option was to allocate on the heap using new. But then I lost the clean syntax
This is really not a tool for linear algebra algorithms implementation that rely heavily on matrix vector products and vector updates. There you do need to allocate on the heap (sizes are determined in runtime) and you do need a clean syntax, for promoting readability. Renaming A.all can help restoring the syntax. But it is clear that another Math library is needed.
An up-to-date Audio library would be nice. I know we have ASFML, but other langauges have a lot more like FMOD, BASS, SFML etc.I know media is not really an avenue Ada/SPARK is aimed at, but personally I feel it’s an excellent language to create something like a video game in. It’s never going to be that popular in that area, but it’s certainly just as powerful as C++ is, and in some areas, better.
I am sure these web servers are fine for my purposes. I was kind of thinking that it would be great for Ada popularity if there was a simple web server and ip stack in Adas stdlib. Go certainly and I think Rust describe themselves as batteries included. Though I guess that is out of scope of this wish list and quite a task especially if the horrid ipv6 is desired.
I would love to see more zfp compatible libraries without protected types. A SPARK container package that utilises it’s new borrowing and leak protection is bound to turn up and would be great, especially if it could handle unconstrained types.
Maybe, even though it uses Ada.Streams which isn’t available on ARM_elf.
Probably Rust and Go use OS support for their stdlib and their httpd and IP and TLS won’t run everywhere either. So maybe zfp compatibility is a no go. I know Go uses boringSSL, akin to AWS. Though RedHat stupidly tried to push OpenSSL onto Go for FIPS support. So FIPS was causing less secure systems until FIPS support was added to BoringSSL.
This doesn’t bother me, because I’m accustomed to writing every library I need by myself, just as in Common Lisp.
I’d be willing to wager that there will never be a suitable HTTP library in Ada, because of the absurd requirements TLS imposes; it’s simply too complicated and changes too often. There’s no point in having an Ada library subject to the same C language flaws as anything else, which is the obvious result of using a C language TLS library.
This reads like something Python would have, and it seems simple enough to write oneself.
I think having those things in separate libraries is fine. I’ve mostly finished a UDP library, and I’m working on a TCP library. I’ll link to them if anyone’s interested.
I outlined how these would work once, on c.l.a. IIRC. Of course, it depends on if you want text, homogeneous binary, or heterogeneous binary. I’ll look into implementing one to see if people use it.
I‘d be interested. You’re using GNAT.Sockets as a base? (I‘m about to start writing a port scanner for the fun of it; that’s one of the codingchallenges.fyi…)
No. I wrote a binding for POSIX Sockets and then wrote a decent library over that. It’s finished, but I’m considering adding non-blocking versions of the Get procedures. Considering that only one UDP System_Resource will be needed for most programs, and because I’m to understand that blocking will only affect the task using the procedures in a program with multiple tasks, it’s not particularly important to have such non-blocking versions. Here are the links: The Usable Datagram Package Ada Library An Ada UDP POSIX Sockets Binding
I’m particularly pleased with my design using controlled types, avoiding any explicit initialization. Unfortunately, I’m not certain if I’ll be able to get such a clean design with TCP. There only needs to be one UDP library, for either end of the connection, but TCP drives a wedge between server and client design; I plan to have two child packages, with the client package having all functionality relating to using TCP connections, and the server package having a TCP connection generator producing connections usable with the other package. I’m uncertain if I can get such a clean design to work, however.