www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D-lighted, I'm Sure

reply Mike Parker <aldacron gmail.com> writes:
Not long ago, in my retrospective on the D Blog in 2018, I 
invited folks to write about their first impressions of D. Ron 
Tarrant, who you may have seen in the Lear forum, answered the 
call. The result is the latest post on the blog, the first guest 
post of 2019. Thanks, Ron!

As a reminder, I'm still looking for new-user impressions and 
guest posts on any D-related topic. Please contact me if you're 
interested. And don't forget, there's a bounty for guest posts, 
so you can make a bit of extra cash in the process.

The blog:
https://dlang.org/blog/2019/01/18/d-lighted-im-sure/

Reddit:
https://www.reddit.com/r/programming/comments/ahawhz/dlighted_im_sure_the_first_two_months_with_d/
Jan 18
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/18/19 9:29 AM, Mike Parker wrote:
 Not long ago, in my retrospective on the D Blog in 2018, I invited folks 
 to write about their first impressions of D. Ron Tarrant, who you may 
 have seen in the Lear forum, answered the call. The result is the latest 
 post on the blog, the first guest post of 2019. Thanks, Ron!
 
 As a reminder, I'm still looking for new-user impressions and guest 
 posts on any D-related topic. Please contact me if you're interested. 
 And don't forget, there's a bounty for guest posts, so you can make a 
 bit of extra cash in the process.
 
 The blog:
 https://dlang.org/blog/2019/01/18/d-lighted-im-sure/
 
 Reddit:
 https://www.reddit.com/r/programming/comments/ahawhz/dlighted_im_sure_the_firs
_two_months_with_d/ 
 
Nice read! And welcome to Ron! I too, started with BASIC, but on a Commodore 64 :) -Steve
Jan 18
parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 18 January 2019 at 15:08:48 UTC, Steven Schveighoffer 
wrote:

 Nice read! And welcome to Ron! I too, started with BASIC, but 
 on a Commodore 64 :)

 -Steve
Thanks, Steve. Just to set the record straight, I only had access to that Coleco Adam for the few weeks I was in that Newfoundland outport. Within a year, I too had my very own C-64 plugged into a monster Zenith console job. Remember those? I don't remember what I paid for a used C-64, but the Zenith 26" was $5 at a garage sale up the street and another $5 for delivery.
Jan 18
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/18/19 11:42 AM, Ron Tarrant wrote:
 On Friday, 18 January 2019 at 15:08:48 UTC, Steven Schveighoffer wrote:
 
 Nice read! And welcome to Ron! I too, started with BASIC, but on a 
 Commodore 64 :)
Thanks, Steve. Just to set the record straight, I only had access to that Coleco Adam for the few weeks I was in that Newfoundland outport. Within a year, I too had my very own C-64 plugged into a monster Zenith console job. Remember those? I don't remember what I paid for a used C-64, but the Zenith 26" was $5 at a garage sale up the street and another $5 for delivery.
I had to use my parents' TV in the living room :) And I was made to learn typing before I could play games on it, so cruel... -Steve
Jan 18
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 18, 2019 at 12:06:54PM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
 On 1/18/19 11:42 AM, Ron Tarrant wrote:
[...]
 Just to set the record straight, I only had access to that Coleco
 Adam for the few weeks I was in that Newfoundland outport. Within a
 year, I too had my very own C-64 plugged into a monster Zenith
 console job.  Remember those? I don't remember what I paid for a
 used C-64, but the Zenith 26" was $5 at a garage sale up the street
 and another $5 for delivery.
I had to use my parents' TV in the living room :) And I was made to learn typing before I could play games on it, so cruel...
[...] Wow, what cruelty! ;-) The Apple II was my first computer ever, and I spent 2 years playing computer games on it until they were oozing out of my ears. Then I got so fed up with them that I decided I'm gonna write my own. So began my journey into BASIC, and then 6502 assembly, etc.. A long road later, I ended up here with D. T -- This is a tpyo.
Jan 18
prev sibling parent Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 18 January 2019 at 17:06:54 UTC, Steven Schveighoffer 
wrote:

 I had to use my parents' TV in the living room :) And I was 
 made to learn typing before I could play games on it, so 
 cruel...
