Phobos Wish List/Next in Review Queue?

[Manu]

On 20 November 2011 05:02, dsimcha <dsimcha at yahoo.com> wrote:

> Now that we've got a lot of contributors to Phobos and many projects in
> the works, I decided to start a thread to help us make a rough plan for
> Phobos's short-to-medium term development.  There are three goals here:
>
> 1.  Determine what's next in the review queue after std.csv (voting on
> std.csv ends tonight, so **please vote**).
>
> 2.  Come up with a wish list of high-priority modules that Phobos is
> missing that would make D a substantially more attractive language than it
> is now.
>
> 3.  Figure out who's already working on what from the wish list and what
> bottlenecks, if any, are getting in the way and what can be done about them.
>
> The following is the wish list as I see it.  Please suggest additions and
> correct any errors, as this is mostly off the top of my head.  Also, status
> updates if you're working on any of these and anything substantial has
> changed would be appreciated.
>
> *  Some higher level networking support, such as HTTP, FTP, etc.  (Jonas
> Drewsen's CURL wrapper handles a lot of this and may be ready for a second
> round of review.)
>
> *  Serialization.  (Jacob Carolberg's Orange library might be a good
> candidate.  IIRC he said it's close to ready for review.)
>
> *  Encryption and hashing.  (This is more an implementation problem than a
> design problem and AFAIK noone is working on it.)
>
> *  Containers.  (AFAIK noone is working on this.  It's tough to get
> started because, despite lots of discussion at various times on this forum,
> noone seems to really know what they want.  Since the containers in
> question are well-known, it's much more a design problem than an
> implementation problem.)
>
> *  Allocators.  (I think Phobos desperately needs a segmented stack/region
> based allocator and I've written one.  I've also tried to define a generic
> allocator API, mostly following Andrei's suggestions, but I'll admit that I
> didn't really know what I was doing for the general API.  Andrei has
> suggested that allocators should have real-world testing on containers
> before being included in Phobos. Therefore, containers block allocators and
> if the same person doesn't write both, there will be a lot of communication
> overhead to make sure the designs are in sync.)
>
> *  Streams.  (Another item where the bottleneck is mostly at the design
> level and people not really knowing what they want.)
>
> *  Compression/archiving.  (Opening standard compressed/archived file
> formats needs to just work.  This includes at least zip, gzip, tar and
> bzip2.  Of course, zip already is available and gzip is supported by the
> zlib module but with a crufty C API.  At least gzip and bzip2, which are
> stream-based as opposed to file-based, should be handled via streams, which
> means that streams block compression/archiving.  Also, since tar and zip
> are both file based, they should probably be handled by the same API, which
> might mean deprecating std.zip and rewriting it.)
>
> *  An improved std.xml.  (I think Thomas Sowinski is working on a
> replacement, but I haven't seen any updates in a long time.)
>
> *  Matrices and linear algebra.  (Cristi Cobzarenco's GSoC project is a
> good starting point but it needs polish.  I've been in contact with him
> occasionally since GSoC ended and he indicated that he wants to get back to
> working on it but doesn't have time.  I've contributed to it sparingly, but
> find it difficult because I haven't gotten around to familiarizing myself
> with the implementation details yet, and it's hard to get into a project
> that complex with a few hours a week as opposed to focusing full time on
> it.)
>
> *  std.database.  (Apparently Steve Teale is working on this.  This is a
> large, complicated project because we're trying to define a common API for
> a variety of RDBMSs.  Again, it's more a design problem than an
> implementation problem.)
>
> *  Better support for creating processes/new std.process.  (Lars
> Kyllingstad wrote a replacement candidate for Posix and Steve Schveighoffer
> ported it to Windows, but issues with the DMC runtime prevent it from
> working on Windows.)
>
> *  Parallel algorithms.  (I've implemented a decent amount of these in my
> std.parallel_algorithm Github project, but I've become somewhat frustrated
> and unmotivated to finish this project because so many of the relevant
> algorithms seem memory bandwidth bound and aren't substantially faster when
> parallelized than when run serially.)
>
> After writing this, the general pattern I notice is that lots of stuff is
> blocked by design, not implementation.  In a lot of cases people don't
> really know what they want and analysis paralysis results.
>

As a console/embedded games developer, my top 4:

*Allocators* - +1 .. GC is lovely to have, but in many cases, I need strict
control over my memory management. Any libraries that use the GC internally
are potentially unusable to me in some applications.

*Low level/hardware vector-maths library* - This is kinda blocked by the
lack of support for an intrinsic vector type in the compiler... the
language needs at very least a 128bit vector type to express the registers
and make it possible to allocate them in structures, and pass them between
functions. Architecture specific compilers/libraries can then build on top
of that, and then ideally, a low level maths library in Phobos might
collate various architectures vector hardware support into a common API.
I would happily volunteer to to handle this, but I need at least a 128bit
hardware vector type in the language first (GDC has this though proprietary
extension, rather, the language should define a standard). I guess I could
design the API without it, but the library would only really work
efficiently on flavours of GCC.

*Crypto *- +1 as mentioned above, blocked on streams...

*Higher level maths/signal processing *- The linear algebra library
mentioned in a previous post might be very useful, but also standard
algorithms like fourier transforms. Library implementations of these would
be amazing, potentially making use of hardware back ends where possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111123/7e2ece5e/attachment-0001.html>