Overfflow in Assert error messages
I am debugging my simple binary search (I still am):
module binary_search;
debug {
static import std;
}
int indexOf(T)(const T[] list, const T key) {
ulong lo = 0;
ulong hi = list.length - 1;
while (hi > lo) {
const ulong mid = lo + (hi - lo) / 2;
if (list[mid] > key)
hi = mid - 1;
else if (list[mid] < key)
lo = mid + 1;
else {
std.writeln("Returning ", mid, ""); // says
its returning 0
return cast(int) mid;
}
}
return -1;
}
unittest {
scope (success)
std.writeln("binary_search.indexOf -- ok");
int[] arr;
foreach (i; 0 .. 101)
arr ~= i;
assert(arr.length > 1);
foreach (idx, i; arr)
assert(indexOf(arr, i) == idx);
}
However my test fails saying something like:
source/binary_search.d(33): [unittest] 18446744073709551615 != 1
core.exception.AssertError@source/binary_search.d(33):
18446744073709551615 != 1
What's causing this underflow?
I am using "dflags": ["-checkaction=context"] in my dub
configuration file.
writeln() in static import std
How can I reach stdout.writeln() using fully qualified name with static import? I have tried: std.stdio.stdout.writeln() -- fails std.writeln() -- works std.stdout.writeln -- works How does static import with std work?
Unpack Variadic Args?
Hello,
Was wondering if there was a simple, efficient way to unpack a
variadic template argument. It needs to be efficient at runtime,
and hopefully not use too much excessive CTFE.
C++ has the "..." operator, is there something equivalent in D?
template
void g(Args... args) {
f(foo(args)...); // f(foo(args[0]), foo(args[1])); // etc
}
What would be a good way to write that in D, with it being as
efficient (no copies or building structs etc) and not use too
much CTFE. Needing to use `.map` or similar at CTFE would be an
example of too much CTFE.
void g(Args...)(auto ref Args args) {
// ?
}
Re: Type sequence concatenation / associative array implementation
On Wednesday, 12 February 2020 at 20:58:49 UTC, Marcel wrote: 2- How is the builtin associative array implemented? I think I read somewhere it's implemented like C++'s std::unordered_map but with BSTs instead of DLists for handling collisions: is this correct? It's an open-addressed hash table. If you want to see all the details, the source is here: https://github.com/dlang/druntime/blob/v2.090.1/src/rt/aaA.d
Re: Type sequence concatenation / associative array implementation
On Wed, Feb 12, 2020 at 09:05:22PM +, user1234 via Digitalmars-d-learn wrote: > On Wednesday, 12 February 2020 at 20:58:49 UTC, Marcel wrote: > > Hello! > > I have two questions: > > > > 1- How can I concatenate two type sequences? > > alias Concatenated = AliasSeq!(TList1, TList2); [...] This is correct. They always auto-expand, and thus do not nest. T -- Let X be the set not defined by this sentence...
Re: Type sequence concatenation / associative array implementation
On Wednesday, 12 February 2020 at 20:58:49 UTC, Marcel wrote: Hello! I have two questions: 1- How can I concatenate two type sequences? alias Concatenated = AliasSeq!(TList1, TList2); or maybe alias Concatenated = AliasSeq!(TList1[0..$], TList2[0..$]); since I don't remember if they nest or not. 2- How is the builtin associative array implemented? I think I read somewhere it's implemented like C++'s std::unordered_map but with BSTs instead of DLists for handling collisions: is this correct? see druntime source.
Type sequence concatenation / associative array implementation
Hello! I have two questions: 1- How can I concatenate two type sequences? 2- How is the builtin associative array implemented? I think I read somewhere it's implemented like C++'s std::unordered_map but with BSTs instead of DLists for handling collisions: is this correct?
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 18:39:36 UTC, Steven Schveighoffer wrote: On 2/12/20 10:52 AM, mark wrote: I also think you split into more HTML files which I prefer. FYI, dlang.org has a secondary version of the docs which splits the documents up more: https://dlang.org/library/index.html I can't find a link to it directly from the main page though... This version is based on ddox (http://code.dlang.org/packages/ddox) -Steve There is also devdocs.io It has many languages and frameworks. The beauty is that it caches in local storage so searches are super fast and it is also available offline. Their d version lags a tiny bit, but that is fine.
Re: Some impressions/notes from a new D programmer
I find it incredibly useful to add a query URL to my browser. In manage search engines, I bind l to https://dpldocs.info/%s Then in the url bar, lapi_that_I_want_to_lookup
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 18:20:47 UTC, Adam D. Ruppe wrote: Weird, that's a legit bug in there. I'll fix them. h it isn't a bug i just forgot to update the file! that version i had was over a year old. so that's fixed The search is in the upper right unless you resize the window, then it disappears. so what happened here is it wraps to the next line if the window is too small. i fixed it basically, i don't love it (need to use flexbox instead of this old float crap, i wrote most this css years ago) but eh you should be able to see the search box consistently now at least.
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 18:20:47 UTC, Adam D. Ruppe wrote: On Wednesday, 12 February 2020 at 15:52:35 UTC, mark wrote: Yours rolls the two examples into one and doesn't show the Standards or Usage sections. Weird, that's a legit bug in there. I'll fix them. I also think you split into more HTML files which I prefer. OTOH yours doesn't have the search box. Given how new I am to D, I really need to be able to search. The search is in the upper right unless you resize the window, then it disappears. lol another bug, how did I not notice that before? well I'll fix those in a little bit. Please mention when you've fixed the search on this list since then I can switch to using your version of the docs. In my browser I can only see your search box if I expand the window to full screen which is wider than I need (I have a 1920x1200 monitor, so only have the browser window 1200x1100.)
Re: Some impressions/notes from a new D programmer
On 2/12/20 10:52 AM, mark wrote: I also think you split into more HTML files which I prefer. FYI, dlang.org has a secondary version of the docs which splits the documents up more: https://dlang.org/library/index.html I can't find a link to it directly from the main page though... This version is based on ddox (http://code.dlang.org/packages/ddox) -Steve
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 15:52:35 UTC, mark wrote: Yours rolls the two examples into one and doesn't show the Standards or Usage sections. Weird, that's a legit bug in there. I'll fix them. I also think you split into more HTML files which I prefer. OTOH yours doesn't have the search box. Given how new I am to D, I really need to be able to search. The search is in the upper right unless you resize the window, then it disappears. lol another bug, how did I not notice that before? well I'll fix those in a little bit.
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 10:39:06 UTC, mark wrote: I've been learning D for a few weeks now. ... I made exactly the same experience in December.
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 10:39:06 UTC, mark wrote: Library Reference Documentation The Library Reference documentation seems to be a mixed bag. Often I've found a good overview at the start, but then few or no examples in the docs for classes and methods (see e.g., https://dlang.org/phobos/std_zip.html#.ZipArchive). I don't find the presentation of the member properties and methods very easy to read, but the worst aspect is the lack of examples. It's a bug if something isn't properly documented, whatever the flaw may be. It's gotten a lot better in the time that I've been using D, but there are still a few rough spots. My strategy has been to ask for an example in the forum. I then click "Improve this page" in the upper right corner and it's a simple process to create a PR with the example added. Most of the documentation PRs I've created have been merged within a fwe hours. If you don't want to do that, you can create an issue in Bugzilla, with a detailed explanation of what you were doing and what the documentation should show instead. It would be nice for this to already be done, and while it's generally good by the standards of programming languages, there are still some weak spots. Anyone can help fix them. In some cases when I've reported missing documentation, there actually *was* documentation but it wasn't getting added to the website for some reason. Nobody will know until it's pointed out. And nobody's going to shout at you for filing too many documentation bugs or creating too many PRs to fix documentation bugs.
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 15:28:57 UTC, Anonymouse wrote: Maybe there are some hard design decisions again $HOME/.dub/bin, unsure. It might be difficult to globally pull off if programs expect the binary to be placed in the source tree (for resources). [1]: https://github.com/CyberShadow/Digger It could just create some shortcuts in ~/bin. AFAIK this special folder got automatically added to the $PATH in RH and deb distributions. The less obvious solution is for Windows systems.
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 14:15:40 UTC, Adam D. Ruppe wrote: On Wednesday, 12 February 2020 at 10:39:06 UTC, mark wrote: Library Reference Documentation Have you seen my fork? http://dpldocs.info/experimental-docs/std.zip.ZipArchive.html Yours is *much* clearer. However, if you compare: http://dpldocs.info/experimental-docs/std.zip.html vs https://dlang.org/phobos/std_zip.html Yours rolls the two examples into one and doesn't show the Standards or Usage sections. But the official page doesn't have the Bugs section. I also think you split into more HTML files which I prefer. OTOH yours doesn't have the search box. Given how new I am to D, I really need to be able to search. for example The documentation doesn't seem that easy to use I generated docs for this too http://gtk-d.dpldocs.info/gtk.AboutDialog.AboutDialog.html though since it is generated from C source ultimately the samples there are still C! But you can navigate members somewhat well. I hadn't seen this and it does looks easier to navigate. I've bookmarked it. Thanks.
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 13:36:13 UTC, mark wrote: Some cargo packages are applications. If I do 'cargo install someapp' it will be installed in $HOME/.cargo/bin. So by simply adding that to my PATH, I can easily use all installed rust apps. But dub doesn't appear to have an equivalent of this. There is 'dub run someapp', which is good enough for some cases, like digger[1]. But no 'dub install someapp', no. Maybe there are some hard design decisions again $HOME/.dub/bin, unsure. It might be difficult to globally pull off if programs expect the binary to be placed in the source tree (for resources). [1]: https://github.com/CyberShadow/Digger
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 10:39:06 UTC, mark wrote: Library Reference Documentation Have you seen my fork? http://dpldocs.info/experimental-docs/std.zip.ZipArchive.html for example The documentation doesn't seem that easy to use I generated docs for this too http://gtk-d.dpldocs.info/gtk.AboutDialog.AboutDialog.html though since it is generated from C source ultimately the samples there are still C! But you can navigate members somewhat well.
Re: Some impressions/notes from a new D programmer
On Wednesday, 12 February 2020 at 11:46:02 UTC, Dennis wrote: Thanks for your perspective. Just a few things are unclear to me: On Wednesday, 12 February 2020 at 10:39:06 UTC, mark wrote: I don't find the presentation of the member properties and methods very easy to read Can you elaborate a bit on this? Maybe I'm just used to the Python docs, but I find them a lot easier to read. The lack of set and B-tree types is disappointing (esp. considering that the much younger Rust has them). I'm using rbtree for sets but that imposes a requirement that my items support < (rather than the == or hash I'd expect for a set). This confuses me. So there is std.container.rbtree, but you don't like that the element type needs to have an order defined? How can Rust do binary search in a tree that has no order? If you are looking for a hashset, you can use an associative array for that. Naturally a tree needs <. But I want a set and since D doesn't have one I can either use an AA or an rbtree and I was advised that an rbtree is better for this purpose. However, dub doesn't seem to be competitive with Rust's cargo. Getting fast statically built (no dependency) executables is really nice. I've heard good things about cargo, but haven't used it myself yet. Do you have a specific thing dub can improve the most on? Some cargo packages are applications. If I do 'cargo install someapp' it will be installed in $HOME/.cargo/bin. So by simply adding that to my PATH, I can easily use all installed rust apps. But dub doesn't appear to have an equivalent of this.
Re: How to get Code.dlang.org to update the package?
On Wednesday, 12 February 2020 at 13:05:00 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 12 February 2020 at 12:42:32 UTC, Dukc wrote: I have pushed a new release tag in Github around two weeks ago, and ordered a manual update at DUB, yet DUB has still not aknowledged the new tag. Is there some requirement for the release tag for it to be recognized? Hi Dukc, I'm not sure which dub package you're referring to, but I'm gonna guess that it's this one: http://code.dlang.org/packages/nuklearbrowser, which corresponds to this github repo: https://github.com/dukc/nuklearbrowser. Correct I think the problem is that your latest tag is 0.0.2, instead of v0.0.2 (https://github.com/dukc/nuklearbrowser/tags). I hope this helps! Cheers, Petar Certainly does, thank you.
Re: How to get Code.dlang.org to update the package?
On Wednesday, 12 February 2020 at 12:42:32 UTC, Dukc wrote: I have pushed a new release tag in Github around two weeks ago, and ordered a manual update at DUB, yet DUB has still not aknowledged the new tag. Is there some requirement for the release tag for it to be recognized? Hi Dukc, I'm not sure which dub package you're referring to, but I'm gonna guess that it's this one: http://code.dlang.org/packages/nuklearbrowser, which corresponds to this github repo: https://github.com/dukc/nuklearbrowser. I think the problem is that your latest tag is 0.0.2, instead of v0.0.2 (https://github.com/dukc/nuklearbrowser/tags). I hope this helps! Cheers, Petar
Re: Building for multiple platforms
On Wednesday, 12 February 2020 at 12:46:23 UTC, Petar Kirov [ZombineDev] wrote: On Wednesday, 12 February 2020 at 08:41:25 UTC, Neils wrote: [...] Since your project is already on GitHub, I think the easiest solution would be to use GitHub Actions [1] + setup-dlang action [2] + upload-release-asset action [3] to automate the whole process. [1]: https://help.github.com/en/actions [2]: https://github.com/mihails-strasuns/setup-dlang [3]: https://github.com/actions/upload-release-asset P.S. Your project looks quite interesting! Best of luck!
Re: Building for multiple platforms
On Wednesday, 12 February 2020 at 08:41:25 UTC, Neils wrote: I maintain an open-source project written in D and I use DUB for building and my compiler backend is DMD. My dub.json file is rather simple: https://github.com/neilsf/XC-BASIC/blob/master/dub.json I offer pre-built binaries for Linux x86, Linux x86_64, Windows and Mac OS. I'm only doing this for a year so I am still quite a beginner in D and my workflow is the following when building the project: 1. Launch a VM using VirtualBox 2. dub build 3. Repeat for each platforms The above is a painfully slow process. Is there any way to make it simpler and faster? Any suggestions are warmly appreciated. Since your project is already on GitHub, I think the easiest solution would be to use GitHub Actions [1] + setup-dlang action [2] + upload-release-asset action [3] to automate the whole process. [1]: https://help.github.com/en/actions [2]: https://github.com/mihails-strasuns/setup-dlang [3]: https://github.com/actions/upload-release-asset
How to get Code.dlang.org to update the package?
I have pushed a new release tag in Github around two weeks ago, and ordered a manual update at DUB, yet DUB has still not aknowledged the new tag. Is there some requirement for the release tag for it to be recognized?
Re: How to set up multi-dimensional DUB package configuration?
Illustration, I want to choose both an edition and marked
copyright holder:
```
configuration "inhouse" {
targetType "executable"
versions "InhouseEdition"
}
configuration "salesmen" {
targetType "executable"
versions "SalesmenEdition"
}
configuration "internet" {
targetType "executable"
versions "InternetEdition"
}
configuration "copyrightcompanya" {
versions "CopyrightCompanyA"
}
configuration "copyrightcompanyb" {
versions "CopyrightCompanyB"
}
```
How to set up multi-dimensional DUB package configuration?
My application has two copyright holders, so I want to be able to specify in the build command whose copyright marks get compiled to the program. D part of the application is built by DUB. DUB configurations would do the trick, but they are already used to define different editions of the application. I have to be able to choose the edition indepently of the copyright holder. I don't necessarily need two-dimensional configuration. If there a way to order DUB to define an extra D version without altering `dub.sdl` to do that, it would suffice. But is there?
Re: Some impressions/notes from a new D programmer
Thanks for your perspective. Just a few things are unclear to me: On Wednesday, 12 February 2020 at 10:39:06 UTC, mark wrote: I don't find the presentation of the member properties and methods very easy to read Can you elaborate a bit on this? The lack of set and B-tree types is disappointing (esp. considering that the much younger Rust has them). I'm using rbtree for sets but that imposes a requirement that my items support < (rather than the == or hash I'd expect for a set). This confuses me. So there is std.container.rbtree, but you don't like that the element type needs to have an order defined? How can Rust do binary search in a tree that has no order? If you are looking for a hashset, you can use an associative array for that. However, dub doesn't seem to be competitive with Rust's cargo. Getting fast statically built (no dependency) executables is really nice. I've heard good things about cargo, but haven't used it myself yet. Do you have a specific thing dub can improve the most on?
Some impressions/notes from a new D programmer
I've been learning D for a few weeks now. I'm an experienced programmer in other languages (esp. Python, but also Rust and C++). Here're some *early* impressions and notes. D Tour I found the D Tour, esp. "D's Basics" to be very helpful. Each part is short and in most cases understandable. Being able to run and edit the code is a real help for learning. D Playground The D playground https://run.dlang.io/ is very useful for trying out snippets and generally learning, so I use it a lot. (I still haven't worked out how to save a URL to my code though.) Library Reference Documentation The Library Reference documentation seems to be a mixed bag. Often I've found a good overview at the start, but then few or no examples in the docs for classes and methods (see e.g., https://dlang.org/phobos/std_zip.html#.ZipArchive). I don't find the presentation of the member properties and methods very easy to read, but the worst aspect is the lack of examples. Standard Library The library itself "feels" a bit incomplete, which is surprising given how long D's been around. To give just two examples: The lack of set and B-tree types is disappointing (esp. considering that the much younger Rust has them). I'm using rbtree for sets but that imposes a requirement that my items support < (rather than the == or hash I'd expect for a set). The fact that the return value of std.file.getAttributes() means completely different things on POSIX and Windows. That's fair enough, but there ought to be a platform-neutral equivalent for those writing cross-platform applications that returned, say, a struct or tuple with the common subset of attributes normalised. (And if there is such a function, why isn't it cross-referenced.) There seems to be a curious mixture of functions which are POSIX- or Windows-specific and those which are platform neutral. The D Language The D language seems to be a "kitchen sink" (i.e., has everything) like C++, Rust, (and nowadays, Python). This makes it big and a *lot* to learn. However, I managed to create a little library that used template types (with some help from this forum), and I _understand_ the templates. This is a huge improvement over C++ or Rust. And to my surprise, so far my D programs have about the same line counts as the Python versions. Also, I've found building much easier than C++. However, dub doesn't seem to be competitive with Rust's cargo. Getting fast statically built (no dependency) executables is really nice. GUI Programming I've tried a number of D GUI libraries, and all bar one have been problematic. To my surprise GtkD was easy to install on both Linux and Windows and getting "hello world" to build and run was fairly easy. The documentation doesn't seem that easy to use, but I'll start with Ron Tarrant's https://gtkdcoding.com/ and see how I get on from there. D Books I find Ali Çehreli's book (http://ddili.org/ders/d.en/index.html) more suited to complete beginners, but I am skim reading it and finding it useful here and there. The main books I'm reading are Mike Parker's Learning D and Adam Ruppe's D Cookbook, both of which I think are pretty good. (However, I hope both will produce more up-to-date and improved second editions with a better publisher.) Learn D Forum People on this forum have always provided polite and helpful answers. This is a very important intangible benefit of the language. Conclusion My hope was that D would offer a sweet spot between Python's ease and speed of development and Rust's performance. And so far this looks like being the case.
Re: Global version/debug statements in file?
On Wednesday, 12 February 2020 at 09:28:15 UTC, Simen Kjærås wrote: https://dlang.org/dmd-windows.html#switches specifies that DMD may be passed a file on the command line that contains compiler arguments and switches. This may be freely combined with regular command line arguments if you so wish. So, you could have a file called 'versions' containing this: # Setting 'Compress' version -version=Compress # Optionally set other versions #-version=Foo #-version=Bar and feed it to dmd like so: dmd -w -wi -g @versions -main foo.d -- Simen Ahh missed that, that should do it, thanks!
Re: Is there a std.zip.ZipArchive isDir or isFile method?
It looks like 004 (octal) is the flag for directories on
linux, but it does seem that std.zip is explicitly returning 0 if
the file was created on the opposite platform re: Posix vs
Windows, which is... odd.
@property @nogc nothrow uint fileAttributes() const
{
version (Posix)
{
if ((_madeVersion & 0xFF00) == 0x0300)
return _externalAttributes >> 16;
return 0;
}
else version (Windows)
{
if ((_madeVersion & 0xFF00) == 0x)
return _externalAttributes;
return 0;
}
else
{
static assert(0, "Unimplemented platform");
}
}
Looks like the only way around it is modifying std.zip? Adding
something like:
@property bool isDir() const {
enum uint FILE_ATTRIBUTE_DIRECTORY = 0x10; // WINNT.h
enum uint S_IFDIR = 0x4000; // sys/stat.h
version(Windows) {
if ((_madeVersion & 0xFF00) == 0x0300) // Archive made on Posix
return cast(bool) (_externalAttributes & (S_IFDIR <<
16));
return cast(bool) (_externalAttributes &
FILE_ATTRIBUTE_DIRECTORY);
} else version(Posix) {
if ((_madeVersion & 0xFF00) == 0x0300) // Archive made on Posix
return cast(bool) (_externalAttributes & (S_IFDIR <<
16));
return cast(bool) ((_externalAttributes) &
FILE_ATTRIBUTE_DIRECTORY);
} else {
static assert(0, "Unimplemented platform");
}
}
will let me do this:
void main() {
foreach (zipfile; ["windowstest.zip", "linuxtest.zip"]) {
writeln(zipfile);
auto zip = new ZipArchive(std.file.read(zipfile));
foreach (fn, am; zip.directory) {
writefln("%24s %5s %s", fn, am.isDir,
am.fileAttributes);
}
}
}
Results on Windows:
windowstest.zip
a.txt false 32
testdir/ true 16
testdir/b.txt false 32
linuxtest.zip
a.txt false 0
testdir/ true 0
testdir/b.txt false 0
Results on Linux:
windowstest.zip
testdir/ true 0
testdir/b.txt false 0
a.txt false 0
linuxtest.zip
testdir/ true 16893
testdir/b.txt false 33204
a.txt false 33204
A D implementation of the Python difflib module's sequence matcher.
I've just completed my first D package: http://code.dlang.org/packages/ddiff It is a straight port, so it isn't at all functional-style. I'd be happy and interested if anyone could show me how to replace some/all of the for[each] loops (without reducing performance), or for any other code improvements that would make it more idiomatic D.
Re: Global version/debug statements in file?
On Wednesday, 12 February 2020 at 08:44:24 UTC, cc wrote: Is there some way to globally declare version= or debug= statements in a file and have them apply to the entire project being compiled? As the documentation says these only apply to the module scope they exist in, and need to be added to the command line otherwise. It would be a bit easier for me to maintain a separate .d source file when I want to add/comment out statements for testing than to keep updating the build command line. https://dlang.org/dmd-windows.html#switches specifies that DMD may be passed a file on the command line that contains compiler arguments and switches. This may be freely combined with regular command line arguments if you so wish. So, you could have a file called 'versions' containing this: # Setting 'Compress' version -version=Compress # Optionally set other versions #-version=Foo #-version=Bar and feed it to dmd like so: dmd -w -wi -g @versions -main foo.d -- Simen
Global version/debug statements in file?
Is there some way to globally declare version= or debug=
statements in a file and have them apply to the entire project
being compiled? As the documentation says these only apply to
the module scope they exist in, and need to be added to the
command line otherwise. It would be a bit easier for me to
maintain a separate .d source file when I want to add/comment out
statements for testing than to keep updating the build command
line. I tried using a mixin, such as:
// constants.d
module constants;
enum VERSIONS = q{
version=Compress;
};
// main.d
import constants;
mixin(VERSIONS);
void main() {
version(Compress)
writeln("Compress it!");
version(Decompress)
writeln("Decompress it!");
}
This does seem to work inside function bodies, but not at module
scope in the importing file. e.g.:
// main.d
import constants;
mixin(VERSIONS)
version(Compress) {
...
}
Gives: Error: version `Compress` defined after use
Building for multiple platforms
I maintain an open-source project written in D and I use DUB for building and my compiler backend is DMD. My dub.json file is rather simple: https://github.com/neilsf/XC-BASIC/blob/master/dub.json I offer pre-built binaries for Linux x86, Linux x86_64, Windows and Mac OS. I'm only doing this for a year so I am still quite a beginner in D and my workflow is the following when building the project: 1. Launch a VM using VirtualBox 2. dub build 3. Repeat for each platforms The above is a painfully slow process. Is there any way to make it simpler and faster? Any suggestions are warmly appreciated.
