On Monday, 10 July 2023 at 14:09:47 UTC, Kagamin wrote:
You try to use C declarations, but they are specific to each C
library, and different C libraries have different declarations,
so headers can't decide which C library declarations to use.
Try -mtriple=riscv32-unknown-linux
It seems to
Recently found out LDC supports cross-compiling to riscv, but
while trying it out I can't seem to make it work. I am very
likely missing something simple, as I haven't done something like
this before. I've already been told it's likely something with
linking, though I'm not sure how to set
On Saturday, 16 July 2022 at 20:08:38 UTC, Adam D Ruppe wrote:
The default here is write in text mode, change the "w" to "wb"
and it won't molest your line endings any more.
Thank you, that worked.
This raises 3 questions for me.
1. Are there any nasty pitfalls with this change that might
While trying to figure out why my reading from & write back to
file kept increasing the size of my entries, I figured out
File.write always introduces a \r character before any \n
characters, even if they are already preceded by one.
Is this intentional behaviour or an oversight?
Example:
On Thursday, 19 May 2022 at 04:33:01 UTC, Tejas wrote:
Does this happen with LDC as well?
I tried it using `LDC 1.29.0` and it prints correctly under both
`--b=release` and `--b=debug` builds.
On Wednesday, 18 May 2022 at 21:49:14 UTC, HuskyNator wrote:
After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get
this behavior.
Only when I use `dub run --b=debug` however (default for me).
`dub run --b=release` does return what one would expect.
I don't know if this matters either,
On Wednesday, 18 May 2022 at 20:16:51 UTC, Dennis wrote:
On Wednesday, 18 May 2022 at 20:05:05 UTC, HuskyNator wrote:
This will print:
```
0
50
nan
```
Which compiler and flags are you using? For me it just prints
50, you might be stumbling on some (old) bugs in the DMD
backend with
I came across strange, seemingly non-deterministic, behaviour
today. I simplified it the best I could below. I entice you to
run the following piece of code.
```d
module app;
import std.stdio;
struct A {
float[1] vec;
this(float[1] n) {
this.vec = n;
}
On Friday, 23 July 2021 at 13:53:27 UTC, Rekel wrote:
As one can see, implicitly casting array literals in templates
works fine in the case of bar, as does explicit use of
templates in the case of foo, but for some reason foo does not
manage to deduce its arguments like bar does.
On Sunday, 17 April 2022 at 17:04:57 UTC, Bastiaan Veelo wrote:
On Sunday, 17 April 2022 at 11:16:25 UTC, HuskyNator wrote:
I recently found out there is [support for vector
extensions](https://dlang.org/spec/simd.html)
But I have found I don't really understand how to use it, not
even
On Monday, 18 April 2022 at 03:21:30 UTC, H. S. Teoh wrote:
Structs in D ought to be treated like "glorified ints", as
Andrei puts it. If you need complex ctors and complex methods,
that's a sign you should be using a class instead.
I prefer not to use classes, as the code would now move
This is a twofold question, along the example code below:
- 1: Why does `m` initialization behave as if `m[0][]=1` and
`m[1][]=2` were used? (Shouldn't this code result in an error
instead?)
- 2: Why does adding a constructor to a struct disable the use of
the static initialization syntax? I
I recently found out there is [support for vector
extensions](https://dlang.org/spec/simd.html)
But I have found I don't really understand how to use it, not
even mentioning the more complex stuff. I couldn't find any good
examples either.
I'm trying to figure out how to implement the
I can't figure out why this code works:
```d
union A {
int* b;
float c;
}
int fun(A a) @safe {
return *(()=>a.b)();
// return *a.b; //Complains about pointer type overlap
}
```
I tried to find out how `@safe` should be handled in this
scenario, and found
On Thursday, 6 January 2022 at 13:33:24 UTC, bauss wrote:
While not the exact same, there's a small work around here that
can help in some cases:
```d
immutable long[string] aa;
shared static this() {
aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
}
```
Thanks a lot!
On Monday, 28 November 2016 at 14:41:44 UTC, Era Scarecrow wrote:
On Monday, 28 November 2016 at 09:06:34 UTC, Paolo Invernizzi
wrote:
The point is that I was trying to avoid some cycle between
modules, detected by 2.072. This bug leads to pollution in the
use of static this only to workaround
On Sunday, 5 September 2021 at 12:12:20 UTC, HuskyNator wrote:
On Saturday, 19 September 2020 at 17:57:09 UTC, Andre Pany
wrote:
In case you have an older version of dub, dmd will build an
x86 executable by default with OMF (Windows). Never versions
of dub defaults to architecture x86_64 with
On Saturday, 19 September 2020 at 17:57:09 UTC, Andre Pany wrote:
In case you have an older version of dub, dmd will build an x86
executable by default with OMF (Windows). Never versions of dub
defaults to architecture x86_64 with COFF.
LDC builds only COFF for x86 and x86_64.
Kind regards
18 matches
Mail list logo
