www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Introducing mach.d, the github repo where I put whatever modules I

reply pineapple <meapineapple gmail.com> writes:
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!
May 25 2016
next sibling parent reply Seb <seb wilzba.ch> writes:
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?

...
May 25 2016
next sibling parent reply pineapple <meapineapple gmail.com> writes:
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
May 25 2016
parent reply pineapple <meapineapple gmail.com> writes:
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")
May 25 2016
parent poliklosio <poliklosio happypizza.com> writes:
On Wednesday, 25 May 2016 at 22:48:53 UTC, pineapple wrote:

 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")


If you are up to maintaining your lib for your own purposes AND 
phobos module, you can run your code through dfmt to adjust to 
the phobos style guide.

On the other hand, from what I observed about programming 
language communities, adding a standard library module seems like 
a ton of work, including:
- Long philosophical discussions about which specific functions 
should or shouldn't be in the standard library, even when their 
usefulness for module users is obvious.
- Long discussions about merging with or reusing other existing 
modules, which result in your solution not being clean anymore, 
which in turn triggers more discussions about what should be 
excluded from the module.
- Adding unittests and type restrictions, static ifs and 
optimizations for every conceivable use case.

I would't bother adding something to standard library unless I 
was an expert in the field who was likely to get things right the 
first time. I would definitely not bother if a module is just 
means to achieve another goal.

It might be better to observe how your code evolves over time and 
then select one or two specific pieces which are definitely 
useful, clean and correct.
May 26 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
May 25 2016
parent reply Seb <seb wilzba.ch> writes:
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  ;-)
May 25 2016
next sibling parent bachmeier <no spam.net> writes:
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.
May 25 2016
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
May 25 2016
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
May 25 2016
prev sibling parent reply Craig Dillabaugh <craig.dillabaugh gmail.com> writes:
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/
May 25 2016
parent pineapple <meapineapple gmail.com> writes:
On Wednesday, 25 May 2016 at 22:59:44 UTC, Craig Dillabaugh wrote:

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


I did, but I wasn't satisfied with the OOP approach and figured 
it would be more fun to write my own wrapper than try to wrestle 
Dgame into doing what I want a graphics library to do. It has 
served as a remarkable source of inspiration for my own project, 
though.

On Thursday, 26 May 2016 at 03:49:08 UTC, Vladimir Panteleev 
wrote:

 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.


Agreed completely - I don't need this sort of additional 
overhead, I just want to write code. If others might find my code 
useful I'm overjoyed to share it with them, but I'm not 
interested in making my process so rigid just to make it a little 
more convenient for others to use it.
May 26 2016