Instagram Clone

[John Britto via Digitalmars-d]

This amazing Instagram Clone app helps effectively in posting 
photos and sharing them on the social media platforms. Also 
featured in it are extra add-ons not found in the original app 
which is used to personalize and edit the pictures.


Website: 
https://www.whatsappupdate.com/products/instagram-clone-android-web-ios.html

How to call function with variable arguments at runtime?

[Mr. Jonse via Digitalmars-d-learn]

I need to store a hetrogeneous array of delegates. How can I do 
this but still call the function with the appropriate number of 
parameters at run time?


I have the parameters as Variant[] params and a function/delegate 
pointer(void* for now).


Normally I'd push the parameters on the stack and use a call, but 
I'm sure D has some ability to do this, like apply(foo, args) 
would be the same as foo(args[0], ..., args[1]).


I'm not concerned about type correctness, it should always be 
consistent between what I call and what is stored.


Thanks.

Re: Current limitations of -dip1000

[Walter Bright via Digitalmars-d]

On 10/9/2017 8:04 AM, Per Nordlöw wrote:
I'm trying to figure out how to make my manually written containers have 
scope-aware element(s)-accessing functions. I've come up with 5 different 
situations as follows


I find it is hopeless to explain how this works with refs, arrays, member 
functions, etc. It's much simpler to rewrite anything you're unsure of as using 
nothing but pointers and free functions. (After all, the compiler lowers all 
that reference stuff to pointers and free functions anyway.)


Making it explicit where all the pointers and parameters are makes it a LOT 
easier to reason about how dip1000 works.


For example, replace:

  int[]
  a[0]

with:

  int*
  *a

Get rid of the templates, too. Replace T with int. Get rid of any of the layers 
of confusing complexity. Think "what does the compiler lower this construct to" 
and do that.


Once it is clear how the pointers works, then start adding the complexity back 
in.

Undo?

[Mr. Jonse via Digitalmars-d-learn]

I requiring an undo feature in my code. Rather than go the 
regular route of using commands, I'm wondering if D can 
facilitate an undo system quite easily?


We can think of an undo system in an app as a sort of recorder. 
The traditional method is to use commands and inverse-commands. 
By recording the commands one can "unwind" the program by 
applying the inverse commands. The down side is that the app must 
be written with this approach in mind.


Storing the complete state of the app is another way which some 
apps use but usually it is too much data to store.


Since the only thing that one has to store from state of the app 
to the next is the change in data long with creation and deletion 
of the data, I think one could simplify the task?


Is it possible to write a generic system that records the the 
entire state changes without much boilerplate?


I'm thinking that two types of attributes would work, one for 
aggregates for creation and deletion of objects and one for 
properties to handle the data changes. If D can be used to 
automatically hook properties to have them report the changes to 
the undo system and one can properly deal with object creation 
and assignment, it might be a pretty sleek way to support undo.



Help appreciated!

