Re: Error: function std.stdio.setmode is not accessible from module a

[Kirill Kryukov via Digitalmars-d-learn]

On Thursday, 3 November 2016 at 08:04:45 UTC, Jonathan M Davis 
wrote:

[...]


Thank you for a detailed clarification about setmode 
availability. I'll think more about how to proceed with it, and 
whether I should request it in druntime.


I will try to make a bug report about deprecation.

Thanks!

Kirill

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

[Steven Schveighoffer via Digitalmars-d]

On 11/3/16 11:48 PM, safety0ff wrote:

On Thursday, 3 November 2016 at 13:19:17 UTC, Steven Schveighoffer wrote:


So technically, the freelist is still needed.


In case I wasn't clear in my previous post:
We can't use a freelist because it breaks safety.


Yes, you can't use a free-list when removing nodes. AA used to actually 
free the memory, but that was decided against long ago.


There are so many possibilities if we just move to a templated type.

-Steve

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

[safety0ff via Digitalmars-d]

On Thursday, 3 November 2016 at 13:19:17 UTC, Steven 
Schveighoffer wrote:


So technically, the freelist is still needed.


In case I wasn't clear in my previous post:
We can't use a freelist because it breaks safety.

Re: not callable error

[Paul Backus via Digitalmars-d-learn]

On Friday, 4 November 2016 at 02:28:17 UTC, bluphantom91 wrote:

Hello,

I am trying to finish up a group project but I am running into 
a small problem. I keep getting an error about fgetc not being 
callable. The purpose of my program is to count the number of 
characters in a file. Any bit of help is appreciated!


Here's my code:

import std.stdio;
import std.file;
import std.string;



Since you're using the C library stdio functions, you should 
import core.stdc.stdio

Calling std.variant.visit from a pure function

[Paul Backus via Digitalmars-d-learn]

As a learning exercise, I'm writing a simple AST evaluator for 
arithmetic expressions in D. (See 
https://gist.github.com/ckirkendall/2934374) In order to get a 
feel for functional programming in D, I decided to try and 
implement my solution in a functional style, using algebraic data 
types and pure functions.


Here's the code:

import std.variant;
import std.typecons;

enum Op { Plus, Minus, Times, Div }

alias Expr = Algebraic!(
double,
string,
Tuple!(Op, "op", This*, "lhs", This*, "rhs")
);


double eval(Expr expr, double[string] env) pure {
return expr.visit!(
(double x) pure => x,
(string v) pure => env[v],
(Tuple!(Op, "op", Expr*, "lhs", Expr*, "rhs") bop) pure {
final switch (bop.op) with (Op) {
case Plus:
return eval(*bop.lhs, env) + eval(*bop.rhs, env);
break;
case Minus:
return eval(*bop.lhs, env) - eval(*bop.rhs, env);
break;
case Times:
return eval(*bop.lhs, env) * eval(*bop.rhs, env);
break;
case Div:
return eval(*bop.lhs, env) / eval(*bop.rhs, env);
break;
}
}
)();
}

When I compile this (using DMD 2.069 on Debian Linux), I get an 
error saying that I can't call visit from a pure function. This 
is surprising, since all visit does (in theory) is call the 
provided functions, and all of _them_ are pure.


My question is, is this an unavoidable limitation of visit's 
implementation, or is there a way to work around this?

not callable error

[bluphantom91 via Digitalmars-d-learn]

Hello,

I am trying to finish up a group project but I am running into a 
small problem. I keep getting an error about fgetc not being 
callable. The purpose of my program is to count the number of 
characters in a file. Any bit of help is appreciated!


Here's my code:

import std.stdio;
import std.file;
import std.string;


void main()
{
FILE *file;
char ch;
int charCount,wordCount,input;



//File file = File("test.txt","w");
 //input=fscanf(file, "%ch",);

 //file.writeln("hello");

//string s = file.readln();

file=fopen("test,txt","r");

while(!file.eof())
{
/*string line = chomp(file.readln());
wordCount++;
writeln(wordCount);*/

ch = getc(file);
charCount++;

}



file.close();




}

Re: CTFE Status

[Chris Wright via Digitalmars-d]

On Thu, 03 Nov 2016 15:44:20 +, Marc Schütz wrote:

> On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
>> I intend to keep the current implemntation around as a fallback.
>> For things that are used rarely.
>> like floating point and others :)
> 
> Is that a good idea? It means that there will be tons of really complex
> code that is rarely if ever used and therefore gets no testing...

I think the intent is that the current implementation will always be used 
for specific features, not that the compiler will attempt to run CTFE 
with the bytecode version and resort to the previous implementation if 
something goes wrong.

Re: Release D 2.072.0

[Johan Engelen via Digitalmars-d-announce]

On Friday, 4 November 2016 at 00:42:48 UTC, Johan Engelen wrote:
On Thursday, 3 November 2016 at 15:51:22 UTC, Steven 
Schveighoffer wrote:


Any cycles that are "newly discovered" were already there. 
What was happening is that the runtime did not detect the 
cycle, and was arbitrarily choosing an order for initializing 
these modules. Either a) the arbitrary order happened to be 
right, or b) the order didn't matter. Most of the time it's b, 
because most static ctors don't depend on externally 
initialized items.


My question is: any cycle is invalid?


nevermind, I found this:
https://dlang.org/spec/module.html#order_of_static_ctor

Re: Release D 2.072.0

[Johan Engelen via Digitalmars-d-announce]

On Thursday, 3 November 2016 at 15:51:22 UTC, Steven 
Schveighoffer wrote:


