www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta D 2.069.0-b1

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.069.0.html

Please report any bugs at https://issues.dlang.org

-Martin
Oct 07 2015
next sibling parent reply extrawurst <stephan extrawurst.org> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


`The -property switch has been deprecated.` Does that mean 
 property has no effect anymore ?

--Stephan
Oct 07 2015
next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


 `The -property switch has been deprecated.` Does that mean 
  property has no effect anymore ?

 --Stephan


 From changelog:

"The -property switch used to disallow calling non-properties 
without parentheses. The switch has not been used to build Phobos 
for some time now. So naturally, code that's incompatible with 
-property has found its way in. This means, the switch has 
effectively not been supported by D at large.

Since the behaviour of the -property switch was not well-liked, 
it's been deprecated and made to have no effect when used."
Oct 08 2015
parent extrawurst <stephan extrawurst.org> writes:
On Thursday, 8 October 2015 at 07:25:36 UTC, Andrea Fontana wrote:

 On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:

 [...]


 `The -property switch has been deprecated.` Does that mean 
  property has no effect anymore ?

 --Stephan


 From changelog:

 "The -property switch used to disallow calling non-properties 
 without parentheses. The switch has not been used to build 
 Phobos for some time now. So naturally, code that's 
 incompatible with -property has found its way in. This means, 
 the switch has effectively not been supported by D at large.

 Since the behaviour of the -property switch was not well-liked, 
 it's been deprecated and made to have no effect when used."


Thanks to clear that up.

--Stephan
Oct 09 2015
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

 Does that mean  property has no effect anymore ?


 property never actually worked anyway. It is still my hope that 
it will be correctly implemented some day though - the hard 
problem it was meant to solve is still there (returning delegates 
from properties, the other things are all minor stylistic things, 
but this is outright breakage).
Oct 08 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote:

 On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

 Does that mean  property has no effect anymore ?


  property never actually worked anyway. It is still my hope 
 that it will be correctly implemented some day though


I think http://wiki.dlang.org/DIP23 reflects the most accurate 
roadmap for  property, basically being permissive w.r.t. parens. 
And who really cares whether it's rng.popFront or rng.popFront()?
Oct 08 2015
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Thursday, October 08, 2015 15:00:15 Martin Nowak via Digitalmars-d-announce
wrote:

 On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote:

 On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

 Does that mean  property has no effect anymore ?


  property never actually worked anyway. It is still my hope
 that it will be correctly implemented some day though


 I think http://wiki.dlang.org/DIP23 reflects the most accurate
 roadmap for  property, basically being permissive w.r.t. parens.
 And who really cares whether it's rng.popFront or rng.popFront()?


What's problematic with regards to requiring parens or not is when the
symbol _can't_ be called with parens. So, whether popFront is called with
parens or not realistically doesn't matter, because it's going to be a
function (theoretically, it could be a member variable that implements
opCall, but that's so unlikely that there really is no need to worry about
it IMHO). However, it _does_ matter whether something that's intended to be
used as a property or not is called with parens. Code which uses parens on
save or front is not going to work with all ranges, because they're not
always functions. So - at least in templated code - it needs to be clear
when a symbol is treated as a property, and it cannot be called with parens
if it is supposed to be a property. Enforcing that  property is called
without parens wouldn't entirely fix that problem, but it would help catch
cases where someone actually used parens when they shouldn't have.

Regardless, what we pretty much need to do with  property at some point is
make is that it's used to make it so that a single pair of parens operate on
the return value rather than the function even if we don't do anything else
with  property - otherwise properties which are delegates or other callables
aren't possible. Having DIP 23 be implemented would be great though.

- Jonathan M Davis
Oct 09 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 10 October 2015 at 01:27:09 UTC, Jonathan M Davis 
wrote:

 Regardless, what we pretty much need to do with  property at 
 some point is make is that it's used to make it so that a 
 single pair of parens operate on the return value rather than 
 the function even if we don't do anything else with  property


Right, ideally a  proptery function can perfectly replace a 
variable, but practically calling the return value seems far 
fetched.
What would you use that for, a handwritten interface struct with 
function pointers made read-only using  property?

To me the whole property discussion looks like one of those 
endless debates about an insignificant detail.
Scala and Ruby seem to do well with sloppy parens.
With the introduction of UFCS it became clear that nobody likes 
byLine().array().sort().release(), and even less 
rng.release.sort().array().front.
For some functions it's really hard to decide whether or not 
something is a property, e.g. for me Range.save is an 
action/function not a property. So for me using  property appears 
to waste time making pointless decisions.
Oct 09 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:

 What would you use that for, a handwritten interface struct 
 with function pointers made read-only using  property?


var a = var.emptyObject; // works today
a.prop = { do_stuff; }; // works today
a.prop(); // useless no op
a.prop()(); // this is needed

That one case alone is all I care about  property for.
Oct 09 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 10 October 2015 at 02:15:14 UTC, Adam D. Ruppe wrote:

 On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak 
 wrote:

 What would you use that for, a handwritten interface struct 
 with function pointers made read-only using  property?


 var a = var.emptyObject; // works today
 a.prop = { do_stuff; }; // works today
 a.prop(); // useless no op
 a.prop()(); // this is needed

 That one case alone is all I care about  property for.


That's what I meant, weird use-case, at best it's a callback 
better/setter.
I've never written such code, but even if you would, the 2 pairs 
of parens are only a tiny problem for generic code, nothing to 
warrant the invasive language feature  property is.
Oct 09 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:

 nothing to warrant the invasive language feature  property is.


There's no reason for  property to be invasive. ALL it needs to 
do is handle that one case, it shouldn't even be used anywhere 
else. Everything else is trivial or irrelevant.

And the beauty of this is it won't even break any code.
Oct 09 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/9/15 10:37 PM, Adam D. Ruppe wrote:

 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:

 nothing to warrant the invasive language feature  property is.


 There's no reason for  property to be invasive. ALL it needs to do is
 handle that one case, it shouldn't even be used anywhere else.
 Everything else is trivial or irrelevant.

 And the beauty of this is it won't even break any code.


I honestly couldn't care less about this.

What I don't like is arbitrary setter property abuse. e.g. 
somerange.find = needle;

My opinion:

Empty parens can always be omitted on functions, but need to be present 
in order to call delegates/function pointers.

 property function on struct/class method enables the instance.method = 
value; syntax. Otherwise, it's rejected (you must use 
instance.method(value); syntax). If I were defining it from scratch, I'd 
say you HAVE to use first syntax if it's marked  property, but I'm OK 
with allowing the normal syntax on  property methods.

Since we have  property, slapping it on a getter that returns a 
delegate/function pointer enables the behavior you want (why not?). 
&instance.prop I'm unsure what it should mean. I'm leaning towards that 
it means get a delegate to the property method itself, not the result of 
calling the property. This makes it behave differently than a field, but 
it already does this today.

 property on module level functions operate like methods, but allow UFCS 
calls. So:

0 params -> Obviously, like a getter (see above).
1 params -> Allow func = val syntax. Other syntaxes still allowed. 
Calling val.func syntax, if returning a delegate, I think should require 
the double parens, since IMO  property is for the setter syntax, not a 
description of a UFCS call.
2 params -> Allow firstParam.func = secondParam syntax. Other syntaxes 
still allowed.

