www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - local import hijacking

reply Byron Heads <bheads moxiegroup.com> writes:
I got burned by this yesterday, this code should not compile

import std.experimental.logger : trace;


void foo() {
	import std.net.curl : trace;
	trace("hello");
}


void main() {
	foo();	
}


Not sure if this is a duplicate
https://issues.dlang.org/show_bug.cgi?id=15567
Jan 14 2016
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 14 Jan 2016 14:25:43 +0000
Byron Heads via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 I got burned by this yesterday, this code should not compile
 
 import std.experimental.logger : trace;
 
 
 void foo() {
 	import std.net.curl : trace;
 	trace("hello");
 }
 
 
 void main() {
 	foo();	
 }
 
 
 Not sure if this is a duplicate
 https://issues.dlang.org/show_bug.cgi?id=15567
 
 
 


No this is OK, there is no reason to not compile.

It is same as:
import std.stdio;

string trace = "trace";
void foo() {
    int trace = 7;
    writeln(trace);
}
void main() {
    foo();	
    writeln(trace);
}


local symbols can hide global symbols
Jan 14 2016
next sibling parent reply Byron Heads <bheads moxiegroup.com> writes:
On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak wrote:

 V Thu, 14 Jan 2016 14:25:43 +0000
 Byron Heads via Digitalmars-d <digitalmars-d puremagic.com> 
 napsáno:


 I got burned by this yesterday, this code should not compile
 
 import std.experimental.logger : trace;
 
 
 void foo() {
 	import std.net.curl : trace;
 	trace("hello");
 }
 
 
 void main() {
 	foo();
 }
 
 
 Not sure if this is a duplicate 
 https://issues.dlang.org/show_bug.cgi?id=15567
 
 
 


 No this is OK, there is no reason to not compile.

 It is same as:
 import std.stdio;

 string trace = "trace";
 void foo() {
     int trace = 7;
     writeln(trace);
 }
 void main() {
     foo();
     writeln(trace);
 }


 local symbols can hide global symbols




import std.experimental.logger;
void foo() {
  	import std.net.curl;

         .... lots of curl calls

  	trace("hello");

         .. more curl calls
}


void main() {
	foo();
}

std.net.curl.CurlException std\net\curl.d(4033): Couldn't resolve 
host name on handle 2188398
----------------
0x00405F65
0x00405F10
0x0040275B
0x0040259E
0x0040202B
0x00402035
0x004257A7
0x004256A8
0x0041B7FF
0x769F337A in BaseThreadInitThunk
0x77429882 in RtlInitializeExceptionChain
0x77429855 in RtlInitializeExceptionChain

This was a 4 hour debug which made it worse as I was adding more 
trace calls to figure out what was going on.  My boss is now on 
the fence, to many compiler bugs with D, he asked me to switch to 
Java if I have to deal to many more issues like this.. 
(https://issues.dlang.org/show_bug.cgi?id=15457  another issue we 
had)

And this awesome stack trace helped me so much to track this 
issue down...
Jan 14 2016
next sibling parent Byron Heads <bheads moxiegroup.com> writes:
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:

 On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak 
 wrote:

 [...]




 import std.experimental.logger;
 void foo() {
  	import std.net.curl;

         .... lots of curl calls

  	trace("hello");

         .. more curl calls
 }


 void main() {
 	foo();
 }

 std.net.curl.CurlException std\net\curl.d(4033): Couldn't 
 resolve host name on handle 2188398
 ----------------
 0x00405F65
 0x00405F10
 0x0040275B
 0x0040259E
 0x0040202B
 0x00402035
 0x004257A7
 0x004256A8
 0x0041B7FF
 0x769F337A in BaseThreadInitThunk
 0x77429882 in RtlInitializeExceptionChain
 0x77429855 in RtlInitializeExceptionChain

 This was a 4 hour debug which made it worse as I was adding 
 more trace calls to figure out what was going on.  My boss is 
 now on the fence, to many compiler bugs with D, he asked me to 
 switch to Java if I have to deal to many more issues like 
 this.. (https://issues.dlang.org/show_bug.cgi?id=15457  another 
 issue we had)

 And this awesome stack trace helped me so much to track this 
 issue down...



