[Issue 17666] std.c.linux.socket has no replacement

[via Digitalmars-d-bugs]

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

--- Comment #3 from Sebastiaan Koppe  ---
(In reply to Sebastiaan Koppe from comment #2)
> Just so that you know, I am working on a PR to add them to druntime.

I am a bit stuck on the issue.

In src/core/sys/posix/netinet/in_.d there are 2 general sections, one for ipv4
and one for ipv6. In each section constants are defined for CRuntime_Glibc,
Darwin, FreeBSD, NetBSD, Solaris and linux (in that order). Except there is no
linux version for ipv6.

Which makes me wonder how things for linux can actually compile, since basic
things like in6_addr and sockaddr_in6 structures are not defined.

I suppose the CRuntime_Glibc branch is taken, but that would be invalid since
the constants differ slightly with linux.

--

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[Nick Treleaven via Digitalmars-d]

On Friday, 28 July 2017 at 16:58:41 UTC, Moritz Maxeiner wrote:
Having a keyword delimit the end of an optional is both 
redundant and inconsistent


You are arguing against the current syntax, not my proposal. In 
my case the `do` keyword would be disambiguating between out 
expressions and out blocks. It is not redundant, by the same 
logic I could argue that `;` in `(; identifier)` is redundant. 
They are different valid options of disambiguation.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[Nick Treleaven via Digitalmars-d]

On Friday, 28 July 2017 at 16:44:24 UTC, MysticZach wrote:

On Friday, 28 July 2017 at 11:04:23 UTC, Nick Treleaven wrote:
One option to solve the out contract ambiguity and aid parsing 
by tools is to require 'do' after out contract expressions.


BTW `do` would only be required before the {} function body - 
further `in` and `out` clauses also can be used to disambiguate, 
see below.


One of the main goals of this DIP is to eliminate the need for 
`body/do` in the common case. It would significantly reduce 
this DIP's value if it couldn't do that, IMO.


This is subjective. If you put `do` on the end of the line, it is 
trivial:


in(x > 4)
out(works)
out(r; r.test)
out(flag) do
{
  // body
}

Re: Taking the address of an eponymous template

[ag0aep6g via Digitalmars-d-learn]

On 07/31/2017 11:44 AM, Arafel wrote:

```
class C {

[...]

 template baz(string S) {
 void baz()() {
 }
 }
}

void main() {

[...]

 void delegate() aBaz = !"a"; // This doesn't compile.
}
```

If I try !"a".baz it doesn't work either (I get a different error 
message.


Do you know if this works (and if so, what should I do), or if it's 
supposed to?


You'd have to instantiate the inner template, too. Something like 
`!"a".baz!()`, but that doesn't work. I don't know how you could 
make it work.


Of course in this case I don't need to use an eponymous template at all, 
bit it's just a simplification to try to get everything else out of the 
way...


In case anyone is interested, the real case is something more like this:

```
class C {
 template baz(args...) if (someCondition!args) {
 void baz(this T) {
 }
 }
}
```


(Assuming the inner baz is supposed to be `void baz(this T)() {}`.)

You'd still have to instantiate the inner baz in order to get a delegate 
of it. But even if we figured out how to do that, my guess is you don't 
want to specify `this T` explicitly.


So how about a function literal:

void delegate() aBaz = () => c.baz!(int, float)();

As far as I know, that's the only way to combine a "this" template 
parameter with variadic template parameters.


That's right if you want to pass `args` explicitly, but `this` 
implicitly. If specifying `args` via IFTI is an option, then this works, 
too:



class C {
void baz(this T, args...)(args) {}
}

void main() {
C c = new C();
void delegate() aBaz = () => c.baz(1, 2.3, "four");
}


A function literal again, because you have to call baz in order to 
instantiate it (or you have specify `this T` and `args` explicitly). But 
you can't get a delegate from a call.

Re: Specify rhs at initialisation or assignment of typedef' d variable

[Cecil Ward via Digitalmars-d-learn]

On Monday, 31 July 2017 at 07:50:57 UTC, inevzxui wrote:

On Monday, 31 July 2017 at 07:16:25 UTC, Cecil Ward wrote:
Say I have used Typedef! to create some new type and I declare 
a variable, constant or enum of that type. Is there a way that 
I can express a literal value on the rhs without having to use 
casts, as that seems to defeat the point of the nice type 
safety?


I may be asking for the impossible or _illogical_ here. In any 
case, I still get to keep the nice feature of not being able 
to mix up types with assignment from one variable to another.


Specific example is

mac_addr_48_t   my_mac_address = 0x112233445566uL;

Which now produces a compile time error after I changed to use 
an alias  = Typedef!uint64_t as opposed to just a straight 
alias = uint64_t earlier with no strong typing.


If struct + alias this is not strong enough the only solution 
is see is a helper template à la "octal" or "hexString", i.e a 
static cally checked string.


I suspect that I am asking for something that literally makes no 
sense at all. I wanted to try and avoid opening the door to 
allowing the following kind of typing error now, eg

enum ip_address = 0x11223344;
mac_addr_48_t my_mac = cast(mac_addr_48_t) ip_address;
as if we are going to the bother of introducing strong type 
checking with Typedef! then the last thing I want to do is 
encourage is a proliferation of casts.


I realise something else now too -

Issue 2: The thing is that I also immediately have to do a lot of 
work to make the simplest operators work anyway, such as in


foreach( addr;  base_mac_address .. base_mac_address + range )

where the + operator is producing compile-time errors now.

So it just seems that the Typedef! feature immediately make life 
into a nightmare. I don't know if something based of the physical 
units module (using 'dimensionless' in this case) would work - 
perhaps it only handles floating point of various types? Or 
whether that would also involve a huge amount of work and still 
have issue 1 mentioned earlier. In any case, I have absolutely no 
clue how to even begin to start using the units module thing.

SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Mike via Digitalmars-d-announce]

https://github.com/JinShil/svd_to_d

SVD_to_D is a command-line utility that generates D code from ARM 
Cortex-M SVD files.


SVD files are XML files that describe, in great detail, the 
memory layout and characteristics of registers in an ARM Cortex-M 
microcontroller. See 
https://github.com/posborne/cmsis-svd/tree/master/data for a 
curated list of SVD files for many ARM Cortex-M microcontrollers 
from various silicon vendeors.


From the information in an SVD file, code for accessing the 
microcontroller's memory-mapped-io registers can be automatically 
generated, and SVD_to_D does exactly that.


For a large microcontroller like the SM32F7, the amount of code 
generated can be more than 100k lines.  See an example of 
generated D code here: 
https://github.com/JinShil/svd_to_d/tree/master/examples/stm32f7x9


The code generated by SVD_to_D depends on this memory-mapped-IO 
library: https://github.com/JinShil/memory_mapped_io  That 
library uses D's CTFE and meta-programming features to generate 
highly optimized code (for both size and speed) at compile-time 
with additional features such as type safety and 
compile-time-enforced mutability.


Enjoy!

Mike

Re: How do you use D?

[Michael via Digitalmars-d]

On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:

How do you use D?
In work, (key projects or smaller side projects)


I did my undergraduate in CS where I picked up Python, Java and a 
little bit of C/C++, but Java was my most familiar language. When 
I started my PhD in an Engineering Maths department, I picked up 
Andrei's book on D as I had come across the language several 
times earlier but never had a good excuse to pick it up properly. 
My supervisor is more of a mathematician so I did not have any 
dependencies or limitations in the tools I chose to use for 
research. For the first year of my PhD I built models in Java 
with Python for scripting on the side. I was incredibly 
disappointed with the performance in Java, and having been 
learning D on the side during that year, I decided to rewrite it 
using D. I essentially chose D for the one reason many people do 
NOT choose D; I wanted a GC-language that offered a decent level 
of control like C/C++ and was much nicer to write than Java, but 
with the convenience of not having to concern myself too much 
with memory management. I was happy to tune for efficiency, but 
did not want memory management to interrupt my workflow when 
writing a new model. D was perfect for this.



in your side project, (github, links please)


I've been lazy with side projects since I am always trying to 
work on my maths and writing skills which are pretty lacking 
given my choice of degree.


Did you introduce D to your work place? How? What challenges 
did you face?


I've tried to inform people of the merits of D but in this 
department, we're heavily tied to Matlab for teaching. When I 
started, they switched up the undergrad courses and started 
teaching Python as an alternative to Matlab alongside C/Java, but 
there's still a lot of reliance on Matlab. I'd like to see them 
chuck Java and teach C/D but we'll see. At university, there's a 
lot of difficulty in balancing the necessities (C for embedded 
systems/robotics and Matlab for modelling).



What is you D setup at work, which compiler, which IDE?


I've been a long-time Sublime Text user, using DMD (rdmd is a 
life saver) and that's about it. I'm interested in VS Code with 
the dlang extension though.



And any other fun facts you may want to share :)


It makes me sad to see so many people disgruntled by the mere 
presence of a garbage collector. I like it a lot and while I am 
completely on board with moving toward making it more optional, I 
am glad it's there and would welcome speed improvements. I think 
there's a balance to be struck between allowing programmers to 
forget about the low-level memory management when writing 
programs and tuning memory management when optimising for 
performance.

Re: DWT is official ?

[User via Digitalmars-d-dwt]

On Wednesday, 12 July 2017 at 10:10:53 UTC, Flaze07 wrote:
hi...so is this group forum about the SWT D bindings ? (I am 
just surprised that it is...in the ecosystem if it is what I 
think it is)


No, D does not have a official gui lib. The dlang core community 
is still small and hardly funded, it's mostly still a 
design-by-volunteers language. Therefore it's impossible to 
maintain any significantly sized lib in phobos. Especially when 
majority of the D users are web based programmers and there is no 
common consensus about which gui lib to pick.


The main focus is to improve safety, before that out used to be 
parallelism and concurrency, even before that it used to be 
speed, ufcs, duck typing etc.


Point is that gui libs or any major libs will almost never be 
official, unless it's web related.


Also, nowadays it's fashionable to design-your-own-lang so every 
major company has their own language now, it seems less and less 
likely that D will be sponsored by any major company. Therefore 
although the language seems to be evolving fast, quality tools 
and libs are evolving excruciatingly slowly.

Re: Specify rhs at initialisation or assignment of typedef' d variable

[Stefan Koch via Digitalmars-d-learn]

On Monday, 31 July 2017 at 08:53:10 UTC, Cecil Ward wrote:

[ ... ]
I suspect that I am asking for something that literally makes 
no sense at all. I wanted to try and avoid opening the door to 
allowing the following kind of typing error now, eg