-Steve
Oct 15 2015
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:

 That's what I meant, weird use-case, at best it's a callback 
 better/setter.
 I've never written such code, but even if you would, the 2 
 pairs of parens are only a tiny problem for generic code, 
 nothing to warrant the invasive language feature  property is.


I don't know how much metaprogramming-heavy generic code you've 
written, but I can say from first-hand experience that there is 
such a thing as Hell, and it is called Optional Parens.

Jokes aside, I've finally fixed (read: worked around using awful 
hacks) a bug where the compiler was complaining about either 
"Type.memberFunction is not callable with arguments ()" or "Need 
'this' for Type.memberFunction". I love optional parens in 
regular code, especially range-based code (doesn't everybody?), 
but I desperately want a way to ensure that the symbol that I'm 
trying to pass to a template function won't be interpreted as a 
function call instead.
Oct 09 2015
next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Saturday, October 10, 2015 02:57:01 Meta via Digitalmars-d-announce wrote:

 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:

 That's what I meant, weird use-case, at best it's a callback
 better/setter.
 I've never written such code, but even if you would, the 2
 pairs of parens are only a tiny problem for generic code,
 nothing to warrant the invasive language feature  property is.


 I don't know how much metaprogramming-heavy generic code you've
 written, but I can say from first-hand experience that there is
 such a thing as Hell, and it is called Optional Parens.


Optional parens definitely do not help with generic code - quite the
opposite. In generic code, it needs to be clear whether a symbol is supposed
to represent a field or a function. If it's a field, you call it without
parens. If it's a function, it has to be called with parens if it's supposed
to be possible to have the symbol emulate a function rather than be a
function (e.g. be a delegate).

We mostly get away with optional parens on function calls in generic code,
because it's pretty rare that we write code that's expecting a function and
is given a delegate, except in the cases (like predicates) where we clearly
expect any kind of callable, and we have to use template wrappers (e.g.
std.functional.binary) in those cases in order to make them all act the same
and not care about what exactly we're getting.

For symbols that are supposed to act like fields, they can't be called with
parens in generic code, or they won't work generically, and unlike with
symbols that are supposed to act like functions, it's _very_ common to get a
mix of variables and functions for the same symbol across different types.
So, generic code that uses parens on what is supposed to be a field will
work with a function but fail miserably if the type it's given implemented
that symbol as a variable. And that's common enough that generic code needs
to get it right, whereas it can mostly get away with it with symbols that
represent functions simply due to the fact that they're pretty much always
implemented as functions.

I don't think that there's any question that generic code would be better
off if we didn't have optional parens and if functions which used the
property syntax weren't allowed to be called with parens. And D programs
typically have a lot of generic code.

The problem is that when folks are writing code that uses generic functions
(rather than necessarily being inside of generic functions), they like to
leave off the parens and think that it's ugly to be required to have them.
So, we don't have full property enforcement and will never get it. But that
same laxity inside of generic code easily leads to compilation failures when
properties are used simply because a function will work with parens (be it
an  property function or not) whereas variables won't.

Hands down, I think that we'd be better off with strict property enhancement
due to all of the generic code that we deal with, but that water is long
since under the brigde.

Instead, we're forever going to be forced to be even more thorough with unit
testing in order to make sure that templated functions don't use parens on
symbols that are supposed to be properties/fields and to make sure that it
does use parens on something that is supposed to be a function. Since, any
time we don't do that, we risk making mistakes and writing generic code that
doesn't work with all of the types that it's supposed to work with.

The only question at this point is whether we can at least get partial
property enforcement out of  property and reduce the number of bugs in
generic code or whether  property is pretty much just going to be tossed
out.

- Jonathan M Davis
Oct 10 2015
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:

 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak 
 wrote:

 That's what I meant, weird use-case, at best it's a callback 
 better/setter.
 I've never written such code, but even if you would, the 2 
 pairs of parens are only a tiny problem for generic code, 
 nothing to warrant the invasive language feature  property is.


 I don't know how much metaprogramming-heavy generic code you've 
 written, but I can say from first-hand experience that there is 
 such a thing as Hell, and it is called Optional Parens.

 Jokes aside, I've finally fixed (read: worked around using 
 awful hacks) a bug where the compiler was complaining about 
 either "Type.memberFunction is not callable with arguments ()" 
 or "Need 'this' for Type.memberFunction". I love optional 
 parens in regular code, especially range-based code (doesn't 
 everybody?), but I desperately want a way to ensure that the 
 symbol that I'm trying to pass to a template function won't be 
 interpreted as a function call instead.


To the next person that is going to say this is overblown, I ran 
into such bugs more than once in phobos.

So, unless we expect most D developer to be better than phobos 
contributor, that is a problem.
Oct 10 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 11 Oct 2015 01:54:39 +0000
schrieb deadalnix <deadalnix gmail.com>:


 On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:

 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak 
 wrote:

 That's what I meant, weird use-case, at best it's a callback 
 better/setter.
 I've never written such code, but even if you would, the 2 
 pairs of parens are only a tiny problem for generic code, 
 nothing to warrant the invasive language feature  property is.


 I don't know how much metaprogramming-heavy generic code you've 
 written, but I can say from first-hand experience that there is 
 such a thing as Hell, and it is called Optional Parens.

 Jokes aside, I've finally fixed (read: worked around using 
 awful hacks) a bug where the compiler was complaining about 
 either "Type.memberFunction is not callable with arguments ()" 
 or "Need 'this' for Type.memberFunction". I love optional 
 parens in regular code, especially range-based code (doesn't 
 everybody?), but I desperately want a way to ensure that the 
 symbol that I'm trying to pass to a template function won't be 
 interpreted as a function call instead.


 
 To the next person that is going to say this is overblown, I ran 
 into such bugs more than once in phobos.
 
 So, unless we expect most D developer to be better than phobos 
 contributor, that is a problem.
 


We even have such a problem in object.d:

https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L1461

I remember somebody asking in D.learn why his custom test runner did
not work. Problem was related to wrong parenthesis: The user wrote
mod.unitTest() instead of mod.unitTest()() IIRC. Unfortunately I can't
find the exact link right now.
Oct 11 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-10-11 11:45, Johannes Pfau wrote:


 We even have such a problem in object.d:

 https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L1461

 I remember somebody asking in D.learn why his custom test runner did
 not work. Problem was related to wrong parenthesis: The user wrote
 mod.unitTest() instead of mod.unitTest()() IIRC. Unfortunately I can't
 find the exact link right now.


That would be me :) [1]. I think the biggest issue was that something 
that worked before stopped working, because a field was changed to a 
method and the method returned a function pointer.

[1] 
http://forum.dlang.org/thread/kaara7$dog$1 digitalmars.com#post-kaara7:24dog:241:40digitalmars.com

-- 
/Jacob Carlborg
Oct 11 2015
parent Kagamin <spam here.lot> writes:
On Sunday, 11 October 2015 at 09:54:04 UTC, Jacob Carlborg wrote:

 That would be me :) [1]. I think the biggest issue was that 
 something that worked before stopped working, because a field 
 was changed to a method and the method returned a function 
 pointer.

 [1] 
 http://forum.dlang.org/thread/kaara7$dog$1 digitalmars.com#post-kaara7:24dog:241:40digitalmars.com


