Re: Diva - D Language Interface for Versioned Applications
On Sunday, 11 July 2021 at 13:39:15 UTC, Jacob Carlborg wrote: Some other differences: * DVM is cross-platform. Diva seems to only run on Ubuntu. * DVM is implemented in D (with a tiny shell script wrapper). Diva depends on Python * DVM does not use symlinks. When invoking the compiler it's the actual executable that's invoked directly * DVM provides a built-in command to install itself and do any setup -- /Jacob Carlborg Fair points here. It's stated in the readme but just to be really clear: I wrote this mainly for my own use. It may or may not work for you out-of-the-box. I put it on GitHub with an MIT license in case it might be useful to others. It's definitely not a polished production-ready piece of software. * DVM is cross-platform. Diva seems to only run on Ubuntu. Well, not exactly. I wrote Diva in a couple of evenings this past week and I haven't had an opportunity to test it on other platforms than Ubuntu so far. I'm confident it will work with other Linux distros (though it might have problems on ARM platforms; it can't build DMD or LDC from source yet which means if there's not a prebuilt binary then Diva can't help you) and I'm reasonably sure it will work with MacOS without any changes. There's a fair chance it will break down on Windows. Even though there's some logic specifically to try to handle Windows, I just haven't tested it yet. If you want to use it on your platform and run into difficulties, the script is fairly simple and fairly well documented and so hopefully feasible to troubleshoot things for yourself. I'm happy to accept a PR if you find and fix issues like this. * DVM is implemented in D (with a tiny shell script wrapper). Diva depends on Python Yep. It was faster for me to write it in Python. I'm personally much more familiar with Python's tools for making HTTP requests and for extracting compressed archives than I am with D's, and my goal here was to just have something usable for myself in little time. If someone wanted to rewrite Diva in D and make sure there's a handy script to bootstrap it if a D compiler isn't already locally available, that would be fantastic. * DVM does not use symlinks. When invoking the compiler it's the actual executable that's invoked directly Yep, symlinking is a fairly standard way to handle this sort of thing, and it's how I wanted to do it on my system. If you prefer to do it differently on your system, you could take Diva's downloading and installation system as a starting point and revise its "use"/"disuse" logic. If it's compatible/configuration-switchable with the symlink implementation, I'd be happy to accept a PR that added this sort of thing. * DVM provides a built-in command to install itself and do any setup Yep, the Diva install process is very slightly more complicated in that you will have to find your bashrc (or equivalent) on your own after using `pip install .` and paste a few lines in according to the instructions in the readme.
Re: Diva - D Language Interface for Versioned Applications
On Saturday, 10 July 2021 at 08:42:46 UTC, Bastiaan Veelo wrote: Could it be that you have overlooked D Version Manager? https://code.dlang.org/packages/dvm — Bastiaan. Oh, I hadn't picked up on that. That only manages DMD, though. Diva can manage DMD and LDC, as well as managing dub separately if you want it to. Personally I'll be using Diva in the future to manage my installations.
Diva - D Language Interface for Versioned Applications
Basically, it's a version manager which currently supports DMD, LDC, and dub. It's rough, but maybe in some ways a little less rough than install.sh, at https://dlang.org/install.html https://github.com/pineapplemachine/diva
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
I really like `unittest`. It's my personal conviction that a developer should not be able to view the documentation, tests, or implementation for some part of a code base in isolation. `unittest` makes it easier for me to work this way. Automated tests are vital for stability and documentation is vital for maintainability and making it possible for others to understand your code. But when they aren't right there in the same place as the implementation, I've noticed that it is the inevitable habit of developers to think of tests and documentation as second-class, if they are thought of at all. The developer updates the implementation and doesn't think to update the tests or the docs. This happens a few times. Then instead of updating the tests to work with the updated implementation, the tests are discarded as an inconvenience. And then end users become confused by docs that have since become inapplicable.
Re: Moonshot: a DMD fork that outputs Lua
On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur wrote: Hi all, I've been working on a little project over the last month and a half, inspired by Adam's dtojs (https://github.com/adamdruppe/dtojs). I've always wanted a typed, powerful, embeddable scripting language, but found the contenders lacking - which is why I decided to hack up DMD to emit Lua. This is awesome. Great work! Is there an easy way to see compiler output for some example programs? I encourage you to submit a dconf talk - I know I'd like to hear more about this - just mind that the submission deadline is coming up in a few days.
Re: Release D 2.073.0
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote: If you've got a case, make it. If you see problems, explain. If you want to help, please do. So, do what numerous people have done numerous times already, to no great effect?
Re: Formal review of DIP1002
On Thursday, 17 November 2016 at 11:37:09 UTC, Dicebot wrote: Disposition: REJECT. A proposal for a similar or identical feature would need to be include qualitatively new motivation/evidence of usefulness. Please follow the link for the full review text / rationale: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review There should be no need for me to repeat the arguments against the DIP process already made by others. I will be submitting no more DIPs or engaging in the process in any way unless and until it is significantly changed.
Re: Introducing mach.d, the github repo where I put whatever modules I happen to write
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.
Re: Introducing mach.d, the github repo where I put whatever modules I happen to write
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")
Re: Introducing mach.d, the github repo where I put whatever modules I happen to write
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
Introducing mach.d, the github repo where I put whatever modules I happen to write
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!
