[Issue 16011] [REG2.068] recursive RefCounted used to work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16011

--- Comment #4 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7196

--

[Issue 17883] Error: undefined identifier: Static if bodies depend on order of declarations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17883

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 16011] [REG2.068] recursive RefCounted used to work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16011

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
Compiling this now gives the following error:

core.exception.AssertError@dstruct.d(380): Assertion failure

0x005FD23F in _d_assertp
0x00408EFA in AttribDeclaration at C:\cbx\mars\attrib.d(181)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x00474D79 in TemplateInstance at C:\cbx\mars\dtemplate.d(8272)
0x00474DDC in TemplateInstance at C:\cbx\mars\dtemplate.d(8290)
0x00470E61 in TemplateInstance at C:\cbx\mars\dtemplate.d(6361)
0x004714BB in TemplateInstance at C:\cbx\mars\dtemplate.d(6595)
0x004ECA1E in TypeInstance at C:\cbx\mars\mtype.d(8004)
0x004ECAE2 in TypeInstance at C:\cbx\mars\mtype.d(8027)
0x00434BE8 in VarDeclaration at C:\cbx\mars\declaration.d(1180)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x00454D54 in Module at C:\cbx\mars\dmodule.d(1065)
0x004D9F9F in int ddmd.mars.tryMain(uint, const(char)**) at
C:\cbx\mars\mars.d(847)
0x004DAB43 in _Dmain at C:\cbx\mars\mars.d(1086)
0x005FF73B in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFNlZv
0x005FF6FF in scope void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x005FF600 in _d_run_main
0x004DCDD8 in main at C:\cbx\mars\root\stringtable.d(7)
0x0061B245 in mainCRTStartup
0x74F3336A in BaseThreadInitThunk
0x77359902 in RtlInitializeExceptionChain
0x773598D5 in RtlInitializeExceptionChain

It appears to be a forward reference error. The code itself cannot work because
RefCounted stores an instance of S in itself, and a struct cannot have itself
as a field. In fact, the same error occurs with the following example:

  struct RefCounted {
S s;
  }

  struct S {
int x;
RefCounted s;
  }

--

[Issue 15985] [REG2.068/2.069] Code doesn't link unless compiled with -debug

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15985

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
Reduced it a bit to:

struct S()
{
void delegate() d;
}

S!() f_Ds(U)()
{
static if (is(U == struct))
return S!()
(
{
foreach (i, field; U.init.tupleof)
f_Ds!(typeof(field))();
}
);

else
return f_Ds!(D)();
}

void f_E()
{
auto f = S!()
(
{
enum x = is(typeof(f_Ds!(D*)()));
f_Ds!(D*)();
}
);
}

struct A
{
D* d;
}

struct D
{
A a;
int b;
}

void main()
{
f_E();
f_Ds!(D*)();
}

--

[Issue 17884] fwd reference leads to dmd assert failure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17884

Walter Bright  changed:

   What|Removed |Added

   Keywords||ice

--

DCompute OpenCL kernels now work

[Nicholas Wilson via Digitalmars-d-announce]

I am happy to announce that DCompute will soon[1] support the 
OpenCL 2.1 runtime. I have tested it locally and it works now :) 
I wasted a good deal of time wondering why it wasn't and it was a 
small typo in DerelictCL trying to load OpenCL 2.2 symbols when 
loading 2.1.  That along with OpenCL 2.x support for DerelictCL 
will be merged and tagged soon and then [1] can be merged.


Most of the hard work is now done, leaving general polish and 
user feedback as the main development tasks. A unified driver 
abstracting over the CUDA and OpenCL drivers is on my todo list.


Launching a kernel is as simple as
```
enum size_t N = 128;
float alpha = 5.0;
float[N] res, x,y;
foreach (i; 0 .. N)
{
x[i] = N - i;
y[i] = i * i;
}

auto platforms = Platform.getPlatforms(theAllocator);
auto platform  = platforms[0]; // Assuming the 0'th platform 
supports 2.1

auto devices  = platform.getDevices(theAllocator);
auto ctx  = Context(devices[0 ..1],null);
Program.globalProgram = 
ctx.createProgram(cast(ubyte[])read("./.dub/obj/kernels_ocl200_64.spv"));

Program.globalProgram.build(devices,"");
auto queue= ctx.createQueue(devices[0]);

Buffer!(float) b_res, b_x, b_y;
b_res = ctx.createBuffer(res[], Memory.Flags.useHostPointer | 
Memory.Flags.readWrite);
b_x = ctx.createBuffer(x[], Memory.Flags.useHostPointer | 
Memory.Flags.readWrite);
b_y = ctx.createBuffer(y[], Memory.Flags.useHostPointer | 
Memory.Flags.readWrite);


Event e = queue.enqueue!(saxpy)([N])(b_res,alpha,b_x,b_y, N);
e.wait();

foreach(i; 0 .. N)
enforce(res[i] == alpha * x[i] + y[i]);
writeln(res[]);
```

Mike, want me to do another blog post about this and the CUDA 
support?


[1]: https://github.com/libmir/dcompute/pull/36

P.S: can those who answer foundat...@dlang.org please tell me 
what you think of my plan to advance the development and exposure 
of DCompute?

[Issue 17884] New: fwd reference leads to dmd assert failure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17884

  Issue ID: 17884
   Summary: fwd reference leads to dmd assert failure
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

struct S()
{
void delegate() d;
}

S!() f_Ds(U)()
{
pragma(msg,U);
static if (is(U == struct))
return S!()
(
{
foreach (i, field; U.init.tupleof)
f_Ds!(typeof(field))();
}
);

else
return f_Ds!(D)();
}

void f_E()
{
auto f = S!()
(
{
enum x = is(typeof(f_Ds!(D*)()));
f_Ds!(D*)();
}
);
}

struct A
{
D d;
}

struct D
{
A a;
int b;
}

void main()
{
f_E();
f_Ds!(D*)();
}
---
dmd bug
bug.d(40): Error: struct bug.A no size because of forward reference

core.exception.AssertError@dstruct.d(380): Assertion failure

0x005FD23F in _d_assertp
0x0040477A in AggregateDeclaration at C:\cbx\mars\aggregate.d(339)
0x00404890 in AggregateDeclaration at C:\cbx\mars\aggregate.d(377)
0x004EE4E0 in TypeStruct at C:\cbx\mars\mtype.d(8662)
0x00434C64 in VarDeclaration at C:\cbx\mars\declaration.d(1199)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x00454D54 in Module at C:\cbx\mars\dmodule.d(1065)
0x004D9F9F in int ddmd.mars.tryMain(uint, const(char)**) at
C:\cbx\mars\mars.d(847)
0x004DAB43 in _Dmain at C:\cbx\mars\mars.d(1086)
0x005FF73B in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFNlZv
0x005FF6FF in scope void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x005FF600 in _d_run_main
0x004DCDD8 in main at C:\cbx\mars\root\stringtable.d(7)
0x0061B245 in mainCRTStartup
0x74F3336A in BaseThreadInitThunk
0x77359902 in RtlInitializeExceptionChain
0x773598D5 in RtlInitializeExceptionChain

--

Re: Enum AA with classes not allowed anymore?

[Daniel Kozak via Digitalmars-d]

Up to  2.062  : Failure with output:
-
onlineapp.d(10): Error: cannot evaluate new Foo("0") at compile time
onlineapp.d(10): Error: cannot evaluate new Foo("1") at compile time
-

2.063   to 2.072.2: Success with output: Hello D
Since  2.073.2: Failure with output: onlineapp.d(10): Error: variable
onlineapp.aa : Unable to initialize enum with class or pointer to struct.
Use static const variable instead.

https://run.dlang.io/is/mJqayC

On Sun, Oct 8, 2017 at 4:29 AM, bauss via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> I'm aware that the following has always been illegal:
>
> enum a = new Foo();
>
> However the following were used to work in older versions of DMD:
>
> enum aa = [0 : new Foo("0"), 1 : new Foo("1")];
>
> When did that change happen and what was the reason for the change? I were
> depending on AA's created like that to use them at compile-time.
>
> It happens to break my following project:
> https://github.com/bausshf/Diamond
>
> More specifically:
> https://github.com/bausshf/Diamond/blob/master/src/templates/parser.d#L13
>
> The change has happened somewhere between 2.072.2 and the current version.
>

Re: D on quora ...

[Jerry via Digitalmars-d]

On Saturday, 7 October 2017 at 06:19:01 UTC, Brad Roberts wrote:


As always, focusing on the users of the language tends to pay a 
lot more dividends than focusing on nay sayers.  Luckily, 
that's how things tend to proceed here, so yay for that.


Doesn't feel like that when the views of the people in charge 
don't align with what people are saying. I can understand 
people's dissatisfaction with Windows, but some people take it 
too far. The compiler for Windows is built using 32-bit, not only 
is the 64-bit version not built it's not even supported or 
tested. I think someone made a post a little while ago about LDC 
that 95% or more of downloads for their compiler were for the 
64-bit version. If only one version is to be supported then it 
should be the 64-bit version. I can't even imagine the outrage 
there would be if 64-bit wasn't supported on Linux. Hell, they 
haven't even bothered setting up AppVeyor for dmd, free testing 
on Windows. Niche within a niche, can't expect much I guess.

[Issue 16100] [REG 2.069] Error with -O of struct enumeration value and comma operator

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16100

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
I cannot reproduce this problem.

--