That refactoring is exactly the (only) use case for strict 
properties, they shouldn't be used in other cases.
Oct 13 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:

 I don't know how much metaprogramming-heavy generic code you've 
 written, but I can say from first-hand experience that there is 
 such a thing as Hell, and it is called Optional Parens.

 Jokes aside, I've finally fixed (read: worked around using 
 awful hacks) a bug where the compiler was complaining about 
 either "Type.memberFunction is not callable with arguments ()" 
 or "Need 'this' for Type.memberFunction". I love optional 
 parens in regular code, especially range-based code (doesn't 
 everybody?), but I desperately want a way to ensure that the 
 symbol that I'm trying to pass to a template function won't be 
 interpreted as a function call instead.


Well, in order to pass the result of a function call to a 
template parameter means that the function must be evaluated at 
compile time, which is not always possible, so it probably 
doesn't make sense to call a function when passed as a template 
argument.
Oct 13 2015
parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 13 October 2015 at 13:18:36 UTC, Kagamin wrote:

 Well, in order to pass the result of a function call to a 
 template parameter means that the function must be evaluated at 
 compile time, which is not always possible, so it probably 
 doesn't make sense to call a function when passed as a template 
 argument.


You'd be surprised what DMD thinks is a function call and what 
isn't.
Oct 13 2015
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 13 October 2015 at 13:57:15 UTC, Meta wrote:

 On Tuesday, 13 October 2015 at 13:18:36 UTC, Kagamin wrote:

 Well, in order to pass the result of a function call to a 
 template parameter means that the function must be evaluated 
 at compile time, which is not always possible, so it probably 
 doesn't make sense to call a function when passed as a 
 template argument.


 You'd be surprised what DMD thinks is a function call and what 
 isn't.


What doesn't work for you?

extern int f();
struct T(F){}
T!f t; //Error: template instance T!(f) does not match template 
declaration T(F)
struct A(alias F){}
A!f a; //works
Oct 13 2015
parent Meta <jared771 gmail.com> writes:
On Tuesday, 13 October 2015 at 16:07:50 UTC, Kagamin wrote:

 What doesn't work for you?

 extern int f();
 struct T(F){}
 T!f t; //Error: template instance T!(f) does not match template 
 declaration T(F)
 struct A(alias F){}
 A!f a; //works


I don't remember. I fixed the issues a few weeks ago using 
various hackarounds. The main area that problems pop up is in 
metaprogramming where you don't know what you're working with 
(could be a member function, free function, template function, 
etc.). It's very hard to deal with optional parens generically, 
and you have to take special care to ensure that the compiler 
doesn't think you're calling a function when that's not what you 
meant to do.
Oct 14 2015
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:

 To me the whole property discussion looks like one of those 
 endless debates about an insignificant detail.
 Scala and Ruby seem to do well with sloppy parens.


Strict typing and explicitness has a real effect on code 
legibility and maintenance. D is trying too hard to be a 
scripting language. Taking away getter/setter typing just 
reinforce that impression.


 With the introduction of UFCS it became clear that nobody likes 
 byLine().array().sort().release(), and even less 
 rng.release.sort().array().front.


Introduce a pipeline operator. Chaining processes with dot 
operators has always been an ugly old OO hack.


 For some functions it's really hard to decide whether or not 
 something is a property, e.g. for me Range.save is an 
 action/function not a property. So for me using  property 
 appears to waste time making pointless decisions.


If it is hard to decide then that probably means that the model 
is flawed and needs more work.

D really needs to start strengthening the type system, rather 
than eroding it.
Oct 09 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-10-10 03:52, Martin Nowak wrote:


 Scala and Ruby seem to do well with sloppy parens.


A few notes about why Ruby doesn't have the same problems as D has:

1. Ruby has optional parentheses for all method calls, regardless if 
they accept arguments or not

2. Ruby has a different syntax for calling lambdas from calling functions:

def foo
end



a = -> { }



In Ruby, no one will ever use empty parentheses for calling a method.

3. You can not use the setter syntax for a "regular" method taking one 
argument:

class Foo
   def bar(a)
   end


   end
end

a = Foo.new




-- 
/Jacob Carlborg
Oct 10 2015
next sibling parent Iain Buclaw via Digitalmars-d-announce writes:
On 10 October 2015 at 14:51, Jacob Carlborg via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On 2015-10-10 03:52, Martin Nowak wrote:

 Scala and Ruby seem to do well with sloppy parens.


 A few notes about why Ruby doesn't have the same problems as D has:

 1. Ruby has optional parentheses for all method calls, regardless if they
 accept arguments or not

 2. Ruby has a different syntax for calling lambdas from calling functions:

 def foo
 end



 a = -> { }



 In Ruby, no one will ever use empty parentheses for calling a method.

 3. You can not use the setter syntax for a "regular" method taking one
 argument:

 class Foo
   def bar(a)
   end


   end
 end

 a = Foo.new





It seems to be a misfeature of D to accept the equivalent of all three of
those examples as valid.



 Oct 10 2015



prev sibling  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
wrote:

 In Ruby, no one will ever use empty parentheses for calling a 
 method.


That's actually the same as Simula. Functions/procedures with no 
parameters is called without parentheses.



 Oct 10 2015



  parent reply deadalnix <deadalnix gmail.com>  writes:


On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
 wrote:

 In Ruby, no one will ever use empty parentheses for calling a 
 method.


 That's actually the same as Simula. Functions/procedures with 
 no parameters is called without parentheses.


That's actually quite beautiful in its simplicity.



 Oct 10 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Sunday, 11 October 2015 at 01:52:12 UTC, deadalnix wrote:

 On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim 
 Grøstad wrote:

 On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
 wrote:

 In Ruby, no one will ever use empty parentheses for calling a 
 method.


 That's actually the same as Simula. Functions/procedures with 
 no parameters is called without parentheses.


 That's actually quite beautiful in its simplicity.


It is ok, but I find it more confusing than the C syntax when 
using a plain text editor. With distinguishing syntax colouring 
it might work out better, it is one of those cases where an IDE 
could make a difference.

Nygaard et al later improved on the uniformity of Simula in the 
language BETA by recognizing that a parameter list is the same as 
a tuple, with this syntax:

    input_tuple -> object_or_function -> output_tuple;
    (1,(2,3)) -> something1 -> something2 -> (a,b)
    (1,(2,3)) -> &run_concurrent_object

Without any input tuple, one can naturally omit the input arrow.

That also means that BETA does not distinguish between a function 
call and an assignment. An instanced object is just a function 
that persist state over calls, aka variable or a 
process/coroutine. A class type acts like a function when it 
called without being already instanced. So I think it provides 
better orthogonality than in C++/D where you can have both opCall 
and opAssign.

The downside by having the consise BETA syntax and OO semantics 
is that you need to change how you conceptualize OO modelling.

BETA has been generalized further in the academic language gbeta, 
which also have some dependent typing. Which is kind of 
interesting in relation to D, because it appears to be heavily 
built upon mixins:

http://www.daimi.au.dk/~eernst/gbeta/



 Oct 11 2015



  parent reply Meta <jared771 gmail.com>  writes:


On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad 
wrote:

 That also means that BETA does not distinguish between a 
 function call and an assignment.


Hey, neither does D!