enum ip_address = 0x11223344;
[ ... ]


Please have a look at the bigEndian function and BigEndian struct 
in SQLite-D


https://github.com/UplinkCoder/sqlite-d/blob/master/source/utils.d

The point here is writing your own struct and using alias-this 
yourself.
Then you only need a function to produce constants of the right 
type.

Such a function should be trivially CTFEable

[Issue 17666] std.c.linux.socket has no replacement

[via Digitalmars-d-bugs]

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

Sebastiaan Koppe  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|m...@skoppe.eu

--

Re: Specify rhs at initialisation or assignment of typedef' d variable

[inevzxui via Digitalmars-d-learn]

On Monday, 31 July 2017 at 07:16:25 UTC, Cecil Ward wrote:
Say I have used Typedef! to create some new type and I declare 
a variable, constant or enum of that type. Is there a way that 
I can express a literal value on the rhs without having to use 
casts, as that seems to defeat the point of the nice type 
safety?


I may be asking for the impossible or _illogical_ here. In any 
case, I still get to keep the nice feature of not being able to 
mix up types with assignment from one variable to another.


Specific example is

mac_addr_48_t   my_mac_address = 0x112233445566uL;

Which now produces a compile time error after I changed to use 
an alias  = Typedef!uint64_t as opposed to just a straight 
alias = uint64_t earlier with no strong typing.


If struct + alias this is not strong enough the only solution is 
see is a helper template à la "octal" or "hexString", i.e a 
static cally checked string.

Re: The progress of D since 2013

[Eugene Wissner via Digitalmars-d]

On Monday, 31 July 2017 at 07:22:06 UTC, Maxim Fomin wrote:
4) What is the state of GDC/LDC? GDC team was actively working 
on including gdc in gcc project. Do gdc and ldc still pull D 
frontend, so there is essentially 1 frontend (where gdc and ldc 
frontends lag several versions behind) + 3 backends? I see in 
the changelog some dmd backend improvements. How the dmd 
backend is compared with C++/GDC/LDC? AFAIK in 2013 there was a 
tradeoff: either you use dmd with brand-new frontend or gdc/ldc 
where performance is comparable to gcc, but frontend lags 
behind. Is it still true?


It is still similar. LDC/GDC for performance and dmd for the 
latest version.
GDC is currently being updated to 2.072, but it still doesn't use 
the new frontend writen in D, but ports the frontend changes to 
the C++-frontend.

Re: Specify rhs at initialisation or assignment of typedef' d variable

[Cecil Ward via Digitalmars-d-learn]

On Monday, 31 July 2017 at 08:53:10 UTC, Cecil Ward wrote:

On Monday, 31 July 2017 at 07:50:57 UTC, inevzxui wrote:

[...]


I suspect that I am asking for something that literally makes 
no sense at all. I wanted to try and avoid opening the door to 
allowing the following kind of typing error now, eg

enum ip_address = 0x11223344;
mac_addr_48_t my_mac = cast(mac_addr_48_t) ip_address;
as if we are going to the bother of introducing strong type 
checking with Typedef! then the last thing I want to do is 
encourage is a proliferation of casts.


[...]


Actually, it would be really nice to have some kind of safe 
initialisation helper that checks value ranges, as in this 
particular case I need to make sure that the literal 64-bit value 
fits in 48 bits.

Taking the address of an eponymous template

[Arafel via Digitalmars-d-learn]

Hi!

I want to create a delegate out of a method that happens to be an 
eponymous (nested) template, like this:


```
class C {
void foo() {}
void bar(string S)() { }
template baz(string S) {
void baz()() {
}
}
}

void main() {
C c = new C();
void delegate() aFoo = 
void delegate() aBar = !"a";
void delegate() aBaz = !"a"; // This doesn't compile.
}
```

If I try !"a".baz it doesn't work either (I get a different error 
message.


Do you know if this works (and if so, what should I do), or if it's 
supposed to?


Of course in this case I don't need to use an eponymous template at all, 
bit it's just a simplification to try to get everything else out of the 
way...


In case anyone is interested, the real case is something more like this:

```
class C {
template baz(args...) if (someCondition!args) {
void baz(this T) {
}
}
}
```

As far as I know, that's the only way to combine a "this" template 
parameter with variadic template parameters.


As usual, thanks for the great support, D hast got a great community!

P.S.: When the function inside the eponymous template is not templated 
itself, then it does work:


´´´
class C {
template baz(string S) {
void baz() {
}
}
}

void main() {
C c = new C();
auto aBaZ = !"a";
}
´´´

Re: How to test tuple in chain

[inevzxui via Digitalmars-d-learn]

On Monday, 31 July 2017 at 12:23:02 UTC, closescreen wrote:

I read my message. Sorry for my poor english and typos.


use res[0] and res[1] to get res.status and the res.output.

[Issue 16744] We should have a TypeOf template so that typeof can be used with templates like staticMap

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/d39cc3ff43501a753c14dc1d7461603dc77640ba
Fix Issue 16744: Add Typeof

https://github.com/dlang/phobos/commit/674f87e061ad55a2a2d312b099d32e58404d92ab
Merge pull request #5662 from dlang/MetaLang-patch-1-3

Fix Issue 16744: Add Typeof
merged-on-behalf-of: Stefan Koch 

--

Re: Compile Time versus Run Time

[ag0aep6g via Digitalmars-d-learn]

On 07/31/2017 05:43 PM, Martin Tschierschke wrote:
As a rookie in D programming I try to understand the power of templated 
functions with compile time parameters. With DMD 2.074 a compile time 
format

(auto output = format!("Print this %s")(var);)

was introduced, now we all know that very many of this format strings 
are immutable, so wouldn't it be cool to automatically detect this and 
use the compile time version?


Without the need to think about it and to use an other syntax?
Is this theoretically possible?


Kinda-sorta, but not really and you have to use the template syntax:


string format(alias fmt, A ...)(A args)
{
import std.format: sformat = format;
static if (__traits(compiles, { enum e = fmt; }))
return sformat!("(CT) " ~ fmt)(args);
else
return sformat("(RT) " ~ fmt, args);
}

void main()
{
import std.stdio: readln, writeln;

// CT
writeln(format!"Print this %s"(42));

// RT
auto fmt = readln();
writeln(format!fmt(42));
// Can't call it like this: format!(readln())(42);

// also still RT
auto fmt2 = "Print this %s";
writeln(format!fmt2(42));

// (somewhat surprisingly) CT
immutable fmt3 = "Print this %s";
writeln(format!fmt3(42));
}

Re: Compile Time versus Run Time

[Martin Tschierschke via Digitalmars-d-learn]

On Monday, 31 July 2017 at 15:57:28 UTC, Anonymouse wrote:

On Monday, 31 July 2017 at 15:46:47 UTC, inevzxui wrote:
On Monday, 31 July 2017 at 15:43:21 UTC, Martin Tschierschke 
wrote:

[...]
But the parameters are not checked at compile-time unless you 
specifically pass the pattern string as a template parameter. I 
think its immutability implicitly converting it into a template 
parameter is what's what he's talking about.


import std.stdio;

void main(string[] args)
{
writefln!"%s"(); // compile-time assert
writefln("%s");  // runtime exception, though everything 
needed for a compile-time assert was inferable during 
compilation

}


This is exactly the "use case", I thought about: How to avoid 
runtime errors, if at compile time the problem might be detected.

Re: all OS functions should be "nothrow @trusted @nogc"

[Vladimir Panteleev via Digitalmars-d]

On Monday, 31 July 2017 at 14:51:22 UTC, Timon Gehr wrote:

On 31.07.2017 16:15, Shachar Shemesh wrote:
That's fine, but since, according to the logic presented here, 
no OS function can ever be @safe,


This is actually not true. Vladimir was just pointing out a 
complication of which to be aware. Are you arguing against 
applying due diligence when specifying library interfaces?


Indeed. @safe is not a sandbox, there is no need to actually go 
to extreme measures to safeguard against potential changes beyond 
our control; just something to keep in mind.

Re: covered - processes output of code coverage analysis performed by the D programming language compiler

[jmh530 via Digitalmars-d-announce]

On Monday, 31 July 2017 at 13:06:44 UTC, Anton Fediushin wrote:
Hello! I am glad to announce a new command-line tool which 
should make development

 a little easier.



You could add a mixin template that injects the 
"version(D_Coverage)" code.

Compile Time versus Run Time

[Martin Tschierschke via Digitalmars-d-learn]

As a rookie in D programming I try to understand the power of 
templated functions with compile time parameters. With DMD 2.074 
a compile time format

(auto output = format!("Print this %s")(var);)

was introduced, now we all know that very many of this format 
strings are immutable, so wouldn't it be cool to automatically 
detect this and use the compile time version?


Without the need to think about it and to use an other syntax?
Is this theoretically possible?

Regards mt.

Re: Compile Time versus Run Time

[inevzxui via Digitalmars-d-learn]

On Monday, 31 July 2017 at 15:43:21 UTC, Martin Tschierschke 
wrote:
As a rookie in D programming I try to understand the power of 
templated functions with compile time parameters. With DMD 
2.074 a compile time format

(auto output = format!("Print this %s")(var);)

was introduced, now we all know that very many of this format 
strings are immutable, so wouldn't it be cool to automatically 
detect this and use the compile time version?


Without the need to think about it and to use an other syntax?
Is this theoretically possible?

Regards mt.


That's what writeln() does. The format is detected for each 
element of the variadic.

Re: Compile Time versus Run Time

[Marco Leise via Digitalmars-d-learn]

Am Mon, 31 Jul 2017 15:43:21 +
schrieb Martin Tschierschke :

> As a rookie in D programming I try to understand the power of 
> templated functions with compile time parameters. With DMD 2.074 
> a compile time format
> (auto output = format!("Print this %s")(var);)
> 
> was introduced, now we all know that very many of this format 
> strings are immutable, so wouldn't it be cool to automatically 
> detect this and use the compile time version?
> 
> Without the need to think about it and to use an other syntax?
> Is this theoretically possible?

I see no way to accomplish this. For the compiler to see the
contents of the format string it needs to be a template
argument and as soon as you want to also allow runtime values
to be accepted there, you need to use an alias, which in turn
precludes the use of function results or concatenation.
Believe me I've spent quite some time on trying something like
this for format strings.
 
> Regards mt.