LOL! (Ahem) I feel your pain, sir.
Jan 19
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Friday, 18 January 2019 at 16:42:15 UTC, Ron Tarrant wrote:
 Just to set the record straight, I only had access to that 
 Coleco Adam for the few weeks I was in that Newfoundland 
 outport. Within a year, I too had my very own C-64 plugged into 
 a monster Zenith console job. Remember those? I don't remember 
 what I paid for a used C-64, but the Zenith 26" was $5 at a 
 garage sale up the street and another $5 for delivery.
Great read Ron. Can I ask which town in Newfoundland it was where you stayed back in 1985?
Jan 18
parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 18 January 2019 at 19:55:34 UTC, Meta wrote:

 Great read Ron. Can I ask which town in Newfoundland it was 
 where you stayed back in 1985?
Sure. I was in St. Lawrence on the Burin Peninsula. Do you know it?
Jan 19
parent Meta <jared771 gmail.com> writes:
On Saturday, 19 January 2019 at 22:09:57 UTC, Ron Tarrant wrote:
 On Friday, 18 January 2019 at 19:55:34 UTC, Meta wrote:

 Great read Ron. Can I ask which town in Newfoundland it was 
 where you stayed back in 1985?
Sure. I was in St. Lawrence on the Burin Peninsula. Do you know it?
Unfortunately (or fortunately?) not. I've spent a good deal of time exploring the western side of NFLD but have only visited Gander and St. John's on the eastern side.
Jan 21
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 18, 2019 at 02:29:14PM +0000, Mike Parker via
Digitalmars-d-announce wrote:
[...]
 The blog:
 https://dlang.org/blog/2019/01/18/d-lighted-im-sure/
[...] Very nice indeed! Welcome aboard, Ron! And wow... 6502? That's what I grew up on too! I used to remember most of the opcodes by heart... though nowadays that memory has mostly faded away. The thought of it still evokes nostalgic feelings, though. I'm also not a big fan of dub, but I'm in the minority around these parts. Having grown up on makefiles and dealt with them in a large project at my day job, I've developed a great distaste for them, and nowadays the standard build tool I reach for is SCons. Though possibly in the not-so-distant future I might start using something more scalable like Tup, or Button, written by one of our very own D community members. But for small projects, just plain ole dmd is Good Enough(tm) for me. I won't bore you with my boring editor, vim (with no syntax highlighting -- yes I've been told I'm crazy, and in fact I agree -- just plain ole text, with little things like autoindenting, no fancy IDE features -- Linux is my IDE, the whole of it :-P). Vim users seem to out in force around these parts for some reason, besides the people clamoring for a "proper" IDE, but I suspect I'm the only one who deliberately turns *off* syntax highlighting, and indeed, any sort of color output from dmd or any other tools (I find it distracting). So don't pay too much heed to what I say, at least on this subject. :-D T -- Живёшь только однажды.
Jan 18
next sibling parent reply JN <666total wp.pl> writes:
On Friday, 18 January 2019 at 18:48:00 UTC, H. S. Teoh wrote:
 I'm also not a big fan of dub, but I'm in the minority around 
 these parts.  Having grown up on makefiles and dealt with them 
 in a large project at my day job, I've developed a great 
 distaste for them, and nowadays the standard build tool I reach 
 for is SCons.  Though possibly in the not-so-distant future I 
 might start using something more scalable like Tup, or Button, 
 written by one of our very own D community members. But for 
 small projects, just plain ole dmd is Good Enough(tm) for me.