Re: Add a precompiled c++ obj file to dub

[user1234 via Digitalmars-d-learn]

On Sunday, 8 October 2017 at 02:58:36 UTC, Fra Mecca wrote:

On Saturday, 7 October 2017 at 23:54:50 UTC, user1234 wrote:

On Saturday, 7 October 2017 at 19:56:52 UTC, Fra Mecca wrote:

Hi all,
I am writing a backend that is partly Vibe.d and partly 
clucene in c++.
I have some object files written in c++ and compiled with g++ 
that are not considered by dub during the linking phase and 
throws `function undefined error ` every time.


Is there a way to tell dub to let dmd handle that .o files?


Yes, add this to your JSON:

  "sourceFiles-linux-x86_64" : [
"somepath/yourobject.o"
  ],


I tried the sourceFiles approach, it failed and I could 
reproduce that in some days.


At the end I added them as linking options (lflags) but it is 
kinda odd that it works given that everything is supplied to 
dmd as -Lobj.o


Huh, i'm surprised but well, if it works for you.
My advice was based on 
https://github.com/BBasile/dbeaengine/blob/master/dub.json 
(object file is passed to dmd) which works, I often use it.

Re: Add a precompiled c++ obj file to dub

[Fra Mecca via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 23:54:50 UTC, user1234 wrote:

On Saturday, 7 October 2017 at 19:56:52 UTC, Fra Mecca wrote:

Hi all,
I am writing a backend that is partly Vibe.d and partly 
clucene in c++.
I have some object files written in c++ and compiled with g++ 
that are not considered by dub during the linking phase and 
throws `function undefined error ` every time.


Is there a way to tell dub to let dmd handle that .o files?


Yes, add this to your JSON:

  "sourceFiles-linux-x86_64" : [
"somepath/yourobject.o"
  ],


I tried the sourceFiles approach, it failed and I could reproduce 
that in some days.


At the end I added them as linking options (lflags) but it is 
kinda odd that it works given that everything is supplied to dmd 
as -Lobj.o

Enum AA with classes not allowed anymore?

[bauss via Digitalmars-d]

I'm aware that the following has always been illegal:

enum a = new Foo();

However the following were used to work in older versions of DMD:

enum aa = [0 : new Foo("0"), 1 : new Foo("1")];

When did that change happen and what was the reason for the 
change? I were depending on AA's created like that to use them at 
compile-time.


It happens to break my following project:
https://github.com/bausshf/Diamond

More specifically:
https://github.com/bausshf/Diamond/blob/master/src/templates/parser.d#L13

The change has happened somewhere between 2.072.2 and the current 
version.

Re: Should we add `a * b` for vectors?

[Timon Gehr via Digitalmars-d]

On 07.10.2017 09:24, Walter Bright wrote:


I've got a lot of scar tissue from "compiler implementation difficulty 
is not a consideration." I don't believe that is a necessary path to a 
high quality language. Compiler complexity is a huge red flag that 
something is wrong with the design of the language.


The compiler implementation should be a joy to read and someone should 
be able to read the spec, read the implementation of the spec, and go 
yeah, of course, this is obviously correct, it's so simple!


I fully agree, my point was more that details of a specific 
implementation should not influence the language design (too much).


What should matter more is compiler implementation difficulty "from 
scratch", assuming all features that need to be supported are known from 
the beginning. We don't really need technical debt in the language 
specification.

Re: Proposal: Object/?? Destruction

[Timon Gehr via Digitalmars-d]

On 06.10.2017 23:34, Steven Schveighoffer wrote:




No. All functions take one argument and produce one result. (The 
argument and the result may or may not be a tuple, but there is no 
essential difference between the two cases.) You can match a value 
against a pattern on the function call.


It is weird to me that a function with 2 parameters is the same as a 
function that takes a 2-element tuple, but a function with one parameter 
is not the same as a function that takes a 1-element tuple. That is 
where I feel it's a contradiction.

...
If a function with 2 parameters was the same as a function that takes a 
2-element tuple, and a function with one parameter that is a 2-element 
tuple is the same as a function that takes a 1-element tuple, then a 
function that takes a 2-element tuple is the same as a function that 
takes a 1-element tuple. So I think the opposite is the case.


// those two are the same
void foo(int a,string b); // match two-element tuple
void foo((int,string) x); // take two-element tuple w/o matching

// those two are the same
void bar(int a,);   // match one-element tuple
void bar((int,) x); // take one-element tuple w/o matching

This is like:

(int a,string b)=(1,"2"); // match
// vs
(int,string) x=(1,"2"); // w/o matching

and

(int a,)=(1,); // match
// vs
(int,) x=(1,); // w/o matching

In case this is not convincing to you: Why does your reasoning apply to 
arguments but not return values? Why should arguments not behave the 
same as return values? If it does actually apply to return values: what 
special syntax would you propose for functions that "return multiple 
values"? Is it really reasonable to not use tuples for that?


This would mess up a TON of code. I can say for certain, a single 
type argument can never be made to accept a tuple.


The proposal is to make all arguments "single type arguments". The 
"single type" might be a tuple. A tuple type is just a type, after 
all. For two current functions where only one matches but after the 
change both would match, the same one would still be selected, because 
it is more specialized.


Right, but cases where T is expected to match to exactly one type will 
now match with multiple types. It messes up is(typeof(...)) checks.


-Steve


All new language features can be detected using is(typeof(...)) this is 
usually ignored for language evolution. We'd need to check how much code 
relies on this specific case not compiling.


We can also think about adding a "light" version of tuple support, that 
just supports unpacking for library-defined tuple types and nothing 
else, but I'd prefer to have proper tuples.

Re: Double ended arrays?

[Ali Çehreli via Digitalmars-d-learn]

On 10/07/2017 05:02 PM, Steven Schveighoffer wrote:

> 
https://github.com/schveiguy/dcollections/blob/master/dcollections/Deque.d

>
> It's implemented by maintaining 2 dynamic arrays, one that is "reversed"
> at the front, and one that is normal at the back. When you prepend, it
> appends to the "reverse" array.
>
> It's probably not the most efficient, but it does maintain the correct
> complexities.

I stole the idea from one of Chuck Allison's DConf talks[1] and used as 
the example for the Indexing Operators section here:



http://ddili.org/ders/d.en/operator_overloading.html#ix_operator_overloading.opIndex

> Note: that code is many years old, so it may not compile with the latest
> compiler.

Mine is supposed to compile with 2.076.

> -Steve

Ali

[1] He knows about the theft. :)

Re: Double ended arrays?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/7/17 3:38 AM, Chirs Forest wrote:
I have some data that I want to store in a dynamic 2d array... I'd like 
to be able to add elements to the front of the array and access those 
elements with negative integers as well as add numbers to the back that 
I'd acess normally with positive integers. Is this something I can do, 
or do I have to build a container to handle what I want?


Dcollections has something like this, a deque. It doesn't use negative 
integers to access the prepended elements, but I suppose it could be 
made to do this.


See here:

https://github.com/schveiguy/dcollections/blob/master/dcollections/Deque.d

It's implemented by maintaining 2 dynamic arrays, one that is "reversed" 
at the front, and one that is normal at the back. When you prepend, it 
appends to the "reverse" array.


It's probably not the most efficient, but it does maintain the correct 
complexities.


Note: that code is many years old, so it may not compile with the latest 
compiler.


-Steve

Re: Add a precompiled c++ obj file to dub

