Re: Floating point types default to NaN?
On Wednesday, 29 November 2017 at 01:24:21 UTC, A Guy With a Question wrote: I was just more curious of the design decisions that were made. So am I. I'm trying to get to the heart of in the the PR comments. Mike
Re: Floating point types default to NaN?
On Monday, 27 November 2017 at 23:05:55 UTC, Michael V. Franklin wrote: I think I'm going to implement a feature gate to require explicit initialization. It would be better to be strict up front and relax it as flow control analysis becomes more mature. Well, I implemented it (https://github.com/dlang/dmd/pull/7375), but it's off to a pretty rocky start. Mike
Re: Floating point types default to NaN?
On Saturday, 25 November 2017 at 22:13:43 UTC, Adam D. Ruppe wrote: It technically did: https://dlang.org/spec/function.html#local-variables "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. " But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead. WOW!! I am shocked to learn this. All this time, I though it was a design oversight. I think I'm going to implement a feature gate to require explicit initialization. It would be better to be strict up front and relax it as flow control analysis becomes more mature. Mike
Re: DMD test suite assertion failure in test_cdvecfill.d
On Tuesday, 21 November 2017 at 10:04:50 UTC, Petar Kirov [ZombineDev] wrote: File a bug report and try contacting Martin Nowak, as he's the author of this test, IIRC. https://issues.dlang.org/show_bug.cgi?id=18013
Re: betterC and noboundscheck
On Wednesday, 22 November 2017 at 15:10:40 UTC, Oleg B wrote:
import core.stdc.stdio;
import std.algorithm : min;
extern (C) void main()
{
char[256] buf;
buf[] = '\0';
auto str = "hello world";
auto ln = min(buf.length, str.length);
buf[0..ln] = str[0..ln];
printf("%s\n", buf.ptr);
}
rdmd -betterC bettercarray2.d
and get error:
/tmp/.rdmd-1000/rdmd-bettercarray2.d-435C14EC3DAF09FFABF8ED6919B624C1/objs/bettercarray2.o:
In function `main':
bettercarray2.d:(.text.main[main]+0xbc): undefined reference to
`_d_arraycopy'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
Bug submitted here: https://issues.dlang.org/show_bug.cgi?id=18010
Re: Can I count the of enum's fields at compile time?
On Thursday, 23 November 2017 at 00:58:21 UTC, Marc wrote:
for example:
enum A { a = -10, b = -11, c = -12, d = -13, e = -34}
enum int countOfA = coutOfFields(A); // 5 fields
https://dlang.org/spec/traits.html#allMembers
enum A { a = -10, b = -11, c = -12, d = -13, e = -34}
enum int countOfA = __traits(allMembers, A).length; // 5 fields
static assert(countOfA == 5);
Mike
DMD test suite assertion failure in test_cdvecfill.d
I'm getting this error when I try to run the DMD test suite. cd dmd make -C test -f Makefile ... runnable/test_cdvecfill.d -O (-mcpu=avx -mcpu=avx2) Test failed. The logged output: ../src/dmd -conf= -m64 -Irunnable -O -odtest_results/runnable -oftest_results/runnable/test_cdvecfill_0 runnable/test_cdvecfill.d test_results/runnable/test_cdvecfill_0 Expected code sequence for load!(ubyte, 16) not found. Expected: 0x50 0x66 0x0f 0x6e 0xc7 0x66 0x0f 0x60 0xc0 0x66 0x0f 0x61 0xc0 0x66 0x0f 0x70 0xc0 0x00 0x59 0xc3 Actual: 0x55 0x48 0x8b 0xec 0x66 0x0f 0x6e 0xc7 0x66 0x0f 0x60 0xc0 0x66 0x0f 0x61 0xc0 0x66 0x0f 0x70 0xc0 0x00 0x5d 0xc3 0x00 0x55 0x48 0x8b 0xec 0x0f 0xb6 0x07 0x66 0x0f 0x6e 0xc0 0x66 0x0f 0x60 0xc0 0x66 0x0f 0x61 0xc0 0x66 0x0f 0x70 0xc0 0x00 0x5d 0xc3 0x00 0x00 0x55 0x48 0x8b 0xec 0x66 0x0f 0x6e 0xc7 0x66 0x0f 0x60 0xc0 core.exception.AssertError@runnable/test_cdvecfill.d(895): Assertion failure ??:? _d_assertp [0xd9faa4f1] ??:? [0x84bcd81c] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().__lambda1() [0xd9fc7d5f] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0xd9fc7c8f] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0xd9fc7d08] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0xd9fc7c8f] ??:? _d_run_main [0xd9fc7bfa] ??:? [0x84bd1057] ??:? __libc_start_main [0xd8eaaf69] Any idea what I'm doing wrong? I'm running 64-bit Arch Linux. Thanks, Mike
Re: writeln, alias this and dynamic arrays.
On Friday, 17 November 2017 at 02:13:54 UTC, matthewh wrote: [...] as is it produces: [1, 2, 3, 4, 5, 6, 7, 8] [] I expected it to produce: [1, 2, 3, 4, 5, 6, 7, 8] [1, 2, 3, 4, 5, 6, 7, 8] And with the toString override included it does. Why does the version without the toString override output an empty array? Actually, it looks like it's this 4-year old bug. https://issues.dlang.org/show_bug.cgi?id=9506 So frustrating :( Mike
Re: writeln, alias this and dynamic arrays.
On Friday, 17 November 2017 at 02:16:35 UTC, Michael V. Franklin wrote: On Friday, 17 November 2017 at 02:13:54 UTC, matthewh wrote: And with the toString override included it does. Why does the version without the toString override output an empty array? I think that is due to this bug: https://issues.dlang.org/show_bug.cgi?id=13189 It's actually on my todo list to fix, but I'm not sure yet if its within my current abilities. Actually, after playing with your example, I don't think that's the case. There's something else going on, and I'm not sure what it is. It's a strange error indeed. Mike
Re: writeln, alias this and dynamic arrays.
On Friday, 17 November 2017 at 02:13:54 UTC, matthewh wrote: And with the toString override included it does. Why does the version without the toString override output an empty array? I think that is due to this bug: https://issues.dlang.org/show_bug.cgi?id=13189 It's actually on my todo list to fix, but I'm not sure yet if its within my current abilities. Mike
Re: Conditional compilation of array of structs initializer
On Friday, 10 November 2017 at 06:22:51 UTC, Tony wrote:
Doing a port of some C code that has an #ifdef in the middle of
an initialization for an array of structs. I am getting a
compile error trying to get equivalent behavior with "static
if" or "version". Is there a way to achieve this other than
making two separate array initialization sections?
struct a {
int y;
int z;
}
immutable string situation = "abc";
int main()
{
a[] theArray = [
{ 10, 20 },
// version(abc)
static if (situation == "abc")
{
{ 30, 40 },
}
{ 50, 60 }
];
return 0;
}
Here's my attempt. There's probably a more elegant way, but it's
the best I could do.
import std.stdio;
struct a {
int y;
int z;
}
enum situation = "abc";
int main()
{
enum head = "a[] theArray = [ {10, 20},";
static if (situation == "abc")
{
enum middle = "{ 30, 40},";
}
else
{
enum middle = "";
}
enum tail = "{ 50, 60 }];";
mixin(head ~ middle ~ tail);
writeln(head ~ middle ~ tail);
return 0;
}
The use of enums for this is called manifest constants
(https://dlang.org/spec/enum.html#manifest_constants). It's more
analogous to #define in C.
Mixins are documented here
(https://dlang.org/spec/statement.html#mixin-statement)
Mike
Re: Compiler magic for preventing memory access re-ordering _by the compiler_ (keywords: memory model, compiler optimisations, memory order)
On Monday, 6 November 2017 at 05:54:00 UTC, Michael V. Franklin wrote: On Monday, 6 November 2017 at 03:40:23 UTC, Cecil Ward wrote: Is there a magic visible sign (or even one needed) in the D language that tells D _compilers_ not to move certain types of memory load / store operations forwards or backwards relative to other operations when optimising the code so that the order in the actual generated code varies from the source code order? You may be looking for volatileLoad/Store: https://dlang.org/changelog/2.067.0.html#volatile-load-store Also https://dlang.org/phobos/core_bitop.html#.volatileLoad Mike
Re: Compiler magic for preventing memory access re-ordering _by the compiler_ (keywords: memory model, compiler optimisations, memory order)
On Monday, 6 November 2017 at 03:40:23 UTC, Cecil Ward wrote: Is there a magic visible sign (or even one needed) in the D language that tells D _compilers_ not to move certain types of memory load / store operations forwards or backwards relative to other operations when optimising the code so that the order in the actual generated code varies from the source code order? You may be looking for volatileLoad/Store: https://dlang.org/changelog/2.067.0.html#volatile-load-store Mike
Re: Any book recommendation for writing a compiler?
On Wednesday, 1 November 2017 at 20:53:44 UTC, Dr. Assembly wrote: Hey guys, if I were to get into dmd's source code to play a little bit (just for fun, no commercial use at all), which books/resources do you recommend to start out? I found this to be quite helpful: http://llvm.org/docs/tutorial/ Specifically the Kaleidoscope tutorial. Mike
Re: Temporary objects as function parameters or when-is-this-shit-going-to-end?
On Monday, 16 October 2017 at 03:29:03 UTC, Michael V. Franklin wrote: My experience says that BountySource almost doesn't help. It works if the bounty is worth someone sacrificing their free time to do the work. For example, I'd attempt fixing the bug if the bounty were greater than $200, but I don't know if I'd be successful, as I've only just started working working with the DMD source code. In fact, you might want to propose matching bounty from the community on this specific bug to encourage funding. For example, make an announcement on the forum that anyone who places a bounty on the bug in question will receive a matching contribution from you. Maybe that might raise the bounty high enough to get someone qualified to fix the bug. Or maybe not; it's just an idea that occurred to me. Mike
Re: Temporary objects as function parameters or when-is-this-shit-going-to-end?
On Friday, 13 October 2017 at 11:54:38 UTC, Jack Applegame wrote: On Friday, 13 October 2017 at 11:21:48 UTC, Biotronic wrote: BountySource[2] lets you do basically exactly that. My experience says that BountySource almost doesn't help. It works if the bounty is worth someone sacrificing their free time to do the work. For example, I'd attempt fixing the bug if the bounty were greater than $200, but I don't know if I'd be successful, as I've only just started working working with the DMD source code. It would be nice if the D Foundation would do some kind of creative incentivizing, such as prioritizing bugs, and matching bounty contributions. But even then, you might run the risk of the work being done, but having the PR sit in purgatory for an indeterminate length of time. I'm not at all happy with the way D is managed, but I'm also lacking any actionable solutions. Mike
