OpenD first preview release coming soon

Almost two months after being announced, OpenD almost has a working release build on a stable foundation. Some details to follow.

The Language

The language works and has about ten distinct changes already merged in. You can try it using the CI release on github right now.

The Website

The website is still basically the same as it was in the first week, except for small incremental changes on the roadmap, etc., pages. A new domain name has been registered but not fully set up. I did, however, add support to the code for embedding markdown in the html if desired and am refactoring adrdox to be easier to use with it too. I still want to add more updates to the content before tagging. In particular, I want some kind of language reference, but I really don't want to work with upstream's ddoc, even forked. Maybe just focusing on extraordinary parts of the language would be enough anyway.

Writing these things take much more time than you might realize: a blog post that takes 3 minutes to read often takes 3 hours to write, so it'll take some compromise and corner cutting to get up.

Included Tools

OpenD's release right now is a hacked-up fork of upstream ldc's release, so the key component of all of them is ldc. (We are considering renaming it to lodc but I'm concerned that will break other parts of the ci script. Perhaps we can rename the file only on the final bundle step. But I'm also thinking we could do everything through our new driver program...)

It currently does not include dmd, with my thought being that building dmd once you have ldc is not an especially difficult task anyway, but this might change before the actual release since it is nice to have them both there and just working.

What it does include that is unique to OpenD is the opend driver program. This is currently of experimental status and fairly minimal, doing just a dmd source/*.d, which is generally inferior to just using dmd -i, but is a starting point for more.

GrimMaple wrote the first version and has a different vision than mine, so what actually happens will probably be some kind of merger of these, but what I want to see it do is be a single entry point into the world of OpenD, capable of compiling, running, caching, updating, and other forms of code analysis, delegating work to other executables as needed.

For example, opend -O might call ldc2 whereas opend -fast might call dmd. opend -D can call adrdox. Etc., etc., etc. Additionally, I imagine it maintaining some state about what it has already done, in cooperation with the compiler: imagine a dmd -v kind of thing that the opend driver can parse out and save to its own database for further use. Might save symbol types, members, and locations for an ide. Might save template instance to object file mappings to help prevent undefined reference errors. All very pie-in-the-sky idealism right now, but this is what I want to try to make work.

Merging From Upstream

A new upstream dmd+ldc came out for the first time since the fork went live. Merging it has already proven to be a bit of a pain, mostly due to how we combined the dmd and ldc repos here. The single source makes hacking on the language much easier, but it also means some renamed files and some added conditional compilation blocks that are liable to create merge conflicts with upstream. I deferred this for now, but already expect the pain to continue to grow. It might not be worth trying to mass-pull anything as opposed to picking changes one by one to merge in. This could free us up to do more without worrying about internal compatibility, but I'm still hesitant to cut things off entirely since upstream does have some benefits we lack right now.

Bundled Libraries

The OpenD release bundles a great many libraries. This gives a nice out-of-the-box experience at the cost of (currently) just about 4 MB of end user download; about a 5% increase which I deem insignificant, without hurting other things. If you still want to use a specific version from a package manager, you can override the bundled default.

I think there's thus little downside to this: it costs little, it breaks nothing as for workflows, and enables new things such as OpenD fixing things and users getting a just works experience. But it does add a great many commits to the repo and has one risk of user support expectations.

To mitigate this, I've written a libraries index page and adapted the adrdox generator to both match the opend website style but also to highlight both support level and licensing requirement. As things demonstrate (or fail to demonstrate) value in practice, we can adjust the support level accordingly. I had the Wine website in mind, which lists how well various programs work under that environment.

Licenses, of course, are up to the original author, who may not be reachable, but the user can still make an informed decision for their case. If a license is too burdensome for a user they may consider exploring other alternatives. Note that the availability of a library in a bundle doesn't mean you're forced to use it; no part of it is included in any generated code unless you actually import it, or you import something that imports it. I'm considering an extension to pragma(msg) that can warn you once and only once during a build if this happens.

The Schedule

Realistically, we could tag something at any time, but I want to wait until the website is more complete, so if the link goes out, things are more stable and self-explanatory to readers. Going to try to do it at some point in the next couple weeks.