[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 #8 from github-bugzi...@puremagic.com ---
Commits pushed to master 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

--

[Issue 17307] [REG2.072.0][ICE] TypeBasic::implicitConvTo: After error "anonymous struct can only be a part of an aggregate"

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7199

--

[Issue 17869] scope class object no longer deleted when created via factory function

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

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

--- Comment #4 from Rainer Schuetze  ---
I'm not convinced:

> It's was destroyed twice formerly, destruction was never supposed to run for 
> GC allocated classes.

Sure it has been unsafe so far, just like writing "scope(exit) delete obj;"
twice.

> Scope class always referred to RAII allocated classes on the stack.

Yes, but the spec does not say this explicitly about scope declarations.

> The fact that you can assign heap allocated instances to variables with scope
> storage was unfortunately a bug, as was the double destruction of scope class 
> instances assigned to other scope references.

So why is it now silently accepted? 

BTW: Even std.datetime.timezone still uses scope with factory functions,
relying on GC caused bugs in LDC due to premature collection.

I'm not against changing the meaning of scope for the sake of DIP1000, but I
wonder why it's ok in this case to break code without any warning that worked
fine before.

--

Re: Beta 2.076.1

[Eugene Wissner via Digitalmars-d-announce]

On Monday, 9 October 2017 at 18:56:13 UTC, Martin Nowak wrote:

On 10/07/2017 03:20 PM, Eugene Wissner wrote:
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.


Ah good to know, indeed seems to be a problem for GH's archive 
endpoints? Would of course be a nogo for distro build receipts. 
https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745


I had this problem about two weeks ago.
As an example.. Slackware is a half-binary, half-source based 
Linux. The core system is provided as binary packages and the 
most users build other programs from slackbuilds.org which 
provides a huge collection of third-party packages as automated 
build scripts (but they don't keep the sources, only scripts that 
build a package from the source). There are also automation tools 
to compile all the dependencies if needed. It is slightly similar 
to how freebsd ports work. Such a tool has to verify that the 
downloaded source is not corrupted and it is done with md5.
Actually I think that it can be a problem for many smaller linux 
distributions that are community-driven and not  backed by 
commercial organizations and don't have the power to keep all 
sources themselves like debian does.
GitHub breaks the archives very very seldom but if it happens it 
is very painful

Re: Release D v2.076.1

[zabruk70 via Digitalmars-d-announce]

On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak wrote:

Glad to announce D v2.076.1.

http://dlang.org/download.html

This point release fixes a few issues over v2.076.1, see the 
changelog for more details.


http://dlang.org/changelog/v2.076.1.html

- -Martin


http://dlang.org/changelog/v2.076.1.html - not found
http://dlang.org/changelog/2.076.1.html  - right url

Release D v2.076.1

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Glad to announce D v2.076.1.

http://dlang.org/download.html

This point release fixes a few issues over v2.076.1, see the changelog
for more details.

http://dlang.org/changelog/v2.076.1.html

- -Martin
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlnb0ZcACgkQsnOBFhK7
GTlfQhAAtKFPULWZRcpnoBoZ3E5LOijGn3Xj5+08zyx2UZNt2qyZcBySK2rB6NRV
/GTn6fYUPI/tePBHVYACDhmILy8NcXIjdLy0eEdMdNlNfmNRqNZUUW1tKz4Ad6Y+
hwP2CrNYy0Rw8X/udmf8nGDB1Piu4ClJ1NzTDRGC6N1M419SSnErqv1l7gZITa9B
dqgbF4tgjNFHK9UTUcy744/vumoaq3aRsWoy0csytgCZd4n6Hk6BtwcQMmWzmXM5
YFbyLrqsnGDyBIoLYP180D6KKbtmlfjsmXEWouvZpGjyO/5XTlw0pG20TMe23AlZ
aqPRLJ5ysPVekpGi6Rl5MoEy2G5Ml7T1JTe/Grhrwh8ryivasX2NoX6/uB47gYSW
X3xHkfpDCp9GPUUiuH2DcdQkAP0TmGUDIKYbdXVySHDx6LMkVbEY43lHADU0bFru
C9CJMlBTd8RJWf7xl+w/8+4xHhm6yHjDq2+9wF/pcaqV7ifGH19dS3dATabXTEuO
aGESIc0siPnX47exVkV1qgH1UMAJ1odjsbEE0kgalu6cT/+eIs9R6BtBtoHNQnLq
Rgnd7easM6aL3S5a8KOfuj/47gRtrmr0+d59j3x1zIIxreEfQHyfO0x3Ho0raKK3
WvWVwwpusVm1Hg5xl+41lQjRAqqkhYmTiFnouDbgE0V0w+5cMag=
=+IlF
-END PGP SIGNATURE-

[Issue 16273] [REG 2.072a] dmd segfault with inheritance, templates, override

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

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

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

https://github.com/dlang/dmd/commit/3c865d5eedaff4debf7f99df19c38ccb996a017b
fix Issue 16273 - [REG 2.072a] dmd segfault with inheritance, templates,
override

https://github.com/dlang/dmd/commit/2a8fdd858bb408da2785e8eb6c18b5e9f7423d28
Merge pull request #7198 from WalterBright/fix16273

fix Issue 16273 - [REG 2.072a] dmd segfault with inheritance, templat…

--

Re: Beta 2.076.1

[Martin Nowak via Digitalmars-d-announce]

On 10/07/2017 03:20 PM, Eugene Wissner wrote:
> 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.

Ah good to know, indeed seems to be a problem for GH's archive
endpoints? Would of course be a nogo for distro build receipts.
https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745

Re: Should we have prettier string printing for exceptions and std elemts?

[Petar via Digitalmars-d]

On Monday, 9 October 2017 at 17:44:12 UTC, jmh530 wrote:
On Monday, 9 October 2017 at 17:19:42 UTC, Petar Kirov 
[ZombineDev] wrote:


Another point is that if the container contains many elements 
automatically printing all of them would be ugly, unhelpful 
and slow, while printing its identity (I think the address of 
the RefCountedStore doesn't change on reallocation) may be 
more useful.


This relates to your comment in the bugzilla to format with 
'%5r'. This would be similar to using something like head or 
tail in R and the printing the result. I consider that a 
separate issue. It's really easy to handle this in D with UFCS. 
In Mir, you could do slice.select(5).writefln!"%s".


Yes, nowadays I am not so certain that we need a dedicated format 
for printing only some of the elements, as for most containers it 
should be as simple as container[0..5] or container[].take(5). 
What I'm certain though, is that I don't want all my containers 
with millions of elements to have their elements printed by 
default. The std.format code could probably hide them if they're 
too many, but at this point it is better to leave the 
customization to the user. Printing the container type, address 
and length would be most useful default IMO (but in a better 
looking way than what we have now for std.container.array).

Re: Should we have prettier string printing for exceptions and std elemts?

[jmh530 via Digitalmars-d]

On Monday, 9 October 2017 at 17:19:42 UTC, Petar Kirov 
[ZombineDev] wrote:


Another point is that if the container contains many elements 
automatically printing all of them would be ugly, unhelpful and 
slow, while printing its identity (I think the address of the 
RefCountedStore doesn't change on reallocation) may be more 
useful.


This relates to your comment in the bugzilla to format with 
'%5r'. This would be similar to using something like head or tail 
in R and the printing the result. I consider that a separate 
issue. It's really easy to handle this in D with UFCS. In Mir, 
you could do slice.select(5).writefln!"%s".

Re: Should we have prettier string printing for exceptions and std elemts?

[Petar via Digitalmars-d]

On Sunday, 8 October 2017 at 21:48:05 UTC, Fra Mecca wrote:

Hi,
I have noticed that there are elements of core and phobos that 
are pretty ugly when printed via writeln.


One example is container.Array, but also exceptions.

Should we prettify all of them to have a result similar to the 
one in python?


This has been previously discussed 
(https://issues.dlang.org/show_bug.cgi?id=13971) and AFAIR the 
opinions were divided.


For one, the only thing necessary to get pretty-printing of the 
elements of a container is to slice it. Slicing a container 
returns a range and since std.format supports printing ranges it 
works out-of-the box.


import std.stdio, std.container;
void main(string[] args)
{
auto arr = make!(Array!int)(1, 2, 3);
writeln(arr);
writeln(arr[]); // slice
}

Array!int(RefCounted!(Payload, 
cast(RefCountedAutoInitialize)0)(RefCountedStore(7F10930E8490)))

[1, 2, 3]

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

Another point is that if the container contains many elements 
automatically printing all of them would be ugly, unhelpful and 
slow, while printing its identity (I think the address of the 
RefCountedStore doesn't change on reallocation) may be more 
useful.

[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

Alexandru Razvan Caciulescu  changed:

   What|Removed |Added

 CC||alexandru.razva...@gmail.co
   ||m
   Assignee|nob...@puremagic.com|alexandru.razva...@gmail.co
   ||m

--

[Issue 11577] Template std.typetuple.NoDuplicates removes const types for classes and structs

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

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

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

   What|Removed |Added

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

--

[Issue 17876] [REG 2.074] Internal error when comparing inout(Foo[][]) with Foo[][]

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

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

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

https://github.com/dlang/druntime/commit/70d536eddf2bab82e428ea397dec8b4093c9f3c1
fix Issue 17876 - moved bad assertion that failed for arrays of arrays with
mixed modifiers to the memcmp version which should work on values anyway.

https://github.com/dlang/druntime/commit/ec9a79e15d446863191308fd5e20febce2053546
Merge pull request #1934 from rainers/issue_17876

--

[Issue 15740] Indexing a std.typecons.Tuple with names doesn't work in ctfe

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

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

Eduard Staniloiu  changed:

   What|Removed |Added

 CC||edi33...@gmail.com

--- Comment #3 from Eduard Staniloiu  ---
Isn't this a dmd bug?

--

Re: Should we have prettier string printing for exceptions and std elemts?

[jmh530 via Digitalmars-d]

On Sunday, 8 October 2017 at 21:48:05 UTC, Fra Mecca wrote:


One example is container.Array



Ideally you would format the container as a string and then 
writeln that. There are some examples in std.format's 
documentation of how to make it prettier. I relied on that to do 
the same for mir's ndslices:

https://github.com/libmir/numir/pull/10

[Issue 16487] Add function to obtain the available disk space

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

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

--- Comment #12 from b2.t...@gmx.com ---
std.file makes more sense. User wants available disk space to know if it can
create a file or how many byte in disk a cache can use (or whatever else).
Much less useful in std.path.

ideally there would be:

std.filesystem.file
std.filesystem.path
std.filesystem.package <-- i would put it here

but since it's not the case std.file is the best ooption.

--

Re: Should we have prettier string printing for exceptions and std elemts?

[bauss via Digitalmars-d]

On Sunday, 8 October 2017 at 21:48:05 UTC, Fra Mecca wrote:

Hi,
I have noticed that there are elements of core and phobos that 
are pretty ugly when printed via writeln.


One example is container.Array, but also exceptions.

Should we prettify all of them to have a result similar to the 
one in python?


I believe we shouldn't; at least not for the default writeln, 
writefln etc.


If anything there should be made alternative functions to do that.

[Issue 17888] New: dmd fails on Windows if path is too long

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

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

  Issue ID: 17888
   Summary: dmd fails on Windows if path is too long
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lae...@laeeth.com

DMD fails on Windows if the path is too long.  (Sorry for not giving specific
test case yet - I'm on Linux right now, but Atila Neves will elaborate
shortly).

This is particularly a problem when using dub, which likes to turn all paths
into relative ones and this has the consequence of making even a shortish path
long.

There are two reasons for this.  One is that the static array in tk/filespec.c
in the function that builds a path is only 131 chars + null.  Another is that
for the getcwd Windows API function we call, the MAXPATH limit of 260
characters applies.  The way to avoid this is to use the unicode function and
Win32 File namespaces instead of a regular path.  So if the path does not begin
\\ then we should make it look something like: \?\C\D\foo  (note, not \?C\D\foo
- which does something entirely different).  I believe that should:

1. be one step towards permitting unicode characters in the path.  (probably
there are  other functions that would need to be changed - I haven't had time
to look).  See  https://issues.dlang.org/show_bug.cgi?id=13493

2. be one step towards removing the path length limit on Windows which
interacts badly with dub's style in relativisation of paths.  there might be
other functions that need to be changed - in a hurry.

https://github.com/dlang/dmd/blob/2bf9a9d731e88ebd8a175bd0a990a3b651e8df82/src/ddmd/tk/filespec.c
line 119 - cwd is 131 chars + null

prototype:
extern (C) char* getcwd(char* buffer, size_t maxlen);

it's deprecated and replaced by the ISO function:
https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/getcwd-wgetcwd

on Windows and indeed other operating systems we already have the correct code
to get current working directory. so we just need to update dmd to use this.
https://github.com/dlang/phobos/blob/v2.076.0/std/file.d#L2681

even if we can't use Phobos I guess we could copy /paste that code.

--

[Issue 16487] Add function to obtain the available disk space

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

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

--- Comment #11 from alex.jercai...@gmail.com ---
Hi,

I'd like to take this task.
In which part of the std do you think it would be best to put this function?

Thanks,
Alex

--

[Issue 16487] Add function to obtain the available disk space

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

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

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

   What|Removed |Added

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

--

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

[Timon Gehr via Digitalmars-d]

On 09.10.2017 17:41, Timon Gehr wrote:

There wasn't a lack of discussion about the import lookup rules :-)
...


The only related issue of which I was aware was visibility of private 
symbols. (I.e. private symbols should not cause conflicts with public 
symbols in other modules.)


(Besides local imports, that is.)

Re: Proposal: Object/?? Destruction

[jmh530 via Digitalmars-d]

On Monday, 9 October 2017 at 15:22:35 UTC, Timon Gehr wrote:


Singleton tuples might seem pointless, and some languages do 
not support such single-element tuples, but as we want to 
support slicing, they should probably exist. (Also, we might 
want to create a tuple from an AliasSeq, which can be achieved 
by dropping it into a single-element tuple and letting it 
auto-expand.)




Singleton tuples would be necessary for any kind of recursion on 
tuples.


The way mir.functional.RefTuple works is similar to your AliasSeq 
tuple. This is because it uses anonymous names for the fields. 
std.typecons.Tuple assumes field name/Type pairs.

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

[Timon Gehr via Digitalmars-d]

On 06.10.2017 03:01, Walter Bright wrote:

On 10/5/2017 4:26 AM, Timon Gehr wrote:
I know that some of the UFCS code was written without regard to 
hijacking.

...


I think it is by design. Lookup first tries to find members of the 
type, and only if they don't exist applies UFCS lookup. Therefore, if 
members are added to the type or made visible, this may hijack 
existing UFCS usages.


It may have been done that way to avoid breaking existing code.



I think so. It can break new code though. ;)

The way to fix it is to do UFCS lookup always and then error out if 
both UFCS and member lookup match, but there is probably quite some 
code relying on the fact that you can provide a custom implementation 
of a general UFCS function by just adding a member. Also, with the 
hijacking error if you actually meant the member function the only way 
out I see is to use __traits(getMember, ...) for disambiguation.


(BTW: Local imports allow hijacking too. Maybe this one could be fixed?)


I thought that was taken care of when the whole import lookup mechanism 
was redone a year or two ago.

...


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

I think the best fix is what I quickly outline at the end of the issue. 
It is originally a proposal of deadalnix:

https://issues.dlang.org/show_bug.cgi?id=10378#c9


...

D's name lookup rules were quite simple, and deliberately set up that 
way. Unfortunately, most people thought they were unintuitive. It 
turns out that simple algorithms are not intuitive, and we now have a 
fairly complex lookup system. Martin and I implemented it, and 
probably neither of us completely understands it. I find it 
regrettable that things have gotten to that state.

...


It might make sense to sit down at some point and see what goals the 
complex rules try to achieve and then come up with simpler rules that 
achieve the same (or better) goals.


There wasn't a lack of discussion about the import lookup rules :-)
...


The only related issue of which I was aware was visibility of private 
symbols. (I.e. private symbols should not cause conflicts with public 
symbols in other modules.)



... >>> Doing this kind of wrapper doesn't work for operator overloading,

which brings us back to ADL is for operator overloading.


Why does it not work for operator overloading?


3+s


typeof(s) could overload opBinaryRight, no?

Re: Proposal: Object/?? Destruction

[Timon Gehr via Digitalmars-d]

On 09.10.2017 01:20, Steven Schveighoffer wrote:

On 10/7/17 8:56 PM, Timon Gehr wrote:

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


My questioning comes with this:

void bar(int a);
void bar((int,) x);

To me, it is confusing or at least puzzling that these two aren't the same.
...


Well, to me it is a bit confusing that this is puzzling to you. Why 
should int be the same as (int,)? It does not make sense to index an 
integer, but (int,) can be indexed with 0 to get an integer.


I believe your difficulty is rather with the notion that what before was 
a function that takes a single value is no longer analogous to what 
before was a function that takes multiple values. The analogy breaks 
because now they are handled precisely the same way, rather than just 
analogously. Furthermore, some existing syntax slightly changes meaning: 
The prior syntax for declaring multiple arguments is now a pattern that 
matches against a single tuple argument.


The new design is more orthogonal and in effect more useful, because 
functions no longer need to care about and interfere with the concept of 
"multiple values".



The first is like a "regular" function that doesn't take a tuple.

The second is a new "tuplized" function that takes a tuple. both take 
one parameter (one version via the regular argument syntax, one via a 
tuplized syntax).


One takes an argument that is an integer. The other takes an argument 
that is a tuple containing a single integer.



Why is it not the same?


One takes an int while the other takes an (int,).

Clearly a tuple of 1 can bind 
to a single value, just like a tuple of 2 can bind to 2 values.

...


But it is precisely what is happening. However, not every value is a 
singleton tuple just by virtue of not being a tuple of multiple values.



Currently, I can call this:

foo(T...)(T t) if (T.length == 1) // function that takes a single 
element tuple


like this:

foo(1);

Why is this disallowed in your tuple scheme?
...


I take this to mean, why does the following code not compile:

void foo(T)(T t) if(T.length == 1) { ... }

foo(1);

This is because T is matched to int, which does not have length.

A few more examples:

void foo(int x);   // foo takes an int
void foo(int x,);  // foo takes an (int,) and matches it against 
(int x,) in order to extract the value x
void foo(int x,int y); // foo takes an (int,int) and matches it against 
(int x,int y) in order to extract the values x and y.


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?


I don't understand the question.


I'm was trying to figure out what is causing the confusion. I was trying 
to appeal to symmetry to get past what seemed to be your notion that 
there is a significant difference between multiple values and a single 
tuple: If you have a function that needs to return multiple values, you 
return a single tuple. If you have a function that needs to take 
multiple values, you take a single tuple. With tuples, it is sufficient 
to return a single value, and it is also sufficient to take a single 
value as the argument.


I would think single value tuples and 
single values would be pretty much interchangeable.


Well, no. Otherwise 2[0] would be allowed and equal to 2. And then, what 
would [2][0] be? [2] or 2?


It's up to the user 
of the value whether he wants to look at it as a tuple (which has length 
and must be indexed) vs. a 

Re: How to make commented code to compile?

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 9 October 2017 at 15:15:48 UTC, Zhuo Nengwen wrote:

test(cast(ushort) 1, (m, c) => {
  writeln(m);
  writeln(m);
});


Just remove the =>

(m, c) {
  // code here
}

Re: How to make commented code to compile?

[Zhuo Nengwen via Digitalmars-d-learn]

On Monday, 9 October 2017 at 14:54:33 UTC, Adam D. Ruppe wrote:

//test(cast(ushort) 1, (m, c) => { writeln(m); });


That's a function that returns a function.

Perhaps you meant to just remove the => and be left with a 
multi-line function.


I simplified the test codes. I want write mode codes in closure, 
such as:


test(cast(ushort) 1, (m, c) => {
  writeln(m);
  writeln(m);
});

ASYNCREAD in dmd driver (mars.d)

[b4s1L3 via Digitalmars-d]

I've just noticed some dead code (at least since self-hosting 
started, because otherwise git blame is not useful) in dmd's 
driver.


All the *static if* blocks that test the value of ASYNCREAD are 
dead.

Should they be removed or something ?

https://github.com/dlang/dmd/blame/32bb4ed7526b2bd622c0576734e5a6a6bd3c8278/src/ddmd/mars.d#L1361

although That's not much code.

Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[Alexandru Caciulescu via Digitalmars-d]

On Wednesday, 4 January 2017 at 08:00:14 UTC, Jon Degenhardt 
wrote:

Alex, Andrei - Any updates on pursuing this?


https://github.com/dlang/druntime/pull/1929#pullrequestreview-67691304

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

[b4s1L3 via Digitalmars-d-learn]

On Sunday, 8 October 2017 at 04:03:27 UTC, user1234 wrote:

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.


Yeah that's becuz passing *.o / *.obj files to the linker or to 
dmd is the same buisness under the hood. The problem with this 
DUB project is that it will only compiles with DMD. Maybe the OP 
used another compiler. other compilers may not support the 
shortcut here:


https://github.com/dlang/dmd/blob/master/src/ddmd/mars.d#L626

Current limitations of -dip1000

[Per Nordlöw via Digitalmars-d]

I'm trying to figure out how to make my manually written 
containers have scope-aware element(s)-accessing functions. I've 
come up with 5 different situations as follows


@safe pure nothrow @nogc:

struct S(T)
{
static private struct Range
{
S!T* _parent;
}

scope inout(Range) range() inout return
{
return typeof(return)();
}

scope inout(T)[] opSlice() inout return
{
return x[];
}

scope inout(T)[] slice() inout return
{
return x[];
}

scope ref inout(T) front() inout return
{
return x[0];
}

scope inout(T)* pointer() inout return
{
return [0];
}

T[128] x;
}

/// this correctly fails
int[] testOpSlice()
{
S!int s;
return s[]; // errors with -dip1000
}

/// this correctly fails
int[] testSlice()
{
S!int s;
return s.slice; // errors with -dip1000
}

/// this correctly fails
auto testRange()
{
S!int s;
return s.range; // errors with -dip1000
}

/// TODO this should fail
ref int testFront()
{
S!int s;
return s.front; // should error with -dip1000
}

/// TODO this should fail
int* testPointer()
{
S!int s;
return s.pointer;   // should error with -dip1000
}

Compiling this with dmd version 2.076.0-b1 along with -dip25 and 
-dip1000 flags gives three errors:


test_scope.d(42,13): Error: returning `s.opSlice()` escapes a 
reference to local variable `s`
test_scope.d(49,12): Error: returning `s.slice()` escapes a 
reference to local variable `s`
test_scope.d(56,12): Error: returning `s.range()` escapes a 
reference to local variable `s`


It's very nice that the scope-analysis figures out that even the 
`range` member function contains an escaping pointer to the 
owning struct.


However, the other two `testFront` and `testPointer` don't error. 
Why are these two simpler cases allowed to escape a scoped 
reference and pointer which both outlive the lifetime of the 
owning struct `S`?

Re: How to make commented code to compile?

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 9 October 2017 at 14:34:48 UTC, Zhuo Nengwen wrote:

//test(cast(ushort) 1, (m, c) => { writeln(m); });


That's a function that returns a function.

Perhaps you meant to just remove the => and be left with a 
multi-line function.

Re: Default hashing function for AA's

[Per Nordlöw via Digitalmars-d]

On Monday, 9 October 2017 at 14:11:13 UTC, RazvanN wrote:
We in the UPB dlang group have been having discussions about 
the hashing functions of associative arrays. In particular, we 
were wondering why is the AA implementation in druntime is not 
using the hash function implemented in 
druntime/src/core/internal/hash.hashOf for classes that don't 
define toHash().


For us, that seems to be a very good default hashing function.


Further, I haven't found any instructions on changing the default 
hash-digest for `hashOf`. Is this in conflict with `hashOf` being 
`pure`? Could the interface to builtin AA's be extended to 
support changing the default hash algorithm (which in turn 
`hashOf` will use) upon AA instantiation?

[Issue 17887] Add WebAssembly reserved version identifier

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

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

--- Comment #2 from ZombineDev  ---
dlang.org PR: https://github.com/dlang/dlang.org/pull/1905

--

How to make commented code to compile?

[Zhuo Nengwen via Digitalmars-d-learn]

import std.stdio;

void test(ushort market, void delegate(ushort market, char* pc) 
callback)

{
for (auto i = 0; i < 10; i++)
{
callback(cast(ushort) i, cast(char*) null);
}
}

void main()
{
test(cast(ushort) 1, (m, c) => writeln(m));
//test(cast(ushort) 1, (m, c) => { writeln(m); });
test(cast(ushort) 1, (ushort m, char* c) => writeln(m));
//test(cast(ushort) 1, (ushort m, char* c) => { writeln(m); 
});

}

Default hashing function for AA's

[RazvanN via Digitalmars-d]

Hi all,

We in the UPB dlang group have been having discussions about the 
hashing functions of associative arrays. In particular, we were 
wondering why is the AA implementation in druntime is not using 
the hash function implemented in 
druntime/src/core/internal/hash.hashOf for classes that don't 
define toHash().


For us, that seems to be a very good default hashing function.

Best regards,
On behalf of the UPB Dlang group

[Issue 17887] Add WebAssembly reserved version identifier

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

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from ZombineDev  ---
DMD PR: https://github.com/dlang/dmd/pull/7202

--

Re: [OT] vim tip with column limits

[lithium iodate via Digitalmars-d]

On Monday, 9 October 2017 at 00:24:02 UTC, Jonathan M Davis wrote:

[…]


Thanks for the tip!

[Issue 15504] core.demangle uses exception handling for normal control flow

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

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

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

   What|Removed |Added

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

--

Re: [OT] vim tip with column limits

[mark_mcs via Digitalmars-d]

On Monday, 9 October 2017 at 00:24:02 UTC, Jonathan M Davis wrote:
It would be nice if I could give the lines different colors (it 
does look like it's possible to change the colors of the lines 
but not individually), but it's already fantastic that there's 
a way to have multiple at all - particularly since I had no 
clue before that that was even possible.


I didn't even know about cc. I've always used a custom 
highlighter for this:


hi LineLimit ctermbg=red ctermfg=white guibg=#be322f
match LineLimit /\%121v/

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

[Jacob Carlborg via Digitalmars-d]

On 2017-10-07 09:24, Walter Bright wrote:

Even for something that's not C++'s fault, the C preprocesser, I 
scrapped and completely rewrote it 4 times, I believe. I think I finally 
got it right with Warp :-)


You mean you got it right with D ;)