[user1234 via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 19:56:52 UTC, Fra Mecca wrote:

Hi all,
I am writing a backend that is partly Vibe.d and partly clucene 
in c++.
I have some object files written in c++ and compiled with g++ 
that are not considered by dub during the linking phase and 
throws `function undefined error ` every time.


Is there a way to tell dub to let dmd handle that .o files?


Yes, add this to your JSON:

  "sourceFiles-linux-x86_64" : [
"somepath/yourobject.o"
  ],

Re: D on quora ...

[Walter Bright via Digitalmars-d]

On 10/7/2017 1:36 PM, Laeeth Isharc wrote:
Would it make sense to have a BetterC version define for Phobos? Or is this a 
terrible idea?  So you could still use some subset of Phobos from BetterC mode, 
and maybe this subset could be expanded over time?  And maybe people would write 
a complimentary set of functions to cover the missing most useful things in a 
way that doesn't depend on the runtime?


It does make sense in general for library functions to be less dependent on 
linking to the rest of the library. For example, I discovered recently that 
core.stdc.stdio and core.stdc.errno relied on linking in druntime, making them 
unusable for BetterC.


Fortunately, I found a way to remove those dependencies without any compromises. 
Of course, this won't always be possible, but it is worth thinking about when 
designing Phobos code.


(One way to do this is to use more templates, as the templates will get 
instantiated into the user program rather than needing to be linked in from Phobos.)

Re: compile D to asm.js using ldc --betterC and emcc

[cosinus via Digitalmars-d-announce]

On Saturday, 7 October 2017 at 18:27:53 UTC, Suliman wrote:

could you make it online?


you mean build everything and commit?

I've just added the binaries, I can't add the whole chain, its to 
big.

Re: D on quora ...

[Bastiaan Veelo via Digitalmars-d]

On Saturday, 7 October 2017 at 21:08:42 UTC, Laeeth Isharc wrote:
Who would have thought that probably one of the larger code 
bases (500k SLOC) to be rewritten/converted in D might come 
from Pascal, with D competing with ADA?  I don't know what has 
been decided there, but whatever the outcome, that's highly 
interesting, because it's probably true of others.


Nothing has been decided yet. More work needs to be done in 
determining where we can push the compatibility boundary. I was 
looking for ways to maintain binary compatibility with our 
existing datastructures and file formats, when my attention was 
needed for another big assignment. Our research into languages 
has been on hold since then. I hope to make some progress this 
winter. It is going to take time though, this is a task full of 
interesting challenges. But I am convinced that if we can find a 
way to translate to D, it will be an important move for the 
future of our company.


Bastiaan.

[Issue 17883] Error: undefined identifier: Static if bodies depend on order of declarations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17883

Iain Buclaw  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||ibuc...@gdcproject.org

--

[Issue 17883] New: Error: undefined identifier: Static if bodies depend on order of declarations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17883

  Issue ID: 17883
   Summary: Error: undefined identifier: Static if bodies depend
on order of declarations
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

This does not compile:
---
public import core.sys.posix.sys.mman;
import core.sys.linux.config;

static if (__USE_MISC)
{
enum MAP_RENAME = MAP_ANONYMOUS;
}

static if (__USE_MISC)
{
enum MAP_ANONYMOUS = MAP_ANON;
}
---

Swapping the static ifs around, however, and it does.

This is particular bug is causing SPARC, SPARC64, MIPS and MIPS64 builds to
fail.

--

[Issue 16984] Make more modules runnable on dlang.org

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16984

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/2e96d0654bb7146d40f71697c66a8fa6826440ee
Issue 16984 - Make std.math runnable

https://github.com/dlang/phobos/commit/c2d03bf75492c9141026fc58db865e5e0ca4d5e8
Issue 16984 - Make std.stdio runnable

https://github.com/dlang/phobos/commit/3cc63005e1bb05fdf78fd3017c1d9eb3c41705cc
Issue 16984 - Make std.traits runnable

https://github.com/dlang/phobos/commit/ff6c0f1dfc2405b4d0f92d08079d390fc4cc14a0
Issue 16984 - Make stdx.allocator.building_blocks.quantizer runnable

https://github.com/dlang/phobos/commit/5a20f69160443a17a0fbc1abe2e676b60e5485d2
Issue 16984 - Make stdx.allocator.building_blocks.free_list runnable

https://github.com/dlang/phobos/commit/d661120ff3bef457f1e9413965ebef3dd3f14fff
Fix Issue 16984 - Remove runnable blacklist

--

[Issue 17798] [2.076] "static foreach" not documented

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17798

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/4caec8e66773560bef9e2f9df1f11c4b1e5378df
fix Issue 17798 - [2.076] "static foreach" not documented

https://github.com/dlang/dlang.org/commit/c190c0c29c3f1bd733936f94b69ec56548c33ce3
Merge pull request #1884 from tgehr/fix17798

fix Issue 17798 - [2.076] "static foreach" not documented
merged-on-behalf-of: Petar Kirov 

--

Re: D on quora ...

[Laeeth Isharc via Digitalmars-d]

On Saturday, 7 October 2017 at 20:44:44 UTC, Adam D. Ruppe wrote:
On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc 
wrote:
Would it make sense to have a BetterC version define for 
Phobos?


Quite a lot of Phobos already works that way.


blog post to enlighten the masses?

Re: D on quora ...

[SrMordred via Digitalmars-d]

I think the GC discussion think will never go away because of the 
amount of c++ coders that come here.


If you want to flee from C++ you have two realistic options: Rust 
and D.


When you are looking at D and comparing metaprogramming, traits, 
ranges, UFCS, etc, its amazing: 'SO MUCH better than C++, i'ĺl 
leave right now!'


BUT then there is GC. And its not only about performance. You are 
programming at 5 10, 15 years with manual memory management, you 
lived the your entire live under the law of "you will not pay for 
what you don't use". Then you have to accept that you have a GC 
doing things under the hood. Even if you understand whats going 
on (and thanks the GC series for that :)), its a difficult 
paradigm shift.


I never had problems with GC, and im fine programming with it, 
but there is a c++ ghost in my ear every time speaking about 
manual management ;P


But im so used to D now that everytime I look back at c++ it give 
me chills. and BetterC and noGC libs are coming, so I think there 
is a ever brighter future ahead :)

Re: D on quora ...

[Laeeth Isharc via Digitalmars-d]

On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
> What if we stop focusing on the C/C++ people so much? The 
> like their tools and have no perceivable interest in moving 
> away from them (Stockholm Syndrome much?). The arguments the 
> use are primarily meant as defensive ploys, because they 
> compare everything to C/C++ and when it doesn't match in 
> some way or another the other language must be deficient. 
> They've already decided that C/C++ is the meter stick 
> against which all other languages are to be judged. 
> Unsurprisingly, nothing that is NOT C/C++ meets their 
> exacting demands.


Yes - as Andrei said in a talk, people are looking for an excuse 
not to have to take the time to learn something new.  There's an 
inordinate strength of feeling in discussions in relation to D.  
If it's not your cup of tea, why do you care so much?  The 
raising of spurious objections is much better than indifference 
at this point, and you can see this year that there has been a 
shift.  People got downvoted for repeating the same old talking 
points that are now demonstrably not correct, whereas before it 
was a matter of judgement and people could reasonably differ.




On Friday, October 06, 2017 23:19:01 Brad Roberts via
Or recognize that painting huge diverse groups as if there's a 
single brush with which to do so is a huge fallacy.  Consider 
that the two leaders, as well as a large number of the 
contributing developers, come from the c++ community and 
that's not a bad thing, but rather a big part of _why_ they 
came to D.


As always, focusing on the users of the language tends to pay 
a lot more dividends than focusing on nay sayers.  Luckily, 
that's how things tend to proceed here, so yay for that.


Long tail.  We really couldn't care less about what most people 
think.  In fact it's good that most people won't try D because 
what they will be expecting isn't yet what we offer (glossiness 
and hand-holding).


At any one time there is a proportion of people who are unhappy 
with their existing choices and looking for something better.  
It's easy to grow in the early days - you don't need to appeal to 
most programmers.  You just need to have a slightly stronger 
appeal to those who are already predisposed to like you (and to 
those who are already using your language and would like to use 
it for more things).


And people conceive of the market in too small a way.  People 
talk as if languages are in a battle to the death with each other 
- D can't succeed because it's too late, or because Rust has 
momentum.  But the world is a very big place, and the set of 
people who talk much to a broad audience about what they are 
doing is a small one and thinking it reflects reality leads to 
distorted perceptions.


Who would have thought that probably one of the larger code bases 
(500k SLOC) to be rewritten/converted in D might come from 
Pascal, with D competing with ADA?  I don't know what has been 
decided there, but whatever the outcome, that's highly 
interesting, because it's probably true of others.


Similarly Weka came from nowhere.  A random tweet by Fowler led 
to them building their entire company on a language the founders 
hadn't used before.


Because D is a highly ambitious language that isn't confined to a 
single domain, and that's a potential replacement in some domains 
for many other languages, most people won't know anyone who uses 
D because use is much more spread out.  Enterprise users outside 
of web + big tech/startups don't talk about their choices that 
much.  Microsoft didn't send out a press release when they used D 
in their COM team, for example - someone there just figured it 
was a good tool for the job and got on with it.  Similarly the 
company that Andy Smith worked for (a money management company) 
didn't say anything, and it only happened that he talked about it 
because I suggested it and he happened to have time.


Inordinately at this point in its development D is going to 
appeal to principals over agents, to people who have at least 
local authority to make decisions and don't have to persuade 
others, because the dynamics of how you persuade a committee are 
based on quite different things than making a decision and living 
or dying by how it turns out.


That's okay.  If people don't feel they can use D at work, they 
shouldn't.  Some people will be able to, and as they have some 
success with it, others will start to imitate them.  And in the 
meantime maybe it will be an advantage of sorts for the earlier 
adopters.


It matters who your customers are, because that shapes what you 
become.  And it's better early on to have people who make 
decisions on technical merits and who have the authority to do 
so, then to have a representative enterprise buyer!



On Saturday, 7 October 2017 at 08:36:01 UTC, Jonathan M Davis 
wrote:
Honestly, I've gotten to the point that I don't care much about 
trying to appeal to folks who complain about 

[Issue 17190] [REG2.072] isNumeric!string conflict std.traits std.string

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17190

--- Comment #3 from Jonathan M Davis  ---
https://github.com/dlang/phobos/pull/5763

--

Re: D on quora ...

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote:

Would it make sense to have a BetterC version define for Phobos?


Quite a lot of Phobos already works that way.

Re: D on quora ...

[Laeeth Isharc via Digitalmars-d]

On Saturday, 7 October 2017 at 09:37:12 UTC, Radu wrote:

I think there is some merit criticizing D's GC.

The major problem with it ATM is that there is no convenient 
way to use all (most) of D's std lib without it.


This also extends to third party libs - most of them are coded 
with the GC in mind because of the above point.


I guess a non-GC solution for throw new Exception will help with 
quite a lot.  What to do about the rest (at least for Phobos)?


- Allocators - right now they are in Phobos... This is not 
great, they should be split in 2 parts: core an druntime. One 
should be able to use a minimal set in betterC mode, and the 
full version with druntime (all GC related parts).


Would it make sense to have a BetterC version define for Phobos?  
Or is this a terrible idea?  So you could still use some subset 
of Phobos from BetterC mode, and maybe this subset could be 
expanded over time?  And maybe people would write a complimentary 
set of functions to cover the missing most useful things in a way 
that doesn't depend on the runtime?