Any cycles that are "newly discovered" were already there. What 
was happening is that the runtime did not detect the cycle, and 
was arbitrarily choosing an order for initializing these 
modules. Either a) the arbitrary order happened to be right, or 
b) the order didn't matter. Most of the time it's b, because 
most static ctors don't depend on externally initialized items.


My question is: any cycle is invalid?

-Johan

Re: If Statement with Declaration

[mogu via Digitalmars-d]

On Thursday, 3 November 2016 at 22:32:17 UTC, Stefan Koch wrote:

On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:


So I was thinking of a way of extending if statements that 
have declarations. The following being as example of the 
current use of if statements with declarations:


[...]


Just Introduce another block
{
  int i = someFunc();
  if (i >= 0) { ... }
}
// i is not visible here


Introducing a block is not intuitive and cause an identation. As 
a reference, C++17 has adopted a proposal about this, and 
extended to switch:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html

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

[Era Scarecrow via Digitalmars-d]

On Thursday, 3 November 2016 at 21:00:56 UTC, Yuxuan Shui wrote:
How about let the user provide the memory block when they calls 
reserve()?


 I'd love to see this type of option almost everywhere.

Re: If Statement with Declaration

[Stefan Koch via Digitalmars-d]

On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:


So I was thinking of a way of extending if statements that have 
declarations. The following being as example of the current use 
of if statements with declarations:


[...]


Just Introduce another block
{
  int i = someFunc();
  if (i >= 0) { ... }
}
// i is not visible here

If Statement with Declaration

[Jerry via Digitalmars-d]

So I was thinking of a way of extending if statements that have 
declarations. The following being as example of the current use 
of if statements with declarations:


if(int* weDontPollute = someFunc())
{
 // use weDontPollute
}

That's great and all, but it only works by checking if the 
variable evaluates to true or false. Which is fine for a pointer 
but otherwise useless for anything else, like integers where zero 
is usually valid input (index for array). So currently the only 
way to do something like this in the language, that i've found, 
is to use a for statement.


for(int i = someFunc(); i >= 0;)
{
// use i

break;
}

Not that ideal to use a for statement. It makes it hard to read 
and if the break condition isn't there it might very well be an 
infinite loop. So I was thinking of some sort of syntax like this:


if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts on this sort of feature?

Re: fPIC Error

[dlang user via Digitalmars-d-learn]

On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole 
wrote:
Took me a while to replicate your build environment but it 
looks like a false alarm.


rikki@debian:/tmp/test$ dmd test.d
rikki@debian:/tmp/test$ file test
test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
for GNU/Linux 2.6.32, 
BuildID[sha1]=0a6394b9ec9b82e07440ab62cd71932f0ab568d1, not 
stripped


rikki@debian:/tmp/test$ ./test
Edit source/app.d to start your project.

rikki@debian:/tmp/test$ cat /etc/dmd.conf
;
; dmd.conf file for dmd
;
; dmd will look for dmd.conf in the following sequence of 
directories:

;   - current working directory
;   - directory specified by the HOME environment variable
;   - directory dmd resides in
;   - /etc directory
;
; Names enclosed by %% are searched for in the existing 
environment and inserted

;
; The special name %@P% is replaced with the path to this file
;

[Environment32]
DFLAGS=-I/usr/include/dmd/phobos 
-I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu 
-L--export-dynamic -fPIC -defaultlib=libphobos2.so


[Environment64]
DFLAGS=-I/usr/include/dmd/phobos 
-I/usr/include/dmd/druntime/import 
-L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC 
-defaultlib=libphobos2.so


Thanks for looking at it and confirming you are seeing the same 
thing.


I am no expert, but after some additional research I think I see 
what is going on.  From what I read the gcc -fPIC option creates 
a shared library, while gcc -fPIE option creates an executable.  
You can also create a dual purpose file that is a shared library 
and is also executable by creating a shared library if that file 
also contains a main function (that might be oversimplified a 
little bit).


Looking at the dmd documentation, it only has a -fPIC option, 
there is no -fPIE option, which has the following description:


generate Position Independent Code (which is used for building 
shared libraries).


So, if I am understanding everything correctly because dmd only 
has -fPIC, the only option is to create a dual purpose file that 
is both a shared library and executable.

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

[Yuxuan Shui via Digitalmars-d]

On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei 
Alexandrescu wrote:

[snip]

* The implementation cannot use Phobos' allocator because it's 
in druntime.


How about let the user provide the memory block when they calls 
reserve()?




Please share your thoughts.


Thanks,

Andrei

[Issue 9094] GC not collecting under Windows

[via Digitalmars-d-bugs]

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

Jesse Phillips  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jesse.k.phillip...@gmail.co
   ||m
 Resolution|WONTFIX |---

--- Comment #4 from Jesse Phillips  ---
I'm having this issue with Windows 64bit on 30MB files, and it appears is also
affecting zip extraction of similar size. I'm reopening so the issue can be
re-evaluated considering this isn't just a 32bit + gigabyte file issue.

Does anyone have a suggestion for manually releasing the expanded data when
using std.zip.ZipArchive.expand() on a ArchiveMember?

--

Re: What is the simplest way of doing @nogc string concatenation?

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/3/16 2:54 PM, Gary Willoughby wrote:

What is the simplest way of doing @nogc string concatenation?


Where does it go?

For instance, this should work:

auto newstr = "hello, ".chain("world");

-Steve

Re: What is the simplest way of doing @nogc string concatenation?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, November 03, 2016 18:54:14 Gary Willoughby via Digitalmars-d-
learn wrote:
> What is the simplest way of doing @nogc string concatenation?