--
/Jacob Carlborg

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

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-10-08 04:58, Fra Mecca wrote:

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


Everything passed to DMD with the -L flag is passed to the linker, 
basically as is. So if the linker accepts object files passed directly 
on the command line then it works.


--
/Jacob Carlborg

Re: Bug? ElementType fails if element type is const

[drug via Digitalmars-d-learn]

oops, it was my fault. sorry for noise. my apologies to ElementType ))

Bug? ElementType fails if element type is const

[drug via Digitalmars-d-learn]

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

Re: Eilmer4 - a Computational Fluid Dynamics code in D

[Peter Jacobs via Digitalmars-d-announce]

On Saturday, 7 October 2017 at 09:29:42 UTC, user1234 wrote:

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.


We did consider having the entire application in pure D code, 
however, we find that Lua is an easier configuration language for 
our users, who are mostly non-coders.


Peter J.

[Issue 17797] [REG 2.073.2] double print to stdout when reading stdin in another thread

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

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
   Hardware|All |x86

--- Comment #3 from Martin Nowak  ---
cat > bug.d << CODE
import std.stdio, core.thread;

void main()
{
auto thread = new Thread().start;
writeln("Output");
writeln("Output2");
writeln("Output3");
thread.join();
}

void func()
{
foreach (line; stdin.byLineCopy)
{
}
}
CODE
dmd -run bug.d