Also why is this not allowed then?

import std.stdio;
void main() {
   auto x = "foo";
   for(int x = 0; x < 10; ++x) {
      writeln(x);
   }
}

Error: variable x is shadowing variable f335.main.x

Shadowing is bad and leads to bugs!
Jan 14 2016
prev sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:

 std.net.curl.CurlException std\net\curl.d(4033): Couldn't 
 resolve host name on handle 2188398
 ----------------
 0x00405F65
 0x00405F10
 0x0040275B
 0x0040259E
 0x0040202B
 0x00402035
 0x004257A7
 0x004256A8
 0x0041B7FF
 0x769F337A in BaseThreadInitThunk
 0x77429882 in RtlInitializeExceptionChain
 0x77429855 in RtlInitializeExceptionChain

 This was a 4 hour debug which made it worse as I was adding 
 more trace calls to figure out what was going on.  My boss is 
 now on the fence, to many compiler bugs with D, he asked me to 
 switch to Java if I have to deal to many more issues like 
 this.. (https://issues.dlang.org/show_bug.cgi?id=15457  another 
 issue we had)

 And this awesome stack trace helped me so much to track this 
 issue down...


What compiler are you using?

The useless stack traces got fixed in a fairly recent version of 
DMD - as have many, many other issues which are still present in 
GDC, whose front end is several versions out-of-date.

It is recommended to do your testing with DMD because of issues 
like this, and mostly use GDC for making optimized release builds.

Alternately, if you don't want to mix two compilers like that, 
LDC has good performance and is currently significantly more 
up-to-date than GDC. Or, you could even just use DMD, as the 
performance of its generated binaries has improved a whole lot in 
the past two releases, although it is of course still not as good 
as GDC or LDC in this respect.

More generally, though, much as we might not like to admit it, D2 
is still beta quality software. It is *vastly* more stable and 
less frustrating to work with than it was a few years ago when I 
first tried it, but it still has a long way to go before compiler 
problems cease to be a part of normal day-to-day usage.

If that's not acceptable to you or your business, you really 
probably should just use something else and check back in five 
years or so...
Jan 14 2016
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2016-01-14 at 21:36 +0000, tsbockman via Digitalmars-d wrote:

=20


[=E2=80=A6]

 The useless stack traces got fixed in a fairly recent version of=C2=A0
 DMD - as have many, many other issues which are still present in=C2=A0
 GDC, whose front end is several versions out-of-date.


"several versions behind" might be a better way if putting this. The
release cycles of DMD (basically unconstrained), LDC (basically
unconstrained), and GDC (heavily constrained), mean that "out of date"
is a bad marketing phrase. Especially=E2=80=A6


 It is recommended to do your testing with DMD because of issues=C2=A0
 like this, and mostly use GDC for making optimized release builds.


=E2=80=A6given this.=C2=A0

Clearly the D community needs to try and ensure that each GCC bundle
release has teh latest possible D in it, but we must also be positive
about which version each compiler supports.


 Alternately, if you don't want to mix two compilers like that,=C2=A0
 LDC has good performance and is currently significantly more=C2=A0
 up-to-date than GDC. Or, you could even just use DMD, as the=C2=A0
 performance of its generated binaries has improved a whole lot in=C2=A0
 the past two releases, although it is of course still not as good=C2=A0
 as GDC or LDC in this respect.
=20
 More generally, though, much as we might not like to admit it, D2=C2=A0
 is still beta quality software. It is *vastly* more stable and=C2=A0
 less frustrating to work with than it was a few years ago when I=C2=A0
 first tried it, but it still has a long way to go before compiler=C2=A0
 problems cease to be a part of normal day-to-day usage.
=20
 If that's not acceptable to you or your business, you really=C2=A0
 probably should just use something else and check back in five=C2=A0
 years or so...


I find this the wrong view of progress, yet one that remains embedded
in far too many organizations. It comes in two parts:

1. If a product has changed at all in the last six months, other than
trivial bug fixes, it isn't stable enough to use in production.

2. Once we have stuff out in production, nothing may be changed until
end of life.

Clearly the opposite extreme of "we must use the very latest of every
early-access version we can get out hands on" is equally dangerous in
production. There is a middle ground. Keep everything as up to date
with formally released versions as possible, taking on a continuous
change and evolution strategy.