std.range.chain is the closest that you're going to get with actual strings.
Dynamic arrays require the GC to do concatenation, because they have to
allocate a new string. Now, you can do stuff like

char[] mallocConcat(const(char)[] lhs, const(char)[] right)
{
immutable len = lhs.length + right.length;
return (cast(char*)malloc(len))[0 .. len];
}

But then you have to worry about keeping track of that memory allocation
somehow so that you free it appropriately later. Similarly, if you're
dealing with some sort of maximum string size, you could have static array
somewhere that you assign to and slice, but then you have to have somewhere
appropriate for that static array to live - which is simple enough if you're
just going to operate on it and then let it go away but is much harder if
you actually want to pass the slice around like a normal string.

Really, if you want to be doing actual string concatenation without the GC
and have it be sane, you need a string type which handles its own memory -
presumably using malloc. Concenation with dynamic arrays really needs the
GC - particularly in light of the fact that dynamic arrays are not reference
counted.

In general though, I'd suggest trying to use chain and operating on ranges
rather than creating an actual string to operate on. And if you want to
avoid the whole auto-decoding thing in the process, you can combine it with
std.utf.byCodeUnit.

- Jonathan M Davis

What is the simplest way of doing @nogc string concatenation?

[Gary Willoughby via Digitalmars-d-learn]

What is the simplest way of doing @nogc string concatenation?

Re: is there "this"?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, November 03, 2016 09:40:11 Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 11/2/16 4:43 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Wednesday, November 02, 2016 02:42:01 Konstantin Kutsevalov via
> >
> > Digitalmars-d-learn wrote:
> >> I tested already and it really works, thank you.
> >> I asked that because I tried once to use "this" in past but I got
> >> error. So I asked on some forum "how to get property of class?"
> >> and peoples said that I may use just a name of property. So I
> >> thought that there isn't "this" word.
> >
> > I don't know why you were having trouble before, but I think that most
> > people never use an explicit this unless they need to, so plenty of
> > folks
> > would have just told you to remove the this from you code, especially if
> > it worked without.
>
> In the case of the original post, however, you *need* to use this.value,
> as the parameter masks the member of the same name. Using 'this' removes
> ambiguity.
>
> This is a typical pattern seen in many languages. Often the intuitive
> name of a member is the same name as you want for the parameter of the
> constructor.

Yeah. That's the only reason that I ever use the this pointer/reference.

- Jonathan M Davis

Re: Compilation phobos errors with DMD 2.071,2.072 or dub

[kozzi11 via Digitalmars-d-learn]

Really? This issue is here on forum many times, can you pleas read last few 
post? Just by name.

Sent from my Samsung device. 





 Original message 
From: Ozan (ONS) via Digitalmars-d-learn 
Sent: 03/11/2016 15:55:24
To: digitalmars-d-learn@puremagic.com
Subject: Compilation phobos errors with DMD 2.071,2.072 or dub



Hi,



with a fresh Ubuntu 16.10 installation using "Hello, World" I got 

a list of following errors like:

/usr/bin/ld: 

/usr/lib/x86_64-linux-gnu/libphobos2.a(thread_256_713.o): 

relocation R_X86_64_32 against symbol 

`_D6object9Throwable7__ClassZ' can not be used when making a 

shared object; recompile with -fPIC



Example: Using dmd 2.071 and dub; dub init appName; compile 

appName with dub.

Or direct with dmd



What I'm missing? Any hints?



Thanks & Regards, Ozan

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Thursday, 3 November 2016 at 15:44:20 UTC, Marc Schütz wrote:

On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
I intend to keep the current implemntation around as a 
fallback.

For things that are used rarely.
like floating point and others :)


Is that a good idea? It means that there will be tons of really 
complex code that is rarely if ever used and therefore gets no 
testing...


Passing the whole test-suite is as good as it gets.

Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 3 November 2016 at 12:19:09 UTC, Sönke Ludwig wrote:
Does "if (!_ctfe) assert(false);" work, too? That would also 
protect against accidential mistakes.


Doesn't seem like it. { assert(false); return; } works (in 
reducing compile time) but generates "statement is not reachable" 
warnings for the return statement.

[Issue 16660] Deprecate/Remove Optlink as Default Linker on Windows

[via Digitalmars-d-bugs]

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

--- Comment #1 from Martin Krejcirik  ---
Well, -m32 doesn't require VC installed, that's major point.

--

Re: CTFE Status

[Marc Schütz via Digitalmars-d]

On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:

I intend to keep the current implemntation around as a fallback.
For things that are used rarely.
like floating point and others :)


Is that a good idea? It means that there will be tons of really 
complex code that is rarely if ever used and therefore gets no 
testing...

Re: Release D 2.072.0

[Dicebot via Digitalmars-d-announce]

On 10/31/2016 03:27 AM, Martin Nowak wrote:
> Glad to announce D 2.072.0.

NB: Current release notes are outdated and wrong about
`-transition=safe` flag. It was completely repurposed in stable branch
(https://github.com/dlang/dmd/pull/6183) but somehow changes to release
notes there do not propagate to released changelog.




signature.asc
Description: OpenPGP digital signature

Compilation phobos errors with DMD 2.071,2.072 or dub

[Ozan (ONS) via Digitalmars-d-learn]

Hi,

with a fresh Ubuntu 16.10 installation using "Hello, World" I got 
a list of following errors like:
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(thread_256_713.o): 
relocation R_X86_64_32 against symbol 
`_D6object9Throwable7__ClassZ' can not be used when making a 
shared object; recompile with -fPIC


Example: Using dmd 2.071 and dub; dub init appName; compile 
appName with dub.

Or direct with dmd

What I'm missing? Any hints?

