ddn 2.3.1

DDN

DDN core is a collection of carefully crafted modules for the D programming language.

More about the DDN project here:

• DDN Website
• DDN Codeberg Organisation
• DDN core project at Codeberg
• DDN project Kanban

Modules

This is the current set of modules in the ddn package:

 ddn
 ├── adam             Compact, memory-efficient dynamic value type
 ├── api
 │   └── net
 │       └── http
 │           └── client    HTTP client API (sync + async interfaces)
 ├── config
 │   └── ini          INI file parser and writer
 ├── data
 │   ├── csv          CSV parser
 │   └── json5        JSON5 parsing and serialization
 ├── ddn              Contains just version information and other metadata
 ├── os
 │   └── path         Python pathlib-like filesystem helper
 ├── util
 │   ├── docopt       Python's docopt-like argument parser
 │   ├── json_escape  JSON string escaping utilities
 │   └── semver       Semantic versioning
 └── var              Compact, dynamic value type

Each module has own set of maintainers and contributors. See the MAINTAINERS.md file for more details.

GitLab

The "ddn" project will be hosted on GitLab until DUB starts supporting CodeBerg where the real development is actually happening.

https://gitlab.com/ddn/ddn.git is a MIRROR of Codeberg's https://codeberg.org/ddn/ddn.git repository. In other words, main development is on CodeBerg!

Become a member

If you think you have one or more modules that should be either in the core library, or as an outside project in the ddn namespace, please contact one of the DDN members to add you to the Codeberg ddn organisation. For the time being bindings will be outside projects developed within the organisation. For an example, if you are writing a binding to the libbz2, it would be a ddn.lib.bz2 module inside a ddn/ddn-lib-bz2 project on Codeberg. If you prefer your project elsewhere, then you would create a ddn-lib-bz2 project on git hosting platform of your choice and we would setup a push mirror to GitLab's ddn/ddn-lib-bz2 project, until dub registry starts working with Codeberg.

PS. Things change, and we may find this approach wrong, and adopt something else.

Finally, do not become a member for the sake of being a member. We want you as member if there is something that either already exists in this project (one or more packages/modules) that you genuinely use in your project(s), or you already use in your projects and you feel sharing it would benefit users of ddn packages/modules.

In other words, if you are not using/developing, or planing to use/develop, one or more `ddn` modules, there is no point of you becoming a member.

Demo applications

Each module in the ddn package, except perhaps API modules (in ddn.api.*) has a demo application in the demo directory. They are all in demo.category.module[_extra] modules.

To easily build and run these demo applications we have made the demo.sh (POSIX) and demo.bat (Windows) scripts available in the root directory of the repository.

Let's build ddn and run the var-semver demo application:

dub build              # should use DMD, unless you changed $DC
./demo.sh var-semver   # builds and runs the "var-semver" demo

If you want to build ddn with GDC and run the os-path_walk demo application:

dub build --compiler=gdc # should use GDC
DC=gdc ./demo.sh os-path_walk

The script does not delete them from the bin directory so you may run them multiple times with different parameters. Example: bin/var-semver

Some applications may require additional dependencies in which case you can't run them via demo.sh. Those you should run in --single mode with dub. Example: dub run --single demo/net/http_client_vibed.d Nowadays most of the demo applications are single-file applications, and can be executed this way as well.

ddn.os.path — Pathlib-like filesystem helper

This section has moved to a dedicated document:

• doc/ddn-os-path.md

Please see that file for the quick start, demos, platform notes, and references.