As far as using template arguments for code optimizations go, I
know that at least GCC will turn runtime arguments into
template arguments of sorts internally, thereby creating
duplicates of the function with one or more arguments
optimized out.
On the other hand, you don't want to drive this too far. While
it is nice to have compile-time checks, templates are actually
troublesome on some levels. For example, the duplicated code
makes it hard to cache the formatting function in the CPU and
when writing libraries you always have to provide the full
implementation that will get linked into the host application,
which is a concern under certain licensing schemes.
The benefits of shared libraries, like loading the code into
memory once and use it by multiple processes or fixing
security issues in one central place and have all programs use
the new code without recompilation are also void. I.e. without
template arguments, `format()` and all its dependencies
(templates as well as regular functions) are compiled right
into the Phobos shared library for all programs to use. If
there is a security issue, it can be replaced with a patched
version. Now with template arguments, `format!()` is compiled
into each Dlang application multiple times for each format
string and security fixes cannot be applied without
recompiling them all.

-- 
Marco

[Issue 12260] Improve error of std.stdio.readf when involving whitespace

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/afc732661a5cbdd69b22d5bffa57fddab76172ad
Fix Issue 12260 - Improve error of std.stdio.readf when involving whitespace

https://github.com/dlang/phobos/commit/63de27b5308b6bdb4e0489cc53e87e603f0c95cf
Merge pull request #5591 from RazvanN7/Issue_12260

Fix Issue 12260 - Improve error of std.stdio.readf when involving whitespace
merged-on-behalf-of: Andrei Alexandrescu 

--

Re: DMD library available as DUB package

[Johan Engelen via Digitalmars-d-announce]

On Sunday, 30 July 2017 at 23:41:40 UTC, Johan Engelen wrote:

On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote:
During the dconf hackathon I set out to create a DUB package 
for DMD to be used as a library. This has finally been merged 
[1] and is available here [2]. It contains the lexer and the 
parser.


This is great news of course!

But I have some bad news ;-)
Now that the Lexer nicely separated, it is very easy for me to 
testdrive libFuzzer+AddressSanitizer on the lexer and... Expect 
many bug reports in the next days.


OK, this wasn't entirely fair.
1. I didn't read the API: the buffer needs to be null-terminated.
2. With a fix [1] to prevent reading beyond the input buffer, I 
have yet to find a new bug.


The fuzzer is running now... I wonder how long it takes to find 
the next bug, if any.


-Johan

[1] https://github.com/dlang/dmd/pull/7050

Re: Compile Time versus Run Time

[Anonymouse via Digitalmars-d-learn]

On Monday, 31 July 2017 at 15:46:47 UTC, inevzxui wrote:
On Monday, 31 July 2017 at 15:43:21 UTC, Martin Tschierschke 
wrote:
As a rookie in D programming I try to understand the power of 
templated functions with compile time parameters. With DMD 
2.074 a compile time format

(auto output = format!("Print this %s")(var);)

was introduced, now we all know that very many of this format 
strings are immutable, so wouldn't it be cool to automatically 
detect this and use the compile time version?


Without the need to think about it and to use an other syntax?
Is this theoretically possible?

Regards mt.


That's what writeln() does. The format is detected for each 
element of the variadic.


But the parameters are not checked at compile-time unless you 
specifically pass the pattern string as a template parameter. I 
think its immutability implicitly converting it into a template 
parameter is what's what he's talking about.


import std.stdio;

void main(string[] args)
{
writefln!"%s"(); // compile-time assert
writefln("%s");  // runtime exception, though everything 
needed for a compile-time assert was inferable during compilation

}

covered - processes output of code coverage analysis performed by the D programming language compiler

[Anton Fediushin via Digitalmars-d-announce]

Hello! I am glad to announce a new command-line tool which should 
make development

 a little easier.

Program, compiled with `-cov` switch, generates *.lst files. They 
contain program source, number of executions of each line and 
total code coverage of the file.
Those files are quite useful for small programs/libraries, but 
not that useful for big ones.


Covered processes *.lst files, and reports only useful 
information. Behaviour can be changed with command-line options:


  '--coverage' reports code coverage in % for each file.
  '--blame' shows list of files ordered by code coverage.
  '--average' reports average code coverage for files.

Covered works for lists of files and directories, so '--blame' 
can be used to find less covered files, and '--average' to 
compute average code coverage of the project.


More documentation is available on project page on GitHub: 
https://github.com/ohdatboi/covered
It is also added to DUB package registry: 
http://code.dlang.org/packages/covered


Also, I am looking for huge projects, so I can test covered on 
them. Reply here or start an issue on GitHub if you know one.

Re: It makes me sick!

[Grander via Digitalmars-d-learn]

On Saturday, 29 July 2017 at 21:52:38 UTC, FoxyBrown wrote:

On Saturday, 29 July 2017 at 21:48:09 UTC, Timon Gehr wrote:

On 28.07.2017 23:30, FoxyBrown wrote:


because you didn't want to spend 10 minutes to fix a program.


You need to realize that the same thing applies to you. There 
is no "us" vs "you". I.e. if you know it to only be 10 minutes 
of work, why don't you just fix it yourself? Mike currently 
has as many commits in DMD as you do, and he is already busy 
contributing in other ways.




EXACTLY! Your problem is that you are taking the you vs me too 
literal. I am talking about a mentality people have that think 
that them saving 10 minutes by not implementing something that 
will save 10 hours(low estimate) for everyone else is a good 
thing and criticize people when they say there is a better and 
try to condemn them and continue the status quo that wastes 
more time.


You should probably start to think about the real reason behind 
all this.
The thing you complain about is DMD being flexible, like any 
other compiler is too.


Try blundering around with the 'include' folder of your favorite 
C compiler,
but don't blame me if nothing works any any more, because your 
compiler uses that directory as-is as its include directory and 
does not have an internal whitelist of the files to expect there.


The next question is, would like DMD to require a whitelist for 
every single include directory, which means forcing each dev to 
write or generate a file list of his library directories?

Re: all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

On 31/07/17 17:08, Timon Gehr wrote:

On 31.07.2017 15:56, Shachar Shemesh wrote:


One of the things that really bother me with the D community is the 
"100% or nothing" approach.

...


Personally, I'm more bothered by this kind of lazy argument that sounds 
good but has no substance.


System programming is, by definition, an exercise in juggling 
conflicting aims. The more absolute the language, the less useful it 
is for performing real life tasks.


Why do you think @trusted exists?


That's fine, but since, according to the logic presented here, no OS 
function can ever be @safe, then all code calling such a function can't 
be @safe either. At this point, half your code, give or take, is 
@trusted. That's the point you give up, and just write everything as 
@system.


And what we have here is that you started out trying to be 100% pure 
(and, in this case, there is no problem with current code, only 
*hypothetical* future changes), and end up not getting any protection 
from @safe at all.


There is a proverb in Hebrew that says:
תפסת מרובה, לא תפסת.
Try to grab too much, and you end up holding nothing.

Shachar

Re: The progress of D since 2013

[Guillaume Piolat via Digitalmars-d]

On Monday, 31 July 2017 at 07:22:06 UTC, Maxim Fomin wrote:

Hi!

Good to see D is progressing! I was active forum and bugzilla 
participant in 2011-2013. Since then I have not touched D.


Welcome back :)

3) What is the state of GC? AFAIK there were some improvements 
for GC sent as GSOC projects but they were not added in 2013. I 
see in the changelog that there are some improvements in speed 
and configuration support was added.


"GC" is still the thing that come up as objection from native 
programmers. Recently the perception shifted a bit thanks to the 
D blog (and indeed most users have no irredeemable problems with 
it).


-profile=gc and @nogc makes GC avoidance much simpler than in the 
past.



4) What is the state of GDC/LDC? GDC team was actively working 
on including gdc in gcc project. Do gdc and ldc still pull D 
frontend, so there is essentially 1 frontend (where gdc and ldc 
frontends lag several versions behind) + 3 backends? I see in 
the changelog some dmd backend improvements. How the dmd 
backend is compared with C++/GDC/LDC? AFAIK in 2013 there was a 
tradeoff: either you use dmd with brand-new frontend or gdc/ldc 
where performance is comparable to gcc, but frontend lags 
behind. Is it still true?


LDC got Win32 and Win64 backends. DMD still compiles faster, but 
generates slower code (about 2x).


6) I don't see any significant changes in D core from dlang 
documentation (except those mentioned in changelog for 
2014-2017). Is is true or is the official spec as usual delayed 
:)? Is dlang spec fully and frequently updated or is it sparse 
as in the past? Is TDPL book still relevant?


There are several relevant books to own now.



9) Does D gains popularity?


Yes, from all directions. More and more risk-adverse programmers 
are considering using it, it's not exclusivey early adopters 
anymore.



10) Anything else 2013 D user must know? :) I don't ask about 
Phobos because according to the changelog the progress is 
enormous, incremential and targets several directions - I doubt 
it can be easily summarised...


Use DUB, it makes everyone's life easier.
http://code.dlang.org/

Re: How to test tuple in chain

[closescreen via Digitalmars-d-learn]

I read my message. Sorry for my poor english and typos.

Re: How do you use D?

[Nicholas Wilson via Digitalmars-d]

On Sunday, 30 July 2017 at 01:53:15 UTC, Zwargh wrote:
I am using D to develop a system for rational drug design. The 
main application for D is for protein 3D structure prediction 
and statistical analysis using Differential Geometry and Knot 
Theory.


Cool! Are you considered using dcompute for this once it has 
matured a bit?

Re: [OT] Generative C++

[Joakim via Digitalmars-d]

On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote:
Someone made an interesting proposal to C++: 
https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf


Thoughts?


Thanks for mentioning this: I just watched the video linked from 
his blog post, but didn't read the paper.


It's an elegant design, but strikes me as a bad idea for the 
language. This is the seductive kind of architecture produced by 
architecture astronauts, because it solves real needs, ie 
interface, value, etc. as "keywords," but generalizes it in such 
a way that it's very customizable (as opposed to architecture 
that shuffles codes around and solves no real need).


To start off, this basically will lead to a ton of metaclass 
"keywords" added to every codebase, which simplifies how much 
code is written but still requires the programmer to understand 
how the underlying metaclass works.  It balkanizes the language 
further, because every codebase will have their own metaclasses, 
possibly even naming the exact same metaclass implementation 
differently.  You could work around the syntax problem of a 
keyword explosion a bit by making coders type 
"MetaClass::interface" instead of just "interface", but that 
still leaves the other issues.


The job of language designers like Sutter is to find abstractions 
that would make programmers' lives easier and bake them into the 
language.  Sometimes, the way people use these abstractions is so 
varied that you need what he calls "encapsulated abstractions" or 
"user-written extensions" like functions, classes, or modules, on 
one of his last slides with 7 mins. to go.