In this mindset D is certainly stable enough for production, it is not
beta software. DMD is the playground compiler, GDC the conservative but
solid one, and LDC the core production tool.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 15 2016
parent tsbockman <thomas.bockman gmail.com> writes:
On Friday, 15 January 2016 at 08:12:03 UTC, Russel Winder wrote:

 "several versions behind" might be a better way if putting 
 this. The release cycles of DMD (basically unconstrained),
 LDC (basically unconstrained), and GDC (heavily constrained),
 mean that "out of date" is a bad marketing phrase.


I wasn't trying to market D; I was simply offering my advice to 
the OP.

I think D is a fantastic language, but I'm not going to downplay 
what I perceive to be its shortcomings.


 I find this the wrong view of progress, yet one that remains 
 embedded in far too many organizations. It comes in two parts:

 1. If a product has changed at all in the last six months, 
 other than trivial bug fixes, it isn't stable enough to use in 
 production.

 2. Once we have stuff out in production, nothing may be changed 
 until end of life.

 Clearly the opposite extreme of "we must use the very latest of 
 every early-access version we can get out hands on" is equally 
 dangerous in production. There is a middle ground. Keep 
 everything as up to date with formally released versions as 
 possible, taking on a continuous change and evolution strategy.

 In this mindset D is certainly stable enough for production, it 
 is not beta software. DMD is the playground compiler, GDC the 
 conservative but solid one, and LDC the core production tool.


That is not my mindset.

I consider D beta-quality because whenever I program in D, I 
encounter bugs (both new and old) in the compiler and/or standard 
library on almost a daily basis. This has not been my experience 
with other languages that have more money behind them, like Java 

C++ (so byzantine that I'm not sure I would notice - that's why I 
prefer D :-) ).

None of the bugs I've hit recently has been too difficult to 
diagnose and work around, which is why I no longer consider D 
alpha-quality. I, personally, would be comfortable using D in 
production - but that's because I have a high tolerance for the 
kinds of minor issues beta software brings with it; not everyone 
does.

And to be clear - I think GDC is awesome. But I also think that 
someone with a low tolerance for issues like the one the OP 
complained about will be happier using DMD or LDC, as I find the 
newer front-ends noticeably less buggy in day-to-day use.

Horses for courses.
Jan 15 2016
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 In this mindset D is certainly stable enough for production, it is not
 beta software. DMD is the playground compiler, GDC the conservative but
 solid one, and LDC the core production tool.

 --
 Russel.


Thanks for putting it so eloquently, Russell.

Iain.
Jan 15 2016
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 15 January 2016 at 08:15:50 UTC, Iain Buclaw wrote:

 On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" < 
 digitalmars-d puremagic.com> wrote:

 In this mindset D is certainly stable enough for production, 
 it is not beta software. DMD is the playground compiler, GDC 
 the conservative but solid one, and LDC the core production 
 tool.

 --
 Russel.


 Thanks for putting it so eloquently, Russell.

 Iain.


The difficulty is that gdc includes a lot of long-standing bugs 
that are fixed upstream.
Jan 15 2016
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 January 2016 at 23:50, John Colvin via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Friday, 15 January 2016 at 08:15:50 UTC, Iain Buclaw wrote:


 On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:


 In this mindset D is certainly stable enough for production, it is not
 beta software. DMD is the playground compiler, GDC the conservative but
 solid one, and LDC the core production tool.

 --
 Russel.


 Thanks for putting it so eloquently, Russell.

 Iain.


 The difficulty is that gdc includes a lot of long-standing bugs that are
 fixed upstream.