The trick with makefiles is that they work well for a single developer, or a single project, but become an issue when dealing with multiple libraries, each one coming with its own makefile (if you're lucky, if you're not, you have multiple CMake/SCons/etc. systems to deal with). Makefiles are very tricky to do crossplatform, especially on Windows, and usually they aren't enough, I've often seen people use bash/python/ruby scripts to drive the building process anyway. The big thing dub provides is package management. Having a package manager is an important thing for a language nowadays. Gone are the days of hunting for library source, figuring out where to put includes. Just add a line in your dub.json file and you have the library. Need to upgrade to newer version? Just change the version in dub.json file. Need to download the problem from scratch? No problem, dub can use the json file to download all the dependencies in proper versions.
Jan 18
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 18, 2019 at 06:59:59PM +0000, JN via Digitalmars-d-announce wrote:
[...]
 The trick with makefiles is that they work well for a single
 developer, or a single project, but become an issue when dealing with
 multiple libraries, each one coming with its own makefile (if you're
 lucky, if you're not, you have multiple CMake/SCons/etc. systems to
 deal with). Makefiles are very tricky to do crossplatform, especially
 on Windows, and usually they aren't enough, I've often seen people use
 bash/python/ruby scripts to drive the building process anyway.
Actually, the problems I had with makefiles come from within single projects. One of the most fundamental problems, which is also a core design, of Make is that it's timestamp-based. This means: (1) it often builds unnecessarily -- `touch source.d` and it rebuilds source.d even though the contents haven't changed; and (2) it often fails to build necessary targets -- if for whatever reason your system clock is out-of-sync or whatever, and a newer version of source.d has an earlier date than a previously-built object. Furthermore, makefiles generally do not have a global view of your workspace, so builds are not reproducible (unless you go out of your way to do it). Running `make` after editing some source files does not guarantee you'll end up with the same executables as if you checked in your changes, did a fresh checkout, and ran `make`. I've had horrible all-nighters looking for heisenbugs that have no representation in the source code, but are caused by make picking up stale object files from who knows how many builds ago. You end up having to `make clean; make` every other build "just to be sure", which is really stupid in this day and age. (And even `make clean` does not guarantee you get a clean workspace -- too many projects than I care to count exhibit this problem.) Then there's parallel building, which again requires explicit effort, macro hell typical of tools from that era, etc.. I've already ranted about this at great lengths before, so I'm not going to repeat them again. But make is currently near (if not at) the bottom of my list of build tools for many, many reasons. Ultimately, as I've already said elsewhere, what is needed is a *standard tool-independent dependency graph declaration* attached to every project, that captures the dependency graph of the project in a way that any tool that understands the standard format can parse and act on. At the core of it, every build system out there is essentially just an implementation of a directed acyclic graph walk. A standard problem with standard algorithms to solve it. But everybody rolls their own implementation gratuitously incompatible with everything else, and so we find ourselves today with multiple, incompatible build systems that, in large-scale software, often has to somehow co-exist within the same project.
 The big thing dub provides is package management. Having a package
 manager is an important thing for a language nowadays. Gone are the
 days of hunting for library source, figuring out where to put
 includes. Just add a line in your dub.json file and you have the
 library. Need to upgrade to newer version? Just change the version in
 dub.json file. Need to download the problem from scratch? No problem,
 dub can use the json file to download all the dependencies in proper
 versions.