Other times, there are some really common ways to use the 
abstraction and you're better off adding the most common 
customization of that abstraction to the language with a 
particular keyword, and saying you can't do all those other niche 
customizations.  That is the job of the language designer, and it 
is as important what he excludes as much as what he includes.


I think he'd be better off just adding keywords like "interface" 
for the metaclasses he thinks are really common, rather than 
allowing programmers to define it any way they want.  However, 
this is an empirical question: how widely do C++ programmers need 
to customize their "meta-classes" as they're implemented now, and 
is it worth the additional keywords that noobs would see 
sprinkled all over codebases and get confused by?  I don't write 
C++, so I can't definitely answer this question, but my guess is 
that it isn't worth it.


If he's right that C++ use is so balkanized, this will simplify 
some code but further balkanize the language.  That might be 
worth it for them, but rather than simplifying the language, it 
makes it more powerful and more complex, heading higher up into 
the hills rather than the lower ground he claims to be heading 
for.

Re: The progress of D since 2013

[kinke via Digitalmars-d]

Hi,

On Monday, 31 July 2017 at 07:22:06 UTC, Maxim Fomin wrote:

1) Support of linking in win64?


LDC: MSVC targets, both 32 and 64 bits, fully supported since a 
year or so. Requires Visual Studio 2015+.


2) What is the support of other platforms? AFAIK there was 
progress on Android.


LDC: Quite good. All tests pass on Android, see Joakim Noah's 
work, but currently requires a tiny LLVM patch. That will be 
taken care of by LDC 1.4. All tests also passing on ARMv6+ on 
Linux. A guy got a vibe.d app to work successfully on an ARMv5 
industrial controller. AArch64 support is underway...


4) What is the state of GDC/LDC? GDC team was actively working 
on including gdc in gcc project.


And they succeeded, it has recently been accepted.

Do gdc and ldc still pull D frontend, so there is essentially 1 
frontend (where gdc and ldc frontends lag several versions 
behind) + 3 backends?


More or less. LDC uses a slightly modified D front-end (yep, 
that's been officially converted to D in case you missed it), 
whereas Iain/GDC still uses a C++ one, with backports from newer 
D versions.
The lag isn't that bad for LDC; LDC 1.3 uses the 2.073.2 
front-end, current master the 2.074.1 one, and there's a WIP PR 
for 2.075.0, which already compiles.

Re: The progress of D since 2013

[inevzxui via Digitalmars-d]

On Monday, 31 July 2017 at 07:22:06 UTC, Maxim Fomin wrote:

Hi!

Good to see D is progressing! I was active forum and bugzilla 
participant in 2011-2013. Since then I have not touched D.


[...]

10) Anything else 2013 D user must know? :)


Yes, bug 314 has been fixed !
https://issues.dlang.org/show_bug.cgi?id=314

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 31.07.2017 16:15, Shachar Shemesh wrote:


Why do you think @trusted exists?


That's fine, but since, according to the logic presented here, no OS 
function can ever be @safe,


This is actually not true. Vladimir was just pointing out a complication 
of which to be aware. Are you arguing against applying due diligence 
when specifying library interfaces?




There is a proverb in Hebrew that says:
תפסת מרובה, לא תפסת.
Try to grab too much, and you end up holding nothing. 


I.e. if you mark too many functions as @trusted, you will have no memory 
safety.

Re: Taking the address of an eponymous template

[ag0aep6g via Digitalmars-d-learn]

On 07/31/2017 01:59 PM, Arafel wrote:

On 07/31/2017 12:14 PM, ag0aep6g wrote:

[...]

 > You'd have to instantiate the inner template, too. Something like
 > `!"a".baz!()`, but that doesn't work. I don't know how you could
 > make it work.
 >
I tried this as well, and couldn't make it work either. Do you know if 
it's supposed to work? I mean, do the spec mention this?


I don't think that exact syntax is supposed to work. When you 
instantiate a non-eponymous template, you get a template instantiation 
with members which you can access. With an eponymous template, you get 
the eponymous member, nothing else. There's no way to get the members of 
the template by name then.


Ideally, I'd say this would work: `!"a"!()`. But that's not valid 
syntax.


With a free template, you can make an alias of the first instantiation 
and then use that to instantiate the second time:



template baz(string S)
{
void baz()() {}
}

alias baz1 = baz!"a";
void function() aBaz = !();


Could this work when the template is a class member?


class C
{
template baz(string S)
{
void baz()() {}
}
}

void main()
{
C c = new C();
alias baz1 = c.baz!"a";
// void delegate() aBaz = !(); // doesn't work
pragma(msg, typeof(!()));
// void function() pure nothrow @nogc @safe
}


We see that `!()` is a function pointer, not a delegate. Looks like 
`this` got lost along the way. No idea if this is a bug or expected.


It might be possible to hack around the issue by building the delegate 
manually:



C c = new C();
alias baz1 = c.baz!"a";
void delegate() aBaz;
aBaz.funcptr = !();
aBaz.ptr = cast(void*) c;


That *seems* to work, but I'm not at all sure if it's actually correct.

[...]
OK, not directly with the "this" parameter... those you have to include 
explicitly. However, this seems to be an unrelated problem: the "this T" 
parameter seems to be only automatically deducted during function calls. 
Even this doesn't work:


```
class A {
 template foo(this T) {
 void bar() {
 import std.stdio;
 writeln(typeid(T));
 }
 }
}

void main() {
 A a = new A();
 a.foo.bar();
}
```

But I think that's a completely separate issue (would that be a bug, 
btw?) It's of course a trivial issue here, but it's just an example.


What use is it to allow "this T" parameters in raw template declarations 
if they are not going to be automatically filled?


I don't think it's a bug. The spec says that "TemplateThisParameters are 
used in member function templates" [1]. And it only shows the feature 
working with calls. So that's apparently the only case that has been 
considered and is expected to work.


It might be worthwhile to explore if the feature can be expanded beyond 
calls. No idea what the difficulties would be.


[...]

 > So how about a function literal:
 >
 >  void delegate() aBaz = () => c.baz!(int, float)();
 >
Yeah, that's the solution I was thinking about, but I don't know how 
much of a performance hit the extra function call would be... would the 
function literal extra indirection layer be eventually optimised out?


I don't know.


[1] https://dlang.org/spec/template.html#template_this_parameter

Re: D Debug101

[Kagamin via Digitalmars-d-learn]

gdb wants dwarf debug info, windows uses codeview.

Re: Is std.xml seriously broken, or is it me?

[Kagamin via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 03:16:35 UTC, Mike wrote:

It appears `onStartTag` does not handle the root element.


Looks like a bug. Until the module is replaced, bug reports are 
still accepted for it.

Re: Taking the address of an eponymous template

[Arafel via Digitalmars-d-learn]

On 07/31/2017 12:14 PM, ag0aep6g wrote:

>
> You'd have to instantiate the inner template, too. Something like
> `!"a".baz!()`, but that doesn't work. I don't know how you could
> make it work.
>
I tried this as well, and couldn't make it work either. Do you know if 
it's supposed to work? I mean, do the spec mention this?


The funny part is that id does work with nested, non-eponymous templates:

```
class A {
template foo(string S) {
void bar()() {
import std.stdio;
writeln ("I'm bar");
}
void baz(this T)() {
import std.stdio;
writeln ("I'm baz at class ", typeid(T));
}
}
}

class B : A {
}

void main() {
A a = new A();
B b = new B();
void delegate() aBar = !("a").bar!(); aBar();
void delegate() aBaz = !("a").baz!(typeof (a)); aBaz();
void delegate() bBaz = !("a").baz!(typeof (b)); bBaz();
}
```

OK, not directly with the "this" parameter... those you have to include 
explicitly. However, this seems to be an unrelated problem: the "this T" 
parameter seems to be only automatically deducted during function calls. 
Even this doesn't work:


```
class A {
template foo(this T) {
void bar() {
import std.stdio;
writeln(typeid(T));
}
}
}

void main() {
A a = new A();
a.foo.bar();
}
```

But I think that's a completely separate issue (would that be a bug, 
btw?) It's of course a trivial issue here, but it's just an example.


What use is it to allow "this T" parameters in raw template declarations 
if they are not going to be automatically filled?


>
> (Assuming the inner baz is supposed to be `void baz(this T)() {}`.)
>
Sure :-)

> You'd still have to instantiate the inner baz in order to get a delegate
> of it. But even if we figured out how to do that, my guess is you don't
> want to specify `this T` explicitly.
>
> So how about a function literal:
>
>  void delegate() aBaz = () => c.baz!(int, float)();
>
Yeah, that's the solution I was thinking about, but I don't know how 
much of a performance hit the extra function call would be... would the 
function literal extra indirection layer be eventually optimised out?


> That's right if you want to pass `args` explicitly, but `this`
> implicitly. If specifying `args` via IFTI is an option, then this works,
> too:
>
> 
> class C {
>  void baz(this T, args...)(args) {}
> }
>
> void main() {
>  C c = new C();
>  void delegate() aBaz = () => c.baz(1, 2.3, "four");
> }
> 
>
> A function literal again, because you have to call baz in order to
> instantiate it (or you have specify `this T` and `args` explicitly). But
> you can't get a delegate from a call.
This wouldn't work in my case because the arguments ("args") are string 
themselves, so the function call needs to look like:


c.baz!("one","two");

and not:

c.baz("one","two");

The reasons for that are a bit more complex, but let's say that in this 
case I need the strings to be in the template parameters, I use those 
strings to create an AliasSeq of values of different types that is then 
sent to a "proper" variadic templated function.


Off topic, if anyone knows how to create a va_list dynamically, that 
would save me a lot of problems!!

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 31.07.2017 15:56, Shachar Shemesh wrote:


One of the things that really bother me with the D community is the 
"100% or nothing" approach.

...


Personally, I'm more bothered by this kind of lazy argument that sounds 
good but has no substance.


System programming is, by definition, an exercise in juggling 
conflicting aims. The more absolute the language, the less useful it is 
for performing real life tasks.


Why do you think @trusted exists?

How to test tuple in chain

[closescreen via Digitalmars-d-learn]

Hello!

If I want testing tuple member in functional manner, what I shoul 
do?


Example:


"ls -l".executeShell returns me tuple (int "status", string 
"output")


I want write somthing like:

"ls -l".executeShell.smthTestingOperation!"Error: bad status."( 
res => res.status==0 ).output.writeln;


(where "smthTestingOperation" - is function which I want to find 
in std )

[Issue 6384] std.traits.isComparable

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/24bfb294b7523307d10aaaf41ad2021c6cb38501
Fix Issue 6384 - add std.traits.isComparable

