Re: docker images
On Friday, 29 June 2018 at 06:13:53 UTC, Anton Fediushin wrote: On Friday, 29 June 2018 at 04:51:49 UTC, Joakim wrote: On Thursday, 28 June 2018 at 17:54:45 UTC, Radu wrote: [...] Note that there is also an Alpine container with LDC, should be useful for building D microservices: https://hub.docker.com/r/andrewbenton/alpine-ldc/ It would be so nice if I knew about this image earlier. I ended up making my own minimal image for LDC with OpenSSL 1.1 and goinsu for privilege lowering. https://hub.docker.com/r/ohboi/minildc/ It's 153MiB, which is just 53MiB bigger than alpine-based image. I think I did a pretty good job there, most importantly there aren't any problems with musl libc, since it's based on debian-slim. Yet still I don't really use this image - LDC has some problems compiling my vibe.d applications. For every CI build I use my other image: https://hub.docker.com/r/ohboi/minidmd/ Which is the same thing, but with DMD instead. It's even smaller, only 91MiB. Try out the Alpine image and see if it doesn't have the same issue with vibe-d. Also, if you report your problem with ldc here, preferably with a reduced sample, someone will take a look: https://github.com/ldc-developers/ldc/issues
Re: docker images
On Friday, 29 June 2018 at 04:51:49 UTC, Joakim wrote: On Thursday, 28 June 2018 at 17:54:45 UTC, Radu wrote: Created a couple of docker images useful for dlang dev. LDC cross compiler for ARM - https://hub.docker.com/r/rracariu/ldc-linux-armhf/ This image allows one to easily cross compile to ARM. Main use-case is continuous integration servers. - https://hub.docker.com/r/rracariu/dub-registry/ Allows easily running a private dub repository on cloud. Note that there is also an Alpine container with LDC, should be useful for building D microservices: https://hub.docker.com/r/andrewbenton/alpine-ldc/ It would be so nice if I knew about this image earlier. I ended up making my own minimal image for LDC with OpenSSL 1.1 and goinsu for privilege lowering. https://hub.docker.com/r/ohboi/minildc/ It's 153MiB, which is just 53MiB bigger than alpine-based image. I think I did a pretty good job there, most importantly there aren't any problems with musl libc, since it's based on debian-slim. Yet still I don't really use this image - LDC has some problems compiling my vibe.d applications. For every CI build I use my other image: https://hub.docker.com/r/ohboi/minidmd/ Which is the same thing, but with DMD instead. It's even smaller, only 91MiB.
Re: docker images
On Thursday, 28 June 2018 at 17:54:45 UTC, Radu wrote: Created a couple of docker images useful for dlang dev. LDC cross compiler for ARM - https://hub.docker.com/r/rracariu/ldc-linux-armhf/ This image allows one to easily cross compile to ARM. Main use-case is continuous integration servers. - https://hub.docker.com/r/rracariu/dub-registry/ Allows easily running a private dub repository on cloud. Note that there is also an Alpine container with LDC, should be useful for building D microservices: https://hub.docker.com/r/andrewbenton/alpine-ldc/
Release Candidate 2.081.0 [was: Re: Beta 2.081.0]
On 06/17/2018 06:42 AM, Martin Nowak wrote: First release candidate for the 2.081.0 release is out now. > http://dlang.org/download.html#dmd_beta > http://dlang.org/changelog/2.081.0.html > > As usual please report any bugs at https://issues.dlang.org -Martin
docker images
Created a couple of docker images useful for dlang dev. LDC cross compiler for ARM - https://hub.docker.com/r/rracariu/ldc-linux-armhf/ This image allows one to easily cross compile to ARM. Main use-case is continuous integration servers. - https://hub.docker.com/r/rracariu/dub-registry/ Allows easily running a private dub repository on cloud.
Re: How an Engineering Company Chose to Migrate to D
IMHO, implementing a EP-to-D source code converter was probably more risky than simply extending an existing Pascal Compiler in that case. Risc is in the eye of the beholder ;-) Indeed :) But that doesn't mean I'm completely wrong. I also enjoy A LOT implementing minimalistic transpilers using the most simplistic code possible, because implementing manual tokenization and a parsing using only "baby code" is really all that's needed for my small DSLs. My Github account is literally full of them ;) So yes, implementing transpilers is incredibly fun and easy. But implementing full blown compilers too actually. And the advantage of compilers which generate assembly code is that you don't have to fight with the unavoidable limitations of the high-level target language. For instance I've implemented my first "true" compiler in Basic when I was 13 years old, in order to implement my first 3D renderer and game for my C64 (a simple 3D wireframe tank game using a custom 2x4 pixel charset for rendering), as I quickly found out that it was actually much faster and easier to implement it in a minimalistic basic-like language with integrated fixed point and pointer arithmetic converted into 6502 machine language, than to implement the game directly in 6502 assembler. So if at one moment you hit a wall with the transpiling approach, you should consider trusting me if I say that implementing an EP compiler which emits IL code could actually be just a matter of months. Look at the code of this tutorial, which shows how to implement a very limited closure-based language (i.e. with local functions and variable) in C using just Flex and Bison : https://github.com/senselogic/COMPILER_TUTORIAL It was implemented in just a few days, and if you check by yourself, you will see that it's 100% baby code... So if you change your mind and decide to implement your own extended EP compiler (i.e. with additional modern features), you could be astonished by the number of passionate developers who could also be interested in this "modern object Pascal" project... That's the approach they've had for Crystal, and so far it's worked quite well for them...