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.
I was surprised to see my repo mentioned! This is still very much a science project, but I was able to contribute some code upstream to the SPARKNaCl project to add one of the necessary ciphers for TLS 1.3. The other two can be supported without much effort, I think. I have a PR in (which needs some refactoring) to add the SHA384 hash algo which is required for one of the other TLS 1.3 cipher suites.
Being able to handle certificates means x509 and ASN.1 parsing needs to be present so I have another project SPARKx509 to try and support that. Certificate handling is an area where a lot of CVEs pop-up in OpenSSL so I think a verified library would be really valuable. Again, it’s very much still a science project. Like others here, I would love to have an end-to-end HTTP/S solution in pure Ada/SPARK.
I heard on a podcast of one company that got payed I assume a fair bit of money by facebook for spark x509/asn.1 parsing. I guess facebook never open sourced it. So good on you for doing this work and I hope that you get sponsored if you are looking for that.