GDC is rarely a vanilla cut of the version it supports, and no one should
be allergic to submitting backports of library or frontend fixes. It is
afterall Boost licensed.  :-)
Jan 16 2016
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 14 Jan 2016 21:36:01 +0000
schrieb tsbockman <thomas.bockman gmail.com>:


 On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:

 std.net.curl.CurlException std\net\curl.d(4033): Couldn't 
 resolve host name on handle 2188398
 ----------------
 0x00405F65
 0x00405F10
 0x0040275B
 0x0040259E
 0x0040202B
 0x00402035
 0x004257A7
 0x004256A8
 0x0041B7FF
 0x769F337A in BaseThreadInitThunk
 0x77429882 in RtlInitializeExceptionChain
 0x77429855 in RtlInitializeExceptionChain

 This was a 4 hour debug which made it worse as I was adding 
 more trace calls to figure out what was going on.  My boss is 
 now on the fence, to many compiler bugs with D, he asked me to 
 switch to Java if I have to deal to many more issues like 
 this.. (https://issues.dlang.org/show_bug.cgi?id=15457  another 
 issue we had)

 And this awesome stack trace helped me so much to track this 
 issue down...  


 
 What compiler are you using?
 
 The useless stack traces got fixed in a fairly recent version of 
 DMD - as have many, many other issues which are still present in 
 GDC, whose front end is several versions out-of-date.



I'm not sure why you even think the OP is using GDC. His bug report
says he's on windows 10. GDC is not supported on windows systems and
won't work for anything but trivial programs.

And stack traces is one thing GDC has had proper support way before
DMD. We have proper stack traces since June 2013:
https://github.com/D-Programming-GDC/GDC/pull/65
https://github.com/D-Programming-GDC/GDC/commit/fbde3698398f85768bcf918a7a777d81fd0ac3ed
Jan 15 2016
parent tsbockman <thomas.bockman gmail.com> writes:
On Friday, 15 January 2016 at 09:05:27 UTC, Johannes Pfau wrote:

 I'm not sure why you even think the OP is using GDC. His bug 
 report says he's on windows 10. GDC is not supported on windows 
 systems and won't work for anything but trivial programs.

 And stack traces is one thing GDC has had proper support way 
 before
 DMD. We have proper stack traces since June 2013:
 https://github.com/D-Programming-GDC/GDC/pull/65
 https://github.com/D-Programming-GDC/GDC/commit/fbde3698398f85768bcf918a7a777d81fd0ac3ed


Good to know. I was really trying to ask what front-end version 
he's using, though.
Jan 15 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/14/2016 09:36 AM, Daniel Kozak via Digitalmars-d wrote:

 V Thu, 14 Jan 2016 14:25:43 +0000
 Byron Heads via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
 	import std.net.curl : trace;
 	trace("hello");
 }


 void main() {
 	foo();	
 }


 Not sure if this is a duplicate
 https://issues.dlang.org/show_bug.cgi?id=15567


 No this is OK, there is no reason to not compile.

 It is same as:
 import std.stdio;

 string trace = "trace";
 void foo() {
      int trace = 7;
      writeln(trace);
 }
 void main() {
      foo();	
      writeln(trace);
 }


 local symbols can hide global symbols


Correct. The implicitly introduced locals are the problem. Can anyone on 
the compiler team work on this? -- Andrei
Jan 14 2016
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 14 January 2016 at 16:10:29 UTC, Andrei Alexandrescu 
wrote:

 local symbols can hide global symbols


 Correct. The implicitly introduced locals are the problem. Can 
 anyone on the compiler team work on this? -- Andrei


No, we cannot just jump to anything that pops up on the 
newsgroup, b/c we would only be jump but no longer work on 
anything.
I've trying to put fixing the whole import system on the agenda 
for the past 2 releases, but didn't got much feedback.
Import issues are constantly breaking code (e.g. 
http://forum.dlang.org/post/mailman.3708.1453114739.22025.digitalmars-d-ann
unce puremagic.com) and cause such troubles during development.
I think it's time to dedicate a whole release to work on imports.
Jan 18 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote:

 I think it's time to dedicate a whole release to work on 
 imports.


Please do.

D is damn lucky that the main problem people think it has is the 
GC while it's sitting there with a half finished import system.
Jan 18 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Monday, 18 January 2016 at 13:26:24 UTC, Jack Stouffer wrote:

 On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote:

 I think it's time to dedicate a whole release to work on 
 imports.


 Please do.

 D is damn lucky that the main problem people think it has is 
 the GC while it's sitting there with a half finished import 
 system.