writeln("Hello, World!");
writeln = "Hello, World!";



 Oct 11 2015



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote:

 On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad 
 wrote:

 That also means that BETA does not distinguish between a 
 function call and an assignment.


 Hey, neither does D!

 writeln("Hello, World!");
 writeln = "Hello, World!";


But BETA has a single syntax for it:

"Hello, World!" -> writeln;



 Oct 11 2015



  parent reply Meta <jared771 gmail.com>  writes:


On Sunday, 11 October 2015 at 17:27:39 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote:

 On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim 
 Grøstad wrote:

 That also means that BETA does not distinguish between a 
 function call and an assignment.


 Hey, neither does D!

 writeln("Hello, World!");
 writeln = "Hello, World!";


 But BETA has a single syntax for it:

 "Hello, World!" -> writeln;


Just a joke; I consider this a terrible  aspect of D.



 Oct 11 2015



  parent  Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Sunday, 11 October 2015 at 17:57:54 UTC, Meta wrote:

 Just a joke; I consider this a terrible  aspect of D.


:) I never know what is a joke or not in the forums these days.

Anyway, a key difference is that a key inspiration for both BETA 
and also the actor model is modelling physical (or imaginary) 
world processes . In that context it makes sense to think of a 
variable as a "process/object" that can store what you send to it 
just like a printer is an "process/object" asked to print what 
you send to it.

Most imperative languagedesign struggles with the stateful 
process vs pure math aspect of programming IMO.



 Oct 11 2015



prev sibling  parent  deadalnix <deadalnix gmail.com>  writes:


On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:

 Right, ideally a  proptery function can perfectly replace a 
 variable, but practically calling the return value seems far 
 fetched.
 What would you use that for, a handwritten interface struct 
 with function pointers made read-only using  property?


It doesn't matter. If you want an explosion of special cases, 
there is already a language for that, it is called C++.

Every time an exception is introduced, the "burden of proof" is 
to prove this exception actually bring sufficient value to pay 
for itself, not the other way around.


 To me the whole property discussion looks like one of those 
 endless debates about an insignificant detail.
 Scala and Ruby seem to do well with sloppy parens.


For what I've touched of ruby, the language is very permissive 
and nice. This is good when you do your first prototype, but this 
is also what causes it to be intractable at scale (and also 
impossible to optimize, but that is beside the point here).

Is the parentheses thing a problem ? Not really on its own, but 
it compound.

The parentheses thing and with it the special _ syntax to NOT 
call a function is not considered as a good thing by most scala 
people I've talked to.


 With the introduction of UFCS it became clear that nobody likes 
 byLine().array().sort().release(), and even less 
 rng.release.sort().array().front.
 For some functions it's really hard to decide whether or not 
 something is a property, e.g. for me Range.save is an 
 action/function not a property. So for me using  property 
 appears to waste time making pointless decisions.


One can reach the desired effect by having a consistent set of 
rules and define the calling as a fallback rewrite when there is 
an error. Namely, add a rule that says : if this is an error, add 
() and retry. Here you go, problem solved, you can use 
parentheses function call in every places it is not ambiguous 
without introducing Byzantines set of rules into the language.



 Oct 10 2015



prev sibling next sibling parent reply anonymous <anonymous example.com>  writes:


On Thursday 08 October 2015 06:14, extrawurst wrote:


 `The -property switch has been deprecated.` Does that mean 
  property has no effect anymore ?


Yes. I've made a pull request to mention that (and put a note on the spec 
page).

https://github.com/D-Programming-Language/dlang.org/pull/1119

We should probably try to finally find good semantics for  property.



 Oct 08 2015



  parent  anonymous <anonymous example.com>  writes:


On Thursday 08 October 2015 16:34, anonymous wrote:


 On Thursday 08 October 2015 06:14, extrawurst wrote:
 

 `The -property switch has been deprecated.` Does that mean 
  property has no effect anymore ?


 
 Yes.


Correction:  property has at least one effect without -property. typeof acts 
differently on properties vs non-properties.

----
struct S
{
     property int p();
    int n();
}
pragma(msg, typeof(S.init.p)); /* int */
pragma(msg, typeof(S.init.n)); /* int() -- i.e. a function */
----

I wasn't aware of this before Jonathan M Davis told me [1]. I don't think 
it's specified anywhere, at least I can't find anything.

[1] https://github.com/D-Programming-Language/dlang.org/pull/1119#issuecomment-146576866



 Oct 08 2015



prev sibling  parent  ponce <contact gam3sfrommars.fr>  writes:


On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


 `The -property switch has been deprecated.` Does that mean 
  property has no effect anymore ?

 --Stephan


Now it would be great if  property was removed. It is just one 
more attribute that brings nothing to the table and take valuable 
space on the screen.



 Oct 08 2015



prev sibling next sibling parent reply Suliman <evermind live.ru>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


Is it DDMD based release?



 Oct 07 2015



  parent reply Martin Nowak <code dawg.eu>  writes:


On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:

 Is it DDMD based release?


Yes.



 Oct 08 2015



 next sibling parent reply lobo <swamplobo gmail.com>  writes:


On Thursday, 8 October 2015 at 09:17:16 UTC, Martin Nowak wrote:

 On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:

 Is it DDMD based release?


 Yes.


Is there any info on the benchmarking between DDMD and DMD?

bye,
lobo

PS: Big thanks for the much improved release process that you 
guys are maintaining.



 Oct 08 2015



 next sibling parent  Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 10/08/2015 11:36 AM, lobo wrote:

 
 Is there any info on the benchmarking between DDMD and DMD?


Still on the todo list to decide whether we need to use gdc to build ddmd.
https://trello.com/c/OT6jlFNa/85-rebench-ddmd-vs-dmd-compiler-speed



 Oct 08 2015



prev sibling  parent  Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com>  writes:


On Thursday, 8 October 2015 at 09:36:31 UTC, lobo wrote:

 PS: Big thanks for the much improved release process that you 
 guys are maintaining.


I agree. Thank you, Martin.



 Oct 08 2015



prev sibling  parent reply Andrea Fontana <nospam example.com>  writes:


On Thursday, 8 October 2015 at 09:17:16 UTC, Martin Nowak wrote:

 On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:

 Is it DDMD based release?


 Yes.


Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
2.068.2?



 Oct 08 2015



  parent reply Martin Nowak <code dawg.eu>  writes:


On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana wrote:

 Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
 2.068.2?


The last released compiler, we don't have any bootstrap method 
(using a small C++ compiler or so).



 Oct 08 2015



  parent reply David Nadlinger <code klickverbot.at>  writes:


On Thursday, 8 October 2015 at 15:01:31 UTC, Martin Nowak wrote:

 On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana 
 wrote:

 Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
 2.068.2?


 The last released compiler, we don't have any bootstrap method 
 (using a small C++ compiler or so).


One does not exclude the other. You could still re-build 2.069b1 
using itself.

  — David



 Oct 08 2015



  parent  Andrea Fontana <nospam example.com>  writes:


On Thursday, 8 October 2015 at 15:04:08 UTC, David Nadlinger 
wrote:

 On Thursday, 8 October 2015 at 15:01:31 UTC, Martin Nowak wrote:

 On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana 
 wrote:

 Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with 
 dmd 2.068.2?


 The last released compiler, we don't have any bootstrap method 
 (using a small C++ compiler or so).


 One does not exclude the other. You could still re-build 
 2.069b1 using itself.

  — David


