Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D 2.069.0 released, compiler automatically ported from C++ to D

dlang.org

Post reply on HN
Print view View original

91–100 of 131 posts

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#91

Post by thepumpkin1979 »

destructionator wrote: post #86
thepumpkin1979 wrote: post #72

Earlier quoted context omitted.

I'm intentionally making it null to see how the new backtraces work. I know it's because I'm trying to call a method on "null", but If I'm working on a huge code base, how do I debug this kind of issues if I don't have stack trace with line and error number of the error? I'd like to get at least the stack trace and the error number with the line of the source code that caused the problem, like in golang: $ cat main.g…

null deference in D doesn't throw exceptions by default on Unix so you won't see the backtrace there. If you are working in a big codebase and have this come up, you can enable core dumps and run it in a debugger to get far more information than just a line number (and line numbers are there too at least if compiled in debug mode).

does this mean there is not a way to get stack trace on OSX?

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#92

Post by p0nce »

jeremiep wrote: post #74
yokohummer7 wrote: post #56

Earlier quoted context omitted.

> Implicit numeric casts that lose bits are not allowed anymore. That's good to hear, but I want implicit conversion to be forbidden unconditionally (even int * float -> float). I've been bitten by even widening conversions, so I just want to let them go away. It might be great if such an option could be applied to module level. > ?? Sorry if my understandings or my words were wrong, but I got the impression that D a…

I rather like the implicit conversions. Especially in D where they only happen where its safe. There's the 'to' function to perform checked conversions and the standard cast operator to perform unchecked conversions. int foo = 256; ubyte bar = foo.to!ubyte; // throws ConvException ubyte baz = cast(ubyte) foo; // overflows as expected If I want more type-safety than this, I'll create simple wrappers: struct Seconds {…

std.typecons.Typedef does something similar: http://dlang.org/phobos/std_typecons.html#.Typedef

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#93

Post by e12e »

steveklabnik wrote: post #30
srean wrote: post #27

Earlier quoted context omitted.

On the nontechnical side I would add that since D is a lot older, keeping up with changes is a whole lot less challenging. Its stable enough that one can put it near the money without worrying too much about breaking changes.

Since 1.0 last May, we have a strong commitment to backwards compatibility as well. Stability should not be an issue any longer.

My impression is that things are settling down now, but I've encountered quite a few rust code bases that required "latest rust" (latest > 1.0) - and even "nightly".

Not to say that rust-the-language hasn't stabilized, but I think the point about D being (way) more mature still stands?

(Note, it's a good thing that people are writing code to test/work with/exercise latest rust/nightly etc -- but just because I can be fairly sure code I write today will compile tomorrow (which is good!) -- that doesn't mean "all of rust land" is stable).

Please don't take this of critique of all the hard work going into rust -- the only way this wouldn't be a thing was if rust core was a dead project.

[ed: To add to that - it might well be that all of the projects I've seen lately where I've had to wake up multirust[1] and do a little dance before my beautiful random code from random person on the Internet have been willing to compile -- have all been bad samples of rust code - but they're still part of the landscape of rust code one encounters in the wild.

[1] https://github.com/brson/multirust (eats a bit of space (~200MB per version of the compiler/toolchain) - but in my very limited testing works nicely!)]

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#94

Post by EvenThisAcronym »

thepumpkin1979 wrote: post #91
destructionator wrote: post #86

Earlier quoted context omitted.

null deference in D doesn't throw exceptions by default on Unix so you won't see the backtrace there. If you are working in a big codebase and have this come up, you can enable core dumps and run it in a debugger to get far more information than just a line number (and line numbers are there too at least if compiled in debug mode).

does this mean there is not a way to get stack trace on OSX?

I have not tried it myself but there seem to be ways to get a stack trace on Linux.

http://vibed.org/docs#handling-segmentation-faults

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#95

Post by EvenThisAcronym »

scardine wrote: post #5
amelius wrote: post #3

I'm wondering, is there an advantage of using D over Rust?

I guess D feels more like a better C++ and Rust like a better C, but I may be under the wrong impression.

D is what you get if C married Python and the resulting baby was adopted and raised by Lisp and C#.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#96

Post by EvenThisAcronym »

Solarsail wrote: post #47
bachmeier wrote: post #28

Earlier quoted context omitted.

I disagree. D is an improved C that does a lot of the same things as C++, but in order for it to be a better C++, it would need to start with C++ as a foundation and build on it. D has more of a scripting language feel to me.

> D has more of a scripting language feel to me. I'm curious about this, although I don't think this is the first time I've heard D described as having a script-y feel to it. It sounds along the same lines as people describing Go as almost a scripting language, or comparing it to them. Neither Go nor D seem especially dynamic, both have compilers for reference implementations, both look more like C than Python. (To m…

People often say this because D has many features that allow it to be almost as flexible as the various scripting languages while still being compiled and statically typed. I don't bother with bash/cmd nowadays as D can easily fill that role, with the bonus of my small little scripts having all the power and scalability that D offers.

Also check out https://github.com/Abscissa/scriptlike

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#97

Post by WalterBright »

epoch1970 wrote: post #78
WalterBright wrote: post #69

Earlier quoted context omitted.

> I want implicit conversion to be forbidden unconditionally Not going to happen in a language with 11 integer types. > (double-throw) Exceptions are chained together.

Walter, is there any chance that we will see the source code to Digital Mars C++ release at some point? Or is it encumbered in ways that would make such a release impossible?

You can buy a copy of the source code from Digital Mars if you like. It's a bit old fashioned, though. At some point I'll probably just make it free, though it'll still have the Symantec license on it.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#98

Post by WalterBright »

epoch1970 wrote: post #79
pjmlp wrote: post #75

Earlier quoted context omitted.

Are you sure? I remember reading something about PL/I. :)

Walter has been around a long time. He knows the game. Walter, have you ever used PL/I?

Nope. But Pascal was so simple that a listing for a working subset compiler for it (written in BASIC) was published in BYTE magazine back in the 70s.

But I (and many other compiler devs) thought back in the early 80's that Ada was so complex it was unimplementable. Today that thought seems charmingly naive.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#99

Post by lazyjones »

Zardoz84 wrote: post #24
lazyjones wrote: post #4

Earlier quoted context omitted.

How is the compiler bootstrapped now (i.e. compiled from source without a working D compiler)? Via the gcc D implementation?

Using the previous version write on C++. Like all compilers of other languages did when change to be write on his own language. Or do you think that the first version of C compiler was write on C ?

That's not really the only possible way. You could write an (arbitrarily slow & simple) interpreter in e.g. C to compile the compiler with itself, or translate to C, or use something like a p-code machine as an intermediate step (https://en.wikipedia.org/wiki/P-code_machine) with an assembler-written interpreter. The problem with using older versions is that in principle, you'd have to keep maintaining/porting them for newer systems/architectures.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#100

Post by asdfaoeu »

thepumpkin1979 wrote: post #91
destructionator wrote: post #86

Earlier quoted context omitted.

null deference in D doesn't throw exceptions by default on Unix so you won't see the backtrace there. If you are working in a big codebase and have this come up, you can enable core dumps and run it in a debugger to get far more information than just a line number (and line numbers are there too at least if compiled in debug mode).

does this mean there is not a way to get stack trace on OSX?

Try valgrind
Post reply on HN