It makes sense what you say about allocators - it would be nice 
to be able to write BetterC code using those.  I used dscanner 
quickly to see what the imports are, and I wonder how much work 
it would be to do what you propose.


core.atomic
core.bitop
core.exception
core.internal.spinlock
core.memory
core.stdc.errno
core.stdc.stdlib
core.stdc.string
core.sys.posix.pthread
core.sys.posix.sys.mman
core.sys.windows.unknwn
core.sys.windows.windows
core.thread
std.algorithm.comparison
std.algorithm.iteration
std.algorithm.mutation
std.algorithm.searching
std.algorithm.sorting
std.array
std.c.stdlib
std.c.string
std.concurrency
std.conv
std.exceptionstd.file
std.format
std.internal.test.dummyrange
std.math
std.meta
std.random
std.range
std.range.primitives
std.stdio
std.traits
std.typecons

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #7 from Rainer Schuetze  ---
Benjamin Thaut has prototyped it and showed it at Dconf
http://dconf.org/2016/talks/thaut.html. 
Development seems to have stalled at the moment, though. Latest version should
be this: https://github.com/Ingrater/dmd/tree/DllSupportD2

--

Re: D on quora ...

[qznc via Digitalmars-d]

On Saturday, 7 October 2017 at 05:19:21 UTC, Adam Wilson wrote:
I saw we ditch the lot and focus on the large languages where D 
can get some traction (C#/Java).


I don't see a chance to attack C# unless Microsoft officially 
adopts D.


Java is facing some uncertainty at the moment. The Java 9 module 
feature (Jigsaw) was forced against community/committee 
consensus. Oracle seems to let go (See EE4J). Java people are 
fine with GC, but really care for their IDE and D is lacking 
there.


With respect to GC, I consider performance a red herring. 
Everybody who really cares for performance has enough 
possibilities in D to achieve it. My short answer wrt D and GC is 
"It is not really an issue" which admittedly does not sound very 
convincing. There is a long answer which is basically the article 
series in the D blog and I believe it is convincing enough. 
People looking for a short convincing answer are just chasing 
some hype, ignore them.


I see opportunities for D in the web backend world. Microservices 
and serverless architectures make it (relatively) easy to 
introduce new languages. D needs more framework stuff for "easy 
and quick" microservices. D needs better IDE support, for example 
in hipster editors like VSCode.


I see opportunities for D in the embedded world. The people who 
try to use Java for embedded would be served very well with D. 
Crosscompiling and architecture support needs improvement though. 
I recently heard some praise for Go, which allegedly makes it 
easier than C or Rust.


I'm not sure about performance critical stuff. Maybe marketing 
C++-integration more could be helpful to get the people who rely 
on stuff like OpenCV, are forced to use C++ and dream about 
something better. We are fighting the C++ renaissance cool-aid, 
though. C++21 will surely solve all problems...

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17326

werero...@gmail.com changed:

   What|Removed |Added

 CC||werero...@gmail.com

--- Comment #6 from werero...@gmail.com ---
I'd be lovely to have a doc on how it should be used in the complex cases - if
it works at all :/

--

Re: gdc is in

[Iain Buclaw via Digitalmars-d]

On 7 October 2017 at 20:31, jmh530 via Digitalmars-d
 wrote:
> On Saturday, 7 October 2017 at 17:15:13 UTC, Joakim wrote:
>>
>>
>> Most people don't follow gdc development closely.  If you say that there's
>> a newer version available and you'd like help packaging it, someone might
>> step up.  After all, it's much easier to package the compiler than to keep
>> it up to date, as you've been doing.
>
>
> He'll never know if someone will help if he doesn't ask.

I have a long list of threads going back 8 years asking just that. ;-)

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17619

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17619

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/056160d108df108d99783b77ea5b9e0b04a9d592
fix issue 17619: for statements without curly braces, default endloc to
location of last token, not next token

https://github.com/dlang/dmd/commit/64fda491f77ca98a1814dd20e7be917c1c767369
Merge pull request #7189 from rainers/fix_17619

 fix issue 17619:  [REG2.072] Wrong debug line information with single line
loops
merged-on-behalf-of: Walter Bright 

--

[Issue 17870] recursive template "T is nested in both"

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17870

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #5 from Rainer Schuetze  ---
That's why I've been saying for years that
https://wiki.dlang.org/Win32_DLLs_in_D#D_code_calling_D_code_in_DLLs needs a
big red warning that it doesn't work but in very simple cases.

--

Add a precompiled c++ obj file to dub

[Fra Mecca via Digitalmars-d-learn]

Hi all,
I am writing a backend that is partly Vibe.d and partly clucene 
in c++.
I have some object files written in c++ and compiled with g++ 
that are not considered by dub during the linking phase and 
throws `function undefined error ` every time.


Is there a way to tell dub to let dmd handle that .o files?

exclude members at compile time

[Alex via Digitalmars-d-learn]

Ok, what I'm trying to do is the following:
take a type and a value of its type; given a known member of the 
type, (re?)create a similar type, without this very known member.


What does work is this:

/// --- code ---
void main()
{
S s;
s.i = 42;
s.d = 73.0;
s.s.length = 5;
s.s[] = 1024;
s.c = 'c';

auto n = exclude!"i"(s);
static assert(!__traits(compiles, n.i));
assert(n.d == s.d);
assert(n.s == s.s);
assert(n.c == s.c);
n.s[0] = 55;
assert(n.s == s.s); // works, even by reference.
}

struct S
{
int i;
double d;
size_t[] s;
char c;

//auto fun(){} // <-- a function does not work, line 26
}

auto exclude(string without, T)(T t)
{
immutable b = [ __traits(allMembers, T) ];

struct Result
{
static foreach(i, _; b)
{
static if(without != b[i])
{
mixin(
typeof(__traits(getMember, T, 
b[i])).stringof ~
" " ~
__traits(getMember, T, b[i]).stringof ~
";"
);

}
}   
}
Result res;
static foreach(i, _; b)
{
static if(without != b[i])
{
__traits(getMember, res, b[i]) = __traits(getMember, t, 
b[i]);
}
}
return res;
}
/// --- code ---

And the problem lies in line 26: If there is a method inside the 
type, it won't work this way.


I assume, there should be a way, to copy the original type first 
and to hide a member afterwards. Is there a simple approach for 
this?


I think, the problem with my approach is, that if the member is 
not a "data" member, than there are a plenty of possibilities to 
check, like... function, template, well... there could be very 
much types of indirections, as checking for "isCallable" is not 
enough for recreation(?)
If these checks are the only way to handle this, than the answer 
to my whole question is:

"recreation is restricted to PODs".

Then, I have to consider which checks to implement, and which 
restrictions have to be applied to the input...

[Issue 17864] POD struct not equivalent to primitive type in comparison

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17864

bitwise  changed:

   What|Removed |Added

 CC|nicolas.jincher...@gmail.co |
   |m   |

--

[Issue 17864] POD struct not equivalent to primitive type in comparison

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17864

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

[Issue 17824] wrong visibility deduced for method

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17824

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

[Issue 17865] property/non-property overloads not detected until used

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17865

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

Re: Infuriating DUB/DMD build bug.

[WhatMeForget via Digitalmars-d-learn]

On Friday, 6 October 2017 at 23:02:56 UTC, Laeeth Isharc wrote:

On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:


I've got a github project and using DUB with DMD and I keep 
running into this problem. I've tried deleting the entire 
...\AppData\Roaming\dub\packages folder, but the

problem repeats the very next build attempt.

[...]


See my post in learn on dmd path.  The dmd path code was 
written in 1987 and could do with an update to process longer 
windows paths properly.  We are working on this and I guess a 
chance a pull request on Monday but it depends on what else 
comes up.  In any case it's a trivial fix.


Presuming I am right about it being a path length problem.


I did! But i didn't say anything because i wasn't sure if they 
were related. I'm pretty sure it is path related because the 
exact same dub.sdl files work fine on Linux and MacOS. (It's a 
cross platform project)


Glad it is a trivial fix. Curious what it involves.  Let me know 
if I can help out in any way.  Mike Parker was kind enough to 
show me a manual dub local workaround for this issue. But I'll 
hold off now and see if your change does the fix.


If it does, it will be the best timed bug fix ever :)

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #4 from Walter Bright  ---
Coming up again:

http://www.digitalmars.com/d/archives/digitalmars/D/learn/DLL_hell_S_96980.html

--

Re: Trial v0.4.0 and visual-trial v0.1.0 are out

[WebFreak001 via Digitalmars-d-announce]

On Monday, 18 September 2017 at 20:50:55 UTC, Szabo Bogdan wrote:

Hi!

I want to announce that I managed to release a new version of 
Trial, the DLang test runner. Since my last announcement, I 
made this changes:


 - new TAP and VisualTrial reporters
 - add -r flag to override the default reporters
 - add the describe command which prints a json with the 
discovered tests

 - the tests now vave source location
 - ars.d terminal is now part of trial... to fix some 
dependencies


Also, I worked on a visual studio code plugin, it works on my 
machine... I developed it on mac os, but I will test it on 
windows and linux in the following weeks:


https://marketplace.visualstudio.com/items?itemName=bosz.visual-trial


Any feedback is appreciated!

Thanks!
Bogdan