Sure, just to know which option is used.

I think rebuilding 2.069b1 with 2.069b1 could help to find bugs 
and, of course, can takes advantages from the new improvements... 
am I missing something?



 Oct 09 2015



prev sibling next sibling parent  drug <drug2004 bk.ru>  writes:


08.10.2015 01:33, Martin Nowak пишет:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


Cool!

References to `cmp`, `std.experimental.allocator` reference to current 
phobos, not prerelease one. I tryied to modify the page but can't find 
info about used macros to do it.



 Oct 07 2015



prev sibling next sibling parent  Tourist <gravatar gravatar.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


The "libcurl is now loaded dynamically" link is broken.



 Oct 08 2015



prev sibling next sibling parent  Andrea Fontana <nospam example.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


Got an issue:
https://issues.dlang.org/show_bug.cgi?id=15177

It's really strange and difficult to reduce for me...



 Oct 08 2015



prev sibling next sibling parent  Ilya Yaroshenko <ilyayaroshenko gmail.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


Thanks!

Please add the PR about allocators for the next beta
https://github.com/D-Programming-Language/phobos/pull/3684

-Ilya



 Oct 08 2015



prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


Am I being dumb or does SYSCONFDIR do absolutely nothing...



 Oct 08 2015



  parent  John Colvin <john.loughran.colvin gmail.com>  writes:


On Thursday, 8 October 2015 at 12:32:59 UTC, John Colvin wrote:

 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


 Am I being dumb or does SYSCONFDIR do absolutely nothing...


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



 Oct 09 2015



prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


I think it should be mentioned in the change log the substantial 
improvements that were made to the docs since last release. After 
over 30 PRs were merged for improving the docs, they are WAY 
better than the 2.068 docs.



 Oct 08 2015



  parent  Martin Nowak <code dawg.eu>  writes:


On Thursday, 8 October 2015 at 14:59:15 UTC, Jack Stouffer wrote:

 I think it should be mentioned in the change log the 
 substantial improvements that were made to the docs since last 
 release. After over 30 PRs were merged for improving the docs, 
 they are WAY better than the 2.068 docs.


Sure, just add it to the changelog.
https://github.com/D-Programming-Language/dlang.org/pull/1118



 Oct 08 2015



prev sibling next sibling parent reply ponce <contact gam3sfrommars.fr>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.


Weren't there codegen improvements in DMD?



 Oct 08 2015



  parent  Jack Stouffer <jack jackstouffer.com>  writes:


On Thursday, 8 October 2015 at 16:12:52 UTC, ponce wrote:

 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:

 First beta for the 2.069.0 release.


 Weren't there codegen improvements in DMD?


https://github.com/D-Programming-Language/dlang.org/pull/1121



 Oct 08 2015



prev sibling next sibling parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 10/07/2015 06:33 PM, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


Can we please get this one in?:

https://github.com/D-Programming-Language/dmd/pull/4745

I'm getting tired of watching, updating and rebasing it, and also tired 
of the paragraphs in my generated docs being all messed up.



 Oct 08 2015



prev sibling next sibling parent reply NVolcz <niklas.volcz gmail.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


The changelog links to:
http://dlang.org/phobos/std_experimental_allocator.html
which returns 404 for me.
I remember seeing discussions about versioning the docs. What 
happened to that?



 Oct 08 2015



 next sibling parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 10/8/15 4:59 PM, NVolcz wrote:

 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


 The changelog links to:
 http://dlang.org/phobos/std_experimental_allocator.html
 which returns 404 for me.
 I remember seeing discussions about versioning the docs. What happened
 to that?


This is because the current docs are for the current release, not the 
to-be-released version.

Try http://dlang.org/phobos-prerelease/std_experimental_allocator.html

-Steve



 Oct 08 2015



prev sibling  parent  Martin Nowak <code dawg.eu>  writes:


On Thursday, 8 October 2015 at 20:59:57 UTC, NVolcz wrote:

 The changelog links to:
 http://dlang.org/phobos/std_experimental_allocator.html
 which returns 404 for me.
 I remember seeing discussions about versioning the docs. What 
 happened to that?


Fixed by now.



 Oct 08 2015



prev sibling next sibling parent reply Joakim <dlang joakim.fea.st>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


I just noticed that you added the beta to the main download page, 
nice move, probably overdue.  Has it increased the downloads 
much?  Maybe you should add a warning there, for those who may 
not know the meaning of a beta.



 Oct 09 2015



  parent  Andrea Fontana <nospam example.com>  writes:


On Friday, 9 October 2015 at 09:32:05 UTC, Joakim wrote:

 downloads much?  Maybe you should add a warning there, for 
 those who may not know the meaning of a beta.


If you're a coder you know what it means.
If you just started with programming probably it doesn't make any 
difference :)



 Oct 09 2015



prev sibling next sibling parent  deadalnix <deadalnix gmail.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


First beta, so far I can use it as a drop in replacement. Nothing 
broke. It's like magic :)

Very good job :)



 Oct 10 2015



prev sibling next sibling parent  John Colvin <john.loughran.colvin gmail.com>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


brew reinstall dmd --devel

:) thanks for all the hard work



 Oct 12 2015



prev sibling  parent reply ZombineDev <valid_email he.re>  writes:


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


I decided to try the newly included mscoff 32 Phobos. For this 
purpouse I create a D struct, whose members I call in C++. This 
works in Linux, so any issues should be windows specific.

My directory has the following files:
test_struct.d
main.cpp

I did the following:
1) Installed DMD v2.069.0-b1 with the installer
2) Started VS2015 x86 Native Tools Command Prompt
3) Executed the following commands:
dmd -c -m32mscoff test_struct.d
cl main.cpp test_struct.obj 
C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib

And got the following error:
main.cpp
phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
unresolved exter
nal symbol __minfo_beg referenced in function 
_D2rt14sections_win6414getModuleIn
fosFZAyPS6object10ModuleInfo
phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
unresolved exter
nal symbol __minfo_end referenced in function 
_D2rt14sections_win6414getModuleIn
fosFZAyPS6object10ModuleInfo
phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: 
unresolved external symb
ol _snprintf referenced in function 
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAx
aKfZb
phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: 
unresolved external symb
ol _sscanf referenced in function 
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaK
fZb
hw0_cpp.exe : fatal error LNK1120: 4 unresolved externals

I have declared the druntime hooks like this:
extern "C" int rt_init();
extern "C" void rt_term();

P.S. I decided to try something simpler:
A single .cpp file that calls rt_init() and rt_term() and nothing 
else. I tried the following:
cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib
And I got the same error message.

Any idea what's going wrong?



 Oct 13 2015



  parent reply ZombineDev <valid_email he.re>  writes:


On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:

 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:

 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin


 I decided to try the newly included mscoff 32 Phobos. For this 
 purpouse I create a D struct, whose members I call in C++. This 
 works in Linux, so any issues should be windows specific.

 My directory has the following files:
 test_struct.d
 main.cpp

 I did the following:
 1) Installed DMD v2.069.0-b1 with the installer
 2) Started VS2015 x86 Native Tools Command Prompt
 3) Executed the following commands:
 dmd -c -m32mscoff test_struct.d
 cl main.cpp test_struct.obj 
 C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib

 And got the following error:
 main.cpp
 phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
 unresolved exter
 nal symbol __minfo_beg referenced in function 
 _D2rt14sections_win6414getModuleIn
 fosFZAyPS6object10ModuleInfo
 phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
 unresolved exter
 nal symbol __minfo_end referenced in function 
 _D2rt14sections_win6414getModuleIn
 fosFZAyPS6object10ModuleInfo
 phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: 
 unresolved external symb
 ol _snprintf referenced in function 
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAx
 aKfZb
 phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: 
 unresolved external symb
 ol _sscanf referenced in function 
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaK
 fZb
 hw0_cpp.exe : fatal error LNK1120: 4 unresolved externals


Edit - read this as:
main.exe : fatal error LNK1120: 4 unresolved externals


 I have declared the druntime hooks like this:
 extern "C" int rt_init();
 extern "C" void rt_term();

 P.S. I decided to try something simpler:
 A single .cpp file that calls rt_init() and rt_term() and 
 nothing else. I tried the following:
 cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib
 And I got the same error message.

 Any idea what's going wrong?





 Oct 13 2015



  parent reply ZombineDev <valid_email he.re>  writes:


On Tuesday, 13 October 2015 at 19:17:27 UTC, ZombineDev wrote:

 On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:
 [...]


Is the problem related to the new CRT in VS2015? Previously I 
thought that the problem is 64-bit only, but it seams like it is 
for both 32-bit and 64-bit MSCOFF.

With the VS2015 x64 Native Tools Command Prompt I did:
cl main.cpp C:\D\dmd2\windows\lib64\phobos64.lib

And got:

main.cpp
phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: 
unresolved external sy
mbol _minfo_beg referenced in function 
_D2rt14sections_win6414getModuleInfosFZAy
PS6object10ModuleInfo
phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: 
unresolved external sy
mbol _minfo_end referenced in function 
_D2rt14sections_win6414getModuleInfosFZAy
PS6object10ModuleInfo
phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: 
unresolved external sy
mbol _deh_beg referenced in function 
_D2rt14sections_win6412SectionGroup8ehTable
sMxFNdZAyS2rt15deh_win64_posix9FuncTable
phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: 
unresolved external sy
mbol _deh_end referenced in function 
_D2rt14sections_win6412SectionGroup8ehTable
sMxFNdZAyS2rt15deh_win64_posix9FuncTable
phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved 
external symbol snp
rintf referenced in function 
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved 
external symbol ssc
anf referenced in function 
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
main.exe : fatal error LNK1120: 6 unresolved externals

AFAIR, the support for VS2015 CRT was merged and is included in 
this release, correct?



 Oct 13 2015



  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 13.10.2015 21:44, ZombineDev wrote:

 On Tuesday, 13 October 2015 at 19:17:27 UTC, ZombineDev wrote:

 On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:
 [...]


 Is the problem related to the new CRT in VS2015? Previously I thought
 that the problem is 64-bit only, but it seams like it is for both 32-bit
 and 64-bit MSCOFF.


The library issues are the same for 32-bit and 64-bit.


 With the VS2015 x64 Native Tools Command Prompt I did:
 cl main.cpp C:\D\dmd2\windows\lib64\phobos64.lib

 And got:

 main.cpp
 phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
 external sy
 mbol _minfo_beg referenced in function
 _D2rt14sections_win6414getModuleInfosFZAy
 PS6object10ModuleInfo
 phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
 external sy
 mbol _minfo_end referenced in function
 _D2rt14sections_win6414getModuleInfosFZAy
 PS6object10ModuleInfo
 phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
 external sy
 mbol _deh_beg referenced in function
 _D2rt14sections_win6412SectionGroup8ehTable
 sMxFNdZAyS2rt15deh_win64_posix9FuncTable
 phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
 external sy
 mbol _deh_end referenced in function
 _D2rt14sections_win6412SectionGroup8ehTable
 sMxFNdZAyS2rt15deh_win64_posix9FuncTable
 phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
 symbol snp
 rintf referenced in function
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
 phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
 symbol ssc
 anf referenced in function
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
 main.exe : fatal error LNK1120: 6 unresolved externals

 AFAIR, the support for VS2015 CRT was merged and is included in this
 release, correct?


Yes, but there is some magic involved when linking against the VS2015 
CRT. To use symbols like snprintf and sscanf, you must also pass 
legacy_stdio_definitions.lib to the linker, which is done automatically 
if you use dmd as a frontend to the linker, but not cl.

Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted 
by the compiler if you compile main, WinMain or DllMain. Unfortunately, 
compiling D's main also generates a C-style main, so it's not so easy to 
get these symbols if you need main in C/C++.

I would currently recommend to write main in D, and call into C/C++ from 
there.



 Oct 13 2015



 next sibling parent reply Szymon Gatner <noemail gmail.com>  writes:


On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
wrote:

 On 13.10.2015 21:44, ZombineDev wrote:

 [...]


 The library issues are the same for 32-bit and 64-bit.


 [...]


 Yes, but there is some magic involved when linking against the 
 VS2015 CRT. To use symbols like snprintf and sscanf, you must 
 also pass legacy_stdio_definitions.lib to the linker, which is 
 done automatically if you use dmd as a frontend to the linker, 
 but not cl.

 Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only 
 emitted by the compiler if you compile main, WinMain or 
 DllMain. Unfortunately, compiling D's main also generates a 
 C-style main, so it's not so easy to get these symbols if you 
 need main in C/C++.

 I would currently recommend to write main in D, and call into 
 C/C++ from there.


I am trying (as with every new release ;)) to link static D 
library to existing C++ project and I am having same issue:

Error	2	error LNK2019: unresolved external symbol _snprintf 
referenced in function 
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb	C:\Users\Br
vo\documents\visual studio
2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj)	ConsoleApplication1

_minfo_beg, _minfo_end problems were solved by adding main() to D 
library so this is only porblem left. I am using Visual Studio 
2012



 Oct 14 2015



 next sibling parent reply Szymon Gatner <noemail gmail.com>  writes:


On Wednesday, 14 October 2015 at 11:39:26 UTC, Szymon Gatner 
wrote:

 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
 wrote:

 [...]


 I am trying (as with every new release ;)) to link static D 
 library to existing C++ project and I am having same issue:

 Error	2	error LNK2019: unresolved external symbol _snprintf 
 referenced in function 
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb	C:\Users\Br
vo\documents\visual studio
2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj)	ConsoleApplication1

 _minfo_beg, _minfo_end problems were solved by adding main() to 
 D library so this is only porblem left. I am using Visual 
 Studio 2012


Update: Linking with static D library under Visual Studio 2015 
works fine (which is great). I do need to make it work under VS 
2012 tho. Ideas?



 Oct 14 2015



  parent  Szymon Gatner <noemail gmail.com>  writes:


