Re: Choosing D over C++, Go, Rust, Swift

2016-01-14 Thread Dibyendu Majumdar via Digitalmars-d 

On Thursday, 14 January 2016 at 17:10:34 UTC, Jack Stouffer wrote:
On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar 
wrote:
I did find that I had to go through many articles, video 
presentations etc. to form my conclusions - it would have been 
nice if there was a single page on the D website that 
explained why D should be chosen over the other competing 
languages. The information is all there but scattered all over 
the place.


http://dlang.org/overview.html


Nice - but it is under Getting Started? So it assumes people 
already want to get started in D? Why not put the first few 
sections on the main page.


Another example of what I think ought to be easily accessible is 
Andrei's response to following:


https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

Anyway, I am glad that there is material out there and that I was 
able to find what I needed!


Regards
Dibyendu

LDC 0.17.0-beta1 has been released!

2016-01-14 Thread Kai Nacke via Digitalmars-d-announce 

Hi everyone,

LDC 0.17.0-beta1, the LLVM-based D compiler, is available for 
download!
This release is based on the 2.068.2 frontend and standard 
library and supports LLVM 3.5-3.7.


Don't miss to check if your preferred system is supported by this 
release. We also have a Win64 compiler available!


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

http://forum.dlang.org/post/cnpluyvskgjztnuyp...@forum.dlang.org

Regards,
Kai

Re: Google Summer of Code 2016

2016-01-14 Thread Craig Dillabaugh via Digitalmars-d 
On Thursday, 31 December 2015 at 23:58:32 UTC, Craig Dillabaugh 
wrote:
The deadline for the Google Summer of Code, 2016 is February 
19th. Which means we have about a month and a half to put 
something together.  For the time being I've recycled last 
years projects (with one dropped so far):


[...]


Deadline is getting closer, any new project ideas are welcome. 
Starting to get some contact from students now.

Re: local import hijacking

2016-01-14 Thread Joakim via Digitalmars-d 

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

Re: New D tool releases

2016-01-14 Thread Øivind via Digitalmars-d-announce 
On Thursday, 14 January 2016 at 15:18:09 UTC, Andrei Alexandrescu 
wrote:

On 01/14/2016 04:05 AM, Brian Schott wrote:
Please see the Github links for a list of changes and issues 
resolved.


You may notice that they're all in Dub now. The real Brian is 
in
cryo-stasis in case we need him later. In order to not arouse 
too much
suspicion about shape-shifters these projects can still be 
built with

git and make.


Congrats! Could you please let the real Brian know we're 
waiting for a solution to include all of these tools in our 
official tools/ repo. Thanks! -- Andrei


+1

Re: LDC 0.17.0-beta1 has been released!

2016-01-14 Thread rsw0x via Digitalmars-d-announce 

On Thursday, 14 January 2016 at 20:33:30 UTC, Kai Nacke wrote:

Hi everyone,

LDC 0.17.0-beta1, the LLVM-based D compiler, is available for 
download!
This release is based on the 2.068.2 frontend and standard 
library and supports LLVM 3.5-3.7.


Don't miss to check if your preferred system is supported by 
this release. We also have a Win64 compiler available!


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

http://forum.dlang.org/post/cnpluyvskgjztnuyp...@forum.dlang.org

Regards,
Kai


Congratulations on Win64 support — is this the first LDC version 
with it?

Re: Choosing D over C++, Go, Rust, Swift

2016-01-14 Thread bachmeier via Digitalmars-d 
On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar 
wrote:


I did find that I had to go through many articles, video 
presentations etc. to form my conclusions - it would have been 
nice if there was a single page on the D website that explained 
why D should be chosen over the other competing languages. The 
information is all there but scattered all over the place.


Do you have specific suggestions for improvements? The difficulty 
is predicting where someone will look for that information.

Re: std.experimental.yesnogc

2016-01-14 Thread bachmeier via Digitalmars-d 
On Thursday, 14 January 2016 at 07:44:16 UTC, Jacob Carlborg 
wrote:



