Jonathan M Davis wrote:
I think that it would be useful to query the community for what piece of
library functionality they don't currently have in D and would most like to
see. For instance, there is no official logging framework in D or any 3rd party
libraries which do it AFAIK. So, that could be one type of functionality that
you may like to see. Now, there is a prospective implementation for std.log
which shouldn't be all that far away from being reviewed, so listing that here
wouldn't be all that useful, since it's on its way. But what other major
functionality do you miss in D that other languages' that you use have
available in their libraries?
My hope here would be that we could get some good ideas going here such that
we have can have a better idea what type of functionality it would be
particularly useful to be working on for Phobos or 3rd party D libraries for
the community, and maybe it'll even get some people to actually go and work on
these ideas so that we can improve the libraries that we have to work with in
D. We can always use more help, and we definitely need a richer library
ecosystem for D. But even just discussing ideas could be of benefit.
So, what major functionality which we don't currently have would you like to
see in either Phobos or in a 3rd party library so that you could use it in
your D programs?
- Jonathan M Davis
1. Cryptography (I already wrote all SHA hash implementations and HMAC,
they will be open sourced under Boost license, I'm also working on
Rijndael/AES impl.)
some of the proposed namespaces (just thinking loud):
std.crypto.cipher - block and stream ciphers
std.crypto.hash - message digests (SHA1, RIPEMD, ...)
std.crypto.mac - message auth codes like HMAC, CMAC, UMAC
std.crypto.mode - block cipher modes like CBC, GCM, ...
std.crypto.padding - padding schemes
std.crypto.pki - asymmetric cryptography (RSA), PKI
std.crypto.x509 - certificate support
2. Easy to use non-GC threads for soft real time support. Non-GC threads
must not be suspended by the GC and they must support some kind of
reliable communication with normal (GC) threads. This should be similar
to IPC, where there's no shared memory between GC and non-GC threads.
Consider running two separate programs, one written in D with GC support
and one written in plain C. These programs communicate with each other
using some IPC mechanism. The latter is never suspended.
The whole point is to make equivalent of this configuration in a single
executable using mixture of GC and non-GC threads.