On Wednesday, 14 October 2015 at 12:05:28 UTC, Szymon Gatner 
wrote:

 On Wednesday, 14 October 2015 at 11:39:26 UTC, Szymon Gatner 
 wrote:

 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
 wrote:

 [...]


 I am trying (as with every new release ;)) to link static D 
 library to existing C++ project and I am having same issue:

 Error	2	error LNK2019: unresolved external symbol _snprintf 
 referenced in function 
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb	C:\Users\Br
vo\documents\visual studio
2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj)	ConsoleApplication1

 _minfo_beg, _minfo_end problems were solved by adding main() 
 to D library so this is only porblem left. I am using Visual 
 Studio 2012


 Update: Linking with static D library under Visual Studio 2015 
 works fine (which is great). I do need to make it work under VS 
 2012 tho. Ideas?


Another Update: a bug I reported many moons ago is still there 
when mixing C++ with D. I updated the issue: 
https://issues.dlang.org/show_bug.cgi?id=14327



 Oct 14 2015



prev sibling  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 14.10.2015 13:39, Szymon Gatner wrote:

 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote:

 On 13.10.2015 21:44, ZombineDev wrote:

 [...]


 The library issues are the same for 32-bit and 64-bit.


 [...]


 Yes, but there is some magic involved when linking against the VS2015
 CRT. To use symbols like snprintf and sscanf, you must also pass
 legacy_stdio_definitions.lib to the linker, which is done
 automatically if you use dmd as a frontend to the linker, but not cl.

 Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted
 by the compiler if you compile main, WinMain or DllMain.
 Unfortunately, compiling D's main also generates a C-style main, so
 it's not so easy to get these symbols if you need main in C/C++.

 I would currently recommend to write main in D, and call into C/C++
 from there.


 I am trying (as with every new release ;)) to link static D library to
 existing C++ project and I am having same issue:

 Error    2    error LNK2019: unresolved external symbol _snprintf
 referenced in function
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
 C:\Users\Bravo\documents\visual studio
 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj)
 ConsoleApplication1


I just noticed that the magic symbol translation _snprintf -> __snprintf 
isn't included without linking the internal function init_msvc (which is 
normally done by d_run_main which is called by the generated C main).

The current workaround here is to add

extern "C" void __cdecl init_msvc();

to the C source and call it before rt_init. I think we should move it 
into rt_init inside druntime.



 Oct 14 2015



  parent reply Szymon Gatner <noemail gmail.com>  writes:


On Wednesday, 14 October 2015 at 12:35:30 UTC, Rainer Schuetze 
wrote:

 I just noticed that the magic symbol translation _snprintf -> 
 __snprintf isn't included without linking the internal function 
 init_msvc (which is normally done by d_run_main which is called 
 by the generated C main).

 The current workaround here is to add

 extern "C" void __cdecl init_msvc();

 to the C source and call it before rt_init. I think we should 
 move it into rt_init inside druntime.


This indeed helps, thanks!

There is new problem: creating a class instance on D side, then 
passing it to C++ and then back to D causes casting errors. My 
Example (based on Adam Ruppe's example):

C++ file:

#include <iostream>
#include <stdio.h>

extern "C" int rt_init();
extern "C" void rt_term();

extern "C++" int sumInD(int a, int b);
extern "C++" void printHelloInD();


class Operation {
public:

   virtual ~Operation() {}

   virtual int execute(int a, int b) = 0;
};

class Add : public Operation
{
   int execute(int a, int b) override
   {
     return a + b;
   }
};

extern "C++" void useOperation(Operation* t);
extern "C++" Operation* getSubtract();
extern "C++" void freeSubtract(Operation* cat);

struct DRuntime
{
   DRuntime()
   {
     if (!rt_init())\
     {
       throw std::runtime_error("D Initialization failed");
     }
   }

   ~DRuntime()
   {
     rt_term();
   }
};

void main()
{
   DRuntime druntime;
   Add add;

   useOperation(&add);

   Operation* sub = getSubtract();
   auto value = sub->execute(5, 3);
   freeSubtract(sub);

}

D library:

module lib;
import std.stdio;
import core.stdc.stdlib;

int main()
{
   return 0;
}

extern(C++)
interface Operation {
   void _destructorDoNotUse();
   int execute(int a, int b);
}
class Subtract : Operation {

   extern(C++)
     void _destructorDoNotUse() {}
   extern(C++)
     int execute(int a, int b) {return a - b;}
}

extern(C++)
Operation getSubtract() {
   import std.conv;
   enum size = __traits(classInstanceSize, Subtract);
   auto memory = malloc(size)[0 .. size];
   return emplace!Subtract(memory);
}

extern (C++) int sumInD(int a, int b)
{
   return a + b;
}

extern (C++) void printHelloInD()
{
   writeln("Hello From D!"); << ===== throws exception (bug 
reported)
}

extern(C++)
void freeSubtract(Operation animal) {
   auto cat = cast(Subtract) animal; <<====== cast yields null
   if(cat !is null) {
     destroy(cat);
     free(cast(void*) cat);
   }
}

extern(C++)
void useOperation(Operation t) {
   auto res = t.execute(1, 2);
}

Everything works fine except the marked line. Subtract instance 
seems to be created correctly on D side as it returns valid 
result in the execute() call on C++ side but then when trying to 
free the instance on D side again, downcast from Operation to 
Subtract fails resulting in null.



 Oct 14 2015



  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 14.10.2015 14:57, Szymon Gatner wrote:

 extern(C++)
 void freeSubtract(Operation animal) {
    auto cat = cast(Subtract) animal; <<====== cast yields null
    if(cat !is null) {
      destroy(cat);
      free(cast(void*) cat);
    }
 }

 extern(C++)
 void useOperation(Operation t) {
    auto res = t.execute(1, 2);
 }

 Everything works fine except the marked line. Subtract instance seems to
 be created correctly on D side as it returns valid result in the
 execute() call on C++ side but then when trying to free the instance on
 D side again, downcast from Operation to Subtract fails resulting in null.


To get compatible class layout, the D compiler has to omit it's class 
info entry in the vtable of C++ classes. In addition D doesn't know 
about C++ RTTI (I don't know if this is planned to add), so it cannot do 
the dynamic cast from Operation to Subtract.

I have not tried, but calling the virtual destructor instead of 
destroy() might just work?



 Oct 14 2015



  parent reply Szymon Gatner <noemail gmail.com>  writes:


On Wednesday, 14 October 2015 at 13:12:00 UTC, Rainer Schuetze 
wrote:

 On 14.10.2015 14:57, Szymon Gatner wrote:

 extern(C++)
 void freeSubtract(Operation animal) {
    auto cat = cast(Subtract) animal; <<====== cast yields null
    if(cat !is null) {
      destroy(cat);
      free(cast(void*) cat);
    }
 }

 extern(C++)
 void useOperation(Operation t) {
    auto res = t.execute(1, 2);
 }

 Everything works fine except the marked line. Subtract 
 instance seems to
 be created correctly on D side as it returns valid result in 
 the
 execute() call on C++ side but then when trying to free the 
 instance on
 D side again, downcast from Operation to Subtract fails 
 resulting in null.


 To get compatible class layout, the D compiler has to omit it's 
 class info entry in the vtable of C++ classes. In addition D 
 doesn't know about C++ RTTI (I don't know if this is planned to 
 add), so it cannot do the dynamic cast from Operation to 
 Subtract.

 I have not tried, but calling the virtual destructor instead of 
 destroy() might just work?


Mint that this code comes from Adam Ruppe's book, and it is 
suppose to be working code. Also mind that Subtract is D class 
and instantiated on D side, it is only briefly passed to C++ for 
usage.



 Oct 14 2015



  parent  Rainer Schuetze <r.sagitario gmx.de>  writes:


On 14.10.2015 15:26, Szymon Gatner wrote:

 To get compatible class layout, the D compiler has to omit it's class
 info entry in the vtable of C++ classes. In addition D doesn't know
 about C++ RTTI (I don't know if this is planned to add), so it cannot
 do the dynamic cast from Operation to Subtract.

 I have not tried, but calling the virtual destructor instead of
 destroy() might just work?


 Mint that this code comes from Adam Ruppe's book, and it is suppose to
 be working code. Also mind that Subtract is D class and instantiated on
 D side, it is only briefly passed to C++ for usage.


Check the disassembly: the compiler is not even trying to do a 
conversion, it just loads null. There is no usable type information in a 
C++ interface.

If you know the object "animal" is of type Subtract, you can get the 
object pointer by manually subtracting the pointer difference from the 
passed pointer:

   auto ptr = cast(void*)animal;
   ptr -= cast(void*)cast(Operation)cast(Subtract)ptr - ptr;
   auto cat = cast(Subtract) ptr;



 Oct 14 2015



prev sibling  parent reply ZombineDev <valid_email he.re>  writes:


On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
wrote:

 Yes, but there is some magic involved when linking against the 
 VS2015 CRT. To use symbols like snprintf and sscanf, you must 
 also pass legacy_stdio_definitions.lib to the linker, which is 
 done automatically if you use dmd as a frontend to the linker, 
 but not cl.

 Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only 
 emitted by the compiler if you compile main, WinMain or 
 DllMain. Unfortunately, compiling D's main also generates a 
 C-style main, so it's not so easy to get these symbols if you 
 need main in C/C++.

 I would currently recommend to write main in D, and call into 
 C/C++ from there.


Thanks for the answer.

Just for the reference, under VS2015 x86 Native Tools Command 
Prompt I tried to link a C++ main function that only calls 
rt_init() and rt_term() like this:

cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib 
"C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\lib\legacy_stdio_definitions.lib"

I got:
main.cpp
phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
unresolved external symbol __minfo_beg referenced in function 
_D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
unresolved external symbol __minfo_end referenced in function 
_D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
main.exe : fatal error LNK1120: 2 unresolved externals

Which, based on your answer, is expected.

I'm looking into integrating D into an existing C++ build and I 
need to statically link the D library. So my next questions are:
1) Where can I find legacy_stdio_definitions.lib?
P.S.: It's included in VS (C:\Program Files (x86)\Microsoft 
Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib)
2) How can I workaround the problem that _minfo* and _deh* are 
not generated because my main is in C++?