std.experimental.memory.rc
std.experimental.memory.gc
std.experimental.memory.manual // or something


+1

Re: local import hijacking

2016-01-14 Thread Byron Heads via Digitalmars-d 

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

V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d  
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...

Re: local import hijacking

2016-01-14 Thread Byron Heads via Digitalmars-d 

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!

Re: Choosing D over C++, Go, Rust, Swift

2016-01-14 Thread bachmeier via Digitalmars-d 
On Thursday, 14 January 2016 at 14:29:24 UTC, Dibyendu Majumdar 
wrote:


Hi - apologies I am unable to discuss, as it is not an 
OpenSource project. But let's say it requires lot of numeric 
computing.


Are you familiar with

https://github.com/dlangscience
https://gitter.im/DlangScience/public

Re: std.experimental.yesnogc

2016-01-14 Thread Andrei Alexandrescu via Digitalmars-d 

On 01/14/2016 09:50 AM, bachmeier wrote:

On Thursday, 14 January 2016 at 07:44:16 UTC, Jacob Carlborg wrote:


std.experimental.memory.rc
std.experimental.memory.gc
std.experimental.memory.manual // or something


+1


I don't see how this categorization works. E.g. there's no need for 
special tooling related to the GC. -- Andrei

[Issue 15568] New: Wrong contracts generated when compiled with -O

2016-01-14 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15568

  Issue ID: 15568
   Summary: Wrong contracts generated when compiled with -O
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dragosc...@gmail.com

The PR https://github.com/D-Programming-Language/dmd/pull/4788 fixing issue
https://issues.dlang.org/show_bug.cgi?id=9383 introduced a regression that can
be reproduced with the following test:

---
import std.algorithm;
import std.array;

class A
{
B foo(C c, D[] ds, bool f)
in
{
assert(c !is null);
}
body
{
D[] ds2 = ds.filter!(a => c).array;

return new B(ds2, f);
}
}

class B
{
this(D[], bool)
{
}
}

class C
{
}

struct D
{
}

unittest
{
auto a = new A;
C c = new C;

a.foo(c, null, false);
}
---

It runs successfully when it is compiled with:
  dmd -unittest -main
But the contract throws AssertError when compiled with:
  dmd -unittest -main -O

--

Re: Choosing D over C++, Go, Rust, Swift

2016-01-14 Thread Dibyendu Majumdar via Digitalmars-d 

On Thursday, 14 January 2016 at 14:35:27 UTC, bachmeier wrote:


Are you familiar with

https://github.com/dlangscience
https://gitter.im/DlangScience/public


Thank you for pointing me to above.

Regards

Re: local import hijacking

2016-01-14 Thread H. S. Teoh via Digitalmars-d 
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

-- 
Жил-был король когда-то, при нём блоха жила.

Re: Output range of ranges to single buffer

2016-01-14 Thread Jonathan M Davis via Digitalmars-d-learn 
On Thursday, January 14, 2016 08:41:23 Jacob Carlborg via Digitalmars-d-learn 
wrote:
> On 2016-01-13 22:20, H. S. Teoh via Digitalmars-d-learn wrote:
>
> > Isn't that just a matter of replacing each of the segments with their
> > range equivalents? Also, std.format.formattedWrite will do
> > writeln-formatting into a buffer (well, any output range, really) -- I'm
> > pretty sure it doesn't allocate, at least for the simplest cases like
> > converting an integer. So you should be able to do something like this:
> >
> > auto data = [ 1, 2, 3, 4, 5 ];
> > char[] buf = ...;
> > formattedWrite(buf, "[%(%d, %)]", data);
>
> Aha, interesting. I didn't know formattedWrite could format an
> array/range directly like that.
>
> The more complex example works by defining "toString" which takes an
> output range (delegate). But what if I need to format a third party type
> that I cannot add methods to? UFCS does not seem to work.