https://github.com/dlang/phobos/commit/a6ef870042c2c569c31173645f01a2ec682fc283
Merge pull request #5566 from RazvanN7/Issue_6384

Fix Issue 6384 - add std.traits.isComparable
merged-on-behalf-of: Andrei Alexandrescu 

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:

On 7/26/2017 6:29 AM, Kagamin wrote:

Should we still try to mark them safe at all?


Marking ones that are safe with @safe is fine. OS APIs pretty 
much never change.


Sometimes operating systems add new flags to their API which 
change how some values are interpreted. Some API functions may, 
for example, normally take a pointer to a such-and-such struct, 
but if a certain flag is specified, the parameter is instead 
interpreted as a pointer to a different data type. That would be 
one case where an API call becomes un-@safe due to the addition 
of a flag.

Re: all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

On 31/07/17 16:33, Vladimir Panteleev wrote:

On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:

On 7/26/2017 6:29 AM, Kagamin wrote:

Should we still try to mark them safe at all?


Marking ones that are safe with @safe is fine. OS APIs pretty much 
never change.


Sometimes operating systems add new flags to their API which change how 
some values are interpreted. Some API functions may, for example, 
normally take a pointer to a such-and-such struct, but if a certain flag 
is specified, the parameter is instead interpreted as a pointer to a 
different data type. That would be one case where an API call becomes 
un-@safe due to the addition of a flag.




One of the things that really bother me with the D community is the 
"100% or nothing" approach.


System programming is, by definition, an exercise in juggling 
conflicting aims. The more absolute the language, the less useful it is 
for performing real life tasks.


Shachar

[Issue 12260] Improve error of std.stdio.readf when involving whitespace

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17708

--

[Issue 17708] New: Escape control characters in std.conv.to error messages

[via Digitalmars-d-bugs]

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

  Issue ID: 17708
   Summary: Escape control characters in std.conv.to error
messages
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

Currently this program:

/ test.d 
import std.conv;

void main()
{
to!int("\r");
}
/

will produce output which looks like this in a terminal:

' when converting from type string to type intbin/../phobos/std/conv.d(2168):
Unexpected '

??:? pure @safe int std.conv.parse!(int, immutable(char)[]).parse(ref
immutable(char)[]) [0x4331de]
??:? pure @safe int std.conv.toImpl!(int,
immutable(char)[]).toImpl(immutable(char)[]) [0x436a70]
??:? pure @safe int
std.conv.to!(int).to!(immutable(char)[]).to(immutable(char)[]) [0x432a83]
??:? _Dmain [0x432a5d]

The error message appears malformed.

std.conv.to should escape whitespace / control / non-printable characters in
its error messages. Perhaps the existing functionality in std.conv / std.format
can be reused: format!"%(%s%)"(c.only) will already correctly escape such
characters.

See discussion in https://github.com/dlang/phobos/pull/5591 (which fixed this
issue specifically for the newline character only) for more details.

--

[Issue 17708] Escape control characters in std.conv.to error messages

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12260

--

Re: gtk arch issues

[Mike Wey via Digitalmars-d-learn]

On 31-07-17 19:16, Johnson Jones wrote:

how does one allow both gtk x86 and x64 to work side by side seamlessly?

I installed x64 first and it seems, because whatever is using the path 
to find the gtk runtime, it looks for that first even in x86 build.


Seems like gtkd's dll resolution is not very intelligent. While I could 
manually modify the path each time I switch archs, that seems pointless.


One of the problems in gtkd is that it has multiple places where it 
defines libgdk-3-0.dll.



I've tried modifying gdkD so that it uses versioning properly by 
searching for libgdk-3-0.dll and changing all to use an x86 or x64 when 
appropriate but that doesn't seem to help. Probably have to rebuild gtkD.


Anyways, doesn't seem to be a great solution ;/ Any ideas and maybe 
someone can add an issue to the github page to get this fixed? (I can't 
do it for a while because of other issues).




At startup GtkD searches the Path for "libgtk-3-0.dll", when it finds 
one it checks the architecture of the library. If it's the correct 
architecture it calls `SetDllDirectory` so that the directory with the 
correct architecture will be searched first by `LoadLibrary`.


If it's not the correct architecture it continues searching, if no 
library with the correct architecture is found, we rely on `LoadLibrary` 
to error out if the libraries are also not in the other locations 
searched by `LoadLibrary`.


--
Mike Wey

Re: gtk arch issues

[Mike Wey via Digitalmars-d-learn]

On 31-07-17 19:53, Johnson Jones wrote:

Also, why is gtkD even using gtksharp? That's for mono and .net!


We don't. only the (C) Gtk runtime is needed.

Where did you see gtksharp?

--
Mike Wey

[Issue 17707] New: unimported modules in libraries do not have their module constructors run

[via Digitalmars-d-bugs]

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

  Issue ID: 17707
   Summary: unimported modules in libraries do not have their
module constructors run
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

First with object files:

% ls
app.d foo.d
% cat app.d
void main() { import core.stdc.stdio; puts("and from here"); }
% cat foo.d
static this() { import core.stdc.stdio; puts("hello"); }
% dmd -c app.d foo.d
% ls
app.d app.o foo.d foo.o
% gcc app.o foo.o -lphobos2
% ./a.out
hello
and from here

Everything looks fine there

% ar rcs foo.a foo.o
% gcc app.o foo.a -lphobos2
% ./a.out
and from here

the module constructor from foo.d has gone missing!

test on macOS and linux, with many different permutations. Splitting the object
file back out of the library makes it work again, so no information is lost.

On macOS it was easy to discover that the result of getsectbynamefromheader_64
for __DATA __minfodata is missing an entry for foo in the library case, but not
in the object case.

--

Re: newCTFE Status July 2017

[Marco Leise via Digitalmars-d]

Am Sun, 30 Jul 2017 14:44:07 +
schrieb Stefan Koch :

> On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
> > [ ... ]  
> 
> Hi Guys,
> 
> After getting the brainfuck to D transcompiler to work.
> I now made it's output compatible with newCTFE.
> 
> See it here:
> https://gist.github.com/UplinkCoder/002b31572073798897552af4e8de2024
> 
> Unfortunately the above code does seem to get mis-compiled,
> As it does not output Hello World, but rather:
> 

> 

Funny, it is working and mis-compiling at the same time.
I figure with such complex code, it is working if it ends up
*printing anything* at all and not segfaulting. :)

-- 
Marco

[Issue 16744] We should have a TypeOf template so that typeof can be used with templates like staticMap

[via Digitalmars-d-bugs]

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

--- Comment #11 from github-bugzi...@puremagic.com ---
Commit pushed to revert-5662-MetaLang-patch-1-3 at
https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/be351ebe20df55b72e7441e43b84cfacee42f8ea
Revert "Fix Issue 16744: Add Typeof"

--

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Jesse Phillips via Digitalmars-d]

On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:

On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
* Remove the whole program defaults, I'm ok with it being 
changed in a re-implementation of the runtime (like the 
embedded example), we just don't need the extra confusion 
within user code.


The program defaults are there to make @safe by default a 
thing, and betterC by default a thing, which are covered in the 
_three Primary points_ of the semesters Vision document[1]. 
These would not normally be set (i.e. opt in).


I read that as more, Improve Druntime and phobos's us of @safe so 
that it becomes more usable.


* Specifying inferred needs to be within druntime only, and 
thus may not need to exist.


I think there is usefulness in having it, particularly as the 
meta-default (defaultAttributeSet). Walter has ben pushing for 
some time to infer attributes by default. This would provide a 
directive for the compiler to do so. Please elaborate.


I don't expect inference to happen outside templates. Besides if 
the compiler infers the appropriate attributes by default, isn't 
1. a default attribute redundant and 2. specifying inference 
redundant as the compiler defaults to inferring?


* I'm concerned user defined attributes could define a 
"defaults" for functions.


you mean user UDAs (if not please explain)? the default 
application of UDA is for core attributes only.


Yes I'm User's UDA (user defined attributes). I expected it 
wouldn't apply outside the context of core.attributes.



The compiler will default functions to the first value of the 
enum [for my example].


( That would provide a pessimistic default and debates the 
ability for the compiler to infer)


Yes, just throwing in an example structure and why I mentioned 
[for my example]. But as said earlier infer and default are at 
odds.



[So on and so forth]


Thanks for your suggestions.

[1]: https://wiki.dlang.org/Vision/2017H2

Re: gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

On Monday, 31 July 2017 at 17:16:32 UTC, Johnson Jones wrote:
how does one allow both gtk x86 and x64 to work side by side 
seamlessly?


I installed x64 first and it seems, because whatever is using 
the path to find the gtk runtime, it looks for that first even 
in x86 build.


Seems like gtkd's dll resolution is not very intelligent. While 
I could manually modify the path each time I switch archs, that 
seems pointless.


One of the problems in gtkd is that it has multiple places 
where it defines libgdk-3-0.dll.



I've tried modifying gdkD so that it uses versioning properly 
by searching for libgdk-3-0.dll and changing all to use an x86 
or x64 when appropriate but that doesn't seem to help. Probably 
have to rebuild gtkD.


Anyways, doesn't seem to be a great solution ;/ Any ideas and 
maybe someone can add an issue to the github page to get this 
fixed? (I can't do it for a while because of other issues).


I fixed up gtkd so that it uses x86 and x64 versions of dlls but 
it doesn't seem to help with x64. I was able to get x86 to 
compile and run but x64 just loads then quits without any errors 
;/


C:\Program Files (x86)\GtkSharp\2.12\bin\libgdk_pixbuf-2.0-0.dll 
unloaded.
C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll 
unloaded.

C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgio-2.0-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libintl-8.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libglib-2.0-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgobject-2.0-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libpango-1.0-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded.

Best I can tell is that something is using the x86 verisons for 
some reason. Note that all those dll's should be x64 versions, 
but something outside of gtkD is loading them, I suspect it's Gtk 
itself, which would require proper versioning ;/ I replaced 
libgdk_pxbuf in gtkd to version it,


i.e.,

version (Windows)
version(X86)
		static immutable LIBRARY_GDKPIXBUF = 
["libgdk_pixbuf-2.0-0x86.dll"];

else
		static immutable LIBRARY_GDKPIXBUF = 
["libgdk_pixbuf-2.0-0x64.dll"];


and rebuilt, but it obviously using using that. It's probably a 
gtk-runtime dll that is using it that isn't versioned itself ;/


Of course, I want to be able to run my programs in x64 at some 
point so figuring out what is going on is important.


It would be lovely if people would get their act together so 
things would work properly ;/

Re: gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

On Monday, 31 July 2017 at 17:50:08 UTC, Johnson Jones wrote:

On Monday, 31 July 2017 at 17:16:32 UTC, Johnson Jones wrote:

[...]


I fixed up gtkd so that it uses x86 and x64 versions of dlls 
but it doesn't seem to help with x64. I was able to get x86 to 
compile and run but x64 just loads then quits without any 
errors ;/


[...]


Also, why is gtkD even using gtksharp? That's for mono and .net!

Dlang + compile-time contracts

[Marco Leise via Digitalmars-d]

Coming from D.learn where someone asked for some automatism to
turn runtime format strings to `format()` into the equivalent
`format!()` form automatically to benefit from compile-time
type checks I started wondering...

The OP wasn't looking for other benefits of the template
version other than argument checking and didn't consider the
downsides either. So maybe there is room for improvement using
runtime arguments.

So let's add some features:
1) compile-time "in" contract, run on the argument list
2) functionality to promote runtime arguments to compile-time


