A few weeks ago I made a github repo for D modules. I'm adding to this as I learn the language, and as I find myself writing modules to support other code.

https://github.com/pineapplemachine/mach.d

It hasn't got a lot at the moment, but it will grow for as long as I'm writing D. I suspect that will be a rather long time.

Currently contains such modules as:

mach.error.unit - Provides a better alternative to littering unittest blocks with "assert"s where if an assert fails there's no information regarding why. assert(a == b); vs. testeq(a, b);

mach.math.round - Accepts templates for source and target numeric types.

mach.text.english.plural - Reasonably accurate pluralization of English words.

My focus currently is on developing mach.sdl, a wrapper for SDL2 and OpenGL, since ultimately I'd like to use D primarily for game development.

I hope the library proves useful!

On Wednesday, 25 May 2016 at 20:31:34 UTC, pineapple wrote:
> A few weeks ago I made a github repo for D modules. I'm adding to this as I learn the language, and as I find myself writing modules to support other code.
>
> https://github.com/pineapplemachine/mach.d
>
> It hasn't got a lot at the moment, but it will grow for as long as I'm writing D. I suspect that will be a rather long time.
>
> Currently contains such modules as:
>
> mach.error.unit - Provides a better alternative to littering unittest blocks with "assert"s where if an assert fails there's no information regarding why. assert(a == b); vs. testeq(a, b);
>
> mach.math.round - Accepts templates for source and target numeric types.
>
> mach.text.english.plural - Reasonably accurate pluralization of English words.
>
> My focus currently is on developing mach.sdl, a wrapper for SDL2 and OpenGL, since ultimately I'd like to use D primarily for game development.
>
> I hope the library proves useful!

That's great news!

A bit off-topic, but I can't help to say it.
I know that writing your own library is fun, but something that I see quite often when looking at e.g.

https://github.com/adamdruppe/arsd
https://github.com/CyberShadow/ae
https://github.com/nordlow/phobos-next

is that people love to collect and build their own ecosystem, but it would be a lot better if for a specific use-case there's a great dub package or it's part of Phobos.

mach.error.unit
-> http://code.dlang.org/packages/unit-threaded

mach.math.round
-> sounds like a feature that could be useful for everyone. How about making a PR to Phobos?

...

On Wednesday, 25 May 2016 at 22:19:28 UTC, Seb wrote:
> I know that writing your own library is fun, but something that I see quite often when looking at e.g.

Yep, I saw a couple of those before I got started on mine. For some of us it's a sense of ownership, I think. It feels good to be building projects on top of code I wrote myself.

> mach.error.unit
> -> http://code.dlang.org/packages/unit-threaded

Actually, my module isn't a unittest framework - though I intend to take a shot at one of those, too, at some point. Instead it's a substitute for "assert" everywhere that results in more descriptive errors in case of failure.

For example, this is one way to indicate that some group of not-asserts are testing the same general subject:

    tests("Some feature", {
        ...
    });

And when you do something like this -

    testeq("not", "equal");

You get an error message like this -

    mach.error.unit.TestFailureError@E:\Dropbox\Projects\d\mach\error\unit.d(215): Values must be equal not and equal

Which you can further customize -

    testeq("This is an example and should always fail.", "not", "equal");

Resulting in this -

    mach.error.unit.TestFailureError@E:\Dropbox\Projects\d\mach\error\unit.d(215): This is an example and should always fail. not and equal

And you can also do some cool stuff like this -

    fail(
        "Catch a TestFailureError",
        (caught) => (cast(TestFailureError) caught !is null),
        {testeq("not", "equal");}
    );

> mach.math.round
> -> sounds like a feature that could be useful for everyone. How about making a PR to Phobos?
>
> ...

I will do that

On Wednesday, 25 May 2016 at 22:29:38 UTC, pineapple wrote:
> I will do that

...I'm honestly having second thoughts because reading the style guide for phobos was like a watching a B horror movie.

All the code in the mach.d repo is very permissively licensed and anyone with the patience to write code that looks like this is absolutely free to morph my pretty code into ugly phobos code if they like, provided the license is adhered to (which can be pretty effectively summed up as "please just give credit where it's due")

On Wednesday, 25 May 2016 at 22:19:28 UTC, Seb wrote:
> is that people love to collect and build their own ecosystem, but it would be a lot better if for a specific use-case there's a great dub package or it's part of Phobos.

