Repeated import qualifiers accepted

Doubled (or tripled, etc.) import qualifiers are accepted in some 
cases.

auto m = std.math.std.math.std.math.abs(-32.33); // no error

std.stdio.std.stdio.writeln("123"); // no error

auto fmt = std.array.std.array.appender!(string)(); // no error

auto ms = std.mathspecial.std.mathspecial.gamma(0.5); // error 
"undefined identifier mathspecial"

import std.stdio.std.stdio : writeln; // error "module stdio is 
in file 'std/stdio/std' which cannot be read"

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

via Digitalmars-d | 22 Jul 17:31 2014

Re: Integer overflow and underflow semantics?

On Tuesday, 22 July 2014 at 11:40:08 UTC, Artur Skawina via 
Digitalmars-d wrote:
> obey the exact same rules as RT. Would you really like to use a 
> language
> in which 'enum x = (a+b)/2;' and 'immutable x = (a+b)/2;' 
> results in
> different values?...

With the exception of hash-functions the result will be wrong if 
you don't predict that the value is wrapping. If you do, I think 
you should make the masking explicit e.g. specifying 
'(a+b)&0xffffffff' or something similar, which the optimizer can 
reduce to a single addition.

> That's how it is in D - the arguments are only about the 
> /default/, and in
> this case about /using a different default at CT and RT/. Using 
> a non-wrapping
> default would be a bad idea (perf implications, both direct and

Yes, but there is a difference between saying "it is ok that it 
wraps on addition, but it shouldn't overflow before a store takes 
place" and "it should be masked to N bits or fail on overflow 
even though the end-result is known to be correct". A system 
level language should encourage using the fastest opcode, so you 
shouldn't enforce 32 bit masking when the fastest register size 
is 64 bit etc. It should also encourage reordering so you get to 
use efficient SIMDy instructions.

> Not possible (for integers), unless you'd be ok with getting 
(Continue reading)

Re: What's blocking DDMD?

"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.136.1406040115.32463.digitalmars-d <at> puremagic.com...

> Hmm. We should run a profiler to find out where the performance hit is
> coming from. It should be interesting, since presumably, your script to
> translate dmd to D basically generates the D equivalent of the C++ code,
> so major performance differences would point us to areas that need
> improvement in D.

I don't think any of it is caused by D itself (except maybe some druntime 
startup/shutdown overhead).  I think it's all coming from the memory 
allocation strategies I changed to get it working and haven't finished 
changing back, and from using different optimization settings/optimizer when 
compiling.

> > Also note that the autotester is only building ddmd in debug mode -
> > the dmd I'm comparing it against was built in release mode with full
> > optimizations.
>
> Oh. Could that be the reason for the performance hit?

I'm sure that's part of it.

> One thought that occurred to me -- once the autotester goes green on all
> platforms, we should probably have the autotester include ddmd testing
> on all dmd PR's, so that during the transition period the C++ and D
> changes will be fully in sync.

That's exactly the plan. 

(Continue reading)

Tourist via Digitalmars-d | 22 Jul 16:00 2014

What's blocking DDMD?

Just curious. I remember that there was some kind of a roadmap, 
but I cannot find it now.

Re: __gshared this()

On Tuesday, 22 July 2014 at 08:33:57 UTC, Manu via Digitalmars-d 
wrote:
> Might I suggest some helpful error messages in these cases 
> where the user
> tries to do something stupid like this? :)

You may :-)

https://issues.dlang.org/

Re: Java compilation [was GCs in the news]

On Tuesday, 22 July 2014 at 08:10:31 UTC, Russel Winder via 
Digitalmars-d wrote:
> On Tue, 2014-07-22 at 06:35 +0000, Paulo Pinto via 
> Digitalmars-d wrote:
> […]
>> Yes it can, if developers bother to do PGO + AOT instead and 
>> learn the compiler flags.
>> 
>> I used to have a stronger opinion on JIT, but given how many 
>> JITs perform and do not actually use the hardware as they, in 
>> theory could, JIT tend to only be an advantage for dynamic 
>> languages not strong typed ones.
>> 
>> With JIT, writing the code in a way that makes the JIT 
>> compiler happy is a lost battle, as it depends on the exact 
>> same JIT implementation being available on the deployment 
>> system.
>
> I think you have to make good on this claim since the JVM JIT is
> intended for Java which is supposedly a static, strongly typed 
> language.

The JVM JIT was originally targeted to SELF, not Java.

> Moreover, evidence from Groovy is the JVM JIT provides only 
> patchy
> benefit. The biggest benefit all round is invokedynamic for 
> both static
> and dynamic languages. Java 8 would be nothing without 
> invokedynamic.
(Continue reading)

Re: __gshared this()

On Tuesday, 22 July 2014 at 07:27:46 UTC, Manu via Digitalmars-d 
wrote:
> We have:
>   this()   // instance constructor
>   static this()  // thread-local static constructor
>
> But what I need is:
>   __gshared this()   // not-thread-local static constructor (?)

shared static this() { ... }

http://dlang.org/class#SharedStaticConstructor

Re: __gshared this()

On Tuesday, 22 July 2014 at 07:27:46 UTC, Manu via Digitalmars-d 
wrote:
> But what I need is:
>   __gshared this()   // not-thread-local static constructor

"shared static this()" (or the other b way round, can never 
remember).

Cheers,
David

Re: GCs in the news

On Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via 
Digitalmars-d wrote:
> On Sun, 2014-07-20 at 16:40 +0000, Paulo Pinto via 
> Digitalmars-d wrote:
>
> […]
>> Java has AOT compilers available since the early days. Most 
>> developers just tend to ignore them, because they are not part 
>> of the free package.
>
> Also, it is not entirely clear that AOT optimization can beat 
> JIT
> optimization, at least on the JVM.

Yes it can, if developers bother to do PGO + AOT instead and 
learn the compiler flags.

I used to have a stronger opinion on JIT, but given how many JITs 
perform and do not actually use the hardware as they, in theory 
could, JIT tend to only be an advantage for dynamic languages not 
strong typed ones.

With JIT, writing the code in a way that makes the JIT compiler 
happy is a lost battle, as it depends on the exact same JIT 
implementation being available on the deployment system.

--
Paulo

(Continue reading)

Re: __gshared this()

On 22/07/14 08:25, Manu via Digitalmars-d wrote:

> It seems __gshared constructors aren't working... although I thought
> they did; I'm sure I've used them before in various occasions :/

What would that do? I didn't know that was possible to do.

--

-- 
/Jacob Carlborg

Manu via Digitalmars-d | 22 Jul 08:25 2014

__gshared this()

I has problems:

class T
{
__gshared int global;
int member;

this()
{
member = global;
}

__gshared this()
{
global = 10;
}
}

fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '_D2db2ui2ui1T6__ctorMFZC2db2ui2ui1T (db.ui.ui.T db.ui.ui.T.__ctor())'



Further, if I write this code:

  void f()
  {
T t = new T;
  }

Error: db.ui.ui.T.__ctor called with argument types () matches both:
     db.ui.ui.T.this()
and:
     db.ui.ui.T.this()

It seems __gshared constructors aren't working... although I thought they did; I'm sure I've used them before in various occasions :/

Gmane