string format(string fmt)
in(ctfe) {
  // Test if argument 'fmt' is based off a compile-time
  // readable literal/enum/immutable
  static if (__traits(isCtfeConvertible, fmt))
  {
// Perform the actual promotion
enum ctfeFmt = __traits(ctfeConvert, fmt);
static assert(ctfeFmt == "%s", "fmt string is not '%s'");
  }
}
body
{
  return "...";
}


Note that this idea is based on existing technology in the
front-end. Compare how an alias can stand in for a CT or RT
argument at the same time:


void main()
{
const fmt1 = "%x";
auto fmt2 = "%s";
aliasTest!fmt1;
aliasTest!fmt2;
}

void aliasTest(alias fmt)()
{
import std.stdio;
static if (__traits(compiles, {enum ctfeFmt = fmt;}))
// "Promotion" to compile time value
enum output = "'fmt' is '" ~ fmt ~ "' at compile-time";
else
string output = "'fmt' is '" ~ fmt ~ "' at runtime";
writeln(output);
}


This prints:
'fmt' is '%x' at compile-time
'fmt' is '%s' at runtime

For technical reasons a compile-time "in" contract can not
work in nested functions so all the CTFE contracts need to be
on the top level, user facing code. That means in practice
when there are several formatting functions, they'd extract
the implementation of the compile-time contract into separate
functions. I have no idea how exactly that scales as the
`static if (__traits(isCtfeConvertible, …))` stuff has to
remain in the contract. (It's probably ok.)

Extending the CTFE promotion to any variables that can be
const-folded is not part of this idea as it leaves a lot of
fuzzyness in language specification documents and results in
code that produces errors in one compiler, but not in another.
Since some people will still find it beneficial it should be a
compiler vendor extension and print a warning only on contract
violations.



-- 
Marco

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Andrey via Digitalmars-d-announce]

On Monday, 31 July 2017 at 08:51:16 UTC, Mike wrote:

https://github.com/JinShil/svd_to_d

SVD_to_D is a command-line utility that generates D code from 
ARM Cortex-M SVD files.


[...]



Thanks for your work. Not many people in D community thinking 
about embedded one

gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

how does one allow both gtk x86 and x64 to work side by side 
seamlessly?


I installed x64 first and it seems, because whatever is using the 
path to find the gtk runtime, it looks for that first even in x86 
build.


Seems like gtkd's dll resolution is not very intelligent. While I 
could manually modify the path each time I switch archs, that 
seems pointless.


One of the problems in gtkd is that it has multiple places where 
it defines libgdk-3-0.dll.



I've tried modifying gdkD so that it uses versioning properly by 
searching for libgdk-3-0.dll and changing all to use an x86 or 
x64 when appropriate but that doesn't seem to help. Probably have 
to rebuild gtkD.


Anyways, doesn't seem to be a great solution ;/ Any ideas and 
maybe someone can add an issue to the github page to get this 
fixed? (I can't do it for a while because of other issues).

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Monday, 31 July 2017 at 17:58:56 UTC, Marco Leise wrote:

Am Sun, 30 Jul 2017 14:44:07 +
schrieb Stefan Koch :


On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
> [ ... ]

Hi Guys,

After getting the brainfuck to D transcompiler to work.
I now made it's output compatible with newCTFE.

See it here: 
https://gist.github.com/UplinkCoder/002b31572073798897552af4e8de2024


Unfortunately the above code does seem to get mis-compiled,
As it does not output Hello World, but rather:





Funny, it is working and mis-compiling at the same time.
I figure with such complex code, it is working if it ends up
*printing anything* at all and not segfaulting. :)


I fixed the bug which cause this to miscompile it works now at 
ctfe.

This code is not really that complex, it only looks confusing.
complex code uses slices  of struct-types and pointer-slicing and 
that stuff.

Re: D client for ROS

[Ali Çehreli via Digitalmars-d]

On 07/29/2017 03:21 AM, Johan Engelen wrote:

Hi all,
  Are there any robot folks out here that are working with ROS and would
be able to work on creating a D client library for it?

ROS is used a lot at our university and in robot research in general,
and most people use the C++ client (the main one, next to Python). In
arguing for teaching D at our university, it would help a lot if
students could use D with ROS.

Cheers,
  Johan

(fyi: I'm an assistent prof Robotics and Mechatronics and LDC developer)


Looks like you will have to make a robot to have it write the D client 
for ROS. :o)


Ali

Re: D client for ROS

[aberba via Digitalmars-d]

On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote:

Hi all,
  Are there any robot folks out here that are working with ROS 
and would be able to work on creating a D client library for it?


ROS is used a lot at our university and in robot research in 
general, and most people use the C++ client (the main one, next 
to Python). In arguing for teaching D at our university, it 
would help a lot if students could use D with ROS.


Cheers,
  Johan

(fyi: I'm an assistent prof Robotics and Mechatronics and LDC 
developer)


Mike as been doing some foundation work non ARM Cortex 
...microcontrollers... His work is closest I know of.

Re: D client for ROS

[Johan Engelen via Digitalmars-d]

On Monday, 31 July 2017 at 21:41:47 UTC, aberba wrote:

On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote:

Hi all,
  Are there any robot folks out here that are working with ROS 
and would be able to work on creating a D client library for 
it?


Mike as been doing some foundation work non ARM Cortex 
...microcontrollers... His work is closest I know of.


I know of Mike's work, but ROS is not only for embedded 
platforms. (in fact, I think the majority of people run ROS on 
unconstrained systems with Linux available)

Specify rhs at initialisation or assignment of typedef' d variable

[Cecil Ward via Digitalmars-d-learn]

Say I have used Typedef! to create some new type and I declare a 
variable, constant or enum of that type. Is there a way that I 
can express a literal value on the rhs without having to use 
casts, as that seems to defeat the point of the nice type safety?


I may be asking for the impossible or _illogical_ here. In any 
case, I still get to keep the nice feature of not being able to 
mix up types with assignment from one variable to another.


Specific example is

mac_addr_48_t   my_mac_address = 0x112233445566uL;

Which now produces a compile time error after I changed to use an 
alias  = Typedef!uint64_t as opposed to just a straight alias = 
uint64_t earlier with no strong typing.

[OT] uncovering x86 hardware bugs and unknown instructions by fuzzing.

[Guillaume Chatelet via Digitalmars-d]

Some people here might find this interesting:
https://github.com/xoreaxeaxeax/sandsifter

White paper here:
https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf

The progress of D since 2013

[Maxim Fomin via Digitalmars-d]

Hi!

Good to see D is progressing! I was active forum and bugzilla 
participant in 2011-2013. Since then I have not touched D.


What is the progress of D (2014-2017) in following dimensions:
1) Support of linking in win64? AFAIK Walter introduced win64 
support in circa 2012 which was the big progress. However, 
support for win64 linking was limited because dmd defaulted on 
old dmc linker, and Walter didn't plan to do anything with this.
2) What is the support of other platforms? AFAIK there was 
progress on Android. From my memory recollections, the full 
support of Android was expected at that time.
3) What is the state of GC? AFAIK there were some improvements 
for GC sent as GSOC projects but they were not added in 2013. I 
see in the changelog that there are some improvements in speed 
and configuration support was added.
4) What is the state of GDC/LDC? GDC team was actively working on 
including gdc in gcc project. Do gdc and ldc still pull D 
frontend, so there is essentially 1 frontend (where gdc and ldc 
frontends lag several versions behind) + 3 backends? I see in the 
changelog some dmd backend improvements. How the dmd backend is 
compared with C++/GDC/LDC? AFAIK in 2013 there was a tradeoff: 
either you use dmd with brand-new frontend or gdc/ldc where 
performance is comparable to gcc, but frontend lags behind. Is it 
still true?
5) What is the progress with CTFE? I see a lot of discussions in 
forum archive devoted to the development of CTFE. What is the 
summary of CTFE development in recent years?
6) I don't see any significant changes in D core from dlang 
documentation (except those mentioned in changelog for 
2014-2017). Is is true or is the official spec as usual delayed 
:)? Is dlang spec fully and frequently updated or is it sparse as 
in the past? Is TDPL book still relevant?
7) Is UDA still compile-time? Are there plans to make it also 
runtime?
8) What is the progress with shared and immutable? AFAIK the 
compiler support for shared was not complete and Phobos library 
itself was not 'immutable-' and 'shared-correct'.

9) Does D gains popularity?
10) Anything else 2013 D user must know? :) I don't ask about 
Phobos because according to the changelog the progress is 
enormous, incremential and targets several directions - I doubt 
it can be easily summarised...


Thanks!

Re: The progress of D since 2013

[rikki cattermole via Digitalmars-d]

On 31/07/2017 8:22 AM, Maxim Fomin wrote:

Hi!

Good to see D is progressing! I was active forum and bugzilla 
participant in 2011-2013. Since then I have not touched D.


What is the progress of D (2014-2017) in following dimensions:
1) Support of linking in win64? AFAIK Walter introduced win64 support in 
circa 2012 which was the big progress. However, support for win64 
linking was limited because dmd defaulted on old dmc linker, and Walter 
didn't plan to do anything with this.


Optlink is still the default. MSVC link can be used for both 32bit and 
64bit.