You can't do toString via UFCS any more than you can overload any operators
via UFCS. If a type's toString does not work how you want, or a type does
not provide one, then you'll need to convert objects of that type to a
string in a different way.

- Jonathan M Davis

Re: [dlang.org] new forum design - preview

2016-01-14 Thread ddddddd via Digitalmars-d 

On Thursday, 14 January 2016 at 19:46:33 UTC, anonymous wrote:

On 14.01.2016 16:29, tn wrote:
I don't use my browser in full screen mode, but the useless 
white
margins are still there. With the horizontal-split mode the 
line length
of the message is less than 60 characters. Compared to that, I 
would be

happy with 80 or 90 you suggest.


This is an issue with the horizontal split mode, right? In the 
other modes you should get more than 80 characters on a line.


I agree that horizontal split looks quite cramped right now, 
unless you hide the navigation.



Besides, especially the margin that is on the left side of the
navigation bar looks ugly, like it was rendered improperly.


Would a border help? http://i.imgur.com/XoPddxr.png

Or how about making the whole area gray? 
http://i.imgur.com/AXrmKU4.png


Cant you do a max-width on the container holding the main page?  
I agree it should be an entire 2k display but my laptop the 
sidebar could easily push the edge of the window.

Re: [dlang.org] new forum design - preview

2016-01-14 Thread tsbockman via Digitalmars-d 

On Thursday, 14 January 2016 at 19:46:33 UTC, anonymous wrote:

Would a border help? http://i.imgur.com/XoPddxr.png

Or how about making the whole area gray? 
http://i.imgur.com/AXrmKU4.png


Either of those would be an improvement.

Re: DUB & Win-10 SDK / link lib not found

2016-01-14 Thread Robert M. Münch via Digitalmars-d-learn 

On 2016-01-14 17:40:44 +, Robert M. Münch said:

I was expecting that DUB / DMD & NMAKE take $LIB into account. I try to 
compile some stuff on x64.


This is LIB:

D:\develop\d-language\webchat> $Env:lib
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\LIB\amd64;C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\ATLMFC\LIB\amd64;C:\Program Files (x86)\Windows 
Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows 
Kits\NETFXSDK\4.6.1\lib\um\x64;C:\Program Files (x86)\Windows 
Kits\10\lib\10.0.10240.0\um\x64;



This is the DUB call:

Linking...
dmd 
-of.dub\build\application-debug-windows-x86_64-dmd_2069-B25B434937830646D3F1C40AF40BEB8D\webchat.exe 
.dub\build\application-debug-windows-x86_64-dmd_2069-B25B434937830646D3F1C40AF40BEB8D\webchat.obj 
..\vibe-d-0.7.26\lib\win-amd64\libeay32.lib 
..\vibe-d-0.7.26\lib\win-amd64\ssleay32.lib ..\cairoD\cairoD.lib 
C:\Users\robby\AppData\Roaming\dub\packages\derelict-ft-1.0.2\lib\DerelictFT.lib 
C:\Users\robby\AppData\Roaming\dub\packages\derelict-util-2.0.4\lib\DerelictUtil.lib 
C:\Users\robby\AppData\Roaming\dub\packages\x11-1.0.9\x11.lib 
..\vibe-d-0.7.26\vibe-d.lib wsock32.lib ws2_32.lib advapi32.lib 
user32.lib -LD:\develop\Cairo-VS\projects\x64\Debug\cairo.lib 
-LD:\develop\Cairo-VS\projects\x64\Debug\pixman.lib -m64 -m64 -m64 -m64 
-m64 -m64 -g

LINK : fatal error LNK1104: cannot open file 'wsock32.lib'

Why isn't the "wsock32.lib" found? I really don't have a clue. I think 
that DMD's link step uses the MS tool. Is that right?


I really don't understand why the fundamental wsock32.lib is not found...


Seems that some paths in sc.ini were not setup correctly. For x64 a 
Win10-SDK directory which doesn't exists was referenced.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

<    1   2