I, and I'm pretty sure Vladimir too, have been writing these libs since looooong before dub was conceived and even before anybody took Phobos seriously.

On Wednesday, 25 May 2016 at 20:31:34 UTC, pineapple wrote:
> clip
>
> My focus currently is on developing mach.sdl, a wrapper for SDL2 and OpenGL, since ultimately I'd like to use D primarily for game development.
>
> I hope the library proves useful!

Hey, have you looked at:  http://dgame-dev.de/

On Wednesday, 25 May 2016 at 22:52:44 UTC, Adam D. Ruppe wrote:
> On Wednesday, 25 May 2016 at 22:19:28 UTC, Seb wrote:
>> is that people love to collect and build their own ecosystem, but it would be a lot better if for a specific use-case there's a great dub package or it's part of Phobos.
>
> I, and I'm pretty sure Vladimir too, have been writing these libs since looooong before dub was conceived and even before anybody took Phobos seriously.

Yes, and they are great. However now we have dub and a "serious" standard library  ;-)

On Wednesday, 25 May 2016 at 23:21:09 UTC, Seb wrote:
> On Wednesday, 25 May 2016 at 22:52:44 UTC, Adam D. Ruppe wrote:
>> On Wednesday, 25 May 2016 at 22:19:28 UTC, Seb wrote:
>>> is that people love to collect and build their own ecosystem, but it would be a lot better if for a specific use-case there's a great dub package or it's part of Phobos.
>>
>> I, and I'm pretty sure Vladimir too, have been writing these libs since looooong before dub was conceived and even before anybody took Phobos seriously.
>
> Yes, and they are great. However now we have dub and a "serious" standard library  ;-)

It's really easy to use Adam's libraries. You copy a single file into the directory, add an import to your program, and you're done. With Dub you're fiddling around with config files using a format that's not even properly documented. It's fine if you like Dub, the nice thing about open source is choice, but I wish the constant push to get everything into Dub would end.

On Wednesday, 25 May 2016 at 23:21:09 UTC, Seb wrote:
> Yes, and they are great. However now we have dub and a "serious" standard library  ;-)

I've looked into two options to join the dub bandwagon, and both aren't really any good (and the fact that I don't use it myself means it'd probably be unmaintained anyway):

1) subpackages. I have this right now for some of the modules, but it doesn't work very well because I can't version the subpackages independently of the main package, and it adds a fair chunk of overhead writing those json definitions and git tags.

2) full-blown packages... I'd have to create an individual folder hierarchy (probably like 3 directories per one file!) and git repo, along with a dub.json, for each one of my items. Using hard links, I could maintain compatibility with my existing repo and dev setup, so it might not be extremely horrid in the long run.... but still, creating and maintaining like 35 repos (I have 37 public, documented modules right now, most of which can stand alone) isn't my idea of a good time.

The advantage though is I could actually use dub's versioning scheme.

The disadvantage is all the configuration stuff for optional dependencies would be a pain. Currently, if you use dom.d's UTF-8 functions, the module just works, standalone, no dependencies.

If you call one of the encoding translation functions though, it now depends on characterencodings.d, thanks to a lazy import. I really like that! D rox on its own.

On Wednesday, 25 May 2016 at 22:19:28 UTC, Seb wrote:
> A bit off-topic, but I can't help to say it.
> I know that writing your own library is fun, but something that I see quite often when looking at e.g.
>
> https://github.com/adamdruppe/arsd
> https://github.com/CyberShadow/ae
> https://github.com/nordlow/phobos-next
>
> is that people love to collect and build their own ecosystem, but it would be a lot better if for a specific use-case there's a great dub package or it's part of Phobos.

At least for me, here are the main motivators:

1. Trivia. There are a lot of one-liners in ae which although used often and make the code somewhat more readable, would not be suitable for Phobos because you can think of any number of them.

2. Very often I put a function in ae not because I know I'll need it again, but simply because it seems generic enough that it would better belong in a generic library than the specific program I'm writing. This of course leads to functions that are used only once. Sometimes (rarely) I realize that I don't need that function after all, so some functions probably have never been used.

3. Commitment. Making your library for general consumption means proper versioning, upgrade paths and things like that. It's an additional mental burden on top of getting the thing you want done done.

That said I did add a dub.sdl file to ae a while ago.