2) What is the support of other platforms? AFAIK there was progress on 
Android. From my memory recollections, the full support of Android was 
expected at that time.
3) What is the state of GC? AFAIK there were some improvements for GC 
sent as GSOC projects but they were not added in 2013. I see in the 
changelog that there are some improvements in speed and configuration 
support was added.
4) What is the state of GDC/LDC? GDC team was actively working on 
including gdc in gcc project. Do gdc and ldc still pull D frontend, so 
there is essentially 1 frontend (where gdc and ldc frontends lag several 
versions behind) + 3 backends? I see in the changelog some dmd backend 
improvements. How the dmd backend is compared with C++/GDC/LDC? AFAIK in 
2013 there was a tradeoff: either you use dmd with brand-new frontend or 
gdc/ldc where performance is comparable to gcc, but frontend lags 
behind. Is it still true?
5) What is the progress with CTFE? I see a lot of discussions in forum 
archive devoted to the development of CTFE. What is the summary of CTFE 
development in recent years?


New implementation by Stefan for the purposes of making it faster and 
cheaper.


6) I don't see any significant changes in D core from dlang 
documentation (except those mentioned in changelog for 2014-2017). Is is 
true or is the official spec as usual delayed :)? Is dlang spec fully 
and frequently updated or is it sparse as in the past? Is TDPL book 
still relevant?

7) Is UDA still compile-time? Are there plans to make it also runtime?


No runtime reflection has been added during this period (unfortunately).

8) What is the progress with shared and immutable? AFAIK the compiler 
support for shared was not complete and Phobos library itself was not 
'immutable-' and 'shared-correct'.

9) Does D gains popularity?


Considerably. Downloads for dmd per day.
http://erdani.com/d/downloads.daily.png

10) Anything else 2013 D user must know? :) I don't ask about Phobos 
because according to the changelog the progress is enormous, 
incremential and targets several directions - I doubt it can be easily 
summarised...


Thanks!

[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build

[via Digitalmars-d-bugs]

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

--- Comment #8 from Thomas Mader  ---
(In reply to Thomas Mader from comment #3)
> I was able to hack around the issue by patching the curl.d sourcefile.
> 
>   #Ugly hack so the dlopen call has a chance to succeed.
>   substituteInPlace src/phobos/std/net/curl.d --replace libcurl.so
> ${curl}/lib/libcurl.so
> 
> 
> That's in the package description for the dmd package on NixOS. That's
> necessary because in NixOS every package is stored in isolation to
> everything else.
> So libcurl on my system resides in
> /nix/store/v5a69m1b823zm1yy8yvhrd2zi2w385b1-curl-7.44.0/lib/libcurl.so.

With dmd 2.075.0 I also needed to patch the Makefile of phobos to include the
full path to the shared lib:

substituteInPlace phobos/posix.mak \
--replace "-soname=libcurl.so.4" "-soname=${curl.out}/lib/libcurl.so.4"

--

[Issue 17375] colliding modules detected with binutils 2.28 linker and shared libraries

[via Digitalmars-d-bugs]

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

Thomas Mader  changed:

   What|Removed |Added

 CC||thomas.ma...@gmail.com

--- Comment #10 from Thomas Mader  ---
Had the same problem with binutils 2.28 and dmd 2.075.0 on NixOS with druntime
and phobos.

Working around the problem as suggested with

  make -f posix.mak PIC=-fPIC INSTALL_DIR=$out DMD=$DMD

works for phobos.

But for druntime I needed to patch a Makefile, 

substituteInPlace druntime/test/common.mak \
--replace "DFLAGS:=" "DFLAGS:=-fPIC "

otherwise the link test in the druntime unittests would fail when running with

  make -f posix.mak unittest PIC=-fPIC DMD=$DMD BUILD=release

--

Adding deprecated to an enum member

[Jeremy DeHaan via Digitalmars-d-learn]

I got an error today because I added deprecated to an enum member.

Is there a way to achieve this, or am I out of luck? If it isn't 
doable, should it be?


Here's what I want:

enum PrimitiveType
{
Points,
Lines,
LineStrip,
Triangles,
TriangleStrip,
TriangleFan,
Quads,

deprecated("Use LineStrip instead.")
LinesStrip = LineStrip,
deprecated("Use TriangleStrip instead.")
TrianglesStrip = TriangleStrip,
deprecated("Use TriangleFan instead.")
TrianglesFan   = TriangleFan
}


PrimitiveType ptype = LinesStrip; //error, Use LineStrip instead.

Re: Adding deprecated to an enum member

[dark777 via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 01:12:28 UTC, Jeremy DeHaan wrote:
I got an error today because I added deprecated to an enum 
member.


Is there a way to achieve this, or am I out of luck? If it 
isn't doable, should it be?


Here's what I want:

enum PrimitiveType
{
Points,
Lines,
LineStrip,
Triangles,
TriangleStrip,
TriangleFan,
Quads,

deprecated("Use LineStrip instead.")
LinesStrip = LineStrip,
deprecated("Use TriangleStrip instead.")
TrianglesStrip = TriangleStrip,
deprecated("Use TriangleFan instead.")
TrianglesFan   = TriangleFan
}


PrimitiveType ptype = LinesStrip; //error, Use LineStrip 
instead.


I did as follows using deprecated may help you to elucidate in 
relation to this

https://pastebin.com/NEHtWiGx

Re: The progress of D since 2013

[Mike via Digitalmars-d]

On Monday, 31 July 2017 at 07:22:06 UTC, Maxim Fomin wrote:

Good to see D is progressing! I was active forum and bugzilla 
participant in 2011-2013. Since then I have not touched D.


Good to see you back.  I also took a hiatus from D in 2015 and 
just recently returned after GDC fixed a blocker for me.  I'll 
comment on what I've observed.


1) Support of linking in win64? AFAIK Walter introduced win64 
support in circa 2012 which was the big progress. However, 
support for win64 linking was limited because dmd defaulted on 
old dmc linker, and Walter didn't plan to do anything with this.


Haven't used D on Windows.  Don't know.


2) What is the support of other platforms?


I'm currently only using D for bare-metal type projects and some 
desktop utilities to support that development.  DMD has added 
some improvements to -betterC 
(http://forum.dlang.org/post/cwzmbpttbaqqzdetw...@forum.dlang.org) but I'm not really interested in that feature as I'd like to use all of D for bare-metal, just in a pay-as-you-go fashion. The compiler is still too tightly coupled to the runtime, but there have been some improvements (https://www.youtube.com/watch?v=endKC3fDxqs)



3) What is the state of GC?


From what I can tell, aside from a few improvements to metering 
the GC, most endeavors have not materialized.



4) What is the state of GDC/LDC?


GDC was recently accepted for inclusion in GCC (version 8 I 
believe): https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html


5) What is the progress with CTFE? I see a lot of discussions 
in forum archive devoted to the development of CTFE. What is 
the summary of CTFE development in recent years?


I believe there is an effort to overhaul CTFE, but it is ongoing 
and not yet committed.


6) I don't see any significant changes in D core from dlang 
documentation (except those mentioned in changelog for 
2014-2017). Is is true or is the official spec as usual delayed 
:)? Is dlang spec fully and frequently updated or is it sparse 
as in the past?


I haven't seen any improvements to filling holes in the spec.  I 
believe the semantics of 'shared' are still undefined.


I have seen significant improvements to the website/documentation 
with runnable examples and such.


8) What is the progress with shared and immutable? AFAIK the 
compiler support for shared was not complete and Phobos library 
itself was not 'immutable-' and 'shared-correct'.


AFAIK nothing in that regard has changed.


9) Does D gains popularity?


Not sure.  I've seen some talent in the D community depart, some 
new talent emerge, some talent participating less, and some 
talent taking on more.


10) Anything else 2013 D user must know? :) I don't ask about 
Phobos because according to the changelog the progress is 
enormous, incremential and targets several directions - I doubt 
it can be easily summarised...