I'm not sure I agree on 'half finished', one of the biggest 
things D has over C++ is its vastly superior module system.
Is there a compiled list of issues?
Jan 18 2016
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 18 January 2016 at 14:01:15 UTC, rsw0x wrote:

 one of the biggest things D has over C++ is its vastly superior 
 module system.


When you compare D's something with C++'s nothing, then the 
module system in D is infinitely better by definition.


 Is there a compiled list of issues?


1. As deadalnix pointed out, a lack of spec

2. Issue 313

3. Issue 314

4. Issue 10378

These are the biggest IMO. There are probably others I don't know 
of.


 I'm not sure I agree on 'half finished'


When looking at the above issues, it becomes clear that the D 
module system does not completely provide one of the main things 
module systems are designed for: encapsulation.
Jan 18 2016
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/18/2016 06:02 PM, Jack Stouffer wrote:

 Is there a compiled list of issues?


 1. As deadalnix pointed out, a lack of spec

 2. Issue 313

 3. Issue 314

 4. Issue 10378

 These are the biggest IMO. There are probably others I don't know of.


https://issues.dlang.org/show_bug.cgi?id=1238
Jan 18 2016
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Monday, 18 January 2016 at 17:02:07 UTC, Jack Stouffer wrote:

 On Monday, 18 January 2016 at 14:01:15 UTC, rsw0x wrote:

 one of the biggest things D has over C++ is its vastly 
 superior module system.


 When you compare D's something with C++'s nothing, then the 
 module system in D is infinitely better by definition.


 Is there a compiled list of issues?


 1. As deadalnix pointed out, a lack of spec

 2. Issue 313

 3. Issue 314

 4. Issue 10378

 These are the biggest IMO. There are probably others I don't 
 know of.


 I'm not sure I agree on 'half finished'


 When looking at the above issues, it becomes clear that the D 
 module system does not completely provide one of the main 
 things module systems are designed for: encapsulation.


The problem is that D's import system is much more advanced than 
those in C++ or Java, allowing much more control and precision 
over what's imported, so some leaks have sprung in D's more 
complex module implementation.  Certainly much more than half, 
but definitely not finished. :)

If you simply stick a bunch of non-selective imports at the top 
of a module, ie non-local, and all the modules you import do the 
same (this is tougher, as not everybody is aware of the issue and 
some library might leak symbols into your module if they're not 
as conservative), you'll have no problem.  If you use more 
advanced features like selective or local imports, there are a 
few places they leak symbols or can shadow variables in 
non-intuitive ways, as the issues you listed enumerate.
Jan 18 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote:

 On Thursday, 14 January 2016 at 16:10:29 UTC, Andrei 
 Alexandrescu wrote:

 local symbols can hide global symbols


 Correct. The implicitly introduced locals are the problem. Can 
 anyone on the compiler team work on this? -- Andrei


 No, we cannot just jump to anything that pops up on the 
 newsgroup, b/c we would only be jump but no longer work on 
 anything.
 I've trying to put fixing the whole import system on the agenda 
 for the past 2 releases, but didn't got much feedback.
 Import issues are constantly breaking code (e.g. 
 http://forum.dlang.org/post/mailman.3708.1453114739.22025.digitalmars-d-ann
unce puremagic.com) and cause such troubles during development.
 I think it's time to dedicate a whole release to work on 
 imports.


I tried to simply define imports, and it is way more complex than 
you'd expect. We probably need some spec first.
Jan 18 2016
prev sibling parent reply anonymous <anonymous example.com> writes:
On 14.01.2016 15:25, Byron Heads wrote:

 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
      import std.net.curl : trace;
      trace("hello");
 }


 void main() {
      foo();
 }


I don't see a problem with that specific code. You're explicitly 
importing `trace` from std.net.curl, so it can't be surprising that it's 
called.

But change one little detail and this qualifies as hijacking, I think:

----
void foo() {
     import std.net.curl; /* not mentioning trace */
     trace("hello");
}
----