Cool! I will include it with the D extension bundle for vscode: 
https://marketplace.visualstudio.com/items?itemName=webfreak.dlang-bundle

Re: Inclusion of Serve-d langserver.org

[WebFreak001 via Digitalmars-d]

On Saturday, 7 October 2017 at 14:57:11 UTC, helxi wrote:
I would like to open a pull request in 
https://github.com/langserver/langserver.github.io to include 
serve-d (https://github.com/Pure-D/serve-d). However I would 
like to know which of the following is provided by any of DCD 
and Dscanner and whether it's implemented:

...


Hi, serve-d developer here:


Fix-its => ?
There is automatic import fixing + a sort import (but not 
dscanner compatible) fix provided by serve-d



Source hover => ?

DCD


Signature Help => ?

DCD


Find References => ?

not implemented


Document Highlights => ?
not implemented, but planned 
(https://github.com/Pure-D/code-d/issues/50)



Rename => ?

not implemented


Code Lens => ?

not in serve-d

Re: D on quora ...

[Walter Bright via Digitalmars-d]

On 10/6/2017 1:39 PM, Laeeth Isharc wrote:
Perception is so important when people are making decisions about something they 
don't know.  (As Walter says, you have to write tens of sloc in a language to 
really see it's benefits.  They won't be so evident if you write D like the 
languages you know).


I've nearly finished converting the Digital Mars C++ front end from C++ to D. 
Amusingly, it looks line-for-line almost identical to C++ (the biggest change 
being exchanging "->" for "."). But I deliberately made as few changes as 
possible, because if I introduce a bug doing that, it will be much easier to 
find by comparing the C++ source with the D source.


To aid in this, I do it function-by-function, running the test suite after each 
function is converted. The idea is to use `git bisect` to isolate any conversion 
bugs not covered by the test suite.


So the end result has all the flaws of the C++ version. But once in D, I can 
start taking advantage of D (like nested functions) to structurally improve it. 
It'll always show its C++ inheritance, though.




So I think the GC series has been very helpful.

But it might also be helpful to be very explicit on the functions that can and 
can't be called with nogc (I mean a top level overview in the docs) because it's 
one of the remaining sources of FUD that people say "yeah but you can't use 
large parts of the standard library without the GC".


And for things that are useful and easiest done with GC it would be nice to have 
an alternative that doesn't depend on the GC - if for no other reason than to 
address objections.  So the answer is then "yes - you're right, these X 
functions depend on the GC, but there are similar ones that don't".  (Walter 
already started that for functions that use the GC for purely legacy reasons but 
I mean for more difficult cases too.  I know Weka wrote their own versions of 
some std.algorithm functions for example).  Many things aren't much work, but 
when you have a lot to do, even small frictions can have big consequences.


So it's also a documentation question - it's not that easy from the outside last 
time I looked to see just how easy std.experimental.allocator is to use.


One of the motivations for -betterC is to make D usable without any reliance 
whatsoever on the D runtime library, including the GC. You still get a long list 
of benefits from using D over C++. (The translation above is relying on -betterC.)

Re: Implementing swap for user-defined swaps

[ag0aep6g via Digitalmars-d-learn]

On 10/07/2017 07:55 PM, Balagopal Komarath wrote:
   I was implement my own range type that forwards all accesses to 
another range. I tried to write a `swap` function so that sort etc. 
could be called on my range. However, I cannot get 
`hasSwappableElements!ARange` to evaluate to true. But, when I copy 
pasted the definition of `hasSwappableElements` into my module and 
evaluated it, it was true. I assume this is something to do with how 
name lookup works in D. Here's simplified code that reproduces the same 
problem.


https://dpaste.dzfl.pl/48a420cce261


You can't provide your own swap function. `sort` etc. use 
std.algorithm.swap, so your range has to work with that.

Re: D on quora ...

[user1234 via Digitalmars-d]

On Saturday, 7 October 2017 at 18:31:46 UTC, user1234 wrote:
On Saturday, 7 October 2017 at 15:12:08 UTC, Random D user 
wrote:
Actually, Manual Memory Management is slow and D's GC is 
slower.


Allocators should not work without an internal state.


Damn...I meant the opposite, Allocators should work without an 
internal state.

Re: D on quora ...

[user1234 via Digitalmars-d]

On Saturday, 7 October 2017 at 15:12:08 UTC, Random D user wrote:

Actually, Manual Memory Management is slow and D's GC is slower.


Allocators should not work without an internal state. The fact 
that the heap chunk you get is mallocated or gcallocated 
shouldn't be a concern. The data structure can still use internal 
policies about how to request memory.


At the same time with allocators it's another problem. I'd say 
that the old-fashioned strategies shouldn't slow down the 
growing, even if the memory provider is better.

I don't know if you understand what i mean but in short:

Appender!(SpecializedAllocator, int[])

shouldn't be slowest than

Appender!(int[])

despite of the internal tweak that already exist. With allocators 
the situation is a bit confuse: who does provide the improvement ?

Re: D on quora ...

[Walter Bright via Digitalmars-d]

On 10/7/2017 1:16 AM, AB wrote:
Do you know why I'm not using D right now? Because I'm already invested in C++. 
Also I can get a prebuilt C++14 compiler running on a Jurassic-dated FreeDOS;


DMC++ will still generate code for DOS, and I test it regularly. The compiler 
itself won't run on DOS, because DOS doesn't have enough memory. But as a cross 
compiler, it works fine.


16 bit C++, however, must be subsetted to work on 16 bits - exception handling 
and RTTI won't work (not enough memory).


You can use a 32 bit DOS extender, though.

I'm curious what C++14 compiler runs under DOS. The only C++ compilers I'm aware 
of that run under DOS are very old, pre-C++98, ones.



meanwhile you've abandoned Windows XP.


dmd still works on and compiles for XP, it just officially is not supported on 
it. The problem with XP is its dodgy support for DLLs and thread local storage. 
This is an operating system problem. Officially, we want to support the entire 
language, not a subset.


Where D doesn't tread, C++ persists 
unchallenged. What will happen when Microsoft drops Windows 7, are you going to 
drop it too?


D compilers being Open Source means that anyone can support whatever platform 
they need to.



