Re: openssl 1.1 vs. 3.0 for vibe.d:tls on Ubuntu 22.04
On Friday, 28 July 2023 at 08:56:17 UTC, Guillaume Lathoud wrote: Hello, some context first: I recently updated a server to Ubuntu 22.04 which appears to have only openssl 3.0.2 installed. Dub could compile my project, but could not link it anymore, as the D code seemed to be expecting openssl 1.1 whereas only 3.0.2 was installed. Do you compile directly on the server ? Or on an Ubuntu 22.04 host? The autodetection code happens by calling a D script: https://github.com/D-Programming-Deimos/openssl/blob/master/scripts/generate_version.d Make sure you have `pkg-config` installed as that's what is used for autodetection, as well as the development libraries (the `-dev` package). I've been using openssl 3 on Ubuntu 22.04 since it came out, so it should just work.
Re: Warning The package will no longer be detected starting from v1.42.0
On Sunday, 25 June 2023 at 04:50:42 UTC, Soulsbane wrote: I'm guessing it's caused by this https://github.com/dlang/dub/pull/2610. What's the fix for this exactly? Thanks! A fix would be to do the following: ``` for package in $($HOME/Projects/D/libs/*); do mv -v $package $package/master/$(basename $package) done ``` Provided that all you have in your `libs` folder are folders that represent packages. This would also allow you to use different versions of a library (I'm assuming you only have one, hence the `master`), and work with libraries like Cybershadow's `ae`. However, I'm not sure we should expect our users to do this for a simple `add-path`.
Re: constant pointer failing to compile
immutable ubyte[4] data = [1, 2, 3, 4]; Using a static array instead of a slice will do the trick. You can leave the `__gshared` if you want, but it is redundant on a global, initialized `immutable` variable.
Re: LDC 1.31.0
On Saturday, 11 February 2023 at 13:47:54 UTC, kinke wrote: Glad to announce LDC 1.31.0. Major changes: * Based on D 2.101.2. * ImportC: The C preprocessor isn't invoked yet. * mac/iOS arm64: Linking with `-g` is working again without unaligned pointer warnings/errors. * *Preliminary* support for LLVM 15. Thanks @jamesragray for helping out! * Initial ABI support for 64-bit RISC-V. Thanks @Ast-x64! Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.31.0 Thanks to all contributors & sponsors! Wonderful! Thanks for all the effort you're putting into LDC!
Re: Release D 2.102.0
On Friday, 3 February 2023 at 08:33:26 UTC, Max Samukha wrote: BTW, check out another case of D violating the "if in an invalid state, die" precept. The following code not only runs the upstream destructor (which depends on successful completion of the downstream one), but does that in an infinite loop: [...] Yep, it's a regression: https://issues.dlang.org/show_bug.cgi?id=23164
Re: Which TOML package, or SDLang?
On Monday, 30 January 2023 at 06:38:46 UTC, Daren Scot Wilson wrote: So, which package do I use for TOML? I find these three: * toml-foolery (Andrej Petrović) * toml-d, or toml.d (oglu on github) at ver 0.3.0 * toml, (dlang community on github) at ver 2.0.1 I'm guessing from version numbers that the third one, toml, is officially good for real world use. But I wonder if there are good reasons to use the others. I would go with the dlang-community one, whenever available. Also, a low-effort search for TOML in the D world turned up SDLang, where the substring "DLang" has nothing to do with dlang, the common short name for D Language. SDLang looks nice. Should I ditch TOML for it? I would not recommend it. SDL (Simple Declarative Language) is a language we have support for, but it's rather unknown - TOML will probably be simpler for end users. I just realized - it's been ages since I've dealt with config files, beyond editing them as an end user. I work on existing software where someone else made the choiced and wrote the code, or it's a small specialized project not needing config. I'm a config caveman! This is for a small fun personal project with potential show-off value, available on github but too primitive for now to mention. Controlling hardware, needing to store device info to recall for later runs. There are zero compatibility or standards issues to consider. Whatever is simplest to implement and tinker with is the winner. If I can allow a shameless self plug, and if you are willing to consider YAML: https://github.com/dlang-community/configy If you are willing to stick to a "simple" config where you essentially want some values to end up in a struct, and want decent error messages, this is for you.
Re: forgetting -betterC means no runtime bounds checking?
On Thursday, 5 January 2023 at 09:17:28 UTC, areYouSureAboutThat wrote: core.exception.ArrayIndexError@test.d(25): index [5] exceeds array of length 5 Aborted (core dumped) This is bounds checking happening.
Re: Release D 2.101.0
On Tuesday, 15 November 2022 at 20:54:03 UTC, Iain Buclaw wrote: Glad to announce D 2.101.0, ♥ to the 63 contributors. This release comes with shortened method syntax enabled by default, new bit-field support added as a preview feature, a new `std.typecons.SafeRefCounted` type that can be used in `@safe`, numerous improvements to dub (including colorized output), and many more. http://dlang.org/download.html http://dlang.org/changelog/2.101.0.html -Iain on behalf of the Dlang Core Team Thanks a lot for getting this through the finish line! Release management is an essential part of our ecosystem and a thankless job. And thanks a lot to Martin Nowak for his many years of stewardship and the much improved process he pioneered.
Re: Makefiles and dub
On Friday, 4 November 2022 at 23:19:17 UTC, Anonymouse wrote: [#20699](https://issues.dlang.org/show_bug.cgi?id=20699) must be non-trivial to fix, so I'm exploring makefiles. If possible I'd like to keep dub for dependency management though, just not for actual compilation. That bug is fixed for the last 3 releases (not including the current one in progress), that is, since v1.26.0. Is it at all possible (or even desireable) to construct a makefile that builds dependencies from outside of the source tree (namely `$HOME/.dub/packages/package_with_unknown_version-1.2.[0-9]+/`)? Does anyone have an example `Makefile` I could dissect? Thanks. In the past, I used https://github.com/sociomantic-tsunami/makd for building D code. But it doesn't do dependency management like dub, as it expected libraries to be in `submodules/`.
Re: Best practice for dub registry package and module names
On Sunday, 4 September 2022 at 01:52:11 UTC, Ali Çehreli wrote: Should the package be the author's name: acehreli.a, acehreli.b, and acehreli.c? I use this approach: https://forum.dlang.org/thread/jdkmtgftmwtwaxxqh...@forum.dlang.org
Re: Constructors not working
On Friday, 2 September 2022 at 18:35:22 UTC, Svyat wrote:
I write this code in one directory:
```
module time;
struct Time {
public int hours, minutes, seconds;
this(int h, int m, int s) {
hours = h;
minutes = m;
seconds = s;
}
Time opBinary(string op : "=")(int secos) {
assert(secos <= 86_400);
return new Time(secos / 3600, (secos % 3600) / 60,
secos % 60);
}
}
```
```
module testfortime;
import time;
import std.stdio;
void main() {
Time time = 360;
write(time.hours);
readln;
}
```
After execute 'dmd -run ./testfortime.d' i got this:
```
".\testfortime.d(6): Error: constructor `time.Time.this(int h,
int m, int s)` is not callable using argument types `(int)`
.\testfortime.d(6):too few arguments, expected `3`, got
`1`"
```
WTF? Why standart constructor isn`t callable? How it`s possible
in a programming language?
First of all, the error message is telling you what is wrong: You
are calling the constructor with only one argument, while your
constructor is declared to take 3.
If you wanted your call to work, you should have declared the
constructor as:
```
this(int h, int m = 0, int s = 0) { /* Magic */ }
```
But D will by default give you a default constructor that does
exactly that. And the constructor will be properly attributed,
because in your case, the constructor should actually be this:
```
this(int h, int m = 0, int s = 0) inout scope @safe pure nothrow
@nogc { /* Magic */ }
```
So if you just remove the constructor, things will work. Note
that in D, as soon as you define one constructor, the default one
is no longer generated.
Second, your `opBinary` cannot compile, because `Time` is a
`struct`, and if you are returning a `new Time` in `opBinary`,
you should return a `Time*`. Currently it's working because you
are not using it.
Finally, there is a module in druntime for time management, which
provides a very nice API: `core.time : Duration`. It will allow
you to do everything you want to do with your code, and more.
For example: `import core.time; auto time = 1.hour;
writeln(time);`
Re: Comping a Musl-linked druntime & phobos?
On Thursday, 25 August 2022 at 01:45:50 UTC, TheGag96 wrote: Hi, all. Has anyone had any success compiling a Musl-linked druntime and phobos? I haven't had any luck so far. I'm running Linux Mint x64. Somewhat related - using `-target=x86_64-linux-musl` with dmd master doesn't even set the version `CRuntime_Musl`. I asked about this in the Discord, and I was told by Horo: dmd 2.096 worked well for me. Same for gdc, haven't tried ldc. There is/was a bug that was introduced recently in druntime that broke musl but the older versions should work fine 2.096 doesn't have the `-target` option, and 2.097.0-2.098.0 don't even build properly for me. Using LDC to build works of course, but only with `-betterC` (i.e. no druntime/phobos). Hi! Thinks should mostly work. There is some issues with stack traces, but I don't remember the details. Check what Alpine Linux is doing: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/dmd Note that the `target` should not be required: https://github.com/dlang/dmd/blob/09d04945bdbc0cba36f7bb1e19d5bd009d4b0ff2/compiler/src/dmd/target.d#L1177-L1180
Re: New WIP DUB documentation
On Thursday, 18 August 2022 at 20:00:10 UTC, Bastiaan Veelo wrote: That's already possible, as unrecognised items are ignored. Actually, from next version, dub will start to warn you (in dub.json) about unknown keys. It does catch quite a lot of mistakes, see https://github.com/dlang/dub/pull/2280#issuecomment-1223326664
D-YAML v0.9.0 released (DIP1000 compatibility)
Hi everyone, A few days ago, I released [v0.9.0](https://github.com/dlang-community/D-YAML/releases/tag/v0.9.0) of D-YAML. D-YAML is the most used package for parsing YAML file, and part of dlang-community. This new release makes the library compatible with DIP1000, which required getting rid of Variant (but forking `std.sumtype`).
Vibe.d v0.9.5 released!
Hi everyone, A new version of Vibe.d has been released today. You can see the list of changes [on Github](https://github.com/vibe-d/vibe.d/releases/tag/v0.9.5). Of particular interest to me is the bump of the deimos/OpenSSL dependency to v3.x.x. deimos/OpenSSL v3.x.x is something I worked on a few months ago when Ubuntu 22.04, which includes OpenSSL3 was released. The code in Deimos is now compatible with all OpenSSL versions (v1.0.2 through v3), removing the need for a lot of workaround OpenSSL users previous needed to support multiple versions. With this version, projects depending on Vibe.d and using OpenSSL directly can upgrade to the newest version and take full advantage of it. And if you're an Ubuntu 22.04 user, or need to support it, it will make your life a whole lot simpler! Note that while using dub, the OpenSSL version is auto-detected. If that detection fails, or if you are using another build system (or want to force a specific version), make sure to check [the compatibiliy guide](https://github.com/D-Programming-Deimos/openssl#compatibility) of deimos/OpenSSL.
Re: DConf 2022 in London?
On Tuesday, 15 February 2022 at 12:22:05 UTC, Mike Parker wrote: Yes! Thanks to Symmetry Investments, DConf 2022 is happening in London Aug 1-4. I'll have the web site up soon (waiting to make sure there's no issue with our logo), but I wanted to get the news out ASAP since I have permission now to announce it. [...] Looking forward to it! See you all there.
Re: Added copy constructors to "Programming in D"
On Thursday, 10 February 2022 at 02:39:11 UTC, Ali Çehreli wrote: Yeah, that issue bugs me a little. Ali I think an *immediate* improvement we could make to ease people's life is to make `auto` peel the outermost qualifier level inside functions. So that: ```D const int* ptr; auto p2 = ptr; static assert(is(typeof(p2) == const(int)*)); ``` I really can't think of any downside to it, only upsides: - It is still predictable / consistent; - It *might* reduce the number of template instantiations in some cases; - It just flows more naturally... If you want full constness, there's still `const`; Likewise, I've been tinkering with having `const* p2 = ptr` to allow `p2` to be mutated. But it has far more implications and the benefits aren't as clear. For `auto`, I think the case is pretty straightforward. Fun fact: C++ mangling actually does that. ```D extern(C++) void foo (const int a); extern(C++) void bar (int a); pragma(msg, foo.mangleof); // _Z3fooi not _Z3fooKi pragma(msg, bar.mangleof); // _Z3bari ``` P.S: Thanks for spreading the love about `-preview=in`. I haven't moved forward with enabling it by default yet, because it just does exactly what we want it to do and has never bothered us, so we tend to forget it's not the default. I shall however start to move ahead now that the switch has been available for a few releases.
Re: Approach to Integration Testing in D
On Friday, 4 February 2022 at 12:38:08 UTC, Vijay Nayar wrote: Greetings everyone, ## Question What is your approach to integration testing in D? Do you use `unittest` blocks? Do you write stand-alone programs that interact with a running version of your program? Is there a library that makes certain kinds of testing easier? For server nodes, I've built a library just for this: https://github.com/Geod24/localrest It required careful planning on the application side (e.g. we're not calling `runTask`, we have some classes for dependency injection), but allowed us to write "integration tests" in unittests block: https://github.com/bosagora/agora/tree/75967aac4f41272c6e5e8487c4066174825290e0/source/agora/test#agora-test-folder
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote:
On 21.01.22 13:33, Mike Parker wrote:
### Mathias
Mathias would very much like to see the unification of
delegates and function pointers. There was general agreement
that this is a good goal to aim for. Mathias subsequently
informed me he will look into it once some other things are
off his TODO list if no one else gets to it first.
I still believe it should be fairly simple:
https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
Actually, the idea I had in mind is a little different.
Because a delegate is essentially:
```D
T function (T, Args..)(void* ctx, Args args)
```
It should be possible for the compiler to generate a call to a
trampoline function that just forwards to the actual function:
```D
RT _d_trampoline (FT, RT, Args..)(void* ctx, Args args)
{
return (cast(FT) ctx)(args);
}
```
Re: "need `this` for `s` of type `char*`" error message
On Thursday, 11 November 2021 at 07:10:39 UTC, Mathias LANG wrote:
[...]
Your type definition is wrong:
```D
struct toml_datum_t {
int ok;
union u {
toml_timestamp_t* ts; /* ts must be freed after use */
char* s; /* string value. s must be freed after use */
int b; /* bool value */
int64_t i; /* int value */
double d; /* double value */
}
}
```
If you check the size of this struct, it's going to be 4,
because `u` is a type definition. What you want is either:
```D
struct toml_datum_t {
int ok;
union {
toml_timestamp_t* ts; /* ts must be freed after use */
char* s; /* string value. s must be freed after use */
int b; /* bool value */
int64_t i; /* int value */
double d; /* double value */
}
}
```
Which you access via `host.s` or:
```D
struct toml_datum_t {
int ok;
/// This is the type definition
union U {
toml_timestamp_t* ts; /* ts must be freed after use */
char* s; /* string value. s must be freed after use */
int b; /* bool value */
int64_t i; /* int value */
double d; /* double value */
}
/// This is the field
U u;
}
```
Note that instead of doing this work yourself, I would highly
recommend the excellent
[dstep](https://github.com/jacob-carlborg/dstep).
Fixed formatting (so much for "Fix it for me").
Re: "need `this` for `s` of type `char*`" error message
On Thursday, 11 November 2021 at 07:04:57 UTC, rempas wrote:
After not being able to use ImportC to automatically compile a
C library, now I'm trying to do it myself. The library I want
to use is [tomlc99](https://github.com/cktan/tomlc99) which is
a small C library to parse toml files. Now I compiled the
library and I copied the "config.h" file and modified to make
it a D file that will contain the declaration so D knows which
symbols to call. I resulted with a "toml.d" file and a "main.d"
file. The first one contains the decorations and the second one
contains the code from the example in the
[usage](https://github.com/cktan/tomlc99#usage) section.
However, when I try to compile, I'm getting the following error
message:
```
main.d(51): Error: need `this` for `s` of type `char*`
Deprecation: argument `__error` for format specification `"%s"`
must be `char*`, not `_error_`
main.d(57): Error: need `this` for `i` of type `long`
main.d(63): Error: need `this` for `s` of type `char*`
```
I uploaded the modified files so someone is able to look at
them and explain me what I'm doing wrong so I can properly
learn. Links:
[toml.d](https://gist.github.com/rempas/8aaab43b71e3da720ce298ef472f0673)
[main.d](https://gist.github.com/rempas/07dfb15295c5f6142c6a8dfab669c40e)
Your type definition is wrong:
```D
struct toml_datum_t {
int ok;
union u {
toml_timestamp_t* ts; /* ts must be freed after use */
char* s; /* string value. s must be freed after use */
int b; /* bool value */
int64_t i; /* int value */
double d; /* double value */
}
}
```
If you check the size of this struct, it's going to be 4,
because `u` is a type definition. What you want is either:
```D
struct toml_datum_t {
int ok;
union {
toml_timestamp_t* ts; /* ts must be freed after use */
char* s; /* string value. s must be freed after use */
int b; /* bool value */
int64_t i; /* int value */
double d; /* double value */
}
}
```
Which you access via `host.s` or:
```D
struct toml_datum_t {
int ok;
/// This is the type definition
union U {
toml_timestamp_t* ts; /* ts must be freed after use */
char* s; /* string value. s must be freed after use */
int b; /* bool value */
int64_t i; /* int value */
double d; /* double value */
}
/// This is the field
U u;
}
```
Note that instead of doing this work yourself, I would highly
recommend the excellent
[dstep](https://github.com/jacob-carlborg/dstep).
Re: D Language Foundation Quarterly Meeting, October 2021
On Monday, 8 November 2021 at 21:48:03 UTC, Kagamin wrote: On Friday, 5 November 2021 at 11:57:40 UTC, Mike Parker wrote: `-preview=in` will not be killed. It needs to be changed such that: * `in` always means `const scope ref`; the compiler will not attempt to pass by value based on platform-specific heuristics. What about C functions? The ABI changes. `in` doesn't exist in C. All DRuntime bindings have been switched not to use `in` AFAIK (I'll do another pass on druntime / Phobos when my other changes are ready). There's a PR to disable it for non D/C++: https://github.com/dlang/dmd/pull/12242 but that was before this meeting.
Re: New library: argparse, for parsing CLI arguments
On Wednesday, 13 October 2021 at 11:27:40 UTC, Andrey Zherikov wrote: Hi everyone, I'm happy to announce that I've published a CLI argument parsing library - [argparse](https://code.dlang.org/packages/argparse). It's been around for some time already so please take a look and provide your feedback if you haven't done so. The reasoning to create one more CLI parsing library is that the existing libraries do not provide enough flexibility in parsing that I'm looking for and/or they depend on other libraries. As a result `argparse` supports wide variety of data types including enums, callbacks and arrays as well as a fully customized argument parsing. It also doesn't depend on anything besides the standard library. Since it's in active development (activeness depends on my availability of course), I have few things to do before making the first major release so stay tuned and/or contribute if you'd like to. Very interesting! I was looking for something similar recently, will definitely give it a try! One thing that it'd be interested to see would be subcommand support. Check what DUB is doing for example.
Re: A way to mixin during runtime?
On Friday, 27 August 2021 at 06:52:10 UTC, Kirill wrote: Is there a way to do mixin or similar during runtime? I'm trying to read a csv file and extract data types. Any ideas on how this should be approached in D are greatly appreciated. You cannot mixin at runtime. However, it is fairly easy to map a finite and CT-know set of argument to runtime arguments via `static foreach`. Could you give us example of the content of your CSV file and what you are trying to do ?
Re: Potential strategy for avoiding problems with copy of a struct (maybe??)
On Sunday, 22 August 2021 at 07:58:12 UTC, james.p.leblanc wrote:
Is there a better way?
Best Regards,
James
```
public mixin template NonMovableOrCopyable ()
{
@disable this ();
@disable this (this);
@disable ref typeof (this) opAssign () (auto ref typeof(this)
rhs);
}
```
This will catch most mistakes at CT. However the language is
technically free to copy / move structs at will (and interior
pointers are forbidden).
A recent enough version of LDC (>= v1.20.0 IIRC, might be
v1.22.0) will do a very good job at not needlessly moving things
around.
See for example the discussion here:
https://forum.dlang.org/thread/miuevyfxbujwrhghm...@forum.dlang.org
DMD on the other hand is much more likely to not perform NRVO /
move things, so be wary of compiler differences.
Re: modules and mains
On Sunday, 22 August 2021 at 03:22:02 UTC, Brian Tiffin wrote:
Is this wrong thinking? I'm ~~working on~~ playing with a
first project.
Meant to be a suite of tools, each usable from the command
line, i.e. with a `main`. Then a manager program that accepts
subcommands for dispatch *and other boss type things*.
boss.d wants to import command1.d command2.d etc.
Is there a way for `command1.d` to know it's an `import` versus
a file named as part of a `gdc` compile?
I'd like to skip defining `main` during `import` (using a
different name for boss dispatch), but do define `main` when
it's a standalone compile. Or is that a bad way of thinking
about D program development interactions?
Cheers
IIUC, you want to generate multiple binaries, too ?
In which case, I think you need more of a build tool solution
than a language solution.
Recent-ish versions of DUB (>= v1.24.0) support this out of the
box.
Provided the following structure:
```
+ $(pwd)
+ - dub.json
+ - source/
+ - source/appname/
+ - source/appname/prog1.d
+ - source/appname/prog2.d
+ - source/appname/common.d
```
If your `dub.json` contains:
```
{
"name": "swissarmyknife",
"targetType": "executable",
"configurations": [
{
"name": "prog1",
"targetName": "prog1",
"mainSourceFile": "source/appname/prog1.d"
},
{
"name": "prog2",
"targetName": "prog2",
"mainSourceFile": "source/appname/prog2.d"
}
}
```
It will build `prog1` by default, and `prog2` if you use `dub
build -c prog2`.
Note that you might want to put a `library` configuration as
first entry,
so that you can also use your code base as a library if you wish
to extend your project later.
Re: Drawbacks of exceptions being globally allocated
On Monday, 16 August 2021 at 05:36:07 UTC, Tejas wrote: That is why I was using heapAllocate, because using `new` on scope allocates exception on stack, and if you exit, then the exception is basically freed before it even gets caught. It fails even when you catch within the same function. But allocate on heap and giving ownership to a `scope` qualified variable is no problem at all. No `signal 11` killing my process ^_^ You are relying on an accept-invalid though. The compiler *should not* accept that code, but currently erroneously does so.
Re: Drawbacks of exceptions being globally allocated
On Sunday, 15 August 2021 at 02:09:08 UTC, Tejas wrote: On Sunday, 15 August 2021 at 00:15:32 UTC, Ali Çehreli wrote: On 8/14/21 4:41 AM, Tejas wrote: > [...] exception > [...] So, there would be many exception objects one for each place that an exception can be thrown. Functions like enforce() would have to take a reference to the exception object that is associated with that local scope. [...] I just want ```@nogc``` exceptions ;_; Please tell me that the ```GC.stats``` thing I posted is irrelevant so that I can go back to using ```emplace```. I wanted to allocate a class on the heap without being forced to use templates... but I guess that simply isn't possible(I know I can use ```mixin```, but that's even worse). You can't really have `@nogc` allocated Exception without circumventing the type system. Personally I gave up on `@nogc` just because of how inconvenient it is. Regarding the broader topic, at Sociomantic, we had pre-allocated Exception. After years working there, I grew to see the `throw new Exception` you see everywhere as an anti-pattern. Exceptions aren't convenient to use. At the very least, we should have a way to print a formatted message, however nothing currently offers this. A simple way to achieve this is the following: https://github.com/bosagora/agora/blob/113c89bd63048a7b98b8e9a2a664bd0eb08ebc84/source/agora/common/Ensure.d The gist of it is a statically allocated Exception (via module ctor) that is thrown by our `ensure` method. This is not `pure` unfortunately (because accessing a global mutable is not pure), and not `@nogc` (because `snformat` / `formattedWrite` aren't `@nogc`), but it doesn't allocate. As Ali mentioned, having a single Exception in the program breaks Exception chaining. But Exception chaining is one of the lowest ROI feature of D: It took a lot of effort to implement correctly, and is barely, if at all, used. There have even been talks (involving Walter) of deprecating it. If your goal is to never *link* in the GC, then you can barely use Phobos. If your goal is to never use the GC, I would say, why ? Using the GC for long-lived object and/or infrequent allocation doesn't hurt. GC collections are only triggered when you call new, so as long as you keep your critical path free of allocations, you're in the clear. Another little piece of code you might find interesting: https://github.com/sociomantic-tsunami/ocean/blob/adb31c84baa2061d07aaa0cb7a7d14c3cc98309b/src/ocean/core/Test.d#L305-L340 This uses a built-in method (`gc_stats`) which predates `GC.stats` and doesn't work in D2, but I'm sure you'll easily figure out how to adapt it :)
Re: input range with non copyable element
On Sunday, 8 August 2021 at 18:36:02 UTC, vit wrote: Hello, is there reason why elements of input range must be copyable? By design, not that I can think of. But it is assumed all over the place, unfortunately. You can make your `front` method return by `ref`, but you're still going to get bitten as soon as you do any `std.algorithm`-based operation, as storage classes are not inferred (https://issues.dlang.org/show_bug.cgi?id=9423) and things get passed by value to your delegates by default. The problem can also show up when you `foreach` over a range (https://issues.dlang.org/show_bug.cgi?id=15413). And finally, `std.algorithm` need to support it. So currently you'll have to jump through a lot of hops to get it to work. It'll be much easier to use your own `map` & co to get the job done for the time being. Hopefully at some point in the near future that won't be needed anymore.
Re: __FILE__
On Monday, 26 July 2021 at 11:43:56 UTC, workman wrote:
file test.d:
-
module test;
import abc;
void doTest(){
log!"test"();
}
---
file abc.d:
-
module abc;
import test;
void log(string fmt, int line = __LINE__, string path =
__FILE__[0..$], A...)(A a) {
import core.stdc.stdio;
printf("[%s:%d] \n", path.ptr, line);
}
extern(C) int main() {
doTest();
return 0;
}
-
retult: [abc.d:4]
expect: [test.d:4]
It's a known bug: https://issues.dlang.org/show_bug.cgi?id=18919
If you remove the slicing from `__FILE__`, it'll work as expected.
Re: module search paths
On Wednesday, 4 August 2021 at 04:51:48 UTC, Brian Tiffin wrote: With `import std.json` working for the other symbols like parseJSON? `gdc-11 (Ubuntu 11.1.0-1ubuntu1~18.04.1) 11.1.0` Have good. You are using GDC 11, which has an older version of the frontend. GDC is pretty great for targeting a variety of platform and having a very stable compiler, but it comes with the downside that it is updated less frequently (tied to GCC releases) and the docs may get outdated. JSONType used to be named `JSON_TYPE`, and this was changed in v2.082.0. I think GDC-11 is somewhere around v2.076.0 (with a lot of backport for bugs, but no feature / Phobos backport). Since v2.082.0 was released 2018-09-02 (almost 3 years ago), the documentation has long moved. TL;DR: Use `JSON_TYPE`. Note that you can quickly get LDC / DMD setup with the install script, or d-apt (https://d-apt.sourceforge.io/).
Re: Name Mangling & its representation of D types
On Tuesday, 3 August 2021 at 20:29:10 UTC, NonNull wrote: On Tuesday, 3 August 2021 at 17:01:38 UTC, Mike Parker wrote: On Tuesday, 3 August 2021 at 16:43:52 UTC, NonNull wrote: how does it work for recursive types like a struct containing a pointer to a struct of the same type A struct `S` with a member of type `S*` is still just a struct `S`. The pointer doesn't change anything about the type. Aha, so it just uses the name S, not an algebraic representation of the structure of S. Yes, because D is a nominal type system, using the FQN of the symbol is enough. Mangled names start with `_D` and then contain the encoding of the symbol being mangled (can be a variable, a function, etc...). To avoid an explosion in the symbol length we have back reference (which the blog mentions IIRC). Not only are parameter types encoded, but so are function attributes (`@safe` and co), with the notable exception of inferred `scope`, to allow people to link `-dip1000` code with non-DIP1000 code. `core.demangle` provides a programmatic way to demangle a symbol to its code representation. `ddemangle`, packed with DMD, allow to do it via the CLI (similar to `c++filt`). Newer binutils have support for D as well, so `nm --demangle=dlang` works (note that some older binutils support this, but don't support backref). Mangling is altered by `extern(LANG)` (where LANG is one of `C`, `C++`, `Objective-C`, `System`, `D`), or `pragma(mangle)`.
Re: Exit before second main with -funittest
On Friday, 30 July 2021 at 03:45:21 UTC, Ali Çehreli wrote:
Almost all of my programs are in the following pattern:
```D
import std.stdio;
void main(string[] args) {
version (unittest) {
// Don't execute the main program when unit testing
return;
}
}
```
Are you aware that this isn't necessary since v2.090.0 ?
https://dlang.org/changelog/2.090.0.html#unittest-default
Re: Performance issue with fiber
On Wednesday, 21 July 2021 at 22:51:38 UTC, hanabi1224 wrote: Hi, I'm new to D lang and encounter some performance issues with fiber, not sure if there's something obviously wrong with my code. I took a quick look, and the first problem I saw was that you were using `spawnLinked` but not replacing the scheduler. `std.concurrency` uses a global `scheduler` variable to do its job. Hence doing: ```diff - auto scheduler = new FiberScheduler(); + scheduler = new FiberScheduler(); ``` Will ensure that `spawnLinked` works as expected. There are a few other things to consider, w.r.t. fibers: - Our Fibers are 4 pages (on Linux) by default; - We have an extra guard page, because we are a native language, so we can't do the same trick as Go to auto-grow the stack; - Spawning fibers *is* expensive and other languages reuse fibers (Yes, Go recycle them); The `FiberScheduler` implementation is unfortunately pretty bad: it [does not re-use fibers](https://github.com/dlang/phobos/blob/b48cca57e8ad2dc56872499836bfa1e70e390abb/std/concurrency.d#L1578-L1599). I believe this is the core of the issue.
Re: enum true, or 1
On Thursday, 22 July 2021 at 03:44:13 UTC, Brian Tiffin wrote: What is the preferred syntax for simple on/off states? Did I read that D was moving to strictly 1 and 0 literals instead of true/false on/off yes/no? If so, is there an idiom for yes/no/maybe -1,0,1 less/equal/greater? Excuse the noise. For some backfill; getting used to DDoc. Frontmatter can be attached to the module declaration. Great for setting up a page. Wanted to do something similar for backmatter, in particular the without warranty disclaimer (instead of it taking up space on the first screen of a listing). That means attaching backmatter doc comments to a declaration, something akin to `enum INDEMNITY = true;`. Or is it `= 1`? Opinions welcome, as this will end up being nothing more than a personal preference, but it would be nice to avoid dragging fingernails over anyone's mental chalkboard. Have good, make well. AFAIK, the usual wisdom is to use `true` or `false` over `1` and `0`. However, it still might not be enough in a public API, so there is `std.typecons.Flag`: https://dlang.org/library/std/typecons/flag.html Last but not least, `true` is defined as `1` per the spec, so the following is valid: ``` char[] myString = getString(); bool hasNullCharAtEnd = parseString(myString); char[] copy = new char[](myString.length - hasNullCharAtEnd); ``` This is quite useful when needed to offset something by one: Just add or subtract your `bool` value.
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Wednesday, 21 July 2021 at 03:25:03 UTC, apz28 wrote: with below error message: ..\..\pham\db\db_skdatabase.d(140): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(139): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb ..\..\pham\db\db_skdatabase.d(138): Error: null dereference in function _D4pham2db10fbdatabase7FbArray__T13readArrayImplTbZQsMFNfCQCeQCc8database12DbNameColumnZAb It seems the compiler is doing extra analysis and seeing that a null pointer is being dereferenced. Can you provide the code for "pham\db\db_skdatabase.d" at L138 through 140 ?
Re: How to parse a json node that contains children of different types?
On Tuesday, 20 July 2021 at 21:18:12 UTC, Bagomot wrote:
But there is a problem with different types. I understand that
Object[] is not suitable here, but I don’t know how to do it.
I ask you to help me with this.
IIUC, the `arguments` are command line arguments passed to a Java
program, and some of those might be passed to the JVM ?
So you probably will end up with something like:
```
struct Arguments{
JVMArgs jvm;
ProgramArgs program;
}
```
Of course, the question is, what's `JVMArgs` ?
Now, as you noticed, you can't represent an array of unrelated
types in D (which makes sense). So what you can do is create a
common type for it, by using an `union`.
```
union JVMArg
{
RuleValue ruleValue;
string str;
// Etc...
}
alias JVMArgs = JVMArg[];
```
However, \ might not support it directly, or
might support it through its own type (you will need a tagged
union, and not just a simple union, as you need to know the type
that the library read).
But if you take a step back, I think you might find this solution
is far from ideal.
Having worked on a JSON library myself, I can tell you they are
all implemented with a tagged union. And converting a tagged
union to a tagged union is no improvement.
Instead, I would recommend to just use the JSON directly. If you
need to pass things around, you might want to deserialize it to a
common format. For example, assuming your project is a process
manager for Java program and you want to read a common set of
arguments from a configuration file, you might want to just
generate the strings:
```
auto myJSON = parseConfigFile("config.json");
string[] defaultJVMArgs = parseJVMArgs(myJSON);
auto processMonitor = new ProcessMonitor(defaultJVMArgs);
```
TL;DR: If you want to use loosely typed data in a strongly typed
language, you need to come up with a common type. That common
type is usually either a discriminated union (which a JSON object
is, essentially) or something that is domain-specific.
Hope this helps. I had a quick look at asdf and couldn't see a
support for tagged union, so you would probably need to provide
your data structure with a `deserializeFromAsdf` method. If you
want to do so, look into providing a wrapper to `SumType`, e.g.:
```
struct MyUnion (T...) {
SumType!T data;
alias data this;
SerdeException deserializeFromAsdf(Asdf data) { /* Fill in
the SumType */ }
```
But I would recommend just using the JSON object if you can.
Re: Including a file
On Sunday, 18 July 2021 at 17:48:53 UTC, Vindex wrote:
On Sunday, 18 July 2021 at 17:31:24 UTC, Adam D Ruppe wrote:
On Sunday, 18 July 2021 at 17:28:07 UTC, Vindex wrote:
Error: file "thing.json" cannot be found or not in a path
specified with -J
You need to specify the path where it is found with the -J
switch to the compiler. Like `ldc2 -J. yourfile.d
I already compiled the library itself with -Jres. It turns out
that this must be done twice? Once when compiling the library,
the second time when compiling the program.
Is the inclusion done in a templated function, or in a global ?
If the `import` happens in a function that is not in a root
module, it won't be necessary to use `-J` when linking the
program:
```D
module root;
import nonroot;
import std.stdio;
void main ()
{
writeln(foo());
}
// Some other file:
module nonroot;
string foo ()
{
string val = import("hello.txt");
return foo;
}
```
However, if the `import` is in a templated function, it might
need to be instantiated in the calling module:
```
module root;
import nonroot;
import std.stdio;
void main ()
{
writeln(foo!"hello.txt"());
}
// Some other file:
module nonroot;
string foo (string path) ()
{
string val = import(path);
return foo;
}
```
This will error out because the `foo` function needs to be
generated inside of the `root` module context:
```
nonroot.d(5): Error: need `-J` switch to import text file
`hello.txt`
nonroot.d(6): Error: template `foo(string path)()` has no type
root.d(6): Error: template instance `nonroot.foo!"hello.txt"`
error instantiating
```
An easy way for you to solve this might be to hide the value of
your JSON file behind a simple function that returns it, so that
the compiler never analyzes its body. If you use LDC and LTO, I
doubt it'll make any difference.
Re: assert(false) and GC
On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote: On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve i think you are right Try to use `@nogc` instead, it'll show you it does not allocate. A caveat though: A failing assert used to allocate before v2.097.0 (the latest version), it does not anymore. However, as your test captures all GC allocation, it likely triggers while the runtime is initializing.
Re: vibe.d compilation error
On Sunday, 4 July 2021 at 12:36:24 UTC, seany wrote: Is there any way, I can avoid this error? You are using an old version of Vibe.d, change your dependency to "~>0.9.0".
Re: float price; if (price == float.nan) { // initialized } else { // uninitialized } ... valid ?
On Wednesday, 30 June 2021 at 04:03:24 UTC, someone wrote:
On Wednesday, 30 June 2021 at 03:51:47 UTC, Mathias LANG wrote:
... is far from pretty but it works as expected, thanks for
your tip !
Can be made a bit prettier with UFCS:
```d
import std.math : isNaN;
float lnumStockPricePreceding;
foreach (float lnumStockPrice; ludtStockPriceEvolution.range)
if (!lnumStockPricePreceding.isNan) {
/// do something
}
lnumStockPricePreceding = lnumStockPrice;
}
```
Or even better, with ranges:
```d
import std.math : isNaN;
float lnumStockPricePreceding;
foreach (float lnumStockPrice;
ludtStockPriceEvolution.range.filter!(f => !f.isNan))
/// do something
lnumStockPricePreceding = lnumStockPrice;
}
```
Re: float price; if (price == float.nan) { // initialized } else { // uninitialized } ... valid ?
On Wednesday, 30 June 2021 at 03:32:27 UTC, Vladimir Panteleev wrote: On Wednesday, 30 June 2021 at 03:15:46 UTC, someone wrote: Is the following code block valid ? Comparison with `nan` always results in `false`: See section 10.11.5: https://dlang.org/spec/expression.html#equality_expressions You can use the `is` operator to perform bitwise comparison, or use `std.math.isNaN`. Side note: That doesn't apply to `if (myFloat)` or `assert(myFloat);`, unfortunately: https://issues.dlang.org/show_bug.cgi?id=13489
Re: Are D classes proper reference types?
On Monday, 28 June 2021 at 06:13:06 UTC, Ola Fosheim Grøstad wrote: On Sunday, 27 June 2021 at 23:20:38 UTC, Mathias LANG wrote: - It locks us in a position where we depend on an external committee / implementation to define our ABI. Well, that could be an issue, but it is not likely to change fast or frequently so I don't think it is a high risk approach. The issue is twofold: it requires us to follow upstream changes (the case you are thinking of), but also provides us from making non backward-compatible downstream changes (meaning we can't change it as we see fit if we realize there is potential for optimization). In any case, if you feel like it's worth it @Ola, you could start to look into what it takes (druntime/dmd wise) and start to submit PR. There is no point unless there is consensus. You first need to get consensus otherwise it is means throwing time into the garbage bin. Waiting on "consensus" is an easy way to avoid doing any kind of work :) I'm fairly sure most large achievements that have been undertaken by people in this community (that were not W) have been done without their (W's) blessing. People just went ahead and did it. But obviously those people cared more about getting things done than spending time discussing it on the forums.
Re: Are D classes proper reference types?
On Sunday, 27 June 2021 at 08:41:27 UTC, kinke wrote: On Sunday, 27 June 2021 at 07:54:38 UTC, Ola Fosheim Grøstad wrote: [AFAIK, most C++ implementations put the - of course totally incompatible - *C++* TypeInfo into vtable slot -1.] Actually my understanding is that it's part of the ABI: Each virtual table address in the VTT is the address to be assigned to the respective virtual pointer, i.e. the address past the end of the typeinfo pointer (the address of the first virtual function pointer, if there are any), not of the first vcall offset. [Source: Itanium ABI, 2.6.2 VTT Order](https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-ctor-vtt) Regarding replacing D's ABI with C++, it *might* be possible today, but: - It takes someone to care about it and want it; - It's going to be a lot of work, so it should come with lots of benefit - I don't see much as of now; - It locks us in a position where we depend on an external committee / implementation to define our ABI. In any case, if you feel like it's worth it @Ola, you could start to look into what it takes (druntime/dmd wise) and start to submit PR. For dlang devs questions, I recommend to use the dlang slack.
Re: semi-final switch?
On Thursday, 17 June 2021 at 21:41:28 UTC, Steven Schveighoffer
wrote:
A final switch on an enum complains if you don't handle all the
enum's cases. I like this feature.
However, sometimes the data I'm switching on is coming from
elsewhere (i.e. a user), and while I want to enforce that the
data is valid (it's one of the enum values), I don't want to
crash the program if the incoming value is not correct. But
final switch doesn't let me declare a default case (to throw an
exception instead).
If I use a non-final switch, then my code might forget to
handle one of the cases.
Oh, and to throw a monkey wrench in here, the value is a
string, not an integer. So I can't use std.conv.to to verify
the enum is valid (plus, then I'm running a switch twice).
Any ideas on better ways to handle this?
-Steve
Well, if you receive an `enum` that have an out of bounds value,
your problem lies in the caller, not the callee. You're breaking
the most fundamental promise of a type, that is, the values it
can take. And you obviously also break any `@safe` function by
feeding it this value.
So instead of thinking in terms of `enum`, I would say, think in
them of the value, and generate the switch:
```D
SWITCH: switch (myRawValue)
{
static foreach (EV; NoDuplicates!(EnumMembers!MyEnum))
{
case EV:
// Handle;
break SWITCH;
}
default:
throw new Exception("Invalid value: " ~ myRawValue);
}
```
Note that this can be encapsulated in its own function, like
`validateEnum (EnumType) (BaseType!EnumType value)` (not sure if
we have a `BaseType` template, but you get the point).
Re: Missing stacktrace on memory allocation failure
On Wednesday, 2 June 2021 at 17:52:12 UTC, mw wrote: On Thursday, 12 November 2020 at 13:16:21 UTC, Steven Schveighoffer wrote: On 11/12/20 4:22 AM, Per Nordlöw wrote: Why don't I get a stack trace on Memory allocation exceptions? In my case I only get: src/core/exception.d(647): [unittest] Memory allocation failed core.exception.OutOfMemoryError@src/core/exception.d(647): Memory allocation failed Certain errors are flagged as not able to allocate memory. So you don't get a stack trace. I think it's a huge mistake, and we don't need memory allocation to do stack trace printing. But that's the way it is. Hit this one today, since it's a mistake, what does it take to fix it? or you are saying it's unfix-able in the current D runtime? It is fixable, but it'll take a lot of work. The main blocker is that the interface that is exposed to the user relies on memory allocation. Namely, the `TraceInfo` interface is: https://github.com/dlang/druntime/blob/2d8b28da39e8bc3bc3172c69bb96c35d77f40d2a/src/object.d#L2257-L2261 Note that: 1) `toString` returns a `string` (allocation); 2) The `opApply`'s delegate use a `char[]` as parameter; What we *should* have is an `opApply` on a struct that contains all necessary info, which itself writes to a sink / OutputRange. Such struct exists (https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/src/core/internal/backtrace/dwarf.d#L77-L160) but need to be exposed to user code. Then *printing* the stack trace will no longer allocate. However, `defaultTraceHandler` still returns an object, so acquiring the handler will also need to be addressed. There have been talks of deprecating chained Exceptions, and that would make such a task much simpler.
Re: LDC 1.26.0
On Wednesday, 28 April 2021 at 15:30:58 UTC, kinke wrote: Glad to announce LDC 1.26: * Based on D 2.096.1+. * Fixes a v1.25 regression wrt. corrupt `TypeInfo_Interface.info`. * Some more fixes and dcompute improvements. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.26.0 Thanks to all contributors & sponsors! Thanks a lot for your work on this Martin! We exclusively use LDC, and we're really looking forward to be able to use non-POD C++ types by value across language boundaries, and finally use `-checkaction=context`!
Re: "this" as default parameter for a constructor.
On Sunday, 11 April 2021 at 20:38:10 UTC, Pierre wrote:
Hi,
I have a class with a reference to the parent object and a
constructor that has the parent as parameter
class foo {
this ( foo p /* , other params */ ) {
parent = p;
}
foo parent;
}
Of cause, the parent is almost always the object that creates
the new intance. So
auto f = new foo(this);
I'd like to set "this" ( the creator ) as default argument if
the constructor :
this ( foo p = this ) {...}
I can't. But however, the function, the argument and the
current object in body of the constructor are 3 different
things and the compiler can distinguish each one.
Is there a way to pass the reference of the caller to the
creator as default argument ?
Depending on what you are trying to do, I would recommend to
instead go with nested classes if you can. E.g.
```D
class MyClass {
class MyChild {
this (int value) { this.value = value; }
private int value;
}
}
void main ()
{
auto mc = new MyClass;
auto child = mc.new MyChild(42);
}
```
It'll give you an automatic reference to the parent. Of course if
you are trying to do something like linked list, where all
elements have the same type, it won't work.
In this case, the `create` approach might be better. You should
be able to cook something with a template `this` parameter to
reduce boilerplate.
And regarding allowing `this` as default argument: Definitely no.
While it could be possible with some stretch (e.g. we'll have to
delay default parameter semantic to the call site, unlike what is
currently done, and that would mess with things like overload
resolutions and template type inference), it wouldn't be sound /
it'd be very surprising. I for one would expect `this` to be the
object referencing itself, not the `this` of my caller.
Re: LDC 1.25.0
On Thursday, 25 February 2021 at 19:57:04 UTC, Dennis wrote: In the PR you mentioned tracy*, but I'm still looking at how to compile it for Linux since the release only seems to include Windows binaries. I guess I'll try it out on Windows first. *https://github.com/ldc-developers/ldc/pull/3624#issuecomment-735446453 If it's the regular client, then just cd to https://github.com/wolfpld/tracy/tree/master/profiler/build/unix and run `make`. We use it on Linux without problem, but the profiler crashes on Mac OSX ATM.
Re: LDC 1.25.0
On Sunday, 21 February 2021 at 18:26:38 UTC, kinke wrote: Glad to announce LDC 1.25 - some highlights: - Based on D 2.095.1. - LLVM for prebuilt packages bumped to v11.0.1; support added for LLVM 11.1 and upcoming 12.0. - Profile/trace LDC invocations via --ftime-trace. - New Windows installer and native 'Apple silicon' package. - New experimental template emission scheme for -linkonce-templates. This option can significantly accelerate compilation times for optimized builds (e.g., 56% faster on my box when compiling the optimized Phobos unittests). Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.25.0 Thanks to all contributors & sponsors! Amazing! We were really looking forward to this release, as it makes both Alpine Linux and `-preview=in` finally usable for us, and will allow us to build some useful tools on top of the GC. Many thanks for your continuous efforts in maintaining the project!
Re: using dub and -checkaction=context
On Sunday, 17 January 2021 at 20:42:06 UTC, Steven Schveighoffer wrote: On 1/17/21 2:27 PM, Anonymouse wrote: On Sunday, 17 January 2021 at 15:41:45 UTC, Steven Schveighoffer wrote: I'm trying to run unittests using `dub test`, and I wanted to use the new -checkaction=context feature to avoid having to instrument my unittests to print out the string comparison failure that's happening. But I tried adding this to my dub.sdl file: dflags "-checkaction=context" platform="dmd" But now I get linker errors: /home/steves/.dub/packages/vibe-core-1.10.1/vibe-core/source/vibe/appmain.d:(.text._D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv[_D3std8typecons__T10RefCountedTSQBe9container5array__T5ArrayTS4vibe4core4sync18LocalTaskSemaphore12ThreadWaiterZQCg7PayloadVEQEtQEs24RefCountedAutoInitializei0ZQFm6__dtorMFNaNbNiZv]+0x5c): undefined reference to `_D4core8internal7dassert__T14_d_assert_failVAyaa1_3eTmTiZQBeFNaNbNiNfKxmxiZQBf' https://issues.dlang.org/show_bug.cgi?id=19937 ? Slightly different error message though. Yeah, that's probably it. Hm... this feature isn't very usable if I can't use it with dub. And the bug report you linked to also has an example that fails with straight dmd (even without unittests). -Steve Yeah, it's currently not usable, because DMD thinks the template is already instantiated in Phobos / druntime. I tried to work around it in my projects and it didn't work out. I want to enable it by default but there's 2 issues blocking it ATM (see https://github.com/dlang/dmd/pull/11925). Once that PR is green, we can enable it when compiling druntime / Phobos and your linker errors will disappear. Also, dub-wise, you can't really use `-preview` before the latest release. That's why we added https://github.com/dlang/dub/commit/cd9b30e04813108c05abf97d97a42daf466eabdb ...
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 13:48:52 UTC, angel wrote: On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote: The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvb...@forum.dlang.org Why not "int[auto] arr = [1, 2, 3]" ? IMHO auto keyword is less ambiguous than $. Someone else could misunderstand `auto` to mean partial type deduction on associative array, e.g. `int[auto] arr = ["Hello": ubyte(1), "World": ubyte(2)];`. Personally, I think `$` is very natural here, but I also didn't consider `auto` before.
Re: Release Candidate [was: Re: Beta 2.095.0]
On Wednesday, 30 December 2020 at 14:23:39 UTC, Paolo Invernizzi wrote: On Wednesday, 30 December 2020 at 10:51:38 UTC, Martin Nowak wrote: On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. The release candidate for 2.095.0 is live now. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thank you Mathias for commit 5f701dc! Unfortunately it doesn't fix the exact case you found, it was a byproduct of working on your test case. And I don't think I'll have time to get to it before the release (which is scheduled January 1st).
Re: Beta 2.095.0
On Monday, 28 December 2020 at 20:22:50 UTC, Per Nordlöw wrote: On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html Feature https://dlang.org/changelog/2.095.0.html#better-vtemplates was already added at https://dlang.org/changelog/2.094.0.html#better-vtemplates Shall I fix? Yes please! And thanks for paying attention to the changelog, it matters a lot!
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 21:59:31 UTC, Paolo Invernizzi wrote: My point is that the result without -de is [...] Which unfortunately is pretty useless in my case ... Could you point me towards the code that triggers this ?
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 11:38:11 UTC, Paolo Invernizzi
wrote:
The point is that the deprecation is coming from an external
library, it would be great to have the precise instantiation
point in that source code, so I was wondering if that dmd
improvement [1] should print a more detailed trace.
[1] https://dlang.org/changelog/2.095.0.html#deprecation-context
It does print a detailed stack trace (up to the first symbol that
is not a template) if you don't use `-de`. If you use `-de`,
since the checks in Phobos are `is(typeof(n.toString()))` or
`__traits(compiles, n.toString())`, then it just changes whether
or not the code compiles, and as a result changes the output of
the program. A trivial example:
```
import std.stdio, std.typecons;
struct Foo {
deprecated string toString() const { return "Oops"; }
}
void main () { writefln("%s", Foo.init); }
```
Will print, with v2.094.2 or before (dmd -run):
```
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
Oops
```
Not great. If you use `dmd -de -run`, you'll get:
```
Foo()
```
Notice the deprecations are gone, but so is the usage of the
`toString` method. Using DMD v2.095.0-beta.1 with `-de` should
give you the same output, but without `-de`:
```
% ~/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -run foo.d
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4420):
instantiated from here: hasToString!(Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4430):
instantiated from here: formatObject!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(1875):
instantiated from here: formatValueImpl!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(576):
instantiated from here: formatValue!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(1661):
... (1 instantiations, -v to show) ...
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(4271):
instantiated from here: writefln!(char, Foo)
foo.d(5):instantiated from here: writefln!(char, Foo)
Oops
```
So the feature works as intended, however `-de` is a dangerous
trap, as it changes what is instantiated.
Re: Beta 2.095.0
On Wednesday, 23 December 2020 at 15:38:17 UTC, Steven Schveighoffer wrote: What is happening is that some speculative compilation is checking something via the get function. It might not make a difference, but the error message is useless (who knows where that traits call is triggered). FYI, v2.095.0 *should* print the instantiation trace, so you can actually track down where it comes from. And the reason DMD now shows the trace is exactly because of this deprecation. Most likely, it doesn't change anything. Therefore when you turn on the deprecation as an error, it doesn't affect compilation, it just fails in the speculation instead of succeeds. But the ultimate result doesn't actually change anything. I can't wait until this deprecation has been finalized, because I hate seeing seas of deprecation messages I can't do anything about. 2.097 cannot come soon enough... FYI, in theory we could use `__traits(isDeprecated)` to silence this. But I haven't looked at the code myself.
Re: Vibe.d build on LDC error
On Friday, 6 November 2020 at 05:52:56 UTC, Vino wrote:
Hi All,
When we try to build vide.d using ldc (dub build) we are
getting the below error, openssl is already been installed
(OpenSSL 1.0.2j-fips 26 Sep 2016), hence request your help on
the same.
openssl.d:84: error: undefined reference to 'OPENSSL_init_ssl'
openssl.d:121: error: undefined reference to 'OPENSSL_sk_num'
openssl.d:128: error: undefined reference to 'OPENSSL_sk_value'
openssl.d:243: error: undefined reference to 'BIO_set_init'
openssl.d:244: error: undefined reference to 'BIO_set_data'
openssl.d:245: error: undefined reference to 'BIO_set_shutdown'
openssl.d:1382: error: undefined reference to
'BIO_get_new_index'
openssl.d:1382: error: undefined reference to 'BIO_meth_new'
openssl.d:1384: error: undefined reference to
'BIO_meth_set_write'
openssl.d:1385: error: undefined reference to
'BIO_meth_set_read'
openssl.d:1386: error: undefined reference to
'BIO_meth_set_ctrl'
openssl.d:1387: error: undefined reference to
'BIO_meth_set_create'
openssl.d:1388: error: undefined reference to
'BIO_meth_set_destroy'
openssl.d:899: error: undefined reference to
'BN_get_rfc3526_prime_2048'
openssl.d:1288: error: undefined reference to 'BIO_set_init'
openssl.d:1290: error: undefined reference to 'BIO_set_data'
openssl.d:1298: error: undefined reference to 'BIO_get_shutdown'
openssl.d:1300: error: undefined reference to 'BIO_set_init'
openssl.d:1302: error: undefined reference to 'BIO_set_data'
openssl.d:1309: error: undefined reference to 'BIO_get_data'
openssl.d:1323: error: undefined reference to 'BIO_get_data'
openssl.d:1339: error: undefined reference to 'BIO_get_shutdown'
openssl.d:1342: error: undefined reference to 'BIO_set_shutdown'
openssl.d:1335: error: undefined reference to 'BIO_get_data'
collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
/Project/dlang/ldc-1.24.0/bin/ldc2 failed with exit code 1.
From,
Vino.B
Which Linux distribution ? Which version of Vibe.d ?
A recent enough Vibe.d should detect OpenSSL based on 1)
pkg-config 2) the openssl binary. Make sure you have the
development version of OpenSSL installed.
Additionally, v1.0.2 is quite old (and subject to security
issues), so you might want consider upgrading. But even with that
version, it should work.
You can force the usage of a certain configuration using:
```
"dependencies": {
"vibe-d": "~>0.9",
"vibe-d:tls": "*"
},
"subConfigurations": {
"vibe-d:tls": "openssl-1.0"
},
```
See:
https://github.com/vibe-d/vibe.d/blob/70b50fdb9cd4144f1a5007b36e6ac39d4731c140/tls/dub.sdl#L99-L103
Re: LDC 1.24.0
On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote: Glad to announce LDC 1.24 - some highlights: - Based on D 2.094.1+. - Support for LLVM 11. The prebuilt packages use v11.0.0, and the x86 packages newly include the LLVM backend for AMD GPUs. - Experimental support for targeting macOS on 64-bit ARM. The macOS package includes prebuilt druntime/Phobos libraries for cross-compilation via `-mtriple=arm64-apple-macos`. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.24.0 Thanks to all contributors & sponsors! Thanks for all your work on this and the great releases!
Re: Recommended way to use __FILE__/__LINE__ etc.
On Thursday, 22 October 2020 at 16:03:45 UTC, H. S. Teoh wrote: On Thu, Oct 22, 2020 at 03:32:57PM +, Andrey Zherikov via Digitalmars-d-learn wrote: There are two ways how __FILE__, __LINE__ etc. can se used in function parameters: as regular parameters and as template parameters: [...] What is recommended way? What are pros/cons of each case? I don't know what's the "recommended" way, but generally, I prefer to pass them as regular parameters. Otherwise you will get a lot of template bloat: one instantiation per file/line combination. However, sometimes there is not much choice: if your function is variadic, then you pretty much have to use template parameters, 'cos otherwise you won't be able to pick up the __FILE__/__LINE__ of the caller with default arguments. T You will. This is possible since v2.079.0 (March 2018): https://dlang.org/changelog/2.079.0.html#default_after_variadic So yeah, always pass them as function parameters to avoid bloat.
Re: More elaborate asserts in unittests?
On Wednesday, 21 October 2020 at 22:48:04 UTC, IGotD- wrote: On Wednesday, 21 October 2020 at 22:41:42 UTC, Adam D. Ruppe wrote: try compiling with dmd -checkaction=context Thanks, that was simple and it worked. Speaking of this, shouldn't this be documented here for example. https://dlang.org/spec/unittest.html Just adding a friendly tip that -checkaction=context gives the user more information. I couldn't find this information anywhere. Unfortunately this switch still has some bugs, so you can easily run into linker errors. I'm hoping to ultimately make it the default though.
Re: cannot call impure function
On Sunday, 4 October 2020 at 18:02:11 UTC, Michael wrote: On Sunday, 4 October 2020 at 17:43:13 UTC, Michael wrote: [...] I used the dmg file: dmd.2.094.0.dmg I reinstalled using the installation script (install.sh) and now it works. Still don't know why the dmg-based intstallation did not work. https://dlang.org/install.html Anyway, thanks for your responses! I think there might have been a mismatch between the compiler used, and the Phobos library used. This might happen if you used multiple sources for installation, e.g. brew / macports / dmg (install script is self contained and never affected).
Re: cannot call impure function
On Sunday, 4 October 2020 at 17:05:33 UTC, Michael wrote:
On Sunday, 4 October 2020 at 17:01:44 UTC, Paul Backus wrote:
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael wrote:
Dear all,
Sorry for the potentially stupid question, but I'm a complete
newbie to D. Why does compiling the following trivial code
fail?
import std.stdio;
void main()
{
writeln(3.14);
}
Works fine for me using DMD 2.094.0 on Linux. What OS and
compiler version are you using, and how did you install DMD?
DMD64 D Compiler v2.094.0
on macOS 10.15.6
I cannot reproduce locally (macOS 10.15.6 too). How did you
install DMD ?
Re: Taking arguments by value or by reference
On Sunday, 4 October 2020 at 14:26:43 UTC, Anonymouse wrote: [...] I mostly really only want a read-only view of the struct, and whether a copy was done or not is academic. However, profiling showed (what I interpret as) a lot of copying being done in release builds specifically. https://i.imgur.com/JJzh4Zc.jpg Naturally a situation where I need ref I'd use ref, and in the rare cases where it actually helps to have a mutable copy directly I take it mutable. But if I understand what you're saying, and ignoring --preview=in, you'd recommend I use const ref where I would otherwise use const? Is there some criteria I can go by when making this decision, or does it always reduce to looking at the disassembly? If the struct adds overhead to copy, use `const ref`. But if you do, you might end up with another set of problems. Aliasing is one of them, and the dangers of it are discussed at length in the thread about `-preview=in` in general. The other issue is that `const ref` means you cannot pass rvalues. This is when people usually turn towards `auto ref`. Unfortunately, it requires you to use templates, which is not always possible. So, in short: `auto ref const` if it's a template and aliasing is not a concern, `const ref` if the copy adds overhead, and add a `const` non-`ref` overload to deal with rvalues if needed. If you want to be a bit more strict, throwing `scope` in the mix is good practice, too. -- Now, about `-preview=in`: The aim of this switch is to address *exactly* this use case. While it is still experimental and I don't recommend using it in critical projects just yet, giving it a try should be straightforward and any feedback is appreciated. What I mean by "should be straightforward", is that the only thing `-preview=in` will complain about is `in ref` (it triggers an error). The main issue at the moment is that, if you use `dub`, you need to have control over the dependencies to add a configuration, or use `DFLAGS="-preview=in" dub` in order for it to work. Working on a fix to that right now. For reference, this is what adapting code to use `-preview=in` feels like in my project: https://github.com/Geod24/agora/commit/a52419851a7e6e4ef241c4617ebe0c8cc0ebe5cc You can see that I added it pretty much everywhere the type `Hash` was used, because `Hash` is a 64 bytes struct but I needed to support rvalues.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? Yes we have a 3rd way. Because `auto ref` just doesn't cut it for most usages, and `-preview=rvaluerefparam` never worked. You can have a look at the full discussion in the PR that introduced it (dmd#11000). I try to summarize a few arguments in favor of it here: https://github.com/dlang/dmd/pull/11000#issuecomment-674498704 As you can see from the discussion, it's not really something that was quickly merged, but the results of months of work. So while it might seems "ridiculous" to you, I'd appreciate if you could take the time to read through the discussion, as well as taking a look at Herb Sutter's presentation which was linked. The key takeaway from that presentation is that instead of having the users specify *how* to pass the parameter, they should specify what is the parameter's semantic. In our case, input (in), output (out), or input/output (ref). I'm not aware of a situation where you want to use `auto ref` on a parameter without `const` (or `const` semantic), because if you intend to modify the parameter, you need to be sure whether it's `ref` or not. I'm aware some people use it for forwarding but this has its own set of problem.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! Yay! "-preview=in" is beyond epic! I like epic things. What does it do? :D Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters.
Re: default arguments for const ref parameters in extern C++ functions
On Monday, 14 September 2020 at 18:58:44 UTC, 60rntogo wrote:
On Monday, 14 September 2020 at 17:11:59 UTC, k2aj wrote:
AFAIK the only way to have default ref arguments is to use a
global variable:
---
extern(C++) struct Foo
{
int x;
}
immutable foo1 = Foo(1);
extern(C++) void fun(const ref Foo foo = foo1);
---
Thanks. This appears to work, but feels like a hack. I can live
with that, but I'm still wondering if there is a more idiomatic
way of solving the problem.
D doesn't let rvalues bind to const ref (well, `in` will do that,
but it's D-only).
What was described as "global variable", is more of a "manifest
constant lvalue".
A (static) immutable variable with an initializer will always be
CTFE-d and available at compile time, so in this case it is
*exactly* what you need.
Also note that a default parameter doesn't affect the mangling /
ABI, because it works exclusively on the caller side. Thus, you
could just remove the default argument and your `extern(C++)`
binding would work just fine. But if you want to provide the same
API, `[static] immutable` + initializer is the way to go.
Re: Symmetry Investments and the D Language Foundation are Hiring
On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: 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 Agreed. A server approach would probably scale much better, if the intent is to speed up the developer's CTR cycle. But in any case, thanks to Symmetry for doing this! This is huge.
Re: in; scope; scope ref; DIP1000; documentation
On Thursday, 27 August 2020 at 18:49:19 UTC, James Blachly wrote: Peeling off from Mathias Lang's thread in General about making 'in' useful, for some novice questions: 1. The thread involves 'in' qualifier. Documentation (https://dlang.org/spec/function.html#param-storage) indicates that `in` is defined as `scope const` and should not be used as it is not implemented. **Is this [fact and recommendation] still true?** I have a PR to update the documentation: https://github.com/dlang/dlang.org/pull/2845 I got feedback on it, just didn't have time to complete / finish it, will come back to it soon. Is "scope ref" documented somewhere specifically? I found https://dlang.org/spec/function.html#scope-parameters which discusses the use of `scope` with ref type parameters, but the example given is pointer-based. Is it correct that `scope ref T` behaves the same as `scope T*` ? Regarding `scope` more generally, DIP1000 shows as "superseded" -- **can I still rely on this document for guidance?** We have a `-dip1000` flag but a superseded DIP. The discordance is extremely confusing. It is, for users and compilers developers alike. We're still waiting for Walter to write down the docs on that. If you look in the forums / PRs, you'll see that it's the most common feedback. I am glad D is iterating quickly and improving on safety, but I have found that documentation may not well recent changes in this area. Consequently I am reluctant to use (newer) features related to memory safety. If this is all comprehensively documented somewhere please let me know! We have a policy that every language change should come with a spec PR. It has improved documentation drastically, but there's still a way to go. I hope the aforementioned PR will clarify the status of `in`. I'm currently focusing on making sure it works properly everywhere before the next release (in 1 or 2 weeks), hence why fixing that PR has taken the back-seat (the website gets auto-updated, so even if the PR doesn't make the deadline, it'll be deployed as soon as it gets merged).
Re: Beta 2.093.1
On Monday, 24 August 2020 at 08:08:52 UTC, Martin Nowak wrote: On Thursday, 20 August 2020 at 03:28:38 UTC, Mathias LANG wrote: Just tried to install it on OSX: ``` ~/dlang/install.sh dmd :( Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz ### 100.0% Invalid signature http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz.sig ``` Works for me, maybe retry the download or run `~/dlang/install.sh update` to update your keyring? Right, I just needed to update the script. Perhaps this could be suggested when this error happens ?
Github Actions now support D out of the box!
Hi everyone, Almost a year ago, Ernesto Castelloti (@ErnyTech) submitted a PR for Github's "starter-workflow" to add support for D out of the box (https://github.com/actions/starter-workflows/pull/74). It was in a grey area for a while, as Github was trying to come up with a policy for external actions. I ended up picking up the project, after working with actions extensively for my own projects and the dlang org, and my PR was finally merged yesterday (https://github.com/actions/starter-workflows/pull/546). Starter workflow are suggested to you when you go to the `Actions` tab of a Github repository, or when you first make one. They are templates you can use to easily set-up a CI. Thanks to the work of Mihails Strasuns (@Dicebot) we have an action to install the compiler on all three platforms (https://github.com/dlang-community/setup-dlang), which this workflow use. This is how it looks: https://pbs.twimg.com/media/Ef58CrdU0AA2R7W?format=jpg=4096x4096 Using actions have several benefits over Travis: - Very easy to set up cross platform (Linux, Mac, Windows); - Usually faster machines; - Better integrated with Github; One major downside is that you can't re-triggger a single matrix row in a workflow, hence if your CI is flakey, you're going to have a bad time. Another great thing that is easy to setup with actions is automatically upload documentation. You can see an example here: https://github.com/bpfkorea/agora/blob/08a628ab8e7e38738a88f4c72dc0b42d43da185c/.github/workflows/main.yml#L125-L187 I hope to extract it to an action at some point so anyone can set it up with a single click.
Re: Which version of DMD does GDC 10 target
On Thursday, 20 August 2020 at 05:49:29 UTC, Arun wrote: On Thursday, 20 August 2020 at 05:07:28 UTC, H. S. Teoh wrote: On Thu, Aug 20, 2020 at 04:28:41AM +, Arun via Digitalmars-d-learn wrote: Which version of DMD is GDC 10 based on? Compile the following D program to find out: - static assert(0, "Compiler language version: " ~ __VERSION__.stringof); - I have this line in a file called langver.d, and whenever the exact language version isn't obvious, I compile it to find out the version. :-) (And yes it deliberately asserts instead of using pragma(msg) so that I don't have to type -o- or -of- or -c or whatever to suppress actual code emission, just `$compiler langver.d`.) --T Nice trick. Thanks. For the benefit of others, GDC 10 is based on DMD 2.076. https://dlang.org/changelog/2.076.0.html Side note, Using $() is better than `` for subshells, as it makes nesting much easier. ;-) Side note: Usually a lot of bug fixes are backported to GDC, so even though it says 2.076 feature-wise, bugs that have been fixed much later might not be present. Which is great because it makes bootstrapping *SO MUCH* easier.
Re: Beta 2.093.1
On Tuesday, 11 August 2020 at 09:30:48 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.093.1 point release, ♥ to the 11 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.093.1.html As usual please report any bugs at https://issues.dlang.org -Martin Just tried to install it on OSX: ``` ~/dlang/install.sh dmd :( Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz ### 100.0% Invalid signature http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz.sig ```
Re: How import DUB packcages directly and compile with DMD without use dub.exe?
On Friday, 17 July 2020 at 01:27:09 UTC, Marcone wrote: On Thursday, 16 July 2020 at 11:52:39 UTC, Andre Pany wrote: On Thursday, 16 July 2020 at 11:06:01 UTC, Marcone wrote: I just want import in file and run with dmd. Execute dub build with verbose output. You will find the info how dub is calling dmd. Kind regards Andre dub is calling dmd with -IC:\Users\Usuario\AppData\Local\dub\packages\scriptlike-0.10.3\scriptlike\src but I want dmd auto import any in dub packages, for example: -IC:\Users\Usuario\AppData\Local\dub\packages\. You can alter your `sc.ini` config to add `-I` path. But "auto-importing" package won't work, because packages are stored in a hierarchy that is `dub`-specific and DMD doesn't know about it. The piece of functionality you want sounds exactly like what dub is supposed to do, so why do you want to avoid it ?
Re: Release Candidate [was: Re: Beta 2.093.0]
On Friday, 3 July 2020 at 15:27:54 UTC, user1234 wrote: On Friday, 3 July 2020 at 11:10:25 UTC, Martin Nowak wrote: On Wednesday, 24 June 2020 at 21:01:05 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.093.0 release, ♥ to the 53 contributors. Release Candidate is live now. thanks but Have you see that full changelog is still missing ? A regression caused by the changes in tools. Martin already found the issue and it's in the process of getting fixed.
Re: Interfacing with C++ std::shared_ptr and std::unique_ptr
On Wednesday, 10 June 2020 at 06:43:24 UTC, Andre Pany wrote:
Hi,
I would like to interface with the library
https://github.com/NTNU-IHB/FMI4cpp
and have following class definitions in the header file:
``` c++
namespace fmi4cpp {
template
class fmu_base {
public:
const std::string guid() const {
return get_model_description()->guid;
}
const std::string model_name() const {
return get_model_description()->model_name;
}
virtual std::shared_ptr
get_model_description() const = 0;
};
templateme_fmu>
class fmu_provider : public virtual
fmu_base {
public:
virtual bool supports_cs() const = 0;
virtual bool supports_me() const = 0;
virtual std::unique_ptr as_cs_fmu() const = 0;
virtual std::unique_ptr as_me_fmu() const = 0;
};
```
While unique_ptr is already available in drunime library
core.stdcpp.memory,
shared_ptr is missing. Does someone already have translated
shared_ptr?
Also, the C++ classes make use of templates. Is it still
possible to call these
classes from D?
Kind regards
Andre
Depending on your needs, it might be trivial. We use this, and it
works accross all 3 platforms:
https://github.com/bpfkorea/agora/blob/ddd65e2fc3975d9c14ad36bcf28e5cd32de08945/source/scpd/Cpp.d#L38-L64
As mentioned, you will need to have the instantiation done on the
C++ side, but that's true for any template. Feel free to ask on
slack #cpp-interop.
Re: Alpine Linux 3.12 Released With D Language Support
On Saturday, 30 May 2020 at 21:48:32 UTC, Johan wrote: On Saturday, 30 May 2020 at 20:30:09 UTC, Cogitri wrote: On Saturday, 30 May 2020 at 20:03:30 UTC, Andrei Alexandrescu wrote: https://www.phoronix.com/scan.php?page=news_item=Alpine-Linux-3.12-Released I'm one of the DLang maintainers for Alpine - please feel free to open issues at https://gitlab.alpinelinux.org/alpine/aports/issues if you notice something being broken. Unfortunately *some* C bindings in core aren't quite up to speed on musl yet but I try to add those when I notice that they're missing, but filing an issue about that (or making a PR to core to add the bindings) would be of great help! Also thanks to @geod24 who made this happen and did most of the hard work :) Great work. Which compilers (and versions) are available? -Johan All 3 compilers. The version will be frozen for the next 6 months, but that just means a 2 to 3 releases support period, so it's not an issue IMO. There are still some small issues to iron out, and there's still no support for LTO out of the box (although one can compile it), but we've been using it for ~8 months and it works quite well. Also some of those issues are Musl specific and not related to Dlang, e.g. https://gitlab.alpinelinux.org/alpine/aports/-/issues/11154 Initial announcement: https://forum.dlang.org/post/oznltcuropwzxaakp...@forum.dlang.org Looking at it, all the "What's next?" have been done too :)
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote: The subject says it all. If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best. For everyone else, carry on as before. Thank you for listening to the community's feedback.
Re: Dub platform probes
On Thursday, 28 May 2020 at 02:28:07 UTC, Tim wrote: On Wednesday, 27 May 2020 at 21:17:54 UTC, Andre Pany wrote: I read through the source code. The probe file is created here https://github.com/dlang/dub/blob/master/source/dub/compilers/utils.d#L296 The function getTempFile determines a new random temp file name and stores the file path in a global variable. A module destructor loops through this string array list and deletes the temp files https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L98 I wonder why in your case the temp files are not deleted. Kind regards Andre Me too. I have noticed that sometimes I don't need to and other times I do. Maybe it is to do with program crashes where it isn't cleaned up? I'll keep a closer eye on it Is the app you're building a server by any chance ? There's a recurrent problem with `dub`: - https://github.com/dlang/dub/issues/536 There's a fix for it, unmerged though as it needs some work/testing: https://github.com/dlang/dub/pull/1696
Re: How to target ldc compiler only in dub
On Tuesday, 26 May 2020 at 22:28:14 UTC, data pulverizer wrote:
Hi,
I am trying to build a package to target LDC compiler only. I
have both dmd and ldc2 (1.18.0) installed on my system. The dub
file is:
```
{
"authors": [
"Me"
],
"copyright": "Copyright © 2020, Me",
"dependencies": {
"mir-algorithm": "~>3.8.12",
"mir-random": "~>2.2.14"
},
"description": "Some Cool Stuff",
"license": "MIT",
"name": "myPackage",
"dflags": [
"-O", "--release", "--boundscheck=off",
"--ffast-math", "-mcpu=native"],
"toolchainRequirements": {
"dmd": "no",
"gdc": "no",
"ldc": ">=1.18.0"
},
"targetType": "executable"
}
```
I get the message:
```
Installed dmd 2.090.1 is not supported by myPackage. Supported
compiler(s):
- ldc: >=1.18.0
```
Thanks
Add a `dub.settings.json` with:
```
{
"defaultCompiler": "ldc2"
}
```
Like we did:
https://github.com/bpfkorea/agora/blob/38b2c33cc56acdeeabce8158bf3231a1f51eb5b1/dub.settings.json
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote:
Am I saying nothing bad can happen if we implicitly trust
extern(C) declarations? No. I'm saying we'll be no worse off if
they're all implicitly @system.
This compiles with no warnings right *now*:
void main() {
import core.stdc.stdlib: free;
free(cast(void*) 42);
free(new int);
free();
}
And this code won't compile at all when you make `@safe` the
default:
```
void main ()
{
int[] myArray = (cast(int*) malloc(42 * int.sizeof))[0 .. 42];
}
```
So, we changed the default.
Now those people that want to easily prototype something, or
write applications that extensively use system libraries, will be
extremely inconvenienced, but we satisfied the people that want
more `@safe`ty, which we all known and agree is the future.
Except that in that process we also destroyed the meaning of
`@safe` by shooting a hole into it, for the convenience of the
people that want to easily prototype something and write
applications that interact extensively with system libraries,
because that's what half of the D users do.
Clearly, an improvement.
Re: Error running concurrent process and storing results in array
On Wednesday, 6 May 2020 at 03:41:11 UTC, data pulverizer wrote: Is there something I need to do to wait for each thread to finish computation? Yeah, you need to synchronize so that your main thread wait on all the other threads to finish. Look up `Thread.join`. Yes, that's exactly what I want the actual computation I'm running is much more expensive and much larger. It shouldn't matter if I have like 100_000_000 threads should it? The threads should just be queued until the cpu works on it? It does matter quite a bit. Each thread has its own resources allocated to it, and some part of the language will need to interact with *all* threads, e.g. the GC. In general, if you want to parallelize something, you should aim to have as many threads as you have cores. Having 100M threads will mean you have to do a lot of context switches. You might want to look up the difference between tasks and threads.
Re: Error running concurrent process and storing results in array
On Wednesday, 6 May 2020 at 03:25:41 UTC, data pulverizer wrote: [...] The problem here is that `process` is a delegate, not a function. The compiler *should* know it's a function, but for some reason it does not. Making the function static, or moving it outside of the scope of main, will fix it. For reference, this will spawn 100 threads to do a simple computation so probably not what you would want, I expect. But I suppose this is just example code and the underlying computation is much more expensive ?
Re: odd atomicOp errors from vibe-core
On Friday, 10 April 2020 at 03:26:04 UTC, Steven Schveighoffer wrote: On 4/9/20 11:22 PM, Stefan Koch wrote: On Friday, 10 April 2020 at 01:54:14 UTC, Steven Schveighoffer wrote: I'm building a library that uses vibe-core as an indirect dependency. Specifically, I'm testing the library with dub test. [...] Those are signed unsigned mismatches when it tries to lock. that's probably in vibe-d Can you explain why I do not get the errors when I have taken care of my errors? It doesn't make a whole lot of sense to me. -Steve I've observed this behavior as well. From what can tell, it's a false positive that only shows up in the presence of previous error. I'd say that has something to do with the way the compiler do semantic analysis. My money is on the fact that `core.atomic` is special, and that something else (bad error gagging, perhaps?) triggers an error. As far as I can tell, it is safe to ignore. If you can reduce it to something small enough, I'd say it's worthy of an issue tho.
Re: Fixing race issues the right way
On Sunday, 5 April 2020 at 22:24:27 UTC, solidstate1991 wrote: My game engine is currently broken due to some race issue I don't really know how to resolve. It seems that the compiler tries to skip instructions that are not locked with a `writeln()` or something similar. Usually I can safely remove the writeln after compiling it once with that way. However I've once ran into an issue when a previously working code just started to emit random junk data depending on CPU usage, and in that case the aforementioned workaround only partially worked (delaying crashes, etc). I've heard something about Mutex, however I lack the experience with multithreading. Is there public code you can link to ? Look for any usage of `__gshared`. Are you using `shared` as well ? Turn on `-preview=nosharedaccess` to get better diagnostic. Are you using any `extern` code ? How do you communicate between threads ? Message passing, or simple shared memory ?
Re: How to deploy on GitHub pages
On Tuesday, 31 March 2020 at 12:52:09 UTC, Ahmat wrote: Hi all, I want to use vibe.d for my personal website hosted on Github pages. I am not familiar with vibe.d and I am confused about how to approach this. Any suggestions, ideas ? I will appreciate your help. You can't. Vibe.d is a server technology, but Github pages only host static content. You can write HTML / CSS / JS, and host that, but you can't run a Vibe.d server.
Re: @future attribute / @future keyword?
On Wednesday, 18 March 2020 at 14:23:28 UTC, Steven Schveighoffer wrote: Honestly, I think that concept was never fully implemented (or maybe followed properly). Simply because there has not been much complaint about symbols being added "too quickly". 99.99% of the time, you add a symbol to a module, and there are no ill effects. The problem at the time was a significant one for Sociomantic, I believe because of a change that they needed for switching from Tango to druntime. If you grep druntime, there are 2 usages, both from about 2-3 years ago. Both were either submitted by sociomantic, or asked to add the @__future attribute from them. I'm guessing that either interest was lost in keeping this up, or didn't notice when things were added, and it didn't affect them. Seems like all the focus was on the exception hierarchy (which needs TLC anyway). Maybe someone from that org can identify how this has helped them. The whole concept itself has some rather obscure use cases. Perhaps in the future there will be an obvious use case, and we will be glad that we have it. -Steve Yep that feature is completely under-documented. It ended up being important to Sociomantic because we introduced `message` in `Exception`, as our `Exception` are reusable and use a buffer to minimize allocations, but said `message` broke a bunch of code because other `Exception`-derived class had implemented their own method that clashed with that very common name. In addition, some shadowing might have been involved at the time, which made the issue painful to track down. It is less important to mainstream D than it was to Sociomantic mainly due to the differences in our approaches. Sociomantic code relied heavily on OOP, while mainstream D does not. New symbols in Phobos are rare, and rarely conflict with other modules. Adding a new overload in an overload set is guaranteed to not conflict since the change from protection to visibility. I like to see it this way: Any new virtual function (and potentially new field) in a derived class relies on the absence of such name existing in any of its ancestor. If it does exist, or is introduced, the compiler will complain about `override` not being used. On the other hand, a new symbol in a module does not have this requirement (there is still potential for breaking change: e.g. if you introduce an overload that conflict, for example adding a `const(char)[]` overload to a function that has a `const(char)*` overload and no `string` overload). To answer the OP: It is still in the language, and there's a test for it in druntime (https://github.com/dlang/druntime/blob/master/test/exceptions/src/future_message.d). But yeah, no one uses it.
Re: " include imported modules in the compilation " should exclude di file
On Monday, 9 March 2020 at 13:55:08 UTC, Calvin P wrote: The current compiler "-i=module_name" option will include imported modules as source code. When the module define from di file extension, I think compiler should avoid treat it as source file. What do you think? Sounds sensible. Can you raise a bug report ?
Re: DConf 2020 Canceled
On Saturday, 7 March 2020 at 20:37:32 UTC, Mike Parker wrote: I really wish I didn't have to make this announcement, but in light of the COVID-19 outbreak and with an abundance of caution, the D Language Foundation and Symmetry Investments have agreed to cancel DConf 2020. Though it's possible that things will have cleared up by June, we can't be sure that will be the case. We don't want to put members of the D community at risk if things are not cleared up, or risk travel disruptions for those who do register and make travel plans. We decided it's better to cancel earlier rather than later to minimize the number of people who will need to cancel or rebook their travel arrangements. Personally, I was really looking forward to heading to London and seeing everyone again, but I do agree with the decision. We hope not many of you will be impacted by the decision and we're terribly sorry if you are. Sad to hear this, I was really looking forward to it. But indeed there seem to be no other choice. Don't think an online event will quite fill the gap, many of us already interact online very frequently anyway.
Re: DMD: Is it possible change compile time errors to runtime errors in Dlang?
On Friday, 6 March 2020 at 04:56:28 UTC, Marcone wrote: Is it possible change compile time errors to runtime errors in Dlang? If yes, how can I make it? No it's not possible, D is a statically typed language. Why would you want errors that can be caught at compile time to happen at runtimes ?
Re: Beta 2.091.0
On Thursday, 27 February 2020 at 09:05:47 UTC, JN wrote: "Class deallocator have been deprecated in v2.080.0 (see ), and turned into an error in v2.087.0. They have now been completely removed from the language, and the parser won't recognize them anymore." missing a link after the see Thanks, corrected: https://github.com/dlang/dmd/pull/10841
Re: about const ref
On Tuesday, 11 February 2020 at 07:51:04 UTC, Ferhat Kurtulmuş
wrote:
I need to be sure about "const ref". Based on the following
function, does it mean:
Type can be string or an integral type.
(a) k1 is not copied on function calls
(b) k1 cannot be modified inside function
Please correct me if I am wrong. Can storage class "in" be used
to satisfy (a) and (b)?
void doIt(const ref Type k1){
}
Type k = ...;
doit(k);
You're correct for 'a' and 'b'. However `in` only entails
`const`, so it is not an exact replacement.
Additionally, you might want to add `scope` to show that the
parameter does not escape.
Note that a big limitation on `const ref` parameters at the
moment is that it does not accept literals, which is something
Andrei talked about a few years ago at DConf (or was it last
year?).
Re: [dub] Passing --DRT-gcopt to dmd
On Friday, 31 May 2019 at 15:41:24 UTC, Anonymouse wrote: On Friday, 31 May 2019 at 15:31:13 UTC, kinke wrote: On Friday, 31 May 2019 at 10:27:44 UTC, Anonymouse wrote: $ grep dflags dub.json "dflags": [ "-lowmem", "--DRT-gcopt=profile:1" ], This should work indeed. I guess it doesn't because dub probably uses a response file containing all cmdline options, whereas -lowmem definitely [and --DRT-* probably] need to be direct cmdline args. Is this something I can/should report? (Where do dub issues go?) Replying here despite the delay because this is one of the top post when one google for gcopts. This will be possible with the new version of the runtime (>=2.091.0, not released yet). It has been filled as https://issues.dlang.org/show_bug.cgi?id=20459 and was fixed in https://github.com/dlang/druntime/pull/2881 which means dub compiled with druntime >= 2.091 will allow you to do: `dub -- --DRT-gcopt=profile:1` And any other D program will ignore `--DRT` options if provided after the `--` delimiter.
Re: `This` reference not accessible when overloading an operator?
On Tuesday, 21 January 2020 at 20:48:44 UTC, Enjoys Math wrote:
I have an Integer class in integer.d. A RationalNumber class
in rational_number.d, and they each import each other (so that
could be the issue). However, this is not working:
Symbol opBinary(string op : "/")(const Integer z) const
{
return new RationalNumber(this, z);
}
Getting:
Error: class `rational_number.RationalNumber` member `this` is
not accessible
Error: template instance `integer.Integer.opBinary!"/"` error
instantiating
The error message says that the constructor of `RationalNumber`
is not accessible, not the `this` reference of `integer.Integer`.
Re: DMD docker image
On Friday, 17 January 2020 at 16:43:17 UTC, Jan Hönig wrote:
I have created a docker image.
However the image size is not small (~500MB).
I wonder if others have a suitable dockerfile.
All i want is to install the current dmd release.
Does somebody have something similar?
Does somebody need something similar?
My dockerfile:
```
FROM ubuntu:latest
MAINTAINER Jan Hönig
RUN apt-get update && apt-get install curl build-essential -y \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
RUN latest=$(curl -sS
http://downloads.dlang.org/releases/LATEST) \
&& echo "DMD Release: $latest" \\
&& curl
"http://downloads.dlang.org/releases/2020/dmd_${latest}-0_amd64.deb; -o dmd.deb \
&& dpkg -i "dmd.deb" \
&& rm "dmd.deb"
```
If you want a small image, Alpine Linux is definitely the way to
go.
You can find `gcc-gdc` (however it's an old frontend, v2.076) in
Alpine Linux's main repository.
Additionally, if you can find the latest `ldc` in the `testing`
repository
(https://forum.dlang.org/thread/oznltcuropwzxaakp...@forum.dlang.org).
I intend to add DMD, just didn't have to get to it yet. If you
want to do it yourself, here's the APKBUILD:
https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2880
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Wednesday, 15 January 2020 at 11:48:29 UTC, kinke wrote: On Wednesday, 15 January 2020 at 04:00:26 UTC, Mathias Lang wrote: The LDC package is not going to be cross-architecture in the near future, but it should be able to correctly cross-compile once LDC a version matching 2.090.1 is released (most likely LDC 1.20.0). What's the reason for that requirement? I'll soon release LDC v1.20.0-beta1, so is there something from DMD stable you'd need as prerequisite? While I've never fully understood the popularity of Alpine-based docker images (okay, the base image is tiny, but if all images are based on the same, say, Ubuntu image, the few hundred MB only need to be stored once on each host), it'd probably be nice to have the official prebuilt LDC Linux packages linked against musl, to get rid of the glibc dependency. I assume that would be enough to make it runnable on almost all Linux x64 hosts. Nothing from DMD, but some fixes in Druntime. The `stat` struct definition was broken (among other things), so anything involving files was failing on other architecture. This was fixed in https://github.com/dlang/druntime/pull/2899 . Regarding Alpine's popularity: I think it's a matter of convenience. Just like distributing a single binary (or, like in your case, a standalone package) is easier to deal with, being able to distribute a tiny image packaging your application is great (because the economy of scale argument only holds if you have many images on the same host and don't wipe it frequently). Also, the Ubuntu base image is much slower to build, and just I like my compilation time to be low, I like my image build time to be low. I think the README of alpine covers it pretty well: https://github.com/alpinelinux/docker-alpine#why .
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: What's next ? 1) There is a pending PR (https://github.com/alpinelinux/aports/pull/12006) to have GDC working on all architectures alpine supports, not just x86_64. 2) Adding a package for gdmd 3) Rebuild packages based on GDC, so that all architectures are supported. 4) Move the packages to community so they are available out of the box. It would be great for it to happen by the end of the month, as the next alpine release would be around end of December according to their schedule, but that depends on how long PR take to be reviewed. 5) A DMD package for x86 and x86_64 shouldn't be hard to make either Time for an update! The GDC PR have been merged, and followed by another large fix to make it work on most architectures. So if you use Alpine edge, you can just run `apk add gcc-gdc` and you'll get GDC-9.2.0 (with a lot of patches), which is a 2.076.0 frontend, but allow you to bootstrap efficiently. The package is present on ARMv7, AArch64, x86, x86_64, and s390x. Only ppc64le is not supported as GDC hasn't been ported to it (at least not as of the time of 9.2.0 release). Additionally, `gdmd` has been added to `testing` to make it easier to build packages. LDC has been updated to v1.19.0 and the package definition fixed (only `ldc` and `ldc-runtime` present now, no more `ldc-static`). Dub v1.19.0 is also available, also built with GDC, on all the architectures GDC supports. The LDC package is not going to be cross-architecture in the near future, but it should be able to correctly cross-compile once LDC a version matching 2.090.1 is released (most likely LDC 1.20.0). I am now working on finalizing the LDC package so all tests pass on x86 & x86_64, and to provide a DMD package. While there are still a few details to flesh out, most things should work perfectly on x86_64 (we've been using it for months), so feel free to test it and report back. I also hope we can use it in some of the official dlang repositories (e.g. dlang-tour and the dub testsuite). The best place to report issues with the packages is on the Alpine Gitlab ( https://gitlab.alpinelinux.org/alpine/aports/issues) and to tag @Geod24.
Re: Beta 2.090.0
On Sunday, 22 December 2019 at 22:22:26 UTC, Per Nordlöw wrote: Have I missed something or is this a known problem with dub? If so, do I have any alternative to brute-forcing the problem with dub run --compiler=dmd --build=unittest dub run --compiler=dmd --build=debug which, for me, doubles my development iteration time. If it's something common enough, I suggest just creating an alias such as `dubtest` which does `dub test --compiler=dmd && dub run --compiler --build=debug`. Should you want to change compiler, you can make it a function that takes an argument. The druntime issue with `--DRT` is something that is on the map, and should be fixed soon, but I can't promise it will be fixed before the release, as it requires a druntime fix. Alternatively, some other bugs need to be fixed for the druntime fix to be truly efficient.
Re: A program that does OCR(Optical Character Recognition) inspired by Neural Networks
Nice work! You might want to take a look at the MNIST database ( https://en.wikipedia.org/wiki/MNIST_database) which is freely available and commonly used to train neural network. It will also allow you to benchmark your implementation against other algorithms. On Fri, Dec 6, 2019 at 10:07 AM Murilo via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > Hi everyone. I've spent the last weeks working on a program which > is able to read and understand text from an image file(OCR) by > using a rudimentary neural network after training with a large > amount of images(I made them myself, manually). It even shows a > map of all the parts of the images that have the highest synaptic > weights(warmer colors). It was made purely in D using the arsd > library. Below is the link to it if you wish to take a look. For > now it only understands upper case letters from the English > alphabet. I'll be adding more over time. Cheers. > https://github.com/MuriloMir/Optical-Character-Recognition >
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Wednesday, 13 November 2019 at 12:27:52 UTC, user wrote: On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: ``` apk --no-cache add -X http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc ldc-static dtools-rdmd dub ``` A hello world vibe project doesn't build for me using a Dockerfile using your template. I tried to add missing deps, but I couldn't really figure out what's missing. I get an error during the `dub build` step: ``` eventcore 0.8.48: building configuration "epoll"... /root/.dub/packages/eventcore-0.8.48/eventcore/source/eventcore/drivers/posix/processes.d(316,10): Error: module `core.sys.posix.sys.wait` import `idtype_t` not found` ``` My full Dockefile: ``` FROM alpine:edge as builder RUN apk --no-cache add build-base git RUN apk --no-cache add -X http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc ldc-static dtools-rdmd dub RUN apk --no-cache add -X http://dl-cdn.alpinelinux.org/alpine/edge/testing libevent ibevent-dev WORKDIR /tmp/app ADD source ./source ADD dub.json ./ RUN dub build --compiler=ldc2 ``` Unfortunately recent versions of Vibe.d seems to be broken with Alpine. We use eventcore v0.8.43, Vibe.d v0.8.6, vibe-core v1.7.0. I'll see if I can get a CI in place for Vibe (and fix the issues). Thanks for reporting!