Slightly nicer version that terminates on EOF (Ctrl+D), works as expected on
linux.

Sure about 2.073.2? The only interesting change in

https://github.com/dlang/dmd/compare/v2.073.1...v2.073.2
https://github.com/dlang/druntime/compare/v2.073.1...v2.073.2
https://github.com/dlang/phobos/compare/v2.073.1...v2.073.2

is https://github.com/dlang/dmd/pull/6582.

--

[Issue 17781] printing "Shared libraries are not yet supported on OSX." should be optional

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

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
   Severity|regression  |normal

--- Comment #3 from Martin Nowak  ---
Dynamic loading of shared libraries are still not fully implemented, e.g.
missing GC/EH (TLS?) support.
I think Timothee's comment was a typo and he meant not 100% supported.

Also see issue 11478

--

[Issue 17876] [REG 2.074] Internal error when comparing inout(Foo[][]) with Foo[][]

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

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

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

https://github.com/dlang/druntime/commit/70d536eddf2bab82e428ea397dec8b4093c9f3c1
fix Issue 17876 - moved bad assertion that failed for arrays of arrays with
mixed modifiers to the memcmp version which should work on values anyway.
Also fixed bad comparison via memcmp only comparing first element.

https://github.com/dlang/druntime/commit/ec9a79e15d446863191308fd5e20febce2053546
Merge pull request #1934 from rainers/issue_17876

fix Issue 17876 - [REG 2.074] Internal error when comparing inout(Foo[][]) with
Foo[][]

--

[Issue 17876] [REG 2.074] Internal error when comparing inout(Foo[][]) with Foo[][]

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

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

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

   What|Removed |Added

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

--

[Issue 17869] scope class object no longer deleted when created via factory function

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

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Nowak  ---
It's was destroyed twice formerly, destruction was never supposed to run for GC
allocated classes.
Scope class always referred to RAII allocated classes on the stack.
The fact that you can assign heap allocated instances to variables with scope
storage was unfortunately a bug, as was the double destruction of scope class
instances assigned to other scope references.

Scope variables not pointing to stack allocated RAII classes have been
repurposed to match the semantics of scope pointers.

Sorry for any unforseen troubles this may have caused, but the existing
behavior seemed too buggy to preserve.

--

Re: @nogc formattedWrite

[Ilya Yaroshenko via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 18:14:00 UTC, Nordlöw wrote:
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...


Phobos code is not @nogc (can be fixed), but it will not nothrow.

PRs with  @nogc formatting functionality are welcome in Mir 
Algorithm.


Cheers,
Ilya

Re: [OT] vim tip with column limits

[Anton Pastukhov via Digitalmars-d]

On Monday, 9 October 2017 at 00:24:02 UTC, Jonathan M Davis wrote:
I've wanted this for ages and just figured out how to do it, so 
I figured that I'd share for those vim users who care.




https://github.com/nathanaelkane/vim-indent-guides allows to have 
two  or more lines of different colors.

[Issue 17887] Add WebAssembly reserved version identifier

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

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

ZombineDev  changed:

   What|Removed |Added

Summary|Add WebAssembly predefined  |Add WebAssembly reserved
   |version |version identifier

--

[Issue 17887] Add WebAssembly predefined version

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

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

ZombineDev  changed:

   What|Removed |Added

 Blocks||17886

--

[Issue 17886] [Tracker] WebAssembly support

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

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

ZombineDev  changed:

   What|Removed |Added

 Depends on||17887

--

[Issue 17887] New: Add WebAssembly predefined version

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

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

  Issue ID: 17887
   Summary: Add WebAssembly predefined version
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

The first step to WebAssembly support is adding a predefined version, so
libraries can adapt (for example the D bindings for SDL2). It is yet to be
determined if more parts of the language can be used in addition to the betterC
subset, so this may or may not be used in druntime for implementing full
run-time support.

--

Re: @nogc formattedWrite

[Igor via Digitalmars-d-learn]

On Saturday, 7 October 2017 at 18:27:36 UTC, jmh530 wrote:

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


As far as I know sformat is still not @nogc because it may throw 
an exception if buffer is not large enough, and throwing 
exceptions requires allocation.

[Issue 17886] [Tracker] WebAssembly support

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

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

--- Comment #1 from ZombineDev  ---
See http://webassembly.org/ and http://code.alaiwan.org/wp/?p=140 for more
information.

--

[Issue 17886] New: [Tracker] WebAssembly support

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

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

  Issue ID: 17886
   Summary: [Tracker] WebAssembly support
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

Currently D sort of has WebAssembly support, by using LDC to output LLVM
bitcode and then using the Emscripten toolchain to compile to wasm.

This bug is meant for tracking the support for this target.

--

Re: GDC in Slackware and a bit about GDC development

[Eugene Wissner via Digitalmars-d-announce]

On Monday, 9 October 2017 at 08:10:41 UTC, Iain Buclaw wrote:
On 9 October 2017 at 10:03, Eugene Wissner via 
Digitalmars-d-announce  
wrote:
On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw 
wrote:



That would almost certainly only happen if you were using a 
different druntime.  Check where your import modules are 
coming from, they probably aren't gdc's.




Ah yes. Thanks a lot for the hint. I tried to compile with 
"-v" and got:


importobject(/usr/include/d/object.d)
importcore.stdc.stdarg  
(/usr/include/d/core/stdc/stdarg.d)
importcore.stdc.stdlib  
(/usr/include/d/core/stdc/stdlib.d)
importcore.stdc.config  
(/usr/include/d/core/stdc/config.d)
importcore.stdc.stddef  
(/usr/include/d/core/stdc/stddef.d)

semantic  test
entry main  test.d
import__entrypoint
(/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di)


"/usr/include/d/core" is the druntime of dmd. gdc's one is in: 
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core


But GCC wants to use "/usr/include/d/" for some reason. If I 
remove dmd,

then the example above compiles.
I wasn't able to find how to change it. I'll probably change 
the runtime and
phobos paths for dmd and move gcc's D directories into their 
old place.


It might be a configure flag to change that.  Though I think at 
least Archlinux just applies local patches to all compilers to 
point the system directory explicitly to different locations.  
I'd say it's a dmd package bug for putting dmd sources in 
/usr/include/d, when this should be reserved for more general D 
application libraries.


I've chosen "/usr/include/d" for dmd since freebsd seems to use 
it and IIRC the debian-family aswell (I'm maintaining dmd package 
aswell).


I compared installation directories for c/c++ and gcc include 
files are in "/usr/include/c++/5.3.0/", llvm: 
"/usr/include/llvm". So the appropriate way would be probably 
just to put dmd stuff in "/usr/include/dmd".


Maybe I'll look into it later again. At least I have a quick 
solution for now to get both compilers work on one system.

Re: GDC in Slackware and a bit about GDC development

[Iain Buclaw via Digitalmars-d-announce]

On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce
 wrote:
> On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote:
>>
>>
>> That would almost certainly only happen if you were using a different
>> druntime.  Check where your import modules are coming from, they probably
>> aren't gdc's.
>>
>
> Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got:
>
> importobject(/usr/include/d/object.d)
> importcore.stdc.stdarg  (/usr/include/d/core/stdc/stdarg.d)
> importcore.stdc.stdlib  (/usr/include/d/core/stdc/stdlib.d)
> importcore.stdc.config  (/usr/include/d/core/stdc/config.d)
> importcore.stdc.stddef  (/usr/include/d/core/stdc/stddef.d)
> semantic  test
> entry main  test.d
> import__entrypoint
> (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di)
>
>
> "/usr/include/d/core" is the druntime of dmd. gdc's one is in:
> /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core
>
> But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd,
> then the example above compiles.
> I wasn't able to find how to change it. I'll probably change the runtime and
> phobos paths for dmd and move gcc's D directories into their old place.

It might be a configure flag to change that.  Though I think at least
Archlinux just applies local patches to all compilers to point the
system directory explicitly to different locations.  I'd say it's a
dmd package bug for putting dmd sources in /usr/include/d, when this
should be reserved for more general D application libraries.

Re: GDC in Slackware and a bit about GDC development

[Eugene Wissner via Digitalmars-d-announce]

On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote:


That would almost certainly only happen if you were using a 
different druntime.  Check where your import modules are coming 
from, they probably aren't gdc's.




Ah yes. Thanks a lot for the hint. I tried to compile with "-v" 
and got:


importobject(/usr/include/d/object.d)
importcore.stdc.stdarg  (/usr/include/d/core/stdc/stdarg.d)
importcore.stdc.stdlib  (/usr/include/d/core/stdc/stdlib.d)
importcore.stdc.config  (/usr/include/d/core/stdc/config.d)
importcore.stdc.stddef  (/usr/include/d/core/stdc/stddef.d)
semantic  test
entry main  test.d
import
__entrypoint	(/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di)



"/usr/include/d/core" is the druntime of dmd. gdc's one is in:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core

But GCC wants to use "/usr/include/d/" for some reason. If I 
remove dmd, then the example above compiles.
I wasn't able to find how to change it. I'll probably change the 
runtime and phobos paths for dmd and move gcc's D directories 
into their old place.