Actually, I have the opposite problem. All too often, my projects that depend on some external library become uncompilable because said library has upgraded from version X to version Z, and version X doesn't exist anymore (the oldest version is now Y), or upstream made an incompatible change, or the network is down and dub can't download the right version, etc.. These days, I'm very inclined to just download the exact version of the source code that I need, and include it as part of my source tree, just so there will be no gratuitous breakage due to upstream changes, old versions being no longer supported, or OS changes that break pre-shipped .so files, and all of that nonsense. Just compile the damn thing from scratch from the exact version of the sources that you KNOW works -- sources that you have in hand RIGHT HERE instead of somewhere out there in the nebulous "cloud" which happens to be unreachable right now, because your network is down and in order to fix the network you need to compile this tool that depends on said missing sources. I understand it's convenient for the package manager to "automatically" install dependencies for you, refresh to the latest version, and what-not. But frankly, I find that the amount of effort it takes to download the source code of some library and setup the include paths manually is miniscule, compared to the dependency hell I have to deal with in a system like dub. These days I almost automatically write off 3rd party libraries that have too many dependencies. The best kind of 3rd party code is the standalone kind, like the kind Adam Ruppe provides: just copy the lousy source code into your source tree and import that. 10 years later it will still compile and work as before, and won't suddenly die from missing .so files (because they've been replaced by newer, ABI-incompatible ones), new upstream versions that broke the old API, or from missing source files that were gone from the dub cache when you migrated to a new hard drive and now you can't get them because your network is down, or, worst of all, one of the dependencies of the dependencies of the library you depend on has vanished into the ether and/or become gratuitously incompatible so now you have to spend 5 hours upgrading the entire codebase and 5 days to rewrite your code to work around the missing functionality, etc.. I'm not against fetching new versions of dependencies and what-not, but I'd like to do that as a conscious action instead of some tool deciding to "upgrade" my project and ending up with something uncompilable -- in the middle of a code-build-debug cycle. I don't *want* stuff upgraded behind my back when I'm trying to debug something! With Adam-style libraries, you just copy the damn file into your source tree and that's all there is to it. When you need to upgrade, just download the new file, copy it into your source, and recompile. If that breaks, rollback your code repo and off you go. I'm sick of the baroque nonsense that is the dependency hell of "modern" package managers, or worse, the *versioned* dependency hell of having to explicitly specify what version of the library you depend on. The source file you copied into the source tree *is* the version you're depending on, period. No fuss, no muss. (And don't get me started on dub as a *build* tool. It's actually not bad as a *package manager*, but as a build tool, I find it essentially unusable because it does not support many things I need, like codegen, non-code-related build tasks like data generation, etc.. Until dub is able to support those things, it's not even an option for many of my projects.) T -- All problems are easy in retrospect.
Jan 18
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Fri, 18 Jan 2019 11:43:58 -0800, H. S. Teoh wrote:
 (1) it often builds unnecessarily -- `touch source.d` and it rebuilds
 source.d even though the contents haven't changed; and
Timestamp-based change detection is simple and cheap. If your filesystem supports a revision id for each file, that might work better, but I haven't heard of such a thing. If you're only dealing with a small number of small files, content-based change detection might be a reasonable option.
 (2) it often fails to build necessary targets -- if for whatever reason
 your system clock is out-of-sync or whatever, and a newer version of
 source.d has an earlier date than a previously-built object.
I'm curious what you're doing that you often have clock sync errors.
Jan 18
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 18, 2019 at 08:03:09PM +0000, Neia Neutuladh via
Digitalmars-d-announce wrote:
 On Fri, 18 Jan 2019 11:43:58 -0800, H. S. Teoh wrote:
 (1) it often builds unnecessarily -- `touch source.d` and it
 rebuilds source.d even though the contents haven't changed; and
Timestamp-based change detection is simple and cheap. If your filesystem supports a revision id for each file, that might work better, but I haven't heard of such a thing.
Barring OS/filesystem support, there's recent OS features like inotify that lets a build daemon listen for changes to files within a subdirectory. Tup, for example, uses this to make build times proportional to the size of the changeset rather than the size of the entire workspace. I consider this an essential feature of a modern build system. Timestamp-based change detection also does needless work even when there *is* a change. For example, edit source.c, change a comment, and make will recompile it all the way down -- .o file, .so file or executable, all dependent targets, etc.. Whereas a content-based change detection (e.g. md5 checksum based) will stop at the .o step because the comment did not cause the .o file to change, so further actions like linking into the executable are superfluous and can be elided. For small projects the difference is negligible, but for large-scale projects this can mean the difference between a few seconds -- usable for high productivity code-compile-test cycle -- and half an hour: completely breaks the productivity cycle.
 If you're only dealing with a small number of small files,
 content-based change detection might be a reasonable option.
Content-based change detection is essential IMO. It's onerous if you use the old scan-the-entire-source-tree model of change detection; it's actually quite practical if you use a modern inotify- (or equivalent) based system.
 (2) it often fails to build necessary targets -- if for whatever
 reason your system clock is out-of-sync or whatever, and a newer
 version of source.d has an earlier date than a previously-built
 object.
I'm curious what you're doing that you often have clock sync errors.
Haha, that's just an old example from back in the bad ole days where NTP syncing is rare, and everyone's PC is slightly off anywhere from seconds to minutes (or if it's really badly-managed, hours, or maybe the wrong timezone or whatever). The problem is most manifest when networked filesystems are involved. These days, clock sync isn't really a problem anymore, generally speaking, but there's still something else about make that makes it fail to pick up changes. I still regularly have to `make clean;make` makefile-based projects just to get the lousy system to pick up the changes. I don't have that problem with more modern build systems. Probably it's an issue of undetected dependencies. T -- I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser
Jan 18
parent reply Jacob Carlborg <doob me.com> writes:
On 2019-01-18 21:23, H. S. Teoh wrote:

 Haha, that's just an old example from back in the bad ole days where NTP
 syncing is rare, and everyone's PC is slightly off anywhere from seconds
 to minutes (or if it's really badly-managed, hours, or maybe the wrong
 timezone or whatever).
I had one of those issues at work. One day when I came in to work it was suddenly not possible to SSH into a remote machine. It worked the day before. Turns out the ntpd daemon was not running on the remote machine (for some reason) and we're using Kerberos with SSH, that means if the clocks are too much out of sync it will not be able to login. That was a ... fun, debugging experience. -- /Jacob Carlborg
Jan 18
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 18, 2019 at 09:41:14PM +0100, Jacob Carlborg via
Digitalmars-d-announce wrote:
 On 2019-01-18 21:23, H. S. Teoh wrote:
 
 Haha, that's just an old example from back in the bad ole days where
 NTP syncing is rare, and everyone's PC is slightly off anywhere from
 seconds to minutes (or if it's really badly-managed, hours, or maybe
 the wrong timezone or whatever).
I had one of those issues at work. One day when I came in to work it was suddenly not possible to SSH into a remote machine. It worked the day before. Turns out the ntpd daemon was not running on the remote machine (for some reason) and we're using Kerberos with SSH, that means if the clocks are too much out of sync it will not be able to login. That was a ... fun, debugging experience.
[...] Ouch. Ouch! That must not have been a pleasant experience in any sense of the word. Knowing all too well how these things tend to go, the errors you get from the SSH log probably were very unhelpful, mostly stemming from C's bad ole practice or returning a generic unhelpful "failed" error code for all failures indiscriminately. I had to work on SSH-based code recently, and it's just ... not a nice experience overall due to the way the C code was written. T -- GEEK = Gatherer of Extremely Enlightening Knowledge
Jan 18
prev sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 18 January 2019 at 18:59:59 UTC, JN wrote:

 Just add a line in your dub.json file and you have the library. 
 Need to upgrade to newer version? Just change the version in 
 dub.json file. Need to download the problem from scratch? No 
 problem, dub can use the json file to download all the 
 dependencies in proper versions.
Any idea where we can find a gentle intro to dub?
Jan 19
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 19 January 2019 at 22:07:47 UTC, Ron Tarrant wrote:
 On Friday, 18 January 2019 at 18:59:59 UTC, JN wrote:

 Just add a line in your dub.json file and you have the 
 library. Need to upgrade to newer version? Just change the 
 version in dub.json file. Need to download the problem from 
 scratch? No problem, dub can use the json file to download all 
 the dependencies in proper versions.
Any idea where we can find a gentle intro to dub?
It looks like the best one is the "Getting Started" page on code.dlang.org: https://dub.pm/getting_started
Jan 19
parent Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 19 January 2019 at 22:15:50 UTC, Paul Backus wrote:

 It looks like the best one is the "Getting Started" page on 
 code.dlang.org:

 https://dub.pm/getting_started
Thanks, Paul. I'll take a look.
Jan 20
prev sibling parent Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 18 January 2019 at 18:48:00 UTC, H. S. Teoh wrote:

 Very nice indeed!  Welcome aboard, Ron!
Thanks, H.S.
 I used to remember most of the opcodes by heart... though 
 nowadays that memory has mostly faded away.
I used to write 6502 in my head while riding my bike to school, then write it out, do up a poke statement to jam it into RAM, and most of the time it worked first try. I was so impressed with myself.
 I won't bore you with my boring editor, vim (with no syntax 
 highlighting -- yes I've been told I'm crazy, and in fact I 
 agree
I read somewhere recently that syntax highlighting is considered a distraction, so you're not the only one. I use it mainly as a spellchecker. If it lights up, I know I spelled it right! :)
 Linux is my IDE, the whole of it :-P).
And I thought Atom had overhead! :) I do hope you know I'm kidding. I have been working up to installing Linux on something around here, too. And FreeBSD. I'm seriously short of hardware and space to set up other machines ATM, so it's going to have to wait.
Jan 19
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-01-18 15:29, Mike Parker wrote:
 Not long ago, in my retrospective on the D Blog in 2018, I invited folks 
 to write about their first impressions of D. Ron Tarrant, who you may 
 have seen in the Lear forum, answered the call. The result is the latest 
 post on the blog, the first guest post of 2019. Thanks, Ron!
 
 The blog:
 https://dlang.org/blog/2019/01/18/d-lighted-im-sure/