Imagine that std.net.curl didn't have a `trace` function when the code 
was written. std.experimental.logger.trace would have been called then. 
When a `trace` function is then added to std.net.curl, the code suddenly 
calls a different `trace`, without any warning. Hijacking.
Jan 14 2016
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 14 Jan 2016 16:17:41 +0100
anonymous via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On 14.01.2016 15:25, Byron Heads wrote:

 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
      import std.net.curl : trace;
      trace("hello");
 }


 void main() {
      foo();
 }  


 
 I don't see a problem with that specific code. You're explicitly 
 importing `trace` from std.net.curl, so it can't be surprising that
 it's called.
 
 But change one little detail and this qualifies as hijacking, I think:
 
 ----
 void foo() {
      import std.net.curl; /* not mentioning trace */
      trace("hello");
 }
 ----
 
 Imagine that std.net.curl didn't have a `trace` function when the
 code was written. std.experimental.logger.trace would have been
 called then. When a `trace` function is then added to std.net.curl,
 the code suddenly calls a different `trace`, without any warning.
 Hijacking.


Using local imports is dangerous. It should be used only with
selective imports
Jan 14 2016
parent karabuta <karabutaworld gmail.com> writes:
On Thursday, 14 January 2016 at 15:54:02 UTC, Daniel Kozak wrote:

 V Thu, 14 Jan 2016 16:17:41 +0100
 anonymous via Digitalmars-d <digitalmars-d puremagic.com> 
 napsáno:


 On 14.01.2016 15:25, Byron Heads wrote:

 I got burned by this yesterday, this code should not compile







 void foo() {
      import std.net.curl; /* not mentioning trace */
      trace("hello");
 }
 ----


 Using local imports is dangerous. It should be used only with 
 selective imports



Some of these problems can be avoided when you write good code. 
Explicit import is allowed but not the best especially when you 
are just using one or two functions (locally or globally).


Same as those who write:

class Name {
     string name;
     this(string name) {
         name = name;
     }
}

Instead of;

class Name {
     string name;
     this(string name) {
         this.name = name;
     }
}

Imagine you have;

class Name {
     string realName;

     this(string name) {

         .... a lot of code here.......

         string realName = name ..... //This will punish you

         .... a lot of code here.......
         string finalName = realName .......

         .... a lot of code here.......

         realName = finalName; // code maintained for a long time
     }
}


Writing good code takes time much like mining diamond.
Jan 16 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/14/2016 10:17 AM, anonymous wrote:

 On 14.01.2016 15:25, Byron Heads wrote:

 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
      import std.net.curl : trace;
      trace("hello");
 }


 void main() {
      foo();
 }


 I don't see a problem with that specific code. You're explicitly
 importing `trace` from std.net.curl, so it can't be surprising that it's
 called.

 But change one little detail and this qualifies as hijacking, I think:

 ----
 void foo() {
      import std.net.curl; /* not mentioning trace */
      trace("hello");
 }
 ----

 Imagine that std.net.curl didn't have a `trace` function when the code
 was written. std.experimental.logger.trace would have been called then.
 When a `trace` function is then added to std.net.curl, the code suddenly
 calls a different `trace`, without any warning. Hijacking.


Yes, this needs to be fixed. -- Andrei
Jan 14 2016
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]

 Yes, this needs to be fixed. -- Andrei


This issue has been known for a long time:

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

Kenji even has a PR for it.

My favorite blatant demonstration of its nastiness:

	import std.stdio;
	void func(string text) {
		import std.conv;
		writeln(text);
	}
	void main() {
		func("Hello world");
	}

Program output: (blank)


T

-- 
Жил-был король когда-то, при нём блоха жила.
Jan 14 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 14 January 2016 at 16:32:38 UTC, H. S. Teoh wrote:

 On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu 
 via Digitalmars-d wrote: [...]

 Yes, this needs to be fixed. -- Andrei


 This issue has been known for a long time:

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

 Kenji even has a PR for it.

 My favorite blatant demonstration of its nastiness:

 	import std.stdio;
 	void func(string text) {
 		import std.conv;
 		writeln(text);
 	}
 	void main() {
 		func("Hello world");
 	}

 Program output: (blank)


 T


Wow, can't believe his PR has been sitting unreviewed for 5 
months:

https://github.com/D-Programming-Language/dmd/pull/4915
Jan 14 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/14/2016 02:10 PM, Joakim wrote:

 Wow, can't believe his PR has been sitting unreviewed for 5 months:

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