Thanks & Regards, Ozan

Re: Release D 2.072.0

[Johan Engelen via Digitalmars-d-announce]

On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote:

On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote:


I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but 
boot since master straping works there's probably something 
that's been fixed in one or two of these ddmd modules, likely 
a static ctor...


Maybe after this:

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368

ddmd.attribs was removed

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15

and it was also part of the cycle.


Thanks for the detective work.
I wonder where the bug is: in 2.071 or in 2.072 :)

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
As I determined in that thread, note that core.internal.hash.hashOf does not do
the same thing as object.hashOf. It hashes only the bits of the given type.

I can't think of a single valid reason for hashing the pointer and length of an
array instead of the contents of the array. I don't know the right answer here,
but at the very least hashOf isn't documented or understood properly.

--

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
(In reply to Steven Schveighoffer from comment #1)
> As I determined in that thread, note that core.internal.hash.hashOf does not
> do the same thing as object.hashOf. It hashes only the bits of the given
> type.

It being object.hashOf. core.internal.hash.hashOf does a more reasonable thing.

--

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/2/16 8:36 AM, Johan Engelen wrote:

On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu wrote:

On 11/01/2016 11:41 AM, Johan Engelen wrote:

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.


DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD
2.071.2 for CI testing. :(


Is there somebody working on that bug? Thanks. -- Andrei


LDC built with DMD 2.072.0 gives the following error when run:
object.Error@src/rt/minfo.d(356): Cyclic dependency between module
ddmd.traits and ddmd.cond
ddmd.traits* ->
ddmd.attrib ->
ddmd.cond* ->
ddmd.expression ->
ddmd.traits*


The issue is that DDMD has cycles, always has. But the cycle detection 
was broken. This is now fixed in 2.072. An unfortunate side effect from 
having broken cycle detection since 2011 is that many projects will now 
detect cycles. 2.072 is going to break a lot of code that was already 
"broken". I use scare quotes because likely the code is just fine, but 
the cycle detection is so broad that it's easy to get caught in the net.


The best answer is to somehow do better cycle detection (e.g. determine 
if there really are dependencies that break with cycles). We have some 
ideas, but nothing has been fleshed out yet.


-Steve

Re: is there "this"?

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/2/16 4:43 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Wednesday, November 02, 2016 02:42:01 Konstantin Kutsevalov via
Digitalmars-d-learn wrote:

I tested already and it really works, thank you.
I asked that because I tried once to use "this" in past but I got
error. So I asked on some forum "how to get property of class?"
and peoples said that I may use just a name of property. So I
thought that there isn't "this" word.


I don't know why you were having trouble before, but I think that most
people never use an explicit this unless they need to, so plenty of folks
would have just told you to remove the this from you code, especially if it
worked without.


In the case of the original post, however, you *need* to use this.value, 
as the parameter masks the member of the same name. Using 'this' removes 
ambiguity.


This is a typical pattern seen in many languages. Often the intuitive 
name of a member is the same name as you want for the parameter of the 
constructor.


-Steve

Re: Benchmarking Time Unit

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/3/16 9:03 AM, Steven Schveighoffer wrote:

On 11/1/16 6:55 PM, Nordlöw wrote:

On Tuesday, 1 November 2016 at 20:54:34 UTC, Steven Schveighoffer wrote:

MonoTime has about 5-10 % fluctuations on my laptop. Is this as good as
it gets?


This is not clear. What is this a percentage of?


It percentage of execution time.

15 ms +- 2 ms


2ms variance is not horrendous or unexpected on a non-realtime system.


Put another way, this is not a symptom of MonoTime having issues.

-Steve

Re: Is the following code legal?

[Steven Schveighoffer via Digitalmars-d]

On 11/2/16 11:17 AM, Adam D. Ruppe wrote:

On Wednesday, 2 November 2016 at 14:21:32 UTC, Shachar Shemesh wrote:

The D documentation (https://dlang.org/spec/hash-map.html) leaves this
not defined.


The foreach statement is defined to not allow it:

http://dlang.org/spec/statement.html#ForeachStatement

"The aggregate must be loop invariant, meaning that elements to the
aggregate cannot be added or removed from it in the
NoScopeNonEmptyStatement."


That's only for builtins. Obviously, there are cases where it can work, 
and it needs to be defined by the aggregate/range. I think the 
documentation should be updated to reflect that.


To answer the original question, it's not valid with the current 
implementation AFAIK. I don't think we should define ever that it is 
valid, even if we have an implementation that supports it, as this 
restricts our implementation to always supporting it.


I'll point at my dcollections library as an example where the currently 
iterated value can be removed:


https://github.com/schveiguy/dcollections/blob/master/concepts.txt#L81

I think Java also allows this, and C++ allows this.

-Steve

Re: Release D 2.072.0

[Andre Pany via Digitalmars-d-announce]

On Thursday, 3 November 2016 at 12:17:29 UTC, Sönke Ludwig wrote:

Am 03.11.2016 um 06:58 schrieb Andre Pany:

Temp-folder builds are only done if the special shebang 
invocation syntax is used (i.e. "dub file.d Building with "dub --single file.d" should build normally. This 
was the case within the thread, too. Has anything changed since 
then?


Unfortunately yes, the behavior of dub included in dmd 2.072 is 
not as expected (windows & linux).


/+ dub.sdl:
name "app"
+/
void main(){}

dub --single app.d
Running 
..\..\..\..\..\Users\abcdef\AppData\Local\Temp\.dub\build\app-~master\application-debug-windows-x86-dmd_2072-A4FA96FDE8C9353FB025486E4835F2E0\app.exe


Same behavior for dub build --single app.d

Kind regards
André

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

[Steven Schveighoffer via Digitalmars-d]

On 11/1/16 11:36 PM, Andrei Alexandrescu wrote:

Our student Alex has been looking at this and I wanted to open the floor
for a bit of discussion before we embark on an implementation.

Last time I looked our associative arrays were arrays of singly-linked
lists. It follows that in order to implement reserve() we'd need a
freelist allocator approach, which preallocates a bunch of nodes in a
single contiguous block of memory.


They have changed. Collisions are now handled via finding the next 
available slot in the array. However, elements of the array are still 
pointers to entries.


So technically, the freelist is still needed. But I'm not sure 
preallocating into a contiguous block is the best approach. People don't 
expect a hashtable to hold onto all the memory it has used in the past 
when you remove most of the elements.


In dcollections, I let the allocator take care of the details of 
allocation. I think the best thing to do is to preallocate the array at 
least (so no rehashing occurs during additions of nodes), and then move 
towards a templated solution that can use a custom allocator for tuning 
the performance/memory usage tradeoff.


-Steve

Re: hashOf()

[Márcio Martins via Digitalmars-d]

On Thursday, 3 November 2016 at 13:11:41 UTC, Steven 
Schveighoffer wrote:

On 11/2/16 12:14 PM, Márcio Martins wrote:

[...]


You are not the only one:

https://forum.dlang.org/post/nv85ou$gi5$1...@digitalmars.com

Note, I wholly disagree with the idea that hashOf(arr) hashes 
the pointer and length elements. I get why it does, and get 
what the charter of hashOf is. But nobody expects it.


IMO, hashOf should fail to compile on types that contain 
pointers, including arrays. In fact, I'm thinking hashOf 
shouldn't even be available in object. It's completely 
inconsistent with all other forms of hashing a type (which use 
typeinfo, opHash, etc.). It's too low-level, and should be 
accessible only via an import.


-Steve


That's what I'd expect as well. The hashOf() in 
core.internal.hash is useful, and it works intuitively, IMO, so 
if one is implicitly imported it should be that one...

Re: hashOf()

[Steven Schveighoffer via Digitalmars-d]

On 11/2/16 12:14 PM, Márcio Martins wrote:

There are 2 hashOf() definitions, one in object.d and one in
core.internal.hash.d

If you include core.internal.hash, you cannot call hashOf() anymore,
because it conflicts with the implicit import in object.d, this is
annoying in itself...
The bigger issue though, is that they have different semantics:

import core.internal.hash : hashOfInt = hashOf;

void main() {
string moo = "moo";
assert(moo.hashOfInt == moo.idup.hashOfInt); // ok - hashes
moo.ptr[0..moo.length]
assert(moo.hashOf == moo.idup.hashOf); // fail - hashes
[0..moo.sizeof]
}

Did anyone else fall into this trap?


You are not the only one:

https://forum.dlang.org/post/nv85ou$gi5$1...@digitalmars.com

Note, I wholly disagree with the idea that hashOf(arr) hashes the 
pointer and length elements. I get why it does, and get what the charter 
of hashOf is. But nobody expects it.


IMO, hashOf should fail to compile on types that contain pointers, 
including arrays. In fact, I'm thinking hashOf shouldn't even be 
available in object. It's completely inconsistent with all other forms 
of hashing a type (which use typeinfo, opHash, etc.). It's too 
low-level, and should be accessible only via an import.


-Steve

[Issue 16624] std.path.setExtension ddoc comment is strangely formated

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/9d1fc0750bec03cf1e9cc1fdbbefa8828ae0d418
[TRIVIAL, DDOC] fix issue 16624 - setExtension ddoc comment is strangely
formated

https://github.com/dlang/phobos/commit/bf2550fbc51c3080fd9e730140d1061048053ebc
Merge pull request #4886 from BBasile/issue16624

[TRIVIAL, DDOC] fix issue 16624 - setExtension ddoc comment is strang…

--

Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!

[Jacob Carlborg via Digitalmars-d]

On 2016-11-03 04:43, Vladimir Panteleev wrote:


As it turns out, DMD will codegen all functions, even templated ones
when they're instantiated, whether they're called by something or not.
With metaprogramming-heavy code, it's easy to run into some optimizer
performance corner cases, however this may make an impact regardless.


I guess the compiler assumes that a function can end up in a library and 
be called by some other program. Sounds like a whole program 
analysis/optimization would be required. Or if the compiler is invoked 
as building an executable it can assume it can avoid generating code for 
unused functions?


To me it sounds like a @ctfe attribute would be useful. The compiler 
could enforce that functions annotated with @ctfe will only contain code 
that can be CTFE-able, can only be called in a CTFE context and will not 
generate any code.


--
/Jacob Carlborg

Re: Benchmarking Time Unit

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/1/16 6:55 PM, Nordlöw wrote:

On Tuesday, 1 November 2016 at 20:54:34 UTC, Steven Schveighoffer wrote:

MonoTime has about 5-10 % fluctuations on my laptop. Is this as good as
it gets?


This is not clear. What is this a percentage of?


It percentage of execution time.

15 ms +- 2 ms


2ms variance is not horrendous or unexpected on a non-realtime system.

-Steve

[Issue 16660] New: Deprecate/Remove Optlink as Default Linker on Windows

[via Digitalmars-d-bugs]

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

  Issue ID: 16660
   Summary: Deprecate/Remove Optlink as Default Linker on Windows
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sprink.nore...@gmail.com

It doesn't make sense to have Optlink as the default linker for 32-bit. It
doesn't use the format of the platform and it can't link 64-bit programs. You
have two different linkers being used by default. At the very least -m32mscoff
should be the default and there should be a flag switch to use Optlink. It's an
old linker that has some obscure bugs that won't be fixed. Replacing it with
another linker that supports OMF (not sure there is one) could be an option,
but even then I think COFF should still be the default.

--

[Issue 5243] dmd -run potentially removes user files

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

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

--- Comment #17 from Eduard Staniloiu  ---
I am marking this as resolved.

I've reproduced the steps from Leandro's report, but the issue is not present
anymore; the test file containing very important data is not erased.

Then I tested the following piece of code:

// test.d
void main(string[] args) {
writeln(args[0]);
}

Running
$ dmd -run test.d
outputs: /tmp/dmd_runnUHV2q

As you can see, dmd -run now builds the code in /tmp/ and runs it from there.

All of the above have been tested using the following dmd version:
DMD64 D Compiler v2.073.0-devel-ab9d712

--

[Issue 16659] Clarify mutating while iterating rules

[via Digitalmars-d-bugs]

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

--- Comment #2 from Andrei Alexandrescu  ---
See also: http://forum.dlang.org/thread/nvcspd$1ttj$1...@digitalmars.com

--

Re: __traits(getMember)

[Márcio Martins via Digitalmars-d]

On Wednesday, 2 November 2016 at 19:49:24 UTC, Jacob Carlborg 
wrote:

On 2016-11-02 17:30, Márcio Martins wrote:

Can we get a getMember and a getOverloads that won't check for
visibility or anything else?

__traits appears really powerful, but every-time I try to use 
it for
anything other than a toy example or very simple 
serialization, it seems
like everything falls apart due to some detail... and I end up 
having to
hack it up with string mixins and static if(is(typeof(() { 
some_code; }))).


For serialization, where you most likely only need to access 
the fields, you can use .tupleof which will bypass the 
protection.


@Jonathan I am on 2.072.0, but good to know it's coming.
@Jacob Thanks, that's good to know!

[Issue 16659] Clarify mutating while iterating rules

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--

[Issue 16659] Clarify mutating while iterating rules

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--- Comment #1 from Andrei Alexandrescu  ---
Alex, I'm passing this to you since you've already looked at AAs a bit.

--

Re: Code signing to help with Windows virus false positives

[Andrei Alexandrescu via Digitalmars-d]

On 11/3/16 7:34 AM, Ethan Watson wrote:

Turns out we have some good contacts at F-Secure though. So I can see
about getting the problem fixed at the detection level - and because of
the way the security community operates, that knowledge should flush
across to things like Windows Defender.


That would be awesome. Thanks! -- Andrei

[Issue 16659] Clarify mutating while iterating rules

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--

Re: Release D 2.072.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 03.11.2016 um 06:58 schrieb Andre Pany:

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub (v1.1.0), comes
with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin


Thanks for the new release.

There is an issue with this Dub version, which is as far as I understand
a bug.
While building/running a single source file project (dub information
included in D source file) the artifacts are created in a temporary
folder instead of the source file folder.
This makes the single file functionality in dub more or less not usable
for me, as you cannot influence the behavior.

http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/13012/

Kind regards
André


Temp-folder builds are only done if the special shebang invocation 
syntax is used (i.e. "dub file.d --single file.d" should build normally. This was the case within the 
thread, too. Has anything changed since then?

Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!

[Sönke Ludwig via Digitalmars-d]

Am 03.11.2016 um 04:43 schrieb Vladimir Panteleev:

For each function that is only called during compilation (e.g. for code
generation), at the top add:

if (!__ctfe)
return;

That's it. For one project, this brought compilation time (with
optimizations) from over an hour down to seconds!

As it turns out, DMD will codegen all functions, even templated ones
when they're instantiated, whether they're called by something or not.
With metaprogramming-heavy code, it's easy to run into some optimizer
performance corner cases, however this may make an impact regardless.



Does "if (!_ctfe) assert(false);" work, too? That would also protect 
against accidential mistakes.

Re: Code signing to help with Windows virus false positives

[Ethan Watson via Digitalmars-d]

http://imgur.com/5DnCWYw

One of our guys just tried compiling and running a simple Hello 
World program. F-Secure jumped right in.


Code signing the compiler isn't enough. It's been a persistent 
problem around here with DMD generated binaries that F-Secure 
will pick it up. Needless to say, if this happens out in the wild 
with one of our games you won't want me to paste a single line 
from the feedback we'll get about the game not working.


Turns out we have some good contacts at F-Secure though. So I can 
see about getting the problem fixed at the detection level - and 
because of the way the security community operates, that 
knowledge should flush across to things like Windows Defender.

Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!

[Dmitry Olshansky via Digitalmars-d]

On 11/3/16 5:20 AM, Andrei Alexandrescu wrote:

On 11/02/2016 11:43 PM, Vladimir Panteleev wrote:

For each function that is only called during compilation (e.g. for code
generation), at the top add:

if (!__ctfe)
return;

That's it. For one project, this brought compilation time (with
optimizations) from over an hour down to seconds!

As it turns out, DMD will codegen all functions, even templated ones
when they're instantiated, whether they're called by something or not.
With metaprogramming-heavy code, it's easy to run into some optimizer
performance corner cases, however this may make an impact regardless.



That's interesting. cc Dmitry, perhaps adding that to ctRegex would be
helpful. -- Andrei



For ctRegex it's hardly applicable as it reuses the same code for 
run-time and compile-time version.


---
Dmitry Olshansky

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Thursday, 3 November 2016 at 00:02:46 UTC, Stefan Koch wrote:

No need for prayer.

I am trying my best to be doing solid engineering work.

Neither god nor the devil will paly any role.


Got it.

Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!

[Era Scarecrow via Digitalmars-d]

On Thursday, 3 November 2016 at 03:43:06 UTC, Vladimir Panteleev 
wrote:
For each function that is only called during compilation (e.g. 
for code generation), at the top add:


if (!__ctfe)
return;

That's it. For one project, this brought compilation time (with 
optimizations) from over an hour down to seconds!


As it turns out, DMD will codegen all functions, even templated 
ones when they're instantiated, whether they're called by 
something or not.


 Sounds like an issue. Although, I almost think a @noctfe tag 
which would refuse to compile/use code during CTFE, or in effect 
add that line at the beginning to functions invisibly.


 Obviously having functions only voluntarily used for CTFE would 
be a pain. having a section Opt Out after a certain point seems 
more useful, and would require far less work for the programmers.

Re: Error: function std.stdio.setmode is not accessible from module a

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, November 03, 2016 03:25:31 Kirill Kryukov via Digitalmars-d-
learn wrote:
> Thanks for the explanation, Jonathan! OK, I'll try adding my own
> binding for the time being, and submit a feature request.
>
> I guess this does not count as regression since it was
> undocumented, as you say. Although I would have thought it was a
> documentation deficiency instead. Working, not obviously wrong
> code stopped working without an alternative method available.
> Perhaps it's OK if it can be added to druntime the future.

It's a C binding, and there aren't supposed to be any public C bindings in
Phobos outside of etc.c, and even that is pretty much a legacy thing, since
bindings for 3rd party projects would normally go in deimos now. So, it's
clear that it was accidental that setmode was public, and any time that you
use a symbol that doesn't have a ddoc comment on it, you risk that your code
will break later, even if that symbol really should have been private or
package. It's not in the documentation, so it's an implementation detail and
not part of the Phobos API. And there has been some recent work to make sure
that undocumented symbols are either properly documented or made private or
package, so anyone using undocumented symbols from Phobos definitely runs a
risk of their code breaking, as you experienced.

> Also I am confused by it being both deprecation and error. I
> thought that deprecation message was just a warning about
> something that will stop working in the future, and the code
> should still compile. However in this case dmd first informs me
> that something is deprecated (it's not clear what exactly is
> deprecated). And then immediately fails with an error, on the
> same function call. Is it another separate diagnostic issue, or
> is it working as intended?

That part is definitely weird. I don't know what's going on there exactly,
but it probably relates to how private symbols used to be considered for
stuff like function overloading just like public symbols, and the access
level was only considered after that (meaning that private symbols could
cause symbol conflicts), whereas that was fixed a release or two back. But I
don't think that the symbol is actually completely invisible now like that
deprecation warning implies, just not considered in overloading. But I don't
know. Regardless, it's a diagnostic issue separate from setmode
specifically. You can reproduce it easily enough with just creating a module
with a private symbol and trying to use it in a module that imports it.

So, that may very well merit a bug report. It's certainly not how
deprecation warnings normally work, and I don't know under what
circumstances you could get that warning without the error. The only time
that I'm sure there's a difference is when there's a symbol conflict with a
private symbol, and previously, you would have gotten an error, whereas now,
you wouldn't, so there's nothing to warn about, just an error that went
away.

- Jonathan M Davis

Re: Is the following code legal?

[Shachar Shemesh via Digitalmars-d]

On 02/11/16 16:52, Andrei Alexandrescu wrote:

We should render it defined, and document it as such. Could you please
create an issue and I'll have someone look at it. Thanks! -- Andrei


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

[Issue 16659] New: Clarify mutating while iterating rules

[via Digitalmars-d-bugs]

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

  Issue ID: 16659
   Summary: Clarify mutating while iterating rules
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: shac...@shemesh.biz

Consider the following program:
int[int] hash;

..

foreach( key, ref value; hash ) {
if( value>12 )
hash.remove(key);
}

There is no reference in https://dlang.org/spec/hash-map.html whether this is
legal or not (i.e. - removing an element from the hash while iterating it).

According to http://dlang.org/spec/statement.html#ForeachStatement, this seems
forbidden (in which case it needs to be documented in the first link), but a
forum discussion seemed to gravitate toward needing to allow this (as C++ does,
at least since C++14).

--

Re: Linus' idea of "good taste" code

[Patrick Schluter via Digitalmars-d]

On Thursday, 3 November 2016 at 06:11:08 UTC, Joakim wrote:
On Sunday, 30 October 2016 at 10:04:02 UTC, Patrick Schluter 
wrote:

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:


It is not worth it, the web is dying.  I was stunned to see 
this chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the 
web numbers in those places are much worse. Combined with 
mobile passing even TV for time spent, there is no point in 
wasting time porting D to a dying platform.


Yes, because outside of web on mobile nothing else exists... 
bwahahahah


Pretty soon it won't:

https://mobile.twitter.com/asymco/status/793401867053195264



Even that chart shows a flattening to an asymptote not a linear 
trend. This means desktop will maube go a little bit down but it 
won't disappear. What people often forget is that professional 
office PC will never be completely replaced by mobile. What also 
happens in that branch (i.e. in office environment) is still a 
continuation to replace PC application by browser applications. 
This means that still focussing on good web solutions server or 
client side is a good investment in any case.



On Sunday, 30 October 2016 at 16:35:54 UTC, Laeeth Isharc wrote:
And wouldn't the changes to runtime and phobos be quite 
similar for both dmd and ldc? I don't see how the work flow 
would be any different as a language user whether you used an 
LDC with wasm back end,  or dmd with similar.


The changes to druntime and phobos wouldn't depend on the 
compiler used, but it is difficult to test unless you have a 
compiler with working codegen, so that usually comes first.  
You can go ahead and make changes to druntime- not much has to 
be done for phobos, as the idea is to encapsulate 
platform-specific code in druntime, though a minority of phobos 
does call platform-specific APIs- based on the spec or 
available headers, but you won't know if it will work well till 
you can run it.


Joakim - native on mobile is so much better (setting aside 
having to deal with Apple or Google)   but I guess the browser 
isn't going away on the desktop for a while yet.


I'm actually a heavy web user, have been for almost a 
quarter-century (though I don't use webapps, mostly reading), 
which is why that chart was so surprising to me.  While native 
mobile apps are usually more responsive, they are not ideal for 
reading, as I'm not going to install and load up The Verge's 
app, or an app for every other news site, every time.


The problem for the desktop browser is that the desktop is 
going away, as the linked tweet above shows.


No it is not. Linear extrapolation of an incomplete chart is 
almost always erroneous.


I went from using a FreeBSD desktop and a dumbphone five years 
ago to an Android smartphone and two Android tablets today, ie 
no desktop or laptop since my ultrabook died late last year.  
In my household, we went from using two smartphones, two PC 
laptops, and a Mac laptop four years ago to three smartphones, 
three Android tablets, and a Mac laptop today.


This is a shift that is happening in most households, as a PC 
overserves most and a mobile device will do.  Many D users are 
power users who cling to old tech like the desktop and the web, 
so they are missing this massive wave going on right now.  I 
myself missed the death of the mobile web, as I'm such a heavy 
user.


still bwahahaha, web technology will stay a bit longer, panicking 
is a bit premature yet.

Re: Linus' idea of "good taste" code

[Joakim via Digitalmars-d]

On Sunday, 30 October 2016 at 10:04:02 UTC, Patrick Schluter 
wrote:

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:


It is not worth it, the web is dying.  I was stunned to see 
this chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the 
web numbers in those places are much worse. Combined with 
mobile passing even TV for time spent, there is no point in 
wasting time porting D to a dying platform.


Yes, because outside of web on mobile nothing else exists... 
bwahahahah


Pretty soon it won't:

https://mobile.twitter.com/asymco/status/793401867053195264

On Sunday, 30 October 2016 at 16:35:54 UTC, Laeeth Isharc wrote:
And wouldn't the changes to runtime and phobos be quite similar 
for both dmd and ldc? I don't see how the work flow would be 
any different as a language user whether you used an LDC with 
wasm back end,  or dmd with similar.


The changes to druntime and phobos wouldn't depend on the 
compiler used, but it is difficult to test unless you have a 
compiler with working codegen, so that usually comes first.  You 
can go ahead and make changes to druntime- not much has to be 
done for phobos, as the idea is to encapsulate platform-specific 
code in druntime, though a minority of phobos does call 
platform-specific APIs- based on the spec or available headers, 
but you won't know if it will work well till you can run it.


Joakim - native on mobile is so much better (setting aside 
having to deal with Apple or Google)   but I guess the browser 
isn't going away on the desktop for a while yet.


I'm actually a heavy web user, have been for almost a 
quarter-century (though I don't use webapps, mostly reading), 
which is why that chart was so surprising to me.  While native 
mobile apps are usually more responsive, they are not ideal for 
reading, as I'm not going to install and load up The Verge's app, 
or an app for every other news site, every time.


The problem for the desktop browser is that the desktop is going 
away, as the linked tweet above shows.  I went from using a 
FreeBSD desktop and a dumbphone five years ago to an Android 
smartphone and two Android tablets today, ie no desktop or laptop 
since my ultrabook died late last year.  In my household, we went 
from using two smartphones, two PC laptops, and a Mac laptop four 
years ago to three smartphones, three Android tablets, and a Mac 
laptop today.


This is a shift that is happening in most households, as a PC 
overserves most and a mobile device will do.  Many D users are 
power users who cling to old tech like the desktop and the web, 
so they are missing this massive wave going on right now.  I 
myself missed the death of the mobile web, as I'm such a heavy 
user.

Re: fPIC Error

[rikki cattermole via Digitalmars-d-learn]

Took me a while to replicate your build environment but it looks like a 
false alarm.


rikki@debian:/tmp/test$ dmd test.d
rikki@debian:/tmp/test$ file test
test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, 
BuildID[sha1]=0a6394b9ec9b82e07440ab62cd71932f0ab568d1, not stripped


rikki@debian:/tmp/test$ ./test
Edit source/app.d to start your project.

rikki@debian:/tmp/test$ cat /etc/dmd.conf
;
; dmd.conf file for dmd
;
; dmd will look for dmd.conf in the following sequence of directories:
;   - current working directory
;   - directory specified by the HOME environment variable
;   - directory dmd resides in
;   - /etc directory
;
; Names enclosed by %% are searched for in the existing environment and 
inserted

;
; The special name %@P% is replaced with the path to this file
;

[Environment32]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import 
-L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC 
-defaultlib=libphobos2.so


[Environment64]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import 
-L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC 
-defaultlib=libphobos2.so

Re: Release D 2.072.0

[Andre Pany via Digitalmars-d-announce]

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub 
(v1.1.0), comes

with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin


Thanks for the new release.

There is an issue with this Dub version, which is as far as I 
understand a bug.
While building/running a single source file project (dub 
information included in D source file) the artifacts are created 
in a temporary folder instead of the source file folder.
This makes the single file functionality in dub more or less not 
usable for me, as you cannot influence the behavior.


http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/13012/

Kind regards
André