Re: [Semi-OT] Cross-Platform GitHub Action 0.3.0 - NetBSD
On Tuesday, 16 November 2021 at 14:38:48 UTC, Sebastiaan Koppe wrote: I was reading https://github.com/marketplace/actions/cross-platform-action#under-the-hood and have to say I am impressed. Looks like a very well done library. Thanks. Yeah, it turned out to be quite complex to support everything. Multiple platforms, multiple hypervisors, multiple hosts platforms etc. -- /Jacob Carlborg
Re: [Semi-OT] Cross-Platform GitHub Action 0.3.0 - NetBSD
On Tuesday, 16 November 2021 at 14:04:12 UTC, Imperatorn wrote: Oh, nice to see support for FreeBSD. I just added a version for it in druntime 4 days ago. Now maybe we can test it lol I can add older versions of FreeBSD (currently 12.2 and 13 are supported) if there's a need for that. /Jacob Carlborg
[Semi-OT] Cross-Platform GitHub Action 0.3.0 - NetBSD
# Cross-Platform GitHub Action 0.3.0 I would like to announce a new release of [Cross-Platform GitHub Action](https://github.com/marketplace/actions/cross-platform-action), [0.3.0](https://github.com/cross-platform-actions/action/releases/tag/v0.3.0). For those not familiar with this project, it provides a GitHub action for running GitHub Action workflows on multiple platforms. This includes platforms that GitHub Actions don't natively support (for more information see the original announcement of the project [1]). The major new feature in this release is the support for a new platform: NetBSD. The only supported version so far is 9.2. Other minor features since the last announcement are support for FreeBSD 13 and OpenBSD 6.9. ## Under the Hood For those interested in what's going on under the hood. This release contains some major refactoring to add support for the QEMU hypervisor. Up until now the xhyve hypervisor has been used for the FreeBSD and OpenBSD platforms. Unfortunately NetBSD doesn't run on the xhyve hypervisor, therefore support for QEMU was added. In this release it's only possible to run NetBSD on Linux hosts. The GitHub Linux runners doesn't support hardware accelerated nested virtualization. This unfortunately means that the QEMU hypervisor will be a bit slower than the xhyve hypervisor. [1] https://forum.dlang.org/post/jhasyhuvcxoqhldlb...@forum.dlang.org
Re: OpenBSD DMD package
On Thursday, 14 October 2021 at 16:14:17 UTC, Brian wrote: Awesome! I will spend some time soon figuring it out. Here are two real world examples: https://github.com/jacob-carlborg/lime/blob/master/.github/workflows/ci.yml https://github.com/jacob-carlborg/dlp/blob/master/.github/workflows/ci.yml -- /Jacob Carlborg
Re: OpenBSD DMD package
On Tuesday, 12 October 2021 at 12:42:09 UTC, Brian wrote: I don't think any of the free ones support OpenBSD yet :) There is SourceHut, which does support OpenBSD CI, but I don't think it is free to use. You can use my GitHub action: https://github.com/marketplace/actions/cross-platform-action. -- /Jacob Carlborg
Re: Diva - D Language Interface for Versioned Applications
On Saturday, 10 July 2021 at 12:30:43 UTC, Bastiaan Veelo wrote: Thanks for clarifying the differences. 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
Re: [Semi-OT] Cross-Platform GitHub Action
On Tuesday, 8 June 2021 at 20:39:45 UTC, Steven Schveighoffer wrote: I might have a need for it. When I moved mysql-native to github actions, I could no longer run mysql integration tests on MacOS or Windows, since there is no docker support for a mysql instance on those platforms. I can probably install mysql manually at some point, but I haven't looked into it. At least for MacOS, this sounds like a way I can run a mysql instance that the MacOS host can talk to. I don't think that would work. The VM is only running during one step. When the step is done, the VM is terminated. Also, Docker doesn't support FreeBSD or OpenBSD. I don't plan to add platforms which GitHub Actions natively support. On the other hand, it seems pretty straightforward to install MySQL natively on macOS: ``` brew install mysql brew services start mysql ``` There are also several GitHub Actions that will setup MySQL: https://github.com/marketplace?type=actions=mysql -- /Jacob Carlborg
Re: [Semi-OT] Cross-Platform GitHub Action
On Tuesday, 8 June 2021 at 19:40:01 UTC, kinke wrote: Thx for sharing! Interesting; I've recently worked on something similar, but on Linux hosts and using a kvm/qemu/libvirt stack for running CI jobs in Windows VMs. Yeah, this is running on macOS instead because the Linux and the Windows runners on GitHub actions don't support nested virtualization. The Hypervisor framework is something similar to KVM. The VM images are actually created using QEMU (on Linux hosts), because Packer doesn't have any support for Xhyve. Packer will create a qcow2 VM image. At run time, the qcow2 image will be converted to the "raw" format, which is the only format that Xhyve supports. qcow2 is used up until runtime because it natively supports compression. I do want to support other operating systems going forward, but unfortunately, it's only FreeBSD and OpenBSD that work in Xhyve. For other operating systems I will have to use QEMU. QEMU does support the Hypervisor framework as an accelerator, but I don't think it will be as fast as Xhyve. When QEMU is supported, it will hopefully be trivial to add support for non-native architectures. I've already built the OpenBSD image for ARM64. -- /Jacob Carlborg
[Semi-OT] Cross-Platform GitHub Action
# Cross-Platform GitHub Action
I would like to announce the first version of a project I've been
working on for a while. It's not anything D specific or
implemented in D, but it can be used with D projects. This
project provides a GitHub action for running GitHub Action
workflows on multiple platforms. This includes platforms that
GitHub Actions don't natively support. It currently supports
FreeBSD and OpenBSD.
https://github.com/cross-platform-actions/action
## Features
Some of the features that are supported include:
* Multiple operating system with one single action
* Multiple versions of each operating system
* Allows to use default shell or Bash shell
* Low boot overhead
* Fast execution
Compared to
[vmactions/freebsd-vm](https://github.com/vmactions/freebsd-vm),
the boot time is around a fifth and the full execution time for
the same job is around half of freebsd-vm.
## Usage
Here's a sample workflow file which will setup a matrix resulting
in two jobs.
One which will run on FreeBSD 12.2 and one which runs on OpenBSD
6.8.
```yaml
name: CI
on: [push]
jobs:
test:
runs-on: macos-10.15
strategy:
matrix:
os:
- name: freebsd
version: 12.2
- name: openbsd
version: 6.8
steps:
- uses: actions/checkout@v2
- name: Test on ${{ matrix.os.name }}
uses: cross-platform-actions/action@v0.0.1
env:
MY_ENV1: MY_VALUE1
MY_ENV2: MY_VALUE2
with:
environment_variables: MY_ENV1 MY_ENV2
operating_system: ${{ matrix.os.name }}
version: ${{ matrix.os.version }}
shell: bash
run: |
uname -a
echo $SHELL
pwd
ls -lah
whoami
env | sort
```
I've been using this action for one of my own projects
([DLP](https://github.com/jacob-carlborg/dlp/runs/2759807903))
for now close to a week and it works fine. It's mostly FreeBSD
that has been tested.
If you're interested in how the sausage is made, read on. Also
see the readmes of the builder repositories:
https://github.com/cross-platform-actions/freebsd-builder
https://github.com/cross-platform-actions/openbsd-builder
## Under the Hood
GitHub Actions currently only support the following platforms:
macOS, Linux and
Windows. To be able to run other platforms, this GitHub action
runs the commands
inside a virtual machine (VM). macOS is used as the host platform
because it
supports nested virtualization.
The VMs run on the [xhyve][xhyve] hypervisor, which is built on
top of Apple's
[Hypervisor][hypervisor_framework] framework. The Hypervisor
framework allows
to implement hypervisors with support for hardware acceleration
without the
need for kernel extensions. xhyve is a lightweight hypervisor
that boots the
guest operating systems quickly and requires no dependencies
outside of what's
provided by the system.
The VM images running inside the hypervisor are built using
[Packer][packer].
It's a tool for automatically creating VM images, installing the
guest
operating system and doing any final provisioning.
The GitHub action uses SSH to communicate and execute commands
inside the VM.
It uses [rsync][rsync] to share files between the guest VM and
the host. xhyve
does not have any native support for sharing files. To
authenticate the SSH
connection a unique key pair is used. This pair is generated each
time the
action is run. The public key is added to the VM image and the
private key is
stored on the host. Since xhyve does not support file sharing, a
secondar hard
drive, which is backed by a file, is created. The public key is
stored on this
hard drive, which is then mounted by the VM. At boot time, the
secondary hard
drive will be identified and the public key will be copied to the
appropriate
location.
To reduce the time it takes for the GitHub action to start
executing the
commands specified by the user, it aims to boot the guest
operating systems as
fast as possible. This is achieved in a couple of ways:
* By downloading [resources][resources], like xhyve and a few
other tools,
instead of installing them through a package manager
* No compression is used for the resources that are downloaded.
The size is
small enough anyway and it's faster to download the
uncompressed data than
it is to download compressed data and then uncompress it.
* It leverages `async`/`await` to perform tasks asynchronously.
Like
downloading the VM image and other resources at the same time
* It performs as much as possible of the setup ahead of time when
the VM image
is provisioned
[xhyve]: https://github.com/machyve/xhyve
[hypervisor_framework]:
https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/index.html
[rsync]: https://en.wikipedia.org/wiki/Rsync
[resources]: https://github.com/cross-platform-actions/resources
[packer]:
Re: (Oh My) Gentool 0.3.0 released
On 2021-05-05 13:54, user1234 wrote: Thanks for the explanations. BTW I had the same question for LDC backend being c++, I guess the answer would be similar. If I understand correctly, the Zig compiler is implemented partially in Zig. It use the LLVM C API and some wrappers C around the C++ API where the C API is not sufficient. -- /Jacob Carlborg
Re: (Oh My) Gentool 0.3.0 released
On 2021-05-05 12:01, user1234 wrote: Is it possible to use libclang and more generally LLVM c++ api [directly in D](https://dlang.org/spec/cpp_interface.html) or the Cpp interface is too limited ? Was this an option, have you tried ? Yes, it's possible to use libclang. DStep [1] is using that and it fully written in D. Although DStep cannot create bindings for C++ yet so I cannot guarantee that using only libclang will work for C++ code. [1] https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
Re: Cross-compiler targeting macOS
On 2021-04-10 15:50, kinke wrote: Thanks Jacob, I'm sure this was quite a bit of work, and opening up proprietary SDKs for non-native systems is always welcome. Thumbs up! Thanks. -- /Jacob Carlborg
Re: Cross-compiler targeting macOS
On 2021-04-08 18:36, H. S. Teoh wrote: Thanks for this, it is very helpful. You're welcome. I'm glad that it's useful to someone. I just created a tag [1] (no changes yet), if I would like to make some changes in the future. [1] https://github.com/d-cross-compiler/docker-ldc-darwin/tree/v0.0.1 -- /Jacob Carlborg
Cross-compiler targeting macOS
# Docker LDC Darwin
I would like to announce a new project I'm working on:
docker-ldc-darwin [1]. The project consists of a Dockerfile for
building a Docker image which has all the necessary tools to
cross-compile D applications targeting macOS x86-64.
## Features
* Uses Apple's ld64 linker so all features that are being used
when linking on macOS should work. No reliance on custom linkers
that need to be kept up to date with the system linker
* Ships with the full macOS SDK (for macOS version 10.15.4)
* No reliance on hacks like allowing undefined symbols when
linking like Zig and Rust does
* Minimal Docker image. Only the exact files that are required to
run the compiler and linker are included. Not even a shell is
included
* The Docker image, all tools and resources are fully
reproducible and automated. No manual steps involved of uploading
to random cloud storage accounts
The following tools are included:
* dub
* ldc2
* ldmd2
* rdmd
* ld64 (linker)
* clang (C compiler, used for linking)
## Building
### Prerequisites
* [git](https://git-scm.com)
* [Docker](https://www.docker.com)
### Building the Docker Image
Follow the steps below to build the Docker images by running the
commands in
the terminal:
1. Clone the git repository:
```
git clone
https://github.com/d-cross-compiler/docker-ldc-darwin && cd
docker-ldc-darwin
```
1. Build the Docker image:
```
docker build -t ldc-x86_64-apple-macos .
```
## Usage
By default, the `ldc2` compiler will be invoked.
### Compiling Hello World
Compile Hello World:
```
$ uname
Darwin
$ cat < main.d
import std;
void main()
{
writeln("Hello World");
}
EOF
$ docker run --rm -v "$(pwd):/work" ldc-x86_64-apple-macos main.d
$ ./main
Hello World
```
For more information and examples, see the readme [1].
[1] https://github.com/d-cross-compiler/docker-ldc-darwin
--
/Jacob Carlborg
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On 2021-02-24 17:32, Imperatorn wrote: What happened to utiliD? Broken link to gh I think Mike gave up on D. -- /Jacob Carlborg
Re: Windows Bindings v1.1
On 2021-02-20 15:03, Rumbu wrote: - new attributes (currently ignored): RetVal, NullNullTerminated, NotNullTerminated Regarding the ignored attributes. You could always output these as UDAs. It would not add any semantic meaning, but could serve as documentation. In theory, it would be possible to create a separate tool that will perform some semantic checks on these UDAs. -- /Jacob Carlborg
Re: Article: Why I use the D programming language for scripting
On Sunday, 31 January 2021 at 20:36:43 UTC, aberba wrote: It's finally out! https://opensource.com/article/21/1/d-scripting FYI, the code will compile faster if you use `dmd -run` instead of `rdmd`. If you have multiple files that need to be compiled you can use `dmd -i -run`. -- /Jacob Carlborg
Re: Printing shortest decimal form of floating point number with Mir
On 2021-01-06 03:30, Walter Bright wrote: The baseline Linux target does not have SSE. What about this changelog entry: https://dlang.org/changelog/2.087.0.html#xmm-linux-changelog ? -- /Jacob Carlborg
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On 2021-01-06 10:21, Mike Parker wrote: This is the discussion thread for the first round of Community Review of DIP 1039, "Static Arrays with Inferred Length": https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md There's `staticArray` to solve this issue [1]. [1] https://dlang.org/phobos/std_array.html#.staticArray -- /Jacob Carlborg
Re: Printing shortest decimal form of floating point number with Mir
On 2021-01-06 03:30, Walter Bright wrote: The baseline Linux target does not have SSE. Other compilers solve this by having a flag to specify the minimum target CPU. -- /Jacob Carlborg
Re: I'm creating a game purely written in D with the arsd library
On 2021-01-02 22:21, H. S. Teoh wrote: Nope. Reverse-engineering is a thing. There's even tools out there to automate this stuff. Or you can try to prevent reverse engineering. This is both an interesting and fun talk [1]. [1] https://www.youtube.com/watch?v=HlUe0TUHOIc -- /Jacob Carlborg
Re: DLP - D Language Processing 0.3.0 - infer attributes
On 2020-12-19 00:26, Dave P. wrote: Looks very useful. Something strange I noticed though, it seems to be doing the analysis in 32 bits? I had some static assertions go off due to this which halted the program. Wow, I haven't noticed that. That's not indented. I've created an issue [1] and I'll take a look at it. [1] https://github.com/jacob-carlborg/dlp/issues/7 -- /Jacob Carlborg
DLP - D Language Processing 0.3.0 - infer attributes
I would like to announce a new release of DLP, 0.3.0. For those not familiar with DLP, it's a tool collecting commands/tasks related to processing the D programming language. It uses the DMD frontend as a library to process D code. The major new feature in this release a new command that has been added: `infer-attributes`. This command will print the inferred attributes of all functions that are normally not inferred by the compiler. These are regular functions and methods. Templates, nested functions and lambdas are inferred by the compiler and will not be included by this command. By default, virtual methods are not inferred. Use the flag `--include-virtual-methods` to enable inferring of virtual methods. The attribute inference is enabled only on the file that is currently being processed. This is to avoid the tool outputting attributes that would not be valid unless other files are modified. For example, your code is calling a third-party function. The third-party function is inferred to be `pure`. Now your function is inferred to be `pure` as well. But if you only change your function to be `pure`, it will fail to compile because the third-party function has not been updated. The intention of this command is to help you in adding attributes to your code. You don't have to figure out exactly which attributes you can add to a function, just have the compiler tell you instead. It's recommend to run DLP in an iterative process. Run it on a file, update the file with the new attributes, run it again and repeat the process until the tool doesn't output any more inferred attributes. The release is available here [1]. Pre-compiled binaries are available for macOS, FreeBSD and Linux 64bit and Windows 32bit and 64bit. For the full change log, see [1]. [1] https://github.com/jacob-carlborg/dlp/releases/tag/v0.3.0 -- /Jacob Carlborg
Re: Httparsed - fast native dlang HTTP 1.x message header parser
On 2020-12-14 22:59, tchaloupka wrote: Hi, I was missing some commonly usable HTTP parser on code.dlang.org and after some research and work I've published httparsed[1]. This is awesome. I wanted to use picohttpparser myself and used the C version. But if you already have created a HTTP parser with the same properties in D, that's even better. -- /Jacob Carlborg
Re: Preparing for Google Summer of Code 2021
On Monday, 23 November 2020 at 13:34:14 UTC, Petar Kirov [ZombineDev] wrote: Thanks, I've just added the gsoc2020 label for these issues. I will ping someone to give you permissions for the repo ;) Shouldn't it be gsoc2021? We're already past GSoC 2020 ;) -- /Jacob Carlborg
Re: requests 2.0.0 release
On 2020-11-01 11:13, Sönke Ludwig wrote: ddb marks the vibe-d dependency as optional, so it *should* not trigger a download by itself. It does not trigger a download. The downside is that user of the library needs to manually add vibe.d as a dependency. -- /Jacob Carlborg
Re: requests 2.0.0 release
On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: Hi, requests 2.0.0 released with single change - support for vibe-d moved to separate subpackage. The goal of this update is to prevent dub from downloading vibe-d packages for optional subConfiguration. Another approach is to check if vibe.d is available using version conditions [1]. This is how the DDB [2] package supports both vibe.d sockets and Phobos sockets. [1] https://github.com/pszturmaj/ddb/blob/97bc3652b05492e7917888c92e59f4576a69dfa8/source/ddb/postgres.d#L189-L216 [2] https://code.dlang.org/packages/ddb -- /Jacob Carlborg
Re: Beta 2.094.0
On 2020-09-18 23:14, John Colvin wrote: I know. But it should be. dub.selections.json wasn't available in the initial version. I don't remember if branches were deprecated before or after dub.selections.json was added. -- /Jacob Carlborg
Re: Beta 2.094.0
On 2020-09-17 12:10, John Colvin wrote: I personally think it's not so bad as long as the commit gets written to the dub.selections.json It doesn't. -- /Jacob Carlborg
Re: Beta 2.094.0
On 2020-09-16 19:20, mw wrote: Why it's deprecated? can we revive it? It was deprecated because it's a bad idea to not lock versions. Using `~master` would fetch the latest code from the "master" branch when compiling. You never know which version you get. You don't get reproducible builds. -- /Jacob Carlborg
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Thursday, 3 September 2020 at 08:40:32 UTC, aberba wrote: The slack I have no ideas how people get in. I know there's a number of members in there too. Unfortunately you need to be invited. Anyone can do it, if you're interested. We just need an email address. -- /Jacob Carlborg
Re: Symmetry Investments and the D Language Foundation are Hiring
On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote: Looking for a full-time or part-time gig? Not only is Symmetry Investments hiring D programmers, they are also generously funding two positions for ecosystem work under the D Language Foundation. And they've put up a bounty for a new DUB feature. Read all about it here: https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ As an alternative to use SHA-1 hashing. There's the option to have a daemon running the background listing on filesystem events. BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? -- /Jacob Carlborg
Re: Visual D 1.0.1 released
On Tuesday, 25 August 2020 at 20:37:38 UTC, Per Nordlöw wrote: I'm dying to get a semantic engine that supports code navigation to (and completion of) overloaded functions at their call site including UFCS-calls. DCD doesn't support these two features. I have interest in a LSP server based on the DMD frontend as well. There's also a SAoC 2020 project related to DMD as a library [1]. Was there another master thesis (or similar) that would work on a LSP server as well? Either sponsored by Symmetry or related to the University of Bucharest. We should try to work together instead of duplicating the work. Although I've given up on the DMD upstream project and instead, I've forked it [2] to be able to do the necessary changes. [1] https://dlang.org/blog/2020/08/23/symmetry-autumn-of-code-2020-projects-and-participants [2] https://github.com/jacob-carlborg/ddc -- /Jacob Carlborg
Re: Release D 2.093.0
On 2020-07-12 11:04, Martin Nowak wrote: Glad to announce D 2.093.0, ♥ to the 54 contributors. I just tried to use this release in a GitHub Action using the "dlang-community/setup-dlang@v1" action. I got an error about the signature is not trusted. I tried 2.092.0, that works fine. Here's the full output: Downloading http://downloads.dlang.org/releases/2.x/2.093.0/dmd.2.093.0.osx.tar.xz 7 Verifying the download with GPG 8 gpg: Signature made Tue Jul 7 13:27:08 2020 UTC 9 gpg:using RSA key 3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8 10 gpg: directory '/Users/runner/.gnupg' created 11 gpg: /Users/runner/.gnupg/trustdb.gpg: trustdb created 12 gpg: Good signature from "Martin Nowak " [unknown] 13 gpg: aka "Martin Nowak " [unknown] 14 gpg: aka "Martin Nowak " [unknown] 15 gpg: WARNING: This key is not certified with a trusted signature! 16 gpg: There is no indication that the signature belongs to the owner. 17 Primary key fingerprint: F46A 10D0 AB44 C3D1 5DD6 5797 BCDD 73FF C3EB 6146 18 Subkey fingerprint: 3AAF 1A18 E61F 6FAA 3B71 93E4 DB8C 5218 B932 9CF8 -- /Jacob Carlborg
Re: Documentation repository for Hunt Framework !
On Thursday, 9 July 2020 at 16:37:16 UTC, zoujiaqing wrote: I want to improve the documentation for the application layer first. Let more people use the framework quickly. Later, we will improve the underlying documents when the underlying library API is stable. Fair enough. -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 00:39:49 UTC, Manu wrote: Even DMD itself is too large a D project for Code-D to work well with. I have not used Code-D, but I am using TextMate with DCD integrated. It has no problem with the DMD project. But it only supports go-to-definition, autocomplete and showing documentation for symbols. When opening a project which contains a dub.sdl/dub.json file, the editor reads the import paths. Then it opens a new instance of DCD (one per project) and passes the imports paths to it. Code-D often can't even go to the definition of D functions in D code reliably ;) Yeah, VisualD has a huge advantage since it's now using the DMD frontend for these things. For example, DCD does not support UFCS, which is really annoying. -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 06:46:53 UTC, Rainer Schuetze wrote: There is an extension using DLS as an LSP: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang It's been some time, but when I tried to use that along side Visual D, it caused problems because both are trying to be a language service for the same language. I was more hoping for the engine in VisualD to be the new DCD or DLS, since it's already using the DMD frontend for some things. Then it can be used by other editors and IDEs, hint hint, wink wink ;) -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 05:07:38 UTC, Petar Kirov [ZombineDev] wrote: So, having had to edit both VS *.*proj files and Makefiles manually, I'd say that Makefiles are orders of magnitude more approachable and easier for me. MSBuild is just a giant PITA in my experience. Though I agree that I don't find Makefiles enjoyable either :D, but at least I can more easily track changes to them in VCS. FYI, Visual Studio has native support for CMake projects these days. -- /Jacob Carlborg
Re: Documentation repository for Hunt Framework !
On Tuesday, 30 June 2020 at 15:40:14 UTC, zoujiaqing wrote: I'm glad we've released the first set of Hunt Framework today. Make it easier for you to use Hunt Framework. Hope more people can work with us to improve the content of the document. https://github.com/huntlabs/hunt-framework-docs Really nice to see some documentation. I would love to see some documentation on the internals, especially related to the event loop, concurrency and similar. -- /Jacob Carlborg
Re: Visual D 1.0.0 released
On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov [ZombineDev] wrote: What I really wish is we had a single shared codebase for dlang editor support, that could be shared among editor extension writers, instead of having many community members working on competing solutions. That would be really nice. Doesn't Visual Studio (not VSCode) supports LSP these days? -- /Jacob Carlborg
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Sunday, 5 July 2020 at 14:29:22 UTC, IGotD- wrote: It's a resource question again. I'm all for that for example D should have a native alternative to curl including SSL/TLS support. If someone is willing to invest the man hours into such project, I'm all for it. Nim went that way having partial native http support so it isn't impossible. I agree, that would be really nice. Unfortunately it's quite tricky if you want to integrate with the platform provided TLS implementation [1]. Unless you're suggesting to create a crypto library from scratch, which is a whole different beast, and probably a bad idea [2]. [1] https://forum.dlang.org/post/prsrbzoanxwytrtpy...@forum.dlang.org [2] https://forum.dlang.org/post/hsmjcgxzujgwsiegi...@forum.dlang.org -- /Jacob Carlborg
Re: Hunt Framework 3.0.0 Released, Web Framework for DLang!
On 2020-05-09 09:02, zoujiaqing wrote: ( hunt library is currently the best performing network io in D languages.) Would be interesting to see how Hunt and Mecca [1] compare. Mecca is quite a basic library, compared to Hunt. It doesn't support anything more high level than TCP sockets. http://github.com/weka-io/mecca -- /Jacob Carlborg
Re: Blog Post #0105: D-specific Stuff for GUI Programming
On Monday, 23 March 2020 at 10:41:43 UTC, Jacob Carlborg wrote:
class DSingleton
{
immutable DSingleton instance = new DSingleton;
}
Should of course be `static`:
class DSingleton
{
static immutable DSingleton instance = new DSingleton;
}
--
/Jacob Carlborg
Re: Blog Post #0105: D-specific Stuff for GUI Programming
On Monday, 23 March 2020 at 10:26:33 UTC, Jacob Carlborg wrote:
If it's enough with CTFE compatible code in the constructor,
the following is a much simpler version:
class DSingleton
{
private __gshared DSingleton instance = new DSingleton;
DSingleton get()
{
return instance;
}
}
Or if an immutable instance work, the getter is not necessary and
the instance can be exposed directly.
class DSingleton
{
immutable DSingleton instance = new DSingleton;
}
--
/Jacob Carlborg
Re: Blog Post #0105: D-specific Stuff for GUI Programming
On Monday, 23 March 2020 at 10:02:48 UTC, Ron Tarrant wrote:
Today starts a new series I'm calling Snippets and it's about
various D-specific stuff that may come in handy when building a
GUI. You can find it right here:
https://gtkdcoding.com/2020/03/23/0105-dlang-ui-snippets-i.html
If it's enough with CTFE compatible code in the constructor, the
following is a much simpler version:
class DSingleton
{
private __gshared DSingleton instance = new DSingleton;
DSingleton get()
{
return instance;
}
}
--
/Jacob Carlborg
Re: DIP 1027---String Interpolation---Format Assessment
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright wrote:
I don't know Swift, but this looks like the "generate strings
and concatenate them" approach.
No, it basically lowers to bunch of method calls. Here's an
example of how it could look like with D syntax:
auto a = 3;
auto b = i"foo $a bar";
Could be lowered to:
auto _temp = StringInterpolation(8 /* literal capacity */, 1 /*
interpolation count */);
_temp.appendLiteral("foo ");
_temp.appendInterpolation(a);
_temp.appendLiteral(" bar");
auto b = _temp.toString();
There's nothing here that says that this needs to use the GC to
allocate the final string. "StringInterpolation" could contain
something like OutBuffer from DMD or, if the arguments were
passed as template arguments, it could allocate on the stack.
--
/Jacob Carlborg
Re: LDC 1.20.0
On 2020-02-15 07:17, zoujiaqing wrote: Thanks LDC team! Thanks Jacob for iOS/tvOS/watchOS on AArch64! Thanks :) -- /Jacob Carlborg
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Tuesday, 12 November 2019 at 09:15:28 UTC, SealabJaster wrote:
And if you do allow things such as letting classes have a
'deserialise' member function which can be overloaded, you
still need to create or be given an instance of the class
beforehand, which brings things back around to the "constructor
issue" in the latest post.
I don't quite know if there's actually an automatic solution
for classes that covers most cases? Anything I can think of
places limitations in some form or another.
They way I handled this in Orange [1] which allows to
(de)serialize third party types which you don't have any control
of. First, structs have the same problem as classes: there can be
private members. They way this is handled is to use `.tupleof`.
`.tupleof` will bypass the protection and allows to read and
write private fields:
module foo;
class Foo
{
private int a;
int getA() { return a; }
}
module main;
import std.stdio;
import foo;
void main()
{
auto foo = new Foo;
foo.tupleof[0] = 3;
assert(foo.getA == 3);
assert(foo.tupleof[0] == 3);
}
`.tupleof` is used both for serialization and deserialization. To
create an instance of a class use the same way as the runtime
does. This function [2] is called by the compiler when the code
contains "new Object" (extracted to Orange here [3]). This will
not call a constructor, but that's fine since we will set the
fields anyway directly after.
Orange also offers a way to tweak the (de)serialization process
with hooks. You can define methods in your structs or classes
with any of the following UDAs: `onSerializing`, `onSerialized`,
`onDeserializing` and `onDeserialized`. These method will be
called (if they exist) before/after the (de)serialization process
[4]. This allows you do preform some post-processing that might
be needed since no constructor has been called on deserialization.
When it comes to (de)serializing derived types through a base
class reference Orange requires you do register all derived types
[5].
Then there's the problem with non-mutable fields and instances as
well. But you can just cast away those when deserializing.
There's also the issue with circular references [6]. But that's
pretty easy to solve by storing all serialized instances to see
if they have already been serialized or not.
[1] http://github.com/jacob-carlborg/orange
[2]
https://github.com/dlang/druntime/blob/873fac33014c5af680c4bed69bb74cb0f192198a/src/rt/lifetime.d#L73
[3]
https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/util/Reflection.d#L149-L183
[4]
https://github.com/jacob-carlborg/orange/blob/master/tests/Events.d
[5]
https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/serialization/Serializer.d#L241-L262
[6]
https://github.com/jacob-carlborg/orange/blob/master/tests/CircularReference.d
--
/Jacob Carlborg
Re: Proposal for porting D runtime to WebAssembly
On 2019-11-23 10:51, Sebastiaan Koppe wrote: This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d What will happen to code that uses TLS? Will it be promoted to a global variable or will it fail to compile? -- /Jacob Carlborg
Re: dud: A dub replacement
On Wednesday, 20 November 2019 at 11:40:19 UTC, Robert Schadek wrote: Here is disagree, to a degree I consider comments a code smell. If I have to write them, I failed to convey the information needed to understand the code in the code. You think this is a code smell: https://dlang.org/phobos/std_array.html ? -- /Jacob Carlborg
Re: dud: A dub replacement
On Sunday, 17 November 2019 at 19:10:05 UTC, Sebastiaan Koppe wrote: SDL all the way please. Perhaps this ship has already sail. But YAML would have been a better choice. It's a superset of JSON. All the existing JSON description files would have worked as is. -- /Jacob Carlborg
Re: dud: A dub replacement
On 2019-11-11 14:44, Robert Schadek wrote: So dub has some problems, and personally I find its code base very hard to get into. At Symmetry we are a very heavy user of dub, resulting in many wasted hours. So I started to write dud [1]. I kept some boring/nice parts from dub, but most code so far is a complete rewrite. Hmm, that's unfortunate. It happens way too often in the D community, that a project is rewritten from scratch instead of improving the existing one. Especially since the D community is not that big. Although I can understand the choice. Even if you were to contribute there would be no one to merge the pull requests :(. -- /Jacob Carlborg
Re: Release D 2.089.0
On Thursday, 7 November 2019 at 10:25:46 UTC, Ron Tarrant wrote: I follow the steps outlined here: https://github.com/gtkd-developers/GtkD/wiki/Installing-on-Windows And one of those steps (Step #5) says to copy the gtkd libs to the compiler's directory tree. Is that what you mean by "You really shouldn't be doing the former."? And I also edit sc.ini. I recommend that you use Dub instead and add gtk-d [1] as a dependency. [1] https://code.dlang.org/packages/gtk-d -- /Jacob Carlborg
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On 2019-11-06 02:02, sarn wrote: And the neat way to do that is with a multi-stage build: one Dockerfile, with an Alpine container building the binary, then copying to a FROM scratch container I've used the "smith" tool as well [1]. It has some additonal help with dynamically linked code. It will use "ldd", recursively, to track dependencies and automatically add those. It will also do a couple of other things, like making the filesystem read only. The musl build is practically necessary because glibc has effectively given up standalone static binary support. So, thanks BPF Korea :) Yeah, it helps. Although it still possible to statically link with glibc, although you might get some warnings. [1] https://github.com/oracle/smith -- /Jacob Carlborg
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 11:49:20 UTC, Daniel Kozak wrote: Generally no, because Apline use musl libc instead of glibc, so there are some issues with that The correct way is to use static linking and putting only the binary in a Docker image, i.e. "from scratch" [1] ;). But using Alpine and musl will help with building the binary. [1] https://hub.docker.com/_/scratch
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Friday, 1 November 2019 at 11:29:11 UTC, Ethan wrote: string is immutable(char)[], as we all know. Syntactic sugar, not exactly a built in type but treating it like one is often valuable. It's an alias, but what it's aliased to is a built-in type. -- /Jacob Carlborg
Re: Blog series to teach and show off D's metaprogramming by creating a JSON serialiser
On Thursday, 31 October 2019 at 00:05:06 UTC, SealabJaster wrote: https://bradley.chatha.dev/Home/Blog?post=JsonSerialiser1 FYI, string is a built-in type. Regarding exercise 2. I would be very careful with deserializing a single character from JSON. First, because JSON doesn't support single characters. Second, you'll run into issues with Unicode. For example, you would need to know the exact JSON content, not just the type, to specify the type that should be deserialized. Example: assert(json.deserialise!char() == ''); The above will not work, because the type of '' is not `char`, it's `dchar`. The deserialization would need to throw an exception in this case, because '' won't fit in a `char`. It's much simpler to just not allow this use case. -- /Jacob Carlborg
Re: Build your dub packages with Github Actions
On 2019-09-07 00:02, Andre Pany wrote: Hi, Just a small info, building your D application using Github Actions just works out of the box thanks to the install.sh script! This configuration will install a "dub build" pull request voter: https://github.com/andre2007/coding-puzzles/blob/master/.github/workflows/blank.yml Oh, cool. I didn't know about GitHub actions. Of course, there's no D template among the other languages [1] :( [1] https://github.com/actions/starter-workflows/tree/master/ci -- /Jacob Carlborg
Re: Release D 2.088.0
On Tuesday, 3 September 2019 at 10:02:26 UTC, a11e99z wrote: On Tuesday, 3 September 2019 at 07:57:00 UTC, Martin Nowak wrote: This release comes with a new C:\programz\D>dmd --version DMD32 D Compiler v2.088.0-dirty what is ..-dirty? It means the git repository was not clean when the compiler was built. — /Jacob Carlborg
Re: Five Projects Selected for SAOC 2019
On 2019-08-26 05:55, Andrej Mitrovic wrote: I'm guessing this means we might even be able to use multiple versions of Phobos one day. However before we do that, we will really need to fix the use of globals in Phobos. I don't think that's necessary. All symbols will have the version be part of the mangled name. -- /Jacob Carlborg
Re: Mecca available on macOS
On 2019-08-07 19:45, Ron Tarrant wrote: I'm not familiar with Mecca. What is a Container/reactor library? I guess it's a reactor library. I see it as a library providing fiber based non-blocking IO. It also provides containers, logging, reflection, serialization and a bunch of other things that are usually found in a standard library. -- /Jacob Carlborg
Mecca available on macOS
I would like to announce that I've ported Mecca [1] to macOS. It was merged in May but I never bothered to announce it until now. Everything except the file watcher has been ported and is working. Unfortunately the unit tests fail in Travis CI, but they pass locally and in Circle CI. Something related to a timer that is failing. When it comes to the implementation, it's structured so that the new code will work on any Darwin platform (it's only tested on macOS). In this process I also moved some platform specific code for Linux to the `mecca.platform` and `mecca.reactor.platform` packages. This means that all platform specific code lives in these two packages and there are no version blocks outside of these packages (as far as I could find). The version blocks that exist are very few, due the the platform specific code lives in their own files. They're just needed to import the correct platform specific file. I think this turned out really nice compared to the mess that's in druntime, where most files are littered with version blocks. The Darwin implementation uses kqueue, which is available on other platforms as well, like the various BSD flavors. The kqueue specific code is guarded with its own version block to make it possible to reuse on other platforms, if someone wants to port Mecca to a new platform. Some timer related code is implemented using libdispatch on Darwin, but I think this could be implemented using kqueue as well. I think libdispatch is available on *BSD as well, but might not be installed by default. [1] https://github.com/weka-io/mecca -- /Jacob Carlborg
Re: Intellij: Support for TextMate Bundled
On 2019-08-01 17:19, Andre Pany wrote: There is an answer from Intellij why there are highlighting issues: https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FIDEA-219012 That's disappointing. Named captures are very useful and makes the grammar easier to read and understand. TextMate uses this regular expression implementation [1]. [1] https://github.com/textmate/Onigmo -- /Jacob Carlborg
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On 2019-05-05 05:45, Mike Franklin wrote: The idea behind the library is that it would not depend on druntime, phobos, C standard library, or anything else but would still offer many of the features that those libraries provide. To utilize the library, one would only need a D compiler. It could be used in bare-metal programming, -betterC builds, or as a fundamental utility library for implementing DMD, druntime, and phobos themselves. Might be interesting to write a tool that enforces the rules. It would use DMD as a library. -- /Jacob Carlborg
Re: DStep 1.0.0
On 2019-04-26 10:33, Robert M. Münch wrote: Are there are any functional differences between the platforms? The short answer is yes. Or can I just use the OSX version and use the generated .d files with the DMD Windows version too? The longer answer is that it depends. DStep behaves the same way as the compiler (Clang in this case). That means that there are different predefined macro constants for different platforms. For example: #if _WIN32 #include DWORD foo(); #else int foo(); #endif If you run DStep on Windows it will output: extern (C): DWORD foo(); But on any other platform it will output: extern (C): int foo(); So it's a question if the header files contain any code like the above. The bindings that DStep uses for libclang are generated on macOS but are used unchanged on Windows and Linux as well. But these are the most forgiven headers that I've seen when it comes to create bindings. -- /Jacob Carlborg
Re: DStep 1.0.0 on the Blog
On 2019-04-23 14:10, Mike Franklin wrote: Nice work, Jacob! Very cool! Thanks :) -- /Jacob Carlborg
Re: Beta 2.086.0
On 2019-04-21 19:59, Jacob Carlborg wrote: On 2019-04-20 16:16, Martin Nowak wrote: Glad to announce the first beta for the 2.086.0 release, ♥ to the 52 contributors. I just noticed I got a test failure [1] in one of my projects using this version. I haven't investigated yet. Strangely the nightly build passes. [1] https://travis-ci.org/jacob-carlborg/dstep/jobs/522548540 Managed to find a reduced test case: https://github.com/dlang/dub/issues/1681. -- /Jacob Carlborg
Re: DStep 1.0.0
On 2019-04-22 15:20, Dennis wrote: Huh, I've been using DStep on Windows back in January. I can't remember how I obtained the binary, but it's version 0.2.3-67-gdeabc63. The Windows support was implemented during GSoC 2016. It just has never been a new release since then. I have created a few tags, for various reasons, since then, but no official release. It worked partially, but could not translate C function pointers to D's `function()` syntax, leaving a 'TODO' stub instead. Has that changed? I can't find anything about it in the release notes. Translating function pointers has probably been supported since the first release. There are tests for this. If there's something that is not working, please file a bug at [1]. Ideally with a minimal test case with the C code and the expected D code. [1] https://github.com/jacob-carlborg/dstep/issues -- /Jacob Carlborg
DStep 1.0.0
I would like to announce a new major release of DStep, 1.0.0. This release is the biggest release since the initial release. It has support for translating some of the preprocessor, like `#define` for contestants and function-like macros. It now supports preserving comments and support for one more platform has been added: Windows. Many more features have been added and bugs have been fixed, too many to mention here. For those not familiar, DStep is a tool for automatically generating D bindings for C and Objective-C libraries. This is implemented by processing C or Objective-C header files and output D modules. DStep uses the Clang compiler as a library (libclang) to process the header files. This release would not have been possible without Wojciech Szęszoł, the Google Summer of Code student that started to work on DStep during the summer of 2016 and still is contributing. For the full changelog (this has been built up for over three years, so I'm sure things are missing), see the release page [1]. Binaries are available for macOS, Linux and Windows [1]. The Linux binary is completely statically linked and should work on any distro. The macOS binary is statically linked with libclang and doesn't have any additional dependencies besides the system libraries. The Windwos binaries require to install libclang. [1] https://github.com/jacob-carlborg/dstep/releases/tag/v1.0.0 -- /Jacob Carlborg
Re: Beta 2.086.0
On 2019-04-20 16:16, Martin Nowak wrote: Glad to announce the first beta for the 2.086.0 release, ♥ to the 52 contributors. I just noticed I got a test failure [1] in one of my projects using this version. I haven't investigated yet. Strangely the nightly build passes. [1] https://travis-ci.org/jacob-carlborg/dstep/jobs/522548540 -- /Jacob Carlborg
Re: Two New Manpower Initiatives
On 2019-04-15 12:08, Mike Parker wrote: I've just published a post on the blog introducing two new initiatives, the Manpower Share and the Manpower Fund, that came out of our quarterly D Language Foundation meetings. The goal is to help focus energy on getting more effort directed at the issues that fall by the wayside. The blog post has all the details, so I encourage everyone who cares about improving D and its ecosystem to give it a read. Looking at the Ecosystem Task List, I had expected something more specific than just "close as many bugs as possible" for various projects. -- /Jacob Carlborg
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On 2019-04-12 11:47, DanielG wrote: - OpenWL/DL aren't designed for games or insane frame rates. I *do* think a smooth, 60fps experience is worth shooting for, but because it's CPU-bound with Quartz2D on Mac, and Cairo on Linux, that will depend entirely on the user's resolution / CPU. (But Direct2D is GPU-accelerated and already crazy fast) "Whenever possible, Quartz 2D leverages the power of the graphics hardware." [1]. [1] https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html -- /Jacob Carlborg
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On 2019-04-12 08:45, DanielG wrote: These aren't written in D, but they are *for* D (or any other non-C++ language in need of its own canonical, language-native GUI). They export a C API for maximum ease of use. May I ask why? -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-04-02 13:49, Bastiaan Veelo wrote: So thank you. You're welcome :) -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-04-01 12:31, Mihails wrote: Nice, I must admit I have had my mind set about DVM as something that has existed for years and wasn't quite the right thing. Had no idea you kept improving it lately. Yeah, I thought it was time to fix one or two bugs. -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-03-31 13:39, Mihails wrote: Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction. As for the destruction: * Saying it's cross-platform and only supporting two platforms is stretching it a bit. * Using the "tar" [1] command line tool is cheating :). It might not be available inside a Docker container, for example. * Regarding `currentProcessBinary` [2]. Phobos has a function for that, which is cross-platform [3]. [1] https://github.com/mihails-strasuns/dc/blob/f314916b04879604e3f8629534a3cf2b1bd4d92c/source/dc/platform/posix.d#L78-L81 [2] https://github.com/mihails-strasuns/dc/blob/f314916b04879604e3f8629534a3cf2b1bd4d92c/source/dc/utils/path.d#L46 [3] https://dlang.org/phobos/std_file.html#.thisExePath -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-03-31 13:39, Mihails wrote: Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction. It is a small utility originally created to fulfill similar purpose to existing `install.sh` script but also with Windows support. It's kind of funny that you decided to release this exactly the same day as I planned to release a new version of DVM [1] :) [1] https://forum.dlang.org/post/q7r3i5$2cdh$1...@digitalmars.com -- /Jacob Carlborg
DVM - D Version Manager 0.5.0
I would like to announce a new release of DVM, 0.5.0. This release contains two important bug fixes: making the Dub binary executable and downloading the latest compiler, i.e. the `-l` flag now works again. The release and binaries are available here [1]. I might upload a FreeBSD binary later, if I get that to work. For those not familiar with DVM: DVM allows you to easily download and install D compilers and manage different versions of the compilers. Full changelog: New/Changed Features: * Add a flag to print the version of DVM, `--version` Bugs Fixed: * Fixed installing the latest compiler, that is using the `-l` flag * Issue 44: Make dub executable * Issue 42: Doesn't compile with recent compilers (e.g. dmd-2.074.1) [1] https://github.com/jacob-carlborg/dvm/releases/tag/v0.5.0 -- /Jacob Carlborg
Re: DC v1.0.0 - cross-platform D compiler install management tool
On 2019-03-31 13:39, Mihails wrote: Contrary to `install.sh` and DVM approach, DC changes active compiler globally instead of a current shell context only. FYI, DVM allows to set the globally active compiler as well, using "dvm use -d". This is known as the default compiler. These days I don't use the "use" command that often because the compiler is more stable, less reason to pin a project to a given compiler version. Also most of my projects work with the latest version of the compiler. This done intentionally to simplify integration with IDEs and other non-CLI tools - though temporary shell-only switching is also planned once I come with a decent design. DVM has two wrappers that helps with editor and IDE integration in the form of "dvm-current-dc", which always points to the currently active compiler (which actually more is the latest chosen compiler) and "dvm-default-dc" which always points to the default, or global, compiler. Both of these live in "~/.dvm/bin" (on Posix). You can point your editor or IDE to the full path of one of these two wrappers. DVM also provides wrappers for each compiler version in the form of "dmd-" also located in "~/.dvm/bin", if you want to explicitly invoke a given version without switching the active version. -- /Jacob Carlborg
Re: DLP - D Language Processing 0.1.0
On 2019-03-20 14:12, Stefan Koch wrote: Functions without bodies cannot be considered leaf functions as there are declarations which may call. I thought about adding a flag to control if functions without a body should be considered a leaf function or not. This tool is mostly intended for providing a good starting point to where to add attributes. I think this is still true for functions without a body. -- /Jacob Carlborg
DLP - D Language Processing 0.1.0
I would like to announce a new release of DLP, 0.1.0. For those not familiar with DLP, DLP is a tool collecting commands/tasks related to processing the D programming language. It uses the DMD frontend as a library to process D code. Currently it has only one command, "leaf-functions", that will print all leaf functions. A leaf function is a function that doesn't call any other functions or doesn't have a body. The release is available here [1]. Pre compiled binaries are available for macOS, Linux 64bit and Windows 32bit and 64bit. Here's what's new: * Added a flag, "--frontend-version", which will print the version of the frontend DLP is using * Updated the D frontend DLP is using to DMD 2.085.0+ (dd94ef465) * New formatting of locations For the "leaf-functions" command: * Added a flag, --import-path/-i, which will add the given path as an import path * Fixed issue 1: No error if no input files are given [1] https://github.com/jacob-carlborg/dlp/releases/tag/v0.1.0 -- /Jacob Carlborg
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On 2019-03-18 15:49, Andrea Fontana wrote: Is v2.0xx compiled with v2.0xx-1 or with v2.0xx itself? With v2.0xx-1, as far as I understand. -- /Jacob Carlborg
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On 2019-03-17 21:09, Per Nordlöw wrote: I thought that already is the case... No, the official binaries are built with DMD as the host compiler. -- /Jacob Carlborg
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On 2019-03-16 22:23, Per Nordlöw wrote: After reading https://forum.dlang.org/thread/nlhybmioaoxkydicm...@forum.dlang.org it's about time I announce my little Python snippet that exercises the compilation speed of D and other languages with a superficial test program generator at https://github.com/nordlow/compiler-benchmark Run as ./benchmark.py This generates a single source file for each supported language, currently D, C, C++, Go and Rust, containing 50k number of trivial functions that from the main function are called and reduced to a single integer which is returned at the end of main. The benchmark then measures the time it takes for each compiler to run semantic analysis on the source file (excluding output of any object files). My only question is: How is it possible for Rust be to 50x slower than D in this test!!!??? Am I calling rustc in the wrong way? Especially taking into account the amount of time (and money) that has been put into making Rust fast(er). Through fancy caching of IR-files and more. I very much welcome PRs that add more languages. Output on Ubuntu 18.04 system is Code-generation: Generating generated/c/foo.c took 0.073 seconds (C) Generating generated/c++/foo.c++ took 0.073 seconds (C++) Generating generated/d/foo.d took 0.076 seconds (D) Generating generated/rust/foo.rs took 0.076 seconds (Rust) Generating generated/zig/foo.zig took 0.077 seconds (Zig) Generating generated/go/foo.go took 0.074 seconds (Go) Clang: - Checking of generated/c/foo.c took 1.373 seconds (using "/usr/bin/clang-7") - Checking of generated/c++/foo.c++ took 1.345 seconds (using "/usr/bin/clang++-7") GCC: - Checking of generated/c/foo.c took 0.385 seconds (using "/usr/bin/gcc-5") - Checking of generated/c++/foo.c++ took 0.675 seconds (using "/usr/bin/g++-5") - Checking of generated/c/foo.c took 0.551 seconds (using "/usr/bin/gcc-6") - Checking of generated/c/foo.c took 0.518 seconds (using "/usr/bin/gcc-7") - Checking of generated/c++/foo.c++ took 1.294 seconds (using "/usr/bin/g++-7") - Checking of generated/c/foo.c took 0.527 seconds (using "/usr/bin/gcc-8") - Checking of generated/c++/foo.c++ took 1.363 seconds (using "/usr/bin/g++-8") D: - Checking of generated/d/foo.d took 0.403 seconds (using "/usr/bin/dmd") - Checking of generated/d/foo.d took 0.352 seconds (using "/home/per/.local/ldc2-1.15.0-beta1-linux-x86_64/bin/ldmd2") Go: - Checking of generated/go/foo.go took 1.716 seconds (using "/usr/bin/gccgo") Rust: - Checking of generated/rust/foo.rs took 17.828 seconds (using "/home/per/.cargo/bin/rustc") Zig: Speedups: - D to gcc-8: 1.50 - D to g++-8: 3.88 - D to Clang: 3.90 - D to Clang++: 3.83 - D to Go: 4.88 - D to Rust: 50.71 It would be interesting to measure D's speed with DMD compiled with LDC as the host D compiler. -- /Jacob Carlborg
Re: Containerize Your D Server Application
On 2019-03-14 13:38, Mike Parker wrote: One of the items on my list of "things I'd like to do if I only had the time" is to create a Mud server with D and deploy it with Docker. Just for kicks. If I ever do get around to it, my ignorance of all things Docker will not be the time sink it could have been thanks to this latest post on the D Blog by Kai Nacke. The Blog https://dlang.org/blog/2019/03/14/containerize-your-d-server-application/ Reddit https://www.reddit.com/r/programming/comments/b0zqck/containerize_your_d_server_application/ For reducing the container image I recommend building what's called a "microcontainer" [1]. It's a container that only contains exactly what's needed to run the application, no more, no less. That is, it contains no base image. There's a tool called Smith [2] that helps to build these microcontainers. You specify the files you want to have included in the container, then it will use the dynamic linker to figure out all the dependencies of the executables. With LDC it's possible to build a fully statically linked executable, that makes it trivial to build a microcontainer out of. [1] https://blogs.oracle.com/developers/the-microcontainer-manifesto [2] https://github.com/oracle/smith -- /Jacob Carlborg
Re: Blog post on the joys of hand-translating C++'s std::function to D
On 2019-03-07 16:45, Atila Neves wrote: C++ is hard: https://atilaoncode.blog/2019/03/07/the-joys-of-translating-cs-stdfunction-to-d/ Using ".mangleof" and "pragma(mangle)" on the same symbol looks like something that could easily break. -- /Jacob Carlborg
Re: Release D 2.085.0
On 2019-03-02 19:19, Martin Nowak wrote: Glad to announce D 2.085.0, ♥ to the 49 contributors. This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32. http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html ¹: There is a pending Objective-C fix (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will be released with 2.085.1 soon (~1.5 weeks). I highly recommend that anyone that wants to start using the new Objective-C features to wait until the point release. -- /Jacob Carlborg
Re: Release D 2.085.0
On 2019-03-02 20:44, Basile B. wrote: GoodBye Darwin 32. I wonder if the issues specific to this platform should be all closed as WONTFIX or left as is (example : https://issues.dlang.org/show_bug.cgi?id=13457) I think Walter has mentioned in the past that bugs like this might be an actual problem and could surface on other platforms as well. -- /Jacob Carlborg
Re: DIP 1018--The Copy Constructor--Formal Review
On 2019-02-26 12:07, Walter Bright wrote: It hasn't been approved yet, and please start another thread if you want to discuss it. You have approved the pull request. -- /Jacob Carlborg
Re: DIP 1018--The Copy Constructor--Formal Review
On 2019-02-25 01:38, Walter Bright wrote: D's const has teeth. Nothing can be modified through T. What about the __mutable proposal [1]? [1] https://github.com/dlang/dmd/pull/8315 -- /Jacob Carlborg
Re: DIP 1018--The Copy Constructor--Formal Review
On 2019-02-25 21:23, Andrei Alexandrescu wrote: Jacob, are there amends you need to make to the DIP? No, I'm talking about the process in general. -- /Jacob Carlborg
Re: DIP 1018--The Copy Constructor--Formal Review
On 2019-02-25 20:24, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” Having it documented doesn't make it less flawed. -- /Jacob Carlborg
Re: DIP 1018--The Copy Constructor--Formal Review
On 2019-02-24 11:46, Mike Parker wrote: Walter and Andrei have requested the Final Review round be dropped for DIP 1018, "The Copy Constructor", and have given it their formal approval. They consider copy constructors a critical feature for the language. Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance. I think the process is flawed when not everyone plays by the same rules. -- /Jacob Carlborg
Re: DIP 1018--The Copy Constructor--Formal Review
On 2019-02-25 17:31, Andrei Alexandrescu wrote: The proposers (Razvan and myself) and Walter (the reviewer) do not know how to make DIP 1018 better. That shouldn't justify accepting a DIP that might contain problems. But of course, if you don't think there are any problems. -- /Jacob Carlborg
Re: taggedalgebraic 0.11.0 adds TaggedUnion
On 2019-02-22 18:09, Sönke Ludwig wrote:
TaggedUnion is the low level tagged union functionality separated out
from TaggedAlgebraic. Because it doesn't support transparent access of
methods and operators of the contained value, it is able to provide a
number of convenience features. On top of that, visit and tryVisit is
now supported for pattern matching, analogous to the version for
std.variant.Algebraic. This is the basic usage:
union U {
string caption;
int height;
int width;
}
alias Value = TaggedUnion!U;
auto val = Value.caption("foo");
assert(val.kind == Value.Kind.caption);
assert(val.value!(Value.Kind.caption) == "foo");
// shorthand syntax:
assert(val.isCaption);
assert(val.captionValue == "foo");
// set a different type/kind
val.setHeight(10);
Why not using property syntax, i.e. `val.height = 10`?
val.visit!(
(int i) { assert(i == 10); }
(string s) { assert(false); }
);
How does this handle the above case when there are two `int`? How do I
know if it's the "width" or "height" that has been set?
--
/Jacob Carlborg
New test runner to test DMD
This post is mostly directed to DMD contributors.
Currently most of the tests for DMD are end-to-end like tests. The test
invokes the compiler as a new process and the test asserts the exit code
and/or error messages outputted by the compiler. This means that
basically for each test file a new process is created which runs the
compiler. There are two problems with this: a lot of processes need to
be started and executed and since the compiler runs in a separate
process from the test, it's not possible to access the internals of the
compiler.
DMD also contains a few more of traditional unit tests (using the
`unittest` blocks) which tests individual functions. Mostly utility
functions.
I would like to announce that a new test runner has recently been added
for testing DMD. It's like a mix of both of the existing tests types. It
uses the `unittest` blocks and uses the compiler as a library. It runs
the test and the compiler in the same process. It allows to compile code
without starting a new process, then the test is free to assert whatever
it likes. For example, the structure of internal data that are only
available in the same process as the compiler.
The test runner compiles all files of this test type into a single
executable. This should hopefully speed up running the tests because
only a single executable is compiled and run, instead of hundreds.
This type of tests lives in the `test/unit` directory [1]. They're using
the `unittest` block to declare a test. It supports attaching a UDA to
filter tests. It also supports before and after hooks that are executed
before each `unittest` block within the same module and after each
`unittest` block (regardless of the test failed or passed). The test
runner will print a report at the end of which tests that failed.
The tests are executed by default when `make -C test` or `./test/run.d`
is executed. The runner supports a more finer grained control of running
the tests:
* To run all the unit test (without running the other tests), run:
`./test/run.d -u`
* To only run the unit tests in one or more specific files:
`./test/run.d -u test/unit/self_test.d`
* To only run a subset of the unit tests in a single file:
./test/run.d -u test/unit/self_test.d --filter "self test"
In the above example, the `--filter` flag will filter to only run the
tests with a UDA matching the given value, in this case `self test`.
An example can look like this [2]:
module self_test;
import support : afterEach, beforeEach, defaultImportPaths;
@beforeEach initializeFrontend()
{
import dmd.frontend : initDMD;
initDMD();
}
@afterEach deinitializeFrontend()
{
import dmd.frontend : deinitializeDMD;
deinitializeDMD();
}
@("self test")
unittest
{
import std.algorithm : each;
import dmd.frontend;
defaultImportPaths.each!addImport;
auto t = parseModule("test.d", q{
int a = 3;
});
assert(!t.diagnostics.hasErrors);
assert(!t.diagnostics.hasWarnings);
}
You're free to test whatever you like inside the `unittest` block, the
`parseModule` function is not required to use. Here's another example
that does not use it [3].
I highly recommend splitting up the `unittest` blocks to only test one
thing per `unittest` block.
I encourage all DMD contributors to give this a try. Using this kind of
test will hopefully speed up the DMD test suite and make it possible to
test things that are not tested today.
[1] https://github.com/dlang/dmd/tree/master/test/unit
[2] https://github.com/dlang/dmd/blob/master/test/unit/self_test.d
[3] https://github.com/dlang/dmd/blob/master/test/unit/deinitialization.d
--
/Jacob Carlborg
Re: DConf 2019 Early-Bird Registration Now Open
On 2019-01-28 15:07, Mike Parker wrote: I've published a post on the blog with updates about DConf 2019 registrations, the invited keynote speaker, the Symmetry Autumn of Code finalist, and the previously announced fundraiser for a new forum server. Early-bird registrations are $340 again this year and will remain available until March 17, 24:00 AOE. This time around, we have to factor in a 20% VAT for all registrations, so the actual price will be $408. Has a hotel for post-conference gathering* been picked? * We all know this actually means Beer Conf :D -- /Jacob Carlborg
Re: GtkD Blog Now Up and Running
On 2019-01-30 11:35, Ron Tarrant wrote: You said you're on OSX, right? Is it possible that dub just isn't as cooperative on Windows 10? Of course, if you can see something in this output that hints at a fix, please let me know. It's Optlink being stupid as always. If you want to figure out what's wrong you can invoke Dub with the "--verbose" flag to have it print the commands it's running, i.e. how it's invoking the compiler and the linker. You can do the same thing when invoking the compiler manually by adding "-v" to see how it links the application and compare that with Dub. Or, you can try compiling as COFF instead of OMF which will not use Optlink. Add the flag "--arch=x86mscoff" when invoking Dub. -- /Jacob Carlborg
Re: GtkD Blog Now Up and Running
On 2019-01-30 03:00, Neia Neutuladh wrote: Might I recommend instead: dependency "gtk-d" version="3.8.5" This depends on gtk-d 3.8.5 and only that version. If there is a breaking change in 3.8.6 despite semantic versioning, your code keeps working. In libraries, I prefer using ~> to give more freedom to people depending on my code. But in applications, that isn't a concern. May as well only allow the code to be built with the versions of your dependencies that you've actually tested. That's what the dub.selections.json file is for. It will lock down the version of all dependencies, direct and indirect dependencies. For applications the dub.selections.json should be under version control, while for libraries it should be ignored. -- /Jacob Carlborg
Re: D-lighted, I'm Sure
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