I notice Kenji has been absent for a while, could anyone take over that 
PR? -- Andrei
Jan 14 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 01/14/2016 02:10 PM, Joakim wrote:

Wow, can't believe his PR has been sitting unreviewed for 5 months:

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


 
 I notice Kenji has been absent for a while, could anyone take over
 that PR?  -- Andrei


It's almost an entire month since he suddenly went silent. Completely
silent, in fact -- no activity whatsoever on his github account. Is he
OK??


T

-- 
Unix is my IDE. -- Justin Whear
Jan 14 2016
parent rsw0x <anonymous anonymous.com> writes:
On Thursday, 14 January 2016 at 22:33:51 UTC, H. S. Teoh wrote:

 On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 01/14/2016 02:10 PM, Joakim wrote:

Wow, can't believe his PR has been sitting unreviewed for 5 
months:

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


 
 I notice Kenji has been absent for a while, could anyone take 
 over that PR?  -- Andrei


 It's almost an entire month since he suddenly went silent. 
 Completely silent, in fact -- no activity whatsoever on his 
 github account. Is he OK??


 T


Appears he's back, and he rebased the PR.
https://github.com/D-Programming-Language/dmd/pull/4915
Jan 18 2016
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei Alexandrescu 
wrote:

 On 01/14/2016 02:10 PM, Joakim wrote:

 Wow, can't believe his PR has been sitting unreviewed for 5 
 months:

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


 I notice Kenji has been absent for a while, could anyone take 
 over that PR? -- Andrei


We're live! Please review: 
https://github.com/D-Programming-Language/dmd/pull/5353
Jan 15 2016
next sibling parent reply Meta <jared771 gmail.com> writes:
On Friday, 15 January 2016 at 23:57:51 UTC, Meta wrote:

 On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei 
 Alexandrescu wrote:

 On 01/14/2016 02:10 PM, Joakim wrote:

 Wow, can't believe his PR has been sitting unreviewed for 5 
 months:

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


 I notice Kenji has been absent for a while, could anyone take 
 over that PR? -- Andrei


 We're live! Please review: 
 https://github.com/D-Programming-Language/dmd/pull/5353


And the build is failing on DAutoTest with nasty assert errors. 
It built fine for me locally, anyone know what might be the 
problem?
Jan 15 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 16 January 2016 at 00:03:31 UTC, Meta wrote:

 And the build is failing on DAutoTest with nasty assert errors. 
 It built fine for me locally, anyone know what might be the 
 problem?


Error - file 'dimport.d' contains windows line endings at line 1
...
*** [checkwhitespace] Error 1
Jan 15 2016
parent Meta <jared771 gmail.com> writes:
On Saturday, 16 January 2016 at 00:07:59 UTC, tsbockman wrote:

 On Saturday, 16 January 2016 at 00:03:31 UTC, Meta wrote:

 And the build is failing on DAutoTest with nasty assert 
 errors. It built fine for me locally, anyone know what might 
 be the problem?


 Error - file 'dimport.d' contains windows line endings at line 1
 ...
 *** [checkwhitespace] Error 1


I'm talking about this: 
https://travis-ci.org/D-Programming-Language/dmd/jobs/102725760#L342
Jan 15 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/15/2016 06:57 PM, Meta wrote:

 On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei Alexandrescu wrote:

 On 01/14/2016 02:10 PM, Joakim wrote:

 Wow, can't believe his PR has been sitting unreviewed for 5 months:

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


 I notice Kenji has been absent for a while, could anyone take over
 that PR? -- Andrei


 We're live! Please review:
 https://github.com/D-Programming-Language/dmd/pull/5353


Thanks! "All checks have failed" -- Andrei
Jan 15 2016
parent Meta <jared771 gmail.com> writes:
On Saturday, 16 January 2016 at 01:10:21 UTC, Andrei Alexandrescu 
wrote:

 We're live! Please review:
 https://github.com/D-Programming-Language/dmd/pull/5353


 Thanks! "All checks have failed" -- Andrei


I hoped it would be as simple as rebasing, but either Kenji left 
that PR unfinished or there's something I'm missing, as it is not 
working as evidenced by the autotester. I'll close it in lieu of 
someone more knowledgeable about the compiler fixing it.
Jan 16 2016