So what can you do now, other than abandon all hope? You could standardize D 
("ISO/IEC DLANG:2020"), officially endorse and support an "official" 
**standalone** IDE for it (so that it won't be a one-man two-user project), and 
cross your fingers hoping that C++ will run out of steam before D does.


D doesn't have to destroy C++ in order to be quite successful.

Re: gdc is in

[jmh530 via Digitalmars-d]

On Saturday, 7 October 2017 at 17:15:13 UTC, Joakim wrote:


Most people don't follow gdc development closely.  If you say 
that there's a newer version available and you'd like help 
packaging it, someone might step up.  After all, it's much 
easier to package the compiler than to keep it up to date, as 
you've been doing.


He'll never know if someone will help if he doesn't ask.

Re: compile D to asm.js using ldc --betterC and emcc

[Suliman via Digitalmars-d-announce]

On Saturday, 7 October 2017 at 17:31:37 UTC, cosinus wrote:
I wrote a little working demo that shows how to use D inside 
firefox.


It uses emscripten(emcc) and ldc.

https://github.com/cosinus2/dlang-emscripten-demo


could you make it online?

Re: @nogc formattedWrite

[jmh530 via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 18:14:00 UTC, Nordlöw wrote:


It would be nice to be able to formatted output in -betterC...


Agreed. If you know the size of the buffer, you can use sformat, 
which might be @nogc, but I don't know if it's compatible with 
betterC. Also, you might check out Ocean, which might have nogc 
formatting.

https://github.com/sociomantic-tsunami/ocean

@nogc formattedWrite

[Nordlöw via Digitalmars-d-learn]

Is it currently possible to somehow do @nogc formatted output to 
string?


I'm currently using my `pure @nogc nothrow` array-container 
`CopyableArray` as


@safe pure /*TODO nothrow @nogc*/ unittest
{
import std.format : formattedWrite;
const x = "42";
alias A = CopyableArray!(char);
A a;
a.formattedWrite!("x : %s")(x);
assert(a == "x : 42");
}

but I can't tag the unittest as `nothrow @nogc` because of the 
call to `formattedWrite`. Is this because `formattedWrite` 
internally uses the GC for buffer allocations or because it may 
throw?


It would be nice to be able to formatted output in -betterC...

Implementing swap for user-defined swaps

[Balagopal Komarath via Digitalmars-d-learn]

Hello,

  I was implement my own range type that forwards all accesses to 
another range. I tried to write a `swap` function so that sort 
etc. could be called on my range. However, I cannot get 
`hasSwappableElements!ARange` to evaluate to true. But, when I 
copy pasted the definition of `hasSwappableElements` into my 
module and evaluated it, it was true. I assume this is something 
to do with how name lookup works in D. Here's simplified code 
that reproduces the same problem.


https://dpaste.dzfl.pl/48a420cce261

Thanks,
Balagopal.

Re: gdc is in

[Nordlöw via Digitalmars-d]

On Friday, 6 October 2017 at 15:21:05 UTC, jmh530 wrote:
I would think this would be bigger news...I mean LDC isn't even 
on 2.076 yet...


I very much so agree. This is fantastic news!

Are there any beta (alpha|beta|rc)-builds available for download?

compile D to asm.js using ldc --betterC and emcc

[cosinus via Digitalmars-d-announce]

I wrote a little working demo that shows how to use D inside 
firefox.


It uses emscripten(emcc) and ldc.

https://github.com/cosinus2/dlang-emscripten-demo

Re: gdc is in

[John Colvin via Digitalmars-d]

On Saturday, 7 October 2017 at 16:46:44 UTC, Iain Buclaw wrote:
On 7 October 2017 at 15:00, jmh530 via Digitalmars-d 
 wrote:

On Saturday, 7 October 2017 at 10:24:38 UTC, Joakim wrote:

[...]



Also, maybe it will be easier to get people to help him if 
they know that it's up-to-date.


Why would that change anything?


Because language geeks are often motivated by the new and shiny 
and don't like to put effort in to things that don't feel like 
"the future".

Re: gdc is in

[Joakim via Digitalmars-d]

On Saturday, 7 October 2017 at 16:46:44 UTC, Iain Buclaw wrote:
On 7 October 2017 at 15:00, jmh530 via Digitalmars-d 
 wrote:

On Saturday, 7 October 2017 at 10:24:38 UTC, Joakim wrote:



I understand that you've been very busy with getting gdc into 
gcc and that there's not much manpower helping you out, but 
we're suggesting that you release a binary, even if just a 
beta like ldc does, and announce it to help change that 
perception.  Most people don't read the gdc forum, which is 
one of the reasons I've been posting on gdc progress here, 
even though I'd never use or contribute to it.


Regardless, there are D devs who'd like to use gdc, so I'm 
just trying to help you and them out.



Also, maybe it will be easier to get people to help him if 
they know that it's up-to-date.


Why would that change anything?


Most people don't follow gdc development closely.  If you say 
that there's a newer version available and you'd like help 
packaging it, someone might step up.  After all, it's much easier 
to package the compiler than to keep it up to date, as you've 
been doing.

Re: gdc is in

[Iain Buclaw via Digitalmars-d]

On 7 October 2017 at 15:00, jmh530 via Digitalmars-d
 wrote:
> On Saturday, 7 October 2017 at 10:24:38 UTC, Joakim wrote:
>>
>>
>> I understand that you've been very busy with getting gdc into gcc and that
>> there's not much manpower helping you out, but we're suggesting that you
>> release a binary, even if just a beta like ldc does, and announce it to help
>> change that perception.  Most people don't read the gdc forum, which is one
>> of the reasons I've been posting on gdc progress here, even though I'd never
>> use or contribute to it.
>>
>> Regardless, there are D devs who'd like to use gdc, so I'm just trying to
>> help you and them out.
>
>
> Also, maybe it will be easier to get people to help him if they know that
> it's up-to-date.

Why would that change anything?

Re: DLL hell :S

[Ian Hatch via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 15:30:30 UTC, rikki cattermole 
wrote:
A little from column a, a little from column b, but most 
because he might be able to do something for you.


Thanks, I'll send him an email.

Re: DLL hell :S

[rikki cattermole via Digitalmars-d-learn]

On 07/10/2017 4:29 PM, Ian Hatch wrote:

On Saturday, 7 October 2017 at 15:14:01 UTC, rikki cattermole wrote:

Email Walter directly.

I intend to campaign for next years (basically a soft TODO list) plan 
for what we want done. But until then, he and Andrei need to hear that 
this is the biggest limitation that D faces currently, not memory 
management.


Hm, are you saying "if you email Walter he can tell you how to sort it" 
or "please make sure Walter knows this problem is important" (or both)?  
Definitely happy to give my feedback.


A little from column a, a little from column b, but most because he 
might be able to do something for you.


"not memory management" gives me an idea actually - if I ditch the GC, 
which I may want to do eventually anyway, I guess I won't have this issue.

Re: DLL hell :S

[Ian Hatch via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 15:14:01 UTC, rikki cattermole 
wrote:

Email Walter directly.

I intend to campaign for next years (basically a soft TODO 
list) plan for what we want done. But until then, he and Andrei 
need to hear that this is the biggest limitation that D faces 
currently, not memory management.


Hm, are you saying "if you email Walter he can tell you how to 
sort it" or "please make sure Walter knows this problem is 
important" (or both)?  Definitely happy to give my feedback.


"not memory management" gives me an idea actually - if I ditch 
the GC, which I may want to do eventually anyway, I guess I won't 
have this issue.

Re: D on quora ...

[Random D user via Digitalmars-d]

On Friday, 6 October 2017 at 18:09:58 UTC, Ali wrote:

On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via 
Digitalmars-d wrote:

https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non 
gc version in the future...


Why is GC a problem?


T


The reputation is D's GC is slow, and Manual Memory Management 
is fast


Actually, Manual Memory Management is slow and D's GC is slower.

But IMO that kind of means GC isn't that big of a problem in D. 
Because, if malloc/free is slow (free is often slower), you want 
to avoid them as much as possible. You do this by reusing your 
memory/buffers. Which means that even if they are GC allocated 
buffers, they aren't collected and you are not allocating new 
buffers (often) after initial allocs, so the GC doesn't even run.


There was a good talk in cppcon2016 that gives you an example 
what high perf AAA games do for memory allocation. The presenter 
explains how they reduced memory allocations from 300 000 to 3000 
(https://youtu.be/tD4xRNB0M_Q?t=1200).

Re: DLL hell :S

[rikki cattermole via Digitalmars-d-learn]

Email Walter directly.

I intend to campaign for next years (basically a soft TODO list) plan 
for what we want done. But until then, he and Andrei need to hear that 
this is the biggest limitation that D faces currently, not memory 
management.

DLL hell :S

[Ian Hatch via Digitalmars-d-learn]

Hello!

I'm Ian, and I've been a programmer in games for 10 years.  I've 
been poking at D for a year or so and I'm absolutely in love with 
the compile-time execution and inline unit testing in particular.


I've been trying for a while to set up a project that I intend to 
build a lot of my future code on top of, but I'm stumbling at one 
of the first hurdles at the moment so I'm hoping I can straighten 
this out and be able to keep using D.


My framework is supposed to load plugin dlls (and later 
sharedobjects) which operate on memory allocated by the 
executable, and sadly I've hit roadblock after roadblock trying 
to get this set up.


Following https://wiki.dlang.org/Win32_DLLs_in_D I've gotten to a 
stage where I successfully load the DLL, find my functions, and 
call them passing the objects to be modified.


Initially this was crashing immediately.  After a lot of digging 
I found https://issues.dlang.org/show_bug.cgi?id=17326, so now 
I've added the gcopt to my dll to set the gc to manual, and I'm 
passing over my gc pointer and trying to set it as the proxy.


Unfortunately this results in the DLL getting stuck in a spinlock 
in addRange within gc_setProxy() :(


DLL side:
https://pastebin.com/yBPs0A30

EXE side:
https://pastebin.com/h2qLBqXA

Thread lock call stack:
https://pastebin.com/zUvH3Cnb

I'm not really sure where to go from here.  I'm doing this in my 
spare time and I've been stuck for months on something I know how 
to do in C++ (I really should have asked for help earlier).  Is 
there an up to date example someone can point me to of how to set 
this up correctly so that the DLL uses the exe's runtime and/or 
garbage collector?

Inclusion of Serve-d langserver.org

[helxi via Digitalmars-d]

I would like to open a pull request in 
https://github.com/langserver/langserver.github.io to include 
serve-d (https://github.com/Pure-D/serve-d). However I would like 
to know which of the following is provided by any of DCD and 
Dscanner and whether it's implemented:


Formatting => dfmt
Completion => DCD
Diagnostics => Dscanner  
Fix-its => ?
Go to Definition => DCD
Source hover => ?
Signature Help => ?
Find References => ?
Document Highlights => ? 
Rename => ?
Code Lens => ?

Any help would be appreciated.

[Issue 17559] [REG2.073.0] Wrong line number in stack trace

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17559

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull, symdeb

--- Comment #7 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/6947

--

Re: Beta 2.076.1

[Eugene Wissner via Digitalmars-d-announce]

On Saturday, 7 October 2017 at 12:45:30 UTC, Martin Nowak wrote:

On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote:
Other than that I'm happy with the package, as it provides the 
man pages, pre-built HTML documentation and a binary to 
bootstrap dmd on systems that lack a D compiler. (The use case 
being compilation from source for Gentoo Linux.)


I won't reorganize the folder structure in a point release. But 
thanks for pointing out that this needs a fix.
Would getting the sources as a separate download (or just from 
github) be a feasible alternative.


But please consider something different than github as 
alternative. GitHub doesn't guarantee that it always generates 
the same tarball for the same commit/release, so the checksum can 
change and the downloaded tarball looks corrupted, though it has 
absolutely the same content.

Re: gdc is in

[jmh530 via Digitalmars-d]

On Saturday, 7 October 2017 at 10:24:38 UTC, Joakim wrote:


I understand that you've been very busy with getting gdc into 
gcc and that there's not much manpower helping you out, but 
we're suggesting that you release a binary, even if just a beta 
like ldc does, and announce it to help change that perception.  
Most people don't read the gdc forum, which is one of the 
reasons I've been posting on gdc progress here, even though I'd 
never use or contribute to it.


Regardless, there are D devs who'd like to use gdc, so I'm just 
trying to help you and them out.


Also, maybe it will be easier to get people to help him if they 
know that it's up-to-date.

[Issue 6244] Add powmod / modpow function to std.math

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6244

alex.jercai...@gmail.com changed:

   What|Removed |Added

 CC||alex.jercai...@gmail.com
   Assignee|nob...@puremagic.com|alex.jercai...@gmail.com

--

Re: Beta 2.076.1

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote:
Other than that I'm happy with the package, as it provides the 
man pages, pre-built HTML documentation and a binary to 
bootstrap dmd on systems that lack a D compiler. (The use case 
being compilation from source for Gentoo Linux.)


I won't reorganize the folder structure in a point release. But 
thanks for pointing out that this needs a fix.
Would getting the sources as a separate download (or just from 
github) be a feasible alternative.

Re: Eilmer4 - a Computational Fluid Dynamics code in D

[Martin Nowak via Digitalmars-d-announce]

On Friday, 6 October 2017 at 22:16:09 UTC, Peter Jacobs wrote:
This note is principally to say thank you to all of the people 
who have made the D programming language and its ecosystem.  
Being mechanical engineers, we are occasional but serious 
programmers.  For a number of years, we struggled with C++ and 
a code base of growing complexity.  In 2014, we made a serious 
commitment to reworking the entire code into D. In mid-2017, 
the new code was complete enough for general use and it is 
currently being used in a fourth-year course on computational 
fluid dynamics.  The D programming language has enhanced our 
programming experience and, for that, we are grateful to the 
many people who have built the foundation upon which we build 
our flow simulation code.


Thanks for the kind words. Indeed D seems to be at a sweet spot 
for scientific computation.

[Issue 17882] [The D Style] unittest attributes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17882

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from b2.t...@gmx.com ---
(In reply to Mario Kroeplin from comment #3)
> (In reply to b2.temp from comment #2)
> 
> The issue is just the wording of the guideline:
> "to ensure the existence of attributes on the templated function":
> which "templated function"?

in the example it's "call2". Maybe if you're not comfy enough with D try 

https://forum.dlang.org/group/learn

before opening an issue.

--

[Issue 17881] Provide mechanism to preallocate memory from the GC

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17881

--- Comment #6 from Steven Schveighoffer  ---
(In reply to Rainer Schuetze from comment #5)
> A slightly simpler API could be to add allocating N same-sized chunks from
> the GC that returns them in a free-list-like chain.

I think an array is best, since the data already is an array, and a free-list
requires building a linked list before-hand.

> I agree with Andrei that we should not complicate the GC interface for every
> possible allocation pattern a user might want to optimize for, though.

Hm... I'm trying to find the most generic interface for this. It's not
necessarily limited to AA, as allocating a bunch of blocks in a loop isn't an
uncommon thing.

If there was a way to "re-flavor" the blocks from one giant block into
individual ones, then we could do this outside the GC.

> If you call GC.reserve(20_000_000*(Key.sizeof+Value.sizeof)) before
> inserting elements, there should be no collection while filling the AA.

Limiting the collection in the example I posted shaves off about 300-400msec,
but it still is 1.5 seconds vs. 0.1 for the local array version.

> If we add thread local free-lists to the GC, the overhead of allocating
> these from the GC instead of caching them in the AA would be rather small.

Agreed, I think keeping the lists inside the GC is the most useful, and does
not expose any implementation details to the user.

--

[Issue 17882] [The D Style] unittest attributes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17882

Mario Kroeplin  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Mario Kroeplin  ---
(In reply to b2.temp from comment #2)

The issue is just the wording of the guideline:
"to ensure the existence of attributes on the templated function":
which "templated function"?

--

Re: Need importing dcompute.lib into my project

[kerdemdemir via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 12:12:10 UTC, kinke wrote:

On Saturday, 7 October 2017 at 09:04:26 UTC, kerdemdemir wrote:

Error: static assert  "Need to use a DCompute enabled compiler"


Are you using latest LDC 1.4? The CUDA backend wasn't enabled 
for earlier versions.


Yes I am. Actually I can build dcompute's source code so I am 
sure LDC version is good. Now I am trying to use dcompute within 
my project.

Re: Need importing dcompute.lib into my project

[kinke via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 09:04:26 UTC, kerdemdemir wrote:

Error: static assert  "Need to use a DCompute enabled compiler"


Are you using latest LDC 1.4? The CUDA backend wasn't enabled for 
earlier versions.

[Issue 17882] [The D Style] unittest attributes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17882

--- Comment #2 from b2.t...@gmx.com ---
to be perfectly clear about the invalidity, see:

https://dlang.org/spec/function.html#function-attribute-inference


void call1 () @safe{} // non templatized so no attrib inference
void call2 ()(){} // attrib infered by the caller

@safe unittest
{
  // everything inside **must** be safe or trused.
  call1();
  call2();
}

//is like

void test() @safe
{
  call1();
  call2(); // @safe is infered on call2, so that if not supported compil stops.
}

--

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17619

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #6 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/7189

--

[Issue 17882] [The D Style] unittest attributes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17882

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |INVALID

--- Comment #1 from b2.t...@gmx.com ---
attributes of the unittest blocks are tried on the free functions that are used
inside. Actually you can see a unittest{} as a function itself. (the
getunittests traits returns some void function()).

--

[Issue 17882] New: [The D Style] unittest attributes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17882

  Issue ID: 17882
   Summary: [The D Style] unittest attributes
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: kroepli...@googlemail.com

"Every unittest should be annotated (e.g. pure nothrow @nogc @safe unittest {
... }) to ensure the existence of attributes on the templated function."

But, templated functions should not be annotated. So, do you mean "... on a
non-templated function"? Or maybe "... on the tested function"?

--

Re: isInputRange as a __traits ?

[user1234 via Digitalmars-d]

On Saturday, 7 October 2017 at 10:59:02 UTC, Jonathan M Davis 
wrote:

On Saturday, October 07, 2017 10:46:05 user1234 via

> Why? What would we gain from that?

I've replied in another answer, so again, the idea is to save 
a bit of time spent to compile.


I very much doubt Walter would consider that a good enough 
reason. And it would make more sense to try and improve 
template processing in general than to try and speed things up 
by avoiding one template. In general, __traits does stuff that 
you can't check with a library, and we _can_ check in the case 
of isInputRange. At this point, if something can be done in a 
library, it's almost a guarantee that it won't be added to the 
language. A _really_ strong argument is needed for why 
something should be in the language rather than a library if it 
can be done in a library with the language as-is.


- Jonathan M Davis


Yes i understand the reasoning but the compiler has **already** 
the ability to check input ranges. For now it's just for 
aggregates (and even those who are input ranges by their alias 
this).

Re: isInputRange as a __traits ?

[Jonathan M Davis via Digitalmars-d]

On Saturday, October 07, 2017 10:46:05 user1234 via Digitalmars-d wrote:
> On Saturday, 7 October 2017 at 10:40:16 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, October 07, 2017 10:31:01 user1234 via
> >
> > Digitalmars-d wrote:
> >> Since the compiler has the ability to detect input ranges in
> >> the foreach aggregate that are aggregates implementing the
> >> right primitives, why don't you set the widely used
> >> std.range.isInputRange as a __trait, e.g
> >> __traits(isInputRange, Stuff) ?
> >
> > Why? What would we gain from that?
>
> I've replied in another answer, so again, the idea is to save a
> bit of time spent to compile.

I very much doubt Walter would consider that a good enough reason. And it
would make more sense to try and improve template processing in general than
to try and speed things up by avoiding one template. In general, __traits
does stuff that you can't check with a library, and we _can_ check in the
case of isInputRange. At this point, if something can be done in a library,
it's almost a guarantee that it won't be added to the language. A _really_
strong argument is needed for why something should be in the language rather
than a library if it can be done in a library with the language as-is.

- Jonathan M Davis

Re: isInputRange as a __traits ?

[user1234 via Digitalmars-d]

On Saturday, 7 October 2017 at 10:40:16 UTC, Jonathan M Davis 
wrote:
On Saturday, October 07, 2017 10:31:01 user1234 via 
Digitalmars-d wrote:
Since the compiler has the ability to detect input ranges in 
the foreach aggregate that are aggregates implementing the 
right primitives, why don't you set the widely used 
std.range.isInputRange as a __trait, e.g 
__traits(isInputRange, Stuff) ?


Why? What would we gain from that?


I've replied in another answer, so again, the idea is to save a 
bit of time spent to compile.

Re: isInputRange as a __traits ?

[Jonathan M Davis via Digitalmars-d]

On Saturday, October 07, 2017 10:31:01 user1234 via Digitalmars-d wrote:
> Since the compiler has the ability to detect input ranges in the
> foreach aggregate that are aggregates implementing the right
> primitives, why don't you set the widely used
> std.range.isInputRange as a __trait, e.g __traits(isInputRange,
> Stuff) ?

Why? What would we gain from that?

In general, the idea has been to do as little as possible with __traits and
as much as possible in the library. And in theory, it was more or less the
idea that std.traits would wrap __traits such that you'd never actually use
__traits directly, but that's never quite happened.

- Jonathan M Davis

Re: isInputRange as a __traits ?

[Computermatronic via Digitalmars-d]

On Saturday, 7 October 2017 at 10:31:01 UTC, user1234 wrote:
Since the compiler has the ability to detect input ranges in 
the foreach aggregate that are aggregates implementing the 
right primitives, why don't you set the widely used 
std.range.isInputRange as a __trait, e.g __traits(isInputRange, 
Stuff) ?


Because the __traits expression is supposed to be a fallback in 
place of where std.traits cannot be used, and should see minimum 
use.

Re: isInputRange as a __traits ?

[drug via Digitalmars-d]

07.10.2017 13:31, user1234 пишет:
Since the compiler has the ability to detect input ranges in the foreach 
aggregate that are aggregates implementing the right primitives, why 
don't you set the widely used std.range.isInputRange as a __trait, e.g 
__traits(isInputRange, Stuff) ?


IIRC the reason is if something could be done in library it should be 
done in library. Just to avoid making compiler more complex than it's 
necessary.

As for me isInputRange!Stuff is better than __traits(isInputRange, Stuff).

Re: isInputRange as a __traits ?

[user1234 via Digitalmars-d]

On Saturday, 7 October 2017 at 10:36:21 UTC, drug wrote:

07.10.2017 13:31, user1234 пишет:
Since the compiler has the ability to detect input ranges in 
the foreach aggregate that are aggregates implementing the 
right primitives, why don't you set the widely used 
std.range.isInputRange as a __trait, e.g 
__traits(isInputRange, Stuff) ?


IIRC the reason is if something could be done in library it 
should be done in library. Just to avoid making compiler more 
complex than it's necessary.


The point is that it's **already** in the compiler and that it 
could save hundreds of template instantiation.


As for me isInputRange!Stuff is better than 
__traits(isInputRange, Stuff).


Yeah of course, for code cosmetic it could be wrapped in an 
templatized enum


enum isInputRange(T) = __traits(isInputRangeInternal, T);

isInputRange as a __traits ?

[user1234 via Digitalmars-d]

Since the compiler has the ability to detect input ranges in the 
foreach aggregate that are aggregates implementing the right 
primitives, why don't you set the widely used 
std.range.isInputRange as a __trait, e.g __traits(isInputRange, 
Stuff) ?

Re: Need importing dcompute.lib into my project

[kerdemdemir via Digitalmars-d-learn]

do you set "-mdcompute-targets=cuda-xxx" in the dflags for your 
dub.json for your project?


I have added now after your comment.

But it seems it didn't changed anything.

Here is the dub.json file I have:
{
"name": "dsharpear",
"authors": [
"Erdem"
],
"dflags" : ["-mdcompute-targets=cuda-210" ,"-oq", "-betterC"],
"dependencies": {
"dcompute": ">=0.0.0-alpha0 <0.1.0"
},
"description": "Beamforming with D ",
"copyright": "Copyright © 2017, Erdem",
"license": "proprietary"
}

And running "dub build --compiler=D:\LDCDownload\bin\ldc2.exe 
--force"  fails with:


Performing "debug" build using D:\LDCDownload\bin\ldc2.exe for 
x86.

derelict-util 2.1.0: building configuration "library"...
derelict-cl 2.0.0: building configuration "library"...
derelict-cuda 2.0.1: building configuration "library"...
..\..\..\..\..\AppData\Roaming\dub\packages\derelict-cuda-2.0.1\derelict-cuda\source\derelict\cuda\runtimeapi.d(816,5):
 Deprecation: constructor derelict.cuda.runtimeapi.dim3.this
all parameters have default arguments, but structs cannot have 
default constructors.

dcompute 0.0.0-alpha0: building configuration "library"...
Targeting 'i686-pc-windows-msvc' (CPU 'pentium4' with features '')
Building type: real
Building type: uint
Building type: char
Building type: ubyte
Building type: ulong
Building type: int
Building type: double
Building type: long
Building type: ushort
Building type: wchar
Building type: byte
Building type: short
Building type: float
Building type: dchar
..\..\..\..\..\AppData\Roaming\dub\packages\dcompute-0.0.0-alpha0\dcompute\source\dcompute\std\package.d(6,5):
 Error: static assert  "Need to use a DCompute enabled compiler
See https://github.com/thewilsonator/ldc/tree/dcompute;
D:\LDCDownload\bin\ldc2.exe failed with exit code 1.

Re: gdc is in

[Joakim via Digitalmars-d]

On Saturday, 7 October 2017 at 09:54:41 UTC, Iain Buclaw wrote:
On 7 October 2017 at 04:46, Joakim via Digitalmars-d 
 wrote:



Yes, the gdc downloads page hasn't been updated in 9 months:

https://gdcproject.org/downloads

By comparison, ldc is at the ddmd 2.074 frontend, which has 
been downloaded 7000 times in the last month since it was 
released:


http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

The gdc devs should put out a new release with a more 
up-to-date frontend and announce it, so that all this work 
they've done gets more use.


Why don't _you_ help put out a release?  There are plenty of 
ready-made packages available to distributions from Slackware 
to Archlinux and everything inbetween.


Heh, I don't use GPL software if I can avoid it, so I'd never use 
gdc, even if it's a new release.  It's good that others are 
packaging up newer versions of gdc, but John and I are simply 
pointing out that the official releases page being behind hurts 
the perception of gdc.


I understand that you've been very busy with getting gdc into gcc 
and that there's not much manpower helping you out, but we're 
suggesting that you release a binary, even if just a beta like 
ldc does, and announce it to help change that perception.  Most 
people don't read the gdc forum, which is one of the reasons I've 
been posting on gdc progress here, even though I'd never use or 
contribute to it.


Regardless, there are D devs who'd like to use gdc, so I'm just 
trying to help you and them out.

Re: gdc is in

[Iain Buclaw via Digitalmars-d]

On 7 October 2017 at 04:46, Joakim via Digitalmars-d
 wrote:
>
>
> Yes, the gdc downloads page hasn't been updated in 9 months:
>
> https://gdcproject.org/downloads
>
> By comparison, ldc is at the ddmd 2.074 frontend, which has been downloaded
> 7000 times in the last month since it was released:
>
> http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc
>
> The gdc devs should put out a new release with a more up-to-date frontend
> and announce it, so that all this work they've done gets more use.

Why don't _you_ help put out a release?  There are plenty of
ready-made packages available to distributions from Slackware to
Archlinux and everything inbetween.

Re: D on quora ...

[Radu via Digitalmars-d]

On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:

https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non 
gc version in the future...


I think there is some merit criticizing D's GC.

The major problem with it ATM is that there is no convenient way 
to use all (most) of D's std lib without it.


This also extends to third party libs - most of them are coded 
with the GC in mind because of the above point.


I'm more an ambivalent person re. the GC - I see it as an useful 
tool most of the times, but also would like to get rid of it 
cleanly when circumstances require it.


I think there are some great steps already done to make it easier 
for programmers to use D without the GC: @nogc, betterC and the 
gang, but D is not yet up there.


Not for the naysayers sake - there will always be plenty of them 
regardless, I think more focused work on finishing the bellow 
points will make pragmatic D programmers more productive:


- Scope (-dip1000), a great tool to help code safe manual memory 
managed style apps. This could be huge for attracting more system 
level guys to D once it is finished (see bugzilla), it could 
offer some of Rust's guarantees without resorting to mind bending 
techniques - all in a nice C like syntax.


- betterC, this one is nice as it enforces "cost free 
abstractions" bondage while providing a low level C 
compatibility, more work here on RAII will be a boost! In general 
the work done for betterC for reducing bloat and impose a 
"pay-as-you-go" discipline will help D in general.


- Allocators - right now they are in Phobos... This is not great, 
they should be split in 2 parts: core an druntime. One should be 
able to use a minimal set in betterC mode, and the full version 
with druntime (all GC related parts).


All the above are cascading on each other, and the sum will 
create a hard to refuse offer even for the most dye-hard C/C++ 
guys.


And lastly, Ds GC needs work - it is not yet optimally 
implemented (see 
http://forum.dlang.org/thread/ewdoqmvslcnypzyrb...@forum.dlang.org) not to mention that design wise there are still more things to explore and experiment with: precision scanning, determinism, and a lot of research done on system-level GCs yet to consider.

[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17635

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #9 from ag0ae...@gmail.com ---
The original test case has been fixed, but it can be made to fail again by
changing the parameter type slightly. As far as I can tell, the parameter type
shouldn't matter, as long as it's not mutable.


alias T = immutable int;

T** f(I)(const I input) pure
{
T** output;
return output;
}

void main()
{
/* Not regressions in 2.066 (i.e. 2.065 also rejected these): */

T*** a1;
immutable T** r1 = f(a1);

static struct S2 { T* foo; }
S2* a2;
immutable T** r2 = f(a2);

/* But this one compiles with 2.065, so it's another regression: */

static struct S3 { T foo; }
S3* a3;
immutable T** r3 = f(a3);
}


Tested with DMD64 D Compiler v2.076.1-b1-166-g2f98e66e5.

Reopening. Let me know if I should file a new issue (or multiple ones) instead.

--

Re: Eilmer4 - a Computational Fluid Dynamics code in D

[user1234 via Digitalmars-d-announce]

On Friday, 6 October 2017 at 22:16:09 UTC, Peter Jacobs wrote:
Eilmer is a simulation code for studying high-speed 
compressible flows.  Early versions were written in C and then 
C++.  Version 4 is a complete rewrite in D, with Lua for 
configuration and run-time scripting.  Code and documentation 
may be found at http://cfcfd.mechmining.uq.edu.au/eilmer/


[...]

Cheers,
Peter Jacobs and Rowan Gollan


After reading the pdf i have a question:

Is LUA scripting too complex to be replaced by, let's say, pure D 
code, following a compile-time interface (i.e a duck type) ? I 
understand that existing LUA scripts must still be supported but 
since D is also known for its good speed of compilation perhaps 
the whole thing could be recompiled from scratch for a particular 
set of new scripts.