Basically what's preventing me from using D main is that one of 
the C++ libraries I use creates threads and dispatches functions 
to run on them in manner similar to Boost ASIO, and I don't have 
control over this proprietary library.

To me, the fact that consuming D libraries from C++ works on 
Linux, but not on Windows seems like a very serious issue with 
Windows support.

I know that this is work in progress and that VS 2015 broke the 
ABI of its CRT, and it's hard to track down those problems with 
every VS release, so let me know if I can help with anything. 
Currently I do not have enough knowledge tackle the problem, but 
I am willing to learn.



 Oct 14 2015



 next sibling parent reply Szymon Gatner <noemail gmail.com>  writes:


On Wednesday, 14 October 2015 at 11:46:27 UTC, ZombineDev wrote:


 2) How can I workaround the problem that _minfo* and _deh* are 
 not generated because my main is in C++?


Just add a file with int main() in D library to fix this.



 Oct 14 2015



  parent  ZombineDev <valid_email he.re>  writes:


On Wednesday, 14 October 2015 at 11:54:22 UTC, Szymon Gatner 
wrote:

 On Wednesday, 14 October 2015 at 11:46:27 UTC, ZombineDev wrote:


 2) How can I workaround the problem that _minfo* and _deh* are 
 not generated because my main is in C++?


 Just add a file with int main() in D library to fix this.


Thanks! I didn't realize that I could add an empty main in D and 
force the linker to use the C++ main just by ordering the 
arguments to the linker :D

For 32-bit under VS2015 x86 Native Tools Command Prompt:
dmd -lib -m32mscoff my_d_lib.d
cl main.cpp my_d_lib.lib 
C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib "C:\Program 
Files (x86)\Microsoft Visual Studio 
14.0\VC\lib\legacy_stdio_definitions.lib"

And for 64-bit under VS2015 x64 Native Tools Command Prompt:
dmd -lib -m64 my_d_lib.d
cl main.cpp my_d_lib.lib C:\D\dmd2\windows\lib64\phobos64.lib 
"C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\lib\amd64\legacy_stdio_definitions.lib"

Both works for me.

Anyway, I still don't think that forcing the users to use this 
workaround is a great idea.



 Oct 14 2015



prev sibling  parent reply Rainer Schuetze <r.sagitario gmx.de>  writes:


On 14.10.2015 13:46, ZombineDev wrote:

 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote:

 Yes, but there is some magic involved when linking against the VS2015
 CRT. To use symbols like snprintf and sscanf, you must also pass
 legacy_stdio_definitions.lib to the linker, which is done
 automatically if you use dmd as a frontend to the linker, but not cl.

 Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted
 by the compiler if you compile main, WinMain or DllMain.
 Unfortunately, compiling D's main also generates a C-style main, so
 it's not so easy to get these symbols if you need main in C/C++.

 I would currently recommend to write main in D, and call into C/C++
 from there.


 Thanks for the answer.

 Just for the reference, under VS2015 x86 Native Tools Command Prompt I
 tried to link a C++ main function that only calls rt_init() and
 rt_term() like this:

 cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib "C:\Program
 Files (x86)\Microsoft Visual Studio
 14.0\VC\lib\legacy_stdio_definitions.lib"

 I got:
 main.cpp
 phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019:
 unresolved external symbol __minfo_beg referenced in function
 _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
 phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019:
 unresolved external symbol __minfo_end referenced in function
 _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
 main.exe : fatal error LNK1120: 2 unresolved externals

 Which, based on your answer, is expected.

 I'm looking into integrating D into an existing C++ build and I need to
 statically link the D library. So my next questions are:
 1) Where can I find legacy_stdio_definitions.lib?
 P.S.: It's included in VS (C:\Program Files (x86)\Microsoft Visual
 Studio 14.0\VC\lib\legacy_stdio_definitions.lib)


Your C++ project should have the library paths setup correctly to find 
it if you just add it to the additional input libraries.



 2) How can I workaround the problem that _minfo* and _deh* are not
 generated because my main is in C++?


As Szymon noticed, you can compile an empty main into the static D 
library. The additional C main that is generated by DMD won't cause 
ambiguities as long as your C main is not also in a static library.



 Oct 14 2015



  parent  ZombineDev <valid_email he.re>  writes:


On Wednesday, 14 October 2015 at 12:39:46 UTC, Rainer Schuetze 
wrote:

 As Szymon noticed, you can compile an empty main into the 
 static D library. The additional C main that is generated by 
 DMD won't cause ambiguities as long as your C main is not also 
 in a static library.


Thanks for the advice (I just found that myself). Why this 
workaround is not needed on Linux?



 Oct 14 2015