Regarding Dub. If you only have a project without any dependencies or perhaps only system dependencies already available on the system it might not add that much. But as soon as you want to use someone else D code it helps tremendously. Dub both acts as a build tool and a package manager. It will automatically download the source code for the dependencies, build them and handle the imports paths. As for JSON files, it's possible to use the alternative format SDL. One extremely valuable feature this has over JSON is that it supports comments. To address some of the direct questions in the blog post: "information about how I would go about packaging a D app (with GtkD) for distribution". When it comes to distribution D applications there isn't much that is specific to D. Most of the approaches and documentation that applies to any native language would apply to D as well. There are two D specific things (that I can think of for now) that are worth mentioning: * When you compile a release build for distribution, use the LDC [1] compiler. It produces better code. You can also add things like LTO (Link Time Optimization) and possibly PGO (Profile Guided Optimization). * If you have any static assets for you application, like images, sound videos, config files or similar, it's possible to embed those directly in the executable using the "import expression" [2] feature. This will read a file, at compile time, into a string literal inside the code. Some more general things about distribution. I think it's more platform specific than language specific. I can only speak for macOS (since that's the main platform I use). There it's expected to have the application distributed as a disk image (DMG). This image would contain an application bundle. An application bundle is a regular directory with the ".app" extension with a specific directory and file structure. Some applications in the OS treats these bundles specially. For example, double clicking on this bundle in the file browser will launch the application. The bundle will contain the actual executable and and resources like libraries and assets like images and audio. In your case, don't expect a Mac user to have GTK installed, bundle that in the application bundle. Then there's the issue of which versions of the platforms you want to support. For macOS it's possible to specify a minimum deployment target using the "MACOSX_DEPLOYMENT_TARGET" environment variable. This allows to build the application on the latest version of the OS but still have the application work on older versions. On *BSD and Linux it's not that easy and Linux has the additional axis of distros which adds another level of issues. The best is to compile for each distro and version you want to support, but that's a lot of work. I would provide fully statically linked binaries, including statically linked to the C standard library. This way to can provide one binary for all version of and distros of Linux and you know it will always work. "how to build on one platform for distribution on another (if that’s even possible)" I can say that it's possible, but unless you're targeting a platform that doesn't provide a compiler, like mobile or an embedded platform, I think it's rare to need to cross-compile. I'll tell you way: When building an application that targets multiple platforms you would need to test it at some point. That means running the application on all the supported platforms. That means you need to have access to these platforms. Usually a lot in the beginning when developing the application and in the end when doing final verification before a release. Having said that, I'm all for automating as much as possible. That means automatically running all the tests and building the final release build and packing for distribution. For that I recommend hooking up you're project to one of the publicly available and free CI services. Travis CI [3] is one of them that supports Linux, macOS and Windows (early release [4]). AppVeyor is an alternative that has a much more mature support for Windows. If you really want to cross-compile, it's possible if you use LDC. DMD can compile for the same platform for either 32 bit or 64 bit, but not for a different platform. I think it's simplest to use Docker. I have two Docker files for a container containing LDC setup for cross-compiling to macOS [6] and for Windows [7]. Unfortunately these Docker files pulls down the SDKs from someones (not mine) Dropbox account. [1] https://github.com/ldc-developers/ldc [2] https://dlang.org/spec/expression.html#import_expressions [3] https://travis-ci.com/ [4] https://blog.travis-ci.com/2018-10-11-windows-early-release [5] https://www.appveyor.com [6] https://github.com/jacob-carlborg/docker-ldc-darwin/blob/master/Dockerfile [7] https://github.com/jacob-carlborg/docker-ldc-windows/blob/master/Dockerfile -- /Jacob Carlborg
Jan 18
parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 18 January 2019 at 20:30:25 UTC, Jacob Carlborg wrote:

 Regarding Dub.
[stuff deleted]
 [1] https://github.com/ldc-developers/ldc
 [2] https://dlang.org/spec/expression.html#import_expressions
 [3] https://travis-ci.com/
 [4] https://blog.travis-ci.com/2018-10-11-windows-early-release
 [5] https://www.appveyor.com
 [6] 
 https://github.com/jacob-carlborg/docker-ldc-darwin/blob/master/Dockerfile
 [7] 
 https://github.com/jacob-carlborg/docker-ldc-windows/blob/master/Dockerfile
Wow. That's a lot to think about. Thanks, Jacob. Looks like I've got my weekend reading all lined up. :)
Jan 19
parent Jacob Carlborg <doob me.com> writes:
On 2019-01-19 23:13, Ron Tarrant wrote:

 Wow. That's a lot to think about. Thanks, Jacob. Looks like I've got my 
 weekend reading all lined up. :)
:) -- /Jacob Carlborg
Jan 20
prev sibling parent reply Jon Degenhardt <jond noreply.com> writes:
On Friday, 18 January 2019 at 14:29:14 UTC, Mike Parker wrote:
 Not long ago, in my retrospective on the D Blog in 2018, I 
 invited folks to write about their first impressions of D. Ron 
 Tarrant, who you may have seen in the Lear forum, answered the 
 call. The result is the latest post on the blog, the first 
 guest post of 2019. Thanks, Ron!

 As a reminder, I'm still looking for new-user impressions and 
 guest posts on any D-related topic. Please contact me if you're 
 interested. And don't forget, there's a bounty for guest posts, 
 so you can make a bit of extra cash in the process.

 The blog:
 https://dlang.org/blog/2019/01/18/d-lighted-im-sure/

 Reddit:
 https://www.reddit.com/r/programming/comments/ahawhz/dlighted_im_sure_the_first_two_months_with_d/
Nicely done. Very enjoyable, thanks for publishing this! --Jon
Jan 19
parent Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 19 January 2019 at 20:12:04 UTC, Jon Degenhardt 
wrote:

 Nicely done. Very enjoyable, thanks for publishing this!
Thanks, Jon. Glad you enjoyed it.
Jan 19