* Formal creation of the D Language Foundation
* DMD frontend converted to D
* DMD backend converted to boost license 
(http://forum.dlang.org/post/oc8acc$1ei9$1...@digitalmars.com)
* DIP1000 merged under the -dip1000 feature gate 
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
* Walter claims memory safety will kill C 
(https://www.reddit.com/r/cpp/comments/6b4xrc/walter_bright_believes_memory_safety_will_kill_c/), and if you have any faith in the TIOBE index, it may already be happening (https://www.tiobe.com/tiobe-index/)
* Lots of infrastructure improvments (dlang-bot and other CI 
automation)


Overall, though, I'd say D is just further along on the path it 
was on in 2013.  If you were hoping for a new direction, you'll 
probably be disappointed.


Mike

Re: newCTFE Status July 2017

[Temtaime via Digitalmars-d]

On Sunday, 30 July 2017 at 20:40:24 UTC, Stefan Koch wrote:

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[...]


Hello Guys,

The bug preventing newCTFE from executing bf_ctfe[1] correctly  
(a peculiarity in which for for and if statement-conditions  
other then 32bit integers where ignored) is now fixed.


[...]


Aren't you disabling codegen by passing a -o- to your engine, so 
it starts to compile faster?

Re: gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

On Monday, 31 July 2017 at 20:37:11 UTC, Mike Wey wrote:

On 31-07-17 19:16, Johnson Jones wrote:
how does one allow both gtk x86 and x64 to work side by side 
seamlessly?


I installed x64 first and it seems, because whatever is using 
the path to find the gtk runtime, it looks for that first even 
in x86 build.


Seems like gtkd's dll resolution is not very intelligent. 
While I could manually modify the path each time I switch 
archs, that seems pointless.


One of the problems in gtkd is that it has multiple places 
where it defines libgdk-3-0.dll.



I've tried modifying gdkD so that it uses versioning properly 
by searching for libgdk-3-0.dll and changing all to use an x86 
or x64 when appropriate but that doesn't seem to help. 
Probably have to rebuild gtkD.


Anyways, doesn't seem to be a great solution ;/ Any ideas and 
maybe someone can add an issue to the github page to get this 
fixed? (I can't do it for a while because of other issues).




At startup GtkD searches the Path for "libgtk-3-0.dll", when it 
finds one it checks the architecture of the library. If it's 
the correct architecture it calls `SetDllDirectory` so that the 
directory with the correct architecture will be searched first 
by `LoadLibrary`.


If it's not the correct architecture it continues searching, if 
no library with the correct architecture is found, we rely on 
`LoadLibrary` to error out if the libraries are also not in the 
other locations searched by `LoadLibrary`.


This is not true(at least completely). I have have a fresh 
windows 10 install with fresh dmd and gtkd and gtk x64 and 
x86(installed later).


When running my app in x64 mode it tried to use the x64 but the 
app crashed and I didn't know why as no error message and bug in 
visual D wouldn't allow me to use BP's to find out how far the 
app was getting.


So I decided to install the x86 version. Ran the project in x86 
mode but gtkd was trying to load the x64 dlls and told me they 
were wrong. Remember, now I have both versions on my system. I 
decided to modify gtkd and using some versioning, in which case 
this got me to allow x86 to work as it now used *x86.dll's. I 
noticed that gtksharp was installed in program files (x86).


I then tried to build the x64 version and the app just loads then 
quits but the debug console shows what I pasted and shows that it 
is trying to load stuff from gtksharp.


All I installed as gtk3-runtime_3.22.4_64-bit and 
gtk3-runtime_3.22.4_32-bit.


Now, it may turn out that gtksharp was installed by something 
else(visual studio? or maybe a few other apps I installed). That 
seems to be the case as the modified date predates install of 
gtk3 and seems to correlate to when I installed visual studio 
2017 with it's 50+ gigs worth of crap.


Why is my x64 app trying to load those files though and specially 
from the wrong version? the x86 version



The files being loaded(I suppose they are, not sure what the 
unloaded means):


C:\Windows\SysWOW64\kernel32.dll unloaded.
C:\Windows\SysWOW64\winmmbase.dll unloaded.
C:\Windows\SysWOW64\winmmbase.dll unloaded.
C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll 
unloaded.

C:\Windows\SysWOW64\dnsapi.dll unloaded.
C:\Program Files (x86)\Gtk-Runtime\bin\libpangoft2-1.0-0.dll 
unloaded.

C:\Program Files (x86)\Gtk-Runtime\bin\libgdk-3-0.dll unloaded.
C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.483_none_6dad63fefc436da8\comctl32.dll
 unloaded.
C:\Program Files (x86)\Gtk-Runtime\bin\librsvg-2-2.dll unloaded.
C:\Program Files (x86)\Gtk-Runtime\bin\libcroco-0.6-3.dll 
unloaded.

C:\Program Files (x86)\Gtk-Runtime\bin\libxml2-2.dll unloaded.
C:\Program Files (x86)\Gtk-Runtime\bin\libxml2-2.dll unloaded.
C:\Windows\SysWOW64\winhttp.dll unloaded.
C:\Windows\SysWOW64\OnDemandConnRouteHelper.dll unloaded.


for x86, for x64 I get

C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded.
C:\Program Files (x86)\GtkSharp\2.12\bin\libgdk_pixbuf-2.0-0.dll 
unloaded.
C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll 
unloaded.

C:\Windows\System32\dwmapi.dll unloaded.
C:\Windows\System32\ole32.dll unloaded.
C:\Windows\System32\setupapi.dll unloaded.
C:\Windows\System32\winmm.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded.
The program '[3420] test.exe' has exited with code 1 (0x1).


as you can see, some files are loaded that are from x86. 
Remember, I modified gtk so that it duplicates all the dll's with 
the x??.dll's and modified gtkd to take those x??.dll's instead, 
which you can see in the last libgdk-3-0x64.


So, those files being loaded are surely not coming from inside 
gtkd?


I modified things like

version (Windows)
{
version(X86)
{
const string[LIBRARY.max+1] importLibs =
[
LIBRARY.ATK:  

Re: DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Monday, 31 July 2017 at 19:27:46 UTC, Jesse Phillips wrote:

On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:

On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
* Remove the whole program defaults, I'm ok with it being 
changed in a re-implementation of the runtime (like the 
embedded example), we just don't need the extra confusion 
within user code.


The program defaults are there to make @safe by default a 
thing, and betterC by default a thing, which are covered in 
the _three Primary points_ of the semesters Vision 
document[1]. These would not normally be set (i.e. opt in).


I read that as more, Improve Druntime and phobos's us of @safe 
so that it becomes more usable.


Improving druntime and phobos is obviously important, but so is 
the ability for the end user to use it. If its hard to use less 
people will use it, conversely the easier it is the more likely 
people are to use it. Not that this also provides an easy way to 
find out which function are not @safe and fix them, without 
slapping @safe on main, i.e. build unit (package/library) at a 
time.


* Specifying inferred needs to be within druntime only, and 
thus may not need to exist.


I think there is usefulness in having it, particularly as the 
meta-default (defaultAttributeSet). Walter has ben pushing for 
some time to infer attributes by default. This would provide a 
directive for the compiler to do so. Please elaborate.


I don't expect inference to happen outside templates. Besides 
if the compiler infers the appropriate attributes by default, 
isn't 1. a default attribute redundant and 2. specifying 
inference redundant as the compiler defaults to inferring?


It happens already for dip1000 IIRC and I be surprised if, 
particularly for @safe, Walter didn't want more inference. 
Especially for minimal user effort.


The compiler will default functions to the first value of the 
enum [for my example].


( That would provide a pessimistic default and debates the 
ability for the compiler to infer)


Yes, just throwing in an example structure and why I mentioned 
[for my example]. But as said earlier infer and default are at 
odds.


I disagree. Even if infer wasn't the default I would certainly 
like to be able to have them be inferred at the flick of a 
compiler switch. It goes back to the ease of use argument, its 
more effort for me to manually annotate things.

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Monday, 31 July 2017 at 23:03:21 UTC, Temtaime wrote:

On Sunday, 30 July 2017 at 20:40:24 UTC, Stefan Koch wrote:

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[...]


Hello Guys,

The bug preventing newCTFE from executing bf_ctfe[1] correctly
 (a peculiarity in which for for and if statement-conditions  
other then 32bit integers where ignored) is now fixed.


[...]


Aren't you disabling codegen by passing a -o- to your engine, 
so it starts to compile faster?


Ah yes.
An oversight while posting the results. it does not affect the 
meassurements in any real way though the difference it 3-5 
milliseconds.


In the testcase the ctfe workload is totally dominant.

[Issue 16744] We should have a TypeOf template so that typeof can be used with templates like staticMap

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/be351ebe20df55b72e7441e43b84cfacee42f8ea
Revert "Fix Issue 16744: Add Typeof"

https://github.com/dlang/phobos/commit/f0eaf4456355f3ed68e4fe078663fbb7ccaf46de
Merge pull request #5664 from dlang/revert-5662-MetaLang-patch-1-3

Revert "Fix Issue 16744: Add Typeof"
merged-on-behalf-of: MetaLang 

--

Re: [OT] uncovering x86 hardware bugs and unknown instructions by fuzzing.

[deadalnix via Digitalmars-d]

On Monday, 31 July 2017 at 07:17:33 UTC, Guillaume Chatelet wrote:

Some people here might find this interesting:
https://github.com/xoreaxeaxeax/sandsifter

White paper here:
https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf


This man is a superhero.

See also https://www.youtube.com/watch?v=lR0nh-TdpVg for in 
hardware privilege escalation and 
https://www.youtube.com/watch?v=HlUe0TUHOIc . We should consider 
building a shrine for this guy.

[Issue 17709] New: std.xml doesn't parse the root element

[via Digitalmars-d-bugs]

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

  Issue ID: 17709
   Summary: std.xml doesn't parse the root element
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: slavo5...@yahoo.com

import std.xml;
import std.stdio;

void main()
{
auto parser = new DocumentParser("");
parser.onStartTag["device"] = (ElementParser parser)
{
writeln("device");
};
parser.parse();
}

That code does not print "device",  However...

import std.xml;
import std.stdio;

void main()
{
auto parser = new DocumentParser("");
parser.onStartTag["peripheral"] = (ElementParser parser)
{
writeln("peripheral");
};
parser.parse();
}

that code will print "peripheral".

--

mixin template, extern(C/Windows) and mangled name

[Domain via Digitalmars-d-learn]

I known there is a bug with extern(C) in mixin template: 
https://issues.dlang.org/show_bug.cgi?id=12575


And I can see SimpleDllMain in core.sys.windows.dll, the mangled 
name is correct: DllMain

But my mixin template has wrong mangled name:

mixin template GetMetaData()
{
extern(Windows) MetaData GetMetaData()
{
return MetaData();
}
}

mixin GetMetaData;

I can see the mangled name is:
_D3app8__mixin911GetMetaDataWZS4zero7plugins8metadata8MetaData

Re: mixin template, extern(C/Windows) and mangled name

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

On Tuesday, 1 August 2017 at 03:08:30 UTC, Domain wrote:
And I can see SimpleDllMain in core.sys.windows.dll, the 
mangled name is correct: DllMain


main, DllMain, and WinMain are special cased...

for yours, I think you'll have to hack it with pragma(mangle)

 mixin template GetMetaData()
 {
 pragma(mangle, "GetMetaData") // or whatever maybe @0 ?
 extern(Windows) MetaData GetMetaData()
 {
 return MetaData();
 }
 }

 mixin GetMetaData;


I think.

Re: mixin template, extern(C/Windows) and mangled name

[Domain via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 03:30:08 UTC, Adam D. Ruppe wrote:

On Tuesday, 1 August 2017 at 03:08:30 UTC, Domain wrote:
And I can see SimpleDllMain in core.sys.windows.dll, the 
mangled name is correct: DllMain


main, DllMain, and WinMain are special cased...

for yours, I think you'll have to hack it with pragma(mangle)

 mixin template GetMetaData()
 {
 pragma(mangle, "GetMetaData") // or whatever maybe @0 ?
 extern(Windows) MetaData GetMetaData()
 {
 return MetaData();
 }
 }

 mixin GetMetaData;


I think.


Thanks. Anyone known any plan for issue 12575? It has been 3 
years, it looks like not that hard to fix.

Bug in gtkd?

[Johnson Jones via Digitalmars-d-learn]

Trying a very simple interface. When I add a notebook I get the 
following error


(test.exe:4504): Gtk-ERROR **: failed to add UI: 
C:\Test\Main.Glade:27:43 Invalid property: GtkNotebook.tab_hborder


When removing it from the glade file it then crashes with on the 
homogenous property. Removing that allows it to work but then 
clicking on the border between causes the app to crash.


clicking the link gives

(SongPractice.exe:4796): Gtk-WARNING **: Couldn't 
export handle, unsupported windowing system



Also, there is no icon on the task bar of the app so no way to 
find it if the app is minimized. Not sure why that is, but seems 
like it should be there regardless.


The app is

int main(string[] args)
{
  gtk.Main.init(args);
  auto mw = 
(cast(Window)gtk.builder.getObject("MainWindow"));		mw.showAll();

  gtk.Main.run();   
  return 0;
}

The Main.Glade file is



  
  
  
False

  
True
True

  
True
False
gtk-missing-image
  
  
False
True
  


  
True
True
True
0
True

  
True
False

  
translatable="yes">button

True
True
name="receives_default">True

True
none
name="uri">http://glade.gnome.org

  
  
True
True
0
  

  


  
True
False
name="xalign">0.4798927116394

1
translatable="yes">Settings

  
  
False
  

  
  
True
True