Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 23:59:07 UTC, Yuxuan Shui wrote: On Friday, 31 July 2015 at 22:40:25 UTC, Trent Forkert wrote: On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: [...] Oh hey, that's me! [...] I've got a handful of work-in-progress changes I've yet to push publicly, and even more I've yet to commit. (Yes, I have weird work habits.) [...] Hi, I just want to let you know I've tried to build my project with your cmake fork, and it worked like a charm :) Good to hear it's still alive. Let's hope the situation about shared libraries can improve and you can move on. [...] I use CMake on mixed C/D projects and dub for D-only projects. On one project I'm using CMake to invoke dub to keep the D libs up to date and no another I invoke CMake from dub to build the C cruft. I find both work extremely well and are much better than shell scripts or plain Makefile bashing. bye, lobo
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: Hi, I'm working on a project that mixes both C and D code, and does code generation as well. [...] I'll get that bug fixed soon. I planned on doing it today but ran out of time. Atila
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: I have come across cmake-d and a modified version of cmake (https://github.com/trentforkert/cmake). I haven't tested them yet, because neither of them is updated recently, and I don't know if I should invest time in them. I'm not sure about cmake-d. I think dcarp stated somewhere that he wasn't actively using D any more, or something to that effect. The fork of CMake is still active. Trentforkert said he is just waiting for things to progress in the D ecosystem before continuing work. (Mostly related to shared libraries.) If you're willing to build and use the fork (it's actually really easy,) then you can use the CMake generator I wrote for dub a few months back. Simply run `dub generate cmake` and it will spit out build scripts for your project and all of its dependencies.
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: I have come across cmake-d and a modified version of cmake (https://github.com/trentforkert/cmake). Oh hey, that's me! I haven't tested them yet, because neither of them is updated recently, and I don't know if I should invest time in them. I've got a handful of work-in-progress changes I've yet to push publicly, and even more I've yet to commit. (Yes, I have weird work habits.) So I want to know what is the current status of those build systems? I'm still around, and I fix bugs when they get in my way or someone else complains. Are they abandoned No. Neglected, but not abandoned. or still actively developed? If I can find the time (and the files, which hopefully survived a recent Linux distro-switch), I'll see about cleaning up and publishing the additional changes I have soon, and getting things on to a more recent version of CMake. As Steven Dwy said, I put the project on a bit of a hiatus while waiting for shared lib support to be ironed out (specifically, the behavior of `export`). Part of my unpublished changes includes a change that renders my previous concerns on that front solved regardless of what becomes of `export`. I would still like to be able to run tests for building shared libraries, and I won't even consider upstreaming until I can. Like I said though, I'll deal with bug reports if you file them. - Trent Forkert
Re: What is the current status of D build systems?
On 31 July 2015 at 13:20, Yuxuan Shui via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 31 July 2015 at 02:00:41 UTC, Mike Parker wrote: On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: are there any other build systems I should look into? Premake [1] supports mixing languages in the same build script. It's not a build tool itself, but can generate makefiles and IDE projects. Manu [2] maintains extensions for D support. [1] https://premake.github.io/ [2] https://github.com/premake/premake-dlang It seems premake-dlang is not capable of fetch dub packages, is that correct? In that it doesn't have a special command to fetch dub packages, that is true. Premake projects are expressed with a scripting language though (Lua), so it's very easy to execute dub commands to fetch packages as part of your script if that's what you want to do. I haven't received any interest in built-in dub integration, but it's theoretically possible to make a built-in solution for fetching dub packages as part of the process quite easily. Using dub as a build system though is off the table though if you mix languages. It may be useful as a package manager, but generating standard makefiles for the multi-language build is necessary.
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 22:40:25 UTC, Trent Forkert wrote: On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: [...] Oh hey, that's me! [...] I've got a handful of work-in-progress changes I've yet to push publicly, and even more I've yet to commit. (Yes, I have weird work habits.) [...] Hi, I just want to let you know I've tried to build my project with your cmake fork, and it worked like a charm :) Good to hear it's still alive. Let's hope the situation about shared libraries can improve and you can move on. [...]
What is the current status of D build systems?
Hi, I'm working on a project that mixes both C and D code, and does code generation as well. I've been using a shell script to hack this together, since I can't figure out how to do this with dub. Now I'm looking for a proper build system for building this project. reggae (https://github.com/atilaneves/reggae) seems to be promising, but it has bugs with indirect dependencies and failed to build my project. I have come across cmake-d and a modified version of cmake (https://github.com/trentforkert/cmake). I haven't tested them yet, because neither of them is updated recently, and I don't know if I should invest time in them. So I want to know what is the current status of those build systems? Are they abandoned or still actively developed? And are there any other build systems I should look into? Thanks. --- Regards, Yuxuan Shui
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 02:00:41 UTC, Mike Parker wrote: On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: are there any other build systems I should look into? Premake [1] supports mixing languages in the same build script. It's not a build tool itself, but can generate makefiles and IDE projects. Manu [2] maintains extensions for D support. [1] https://premake.github.io/ [2] https://github.com/premake/premake-dlang It seems premake-dlang is not capable of fetch dub packages, is that correct?
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: are there any other build systems I should look into? Premake [1] supports mixing languages in the same build script. It's not a build tool itself, but can generate makefiles and IDE projects. Manu [2] maintains extensions for D support. [1] https://premake.github.io/ [2] https://github.com/premake/premake-dlang
Re: The current status of D?
On 12/07/2011 08:35 AM, Kagamin wrote:
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
I think ',' in parameter lists are already sequence points.
They aren't, but a function call is a sequence point, so bar is
guaranteed to be called before baz.
?
If bar is guaranteed to be called before baz, then the ',' is associated
with a sequence point. You are right that there is a sequence point
before a function call, but that only guarantees that bar and baz are
called before foo, and says nothing about the evaluation order of bar
and baz (note that function calls are sequence points in C/C++, but the
order of argument evaluation is unspecified).
Re: The current status of D?
On 06.12.2011 09:37, bearophile wrote: Don: Right. But it's hard to come up with high-priority language issues these days. The old ones have been fixed.g. There are several things that I'd like to see fixed/improved in D still. Yes, of course. But most of the showstoppers are done. Not so long ago there were major features in the spec or in TDPL that weren't implemented at all - contracts, @safe, pure, inout, TDPL operator overloading, almost nothing worked in CTFE, Phobos didn't compile on 64 bits, ...
Re: The current status of D?
On Wednesday, December 07, 2011 09:16:48 Don wrote: On 06.12.2011 09:37, bearophile wrote: Don: Right. But it's hard to come up with high-priority language issues these days. The old ones have been fixed.g. There are several things that I'd like to see fixed/improved in D still. Yes, of course. But most of the showstoppers are done. Not so long ago there were major features in the spec or in TDPL that weren't implemented at all - contracts, @safe, pure, inout, TDPL operator overloading, almost nothing worked in CTFE, Phobos didn't compile on 64 bits, ... Where does the compiler stand with multiple alias thises (as TDPL describes). AFAIK, it still doesn't support them at all. That would be a major feature from TDPL which hasn't be implemented. But yes, a lot of work has been done, and we're much closer to having everything fully implemented. - Jonathan M Davis
Re: The current status of D?
http://en.wikipedia.org/wiki/Sequence_point I think ',' in parameter lists are already sequence points. They aren't, but a function call is a sequence point, so bar is guaranteed to be called before baz. ? If bar is guaranteed to be called before baz, then the ',' is associated with a sequence point. You are right that there is a sequence point before a function call, but that only guarantees that bar and baz are called before foo, and says nothing about the evaluation order of bar and baz (note that function calls are sequence points in C/C++, but the order of argument evaluation is unspecified). Well, if sequence points don't go in a sequence, that would mean a total mess. Order of argument evaluation is usually unspecified because arguments are usually simple values and thus don't contain sequence points.
Re: The current status of D?
On 07-12-2011 09:16, Don wrote: On 06.12.2011 09:37, bearophile wrote: Don: Right. But it's hard to come up with high-priority language issues these days. The old ones have been fixed.g. There are several things that I'd like to see fixed/improved in D still. Yes, of course. But most of the showstoppers are done. Not so long ago there were major features in the spec or in TDPL that weren't implemented at all - contracts, @safe, pure, inout, TDPL operator overloading, almost nothing worked in CTFE, Phobos didn't compile on 64 bits, ... Speaking of contracts, what are the plans for: * Supporting contracts in interfaces - sometimes the compiler will not allow this, claiming that a method body must be present (other times it Just Works) * this pointer adjustment in interface contracts - using other interface members in an interface contract currently crashes because the this pointer isn't adjusted correctly * Supporting pre-state (AKA 'old') * Supporting contracts specific to exceptional function exit ? These are all rather essential to have usable contract programming, probably most significantly the interface ones. - Alex
Re: The current status of D?
Don:
Right. But it's hard to come up with high-priority language issues these days.
The old ones have been fixed. g.
There are several things that I'd like to see fixed/improved in D still. In
particular there are two holes from C language that have no place in D, I mean
code like:
x = x++;
Or code like (bar and baz are not pure):
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
You can't remove all undefined behaviours from D, but they must be reduced and
minimized, because D tries to lead to correct and deterministic programs.
A solution is to define the behaviour in those situations (and pay a bit of
performance in some cases), an alternative is to statically forbid some kinds
of code (and pay a bit of flexibility. C lints essentially forbid code like
x=x++;), or a mix of the two solutions. (Forbidding something is not so bad
because I've seen bad C code that mutates some variables inside a single
expression, and it's code that is not easy to understand and it's not easy to
translate to other languages).
Bye,
bearophile
Re: The current status of D?
On 12/06/2011 09:37 AM, bearophile wrote:
Don:
Right. But it's hard to come up with high-priority language issues these days. The old
ones have been fixed.g.
There are several things that I'd like to see fixed/improved in D still. In
particular there are two holes from C language that have no place in D, I mean
code like:
x = x++;
Or code like (bar and baz are not pure):
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
I think ',' in parameter lists are already sequence points.
You can't remove all undefined behaviours from D, but they must be reduced and
minimized, because D tries to lead to correct and deterministic programs.
A solution is to define the behaviour in those situations (and pay a bit of
performance in some cases), an alternative is to statically forbid some kinds
of code (and pay a bit of flexibility. C lints essentially forbid code like
x=x++;), or a mix of the two solutions. (Forbidding something is not so bad
because I've seen bad C code that mutates some variables inside a single
expression, and it's code that is not easy to understand and it's not easy to
translate to other languages).
Bye,
bearophile
Re: The current status of D?
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
I think ',' in parameter lists are already sequence points.
They aren't, but a function call is a sequence point, so bar is guaranteed to
be called before baz.
Re: The current status of D?
On 05.12.2011 06:27, Walter Bright wrote: On 12/3/2011 6:53 PM, Don wrote: It's the things like: is (foo bar == super) which I think you can't understand without looking up the spec every time. We still don't have a nice way of expressing such things. I agree, but that's a low priority for now, because at least you can get work done with it. Right. But it's hard to come up with high-priority language issues these days. The old ones have been fixed. g.
Re: The current status of D?
On 5 December 2011 15:33, Don nos...@nospam.com wrote: On 05.12.2011 06:27, Walter Bright wrote: On 12/3/2011 6:53 PM, Don wrote: It's the things like: is (foo bar == super) which I think you can't understand without looking up the spec every time. We still don't have a nice way of expressing such things. I agree, but that's a low priority for now, because at least you can get work done with it. Right. But it's hard to come up with high-priority language issues these days. The old ones have been fixed. g. I've got one... there's no 128bit hardware vector type! ;) .. That's pretty high for me :P Even if it doesn't do anything, just allocates and addresses the hardware regs and schedules loads/stores... Can write maths in asm, but need a type to pass to/from functions and store in structs/classes...
Re: The current status of D?
torhu wrote: On 01.12.2011 22:24, Buk wrote: Simple question, though not necessarily a simple answer: Is D ready for prime time? Sub-questions: 1. How stable is the language specification? 2. How stable is the language implementation? 3. How stable are the standard library specifications? 4. How stable are the standard library implantations? The last time I looked was just after the D1/D2 split, and much of the design was being revamped and the rate of changes and deprecations was (IMO) too high to consider its use for complex, multi-developer projects. Looking around the docs here, I see that some of the libraries are due for deprecation early next year. Barring surprises, are they likely to be the last major changes? Thanks for your time, buk. If you want something that's ready for prime time, D1+Tango is what I would recommend. Well you obviously suck at marketing. Isn't THAT, D's problem (and it does seem to have one, huh). I think D2 is not there yet. If I had to bring forth a cliche to describe D, it would be some quip saying why throw good money after bad?. I don't hate D. I think Walt and Andrei and Bear, should get together, and produce the fucking language already. (Ha, Walt couldn't do it, so he hired Andrei, Bear seems to both of them in disarray for all his mind can spew at them). (Casually observing). The language has gotten a lot more complex, funny how it started out then? I mean, Yes, we proclaim D, noting C++ bad, and so embard on betterment, and ends up (is it ending?) worse than the incumbent. No it's not funny, but it is useless? The concept for a specialized group may be good it's not, it's just masturbation. I don't conjecture that, even, I am a dancer. I suck at it, so I don't do it professionally. OTOH, I can run circles around ___. (Hint: don't count the number of underscores). quite done figuring out how to get all of it to fit together yet. Pfft. As if a swinging dick could actually think. A least that's my impression. I've used D and followed this newsgroup since 2006, so I don't think I'm completely clueless. Apparently you are, for what else can such mean? OK, I don't get it. This is a gay room? D is a gay thing? Spill. What's up with this D (one letter code?). What does it mean? Don't troll me yet, how does a bunch of enginerds not mean a bunch of gay men? I could say the same about football. Or baseball. You love to circle-jerk above all else. Yes?
Re: The current status of D?
Mehrdad Wrote: On 12/1/2011 1:24 PM, Buk wrote: Is D ready for prime time? Idk, the fact that I run across transitive-const-related situations like stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d makes it so I can't use D at all, since it's hard to go around these issues sometimes. I think, the correct diagnostic it your case should be const constructor is not defined. Also const system gives you a chance to design const-correct code, it doesn't necessarily make it simple. Design takes a lot of effort. That said, yes, you can get stuck unable to solve your problem with your skills. Though I don't think const-correct code is a must: I didn't see a single bug caused by lack of const. Const-correct code doesn't buy you a lot, really. btw, the inout solution is not quite right thing there, Steven proposed the correct design: const opSlice should return Slice!const(T), not const(Slice!T).
Re: The current status of D?
On 12/3/2011 6:53 PM, Don wrote: It's the things like: is (foo bar == super) which I think you can't understand without looking up the spec every time. We still don't have a nice way of expressing such things. I agree, but that's a low priority for now, because at least you can get work done with it.
Re: The current status of D?
Interesting to see Inheriting constructors there under pending decision.
Re: The current status of D?
Removing new was proposed? I don't think I want to know, but I'm curious.
Re: The current status of D?
On 12/03/2011 03:57 PM, Don wrote: On 01.12.2011 22:24, Buk wrote: Simple question, though not necessarily a simple answer: Is D ready for prime time? Sub-questions: 1. How stable is the language specification? 2. How stable is the language implementation? I made a list of major language issues in mid-2009. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#section6 The next release (2.057, release in December) implements half of the remaining items. 3. How stable are the standard library specifications? 4. How stable are the standard library implantations? The last time I looked was just after the D1/D2 split, and much of the design was being revamped and the rate of changes and deprecations was (IMO) too high to consider its use for complex, multi-developer projects. Looking around the docs here, I see that some of the libraries are due for deprecation early next year. Barring surprises, are they likely to be the last major changes? Thanks for your time, buk. - Clean up is(XXX) and __traits(XXX) syntax (eg via meta.XXX proposal, Bugzilla:3702). There is nothing wrong with is(XXX), so what is this about?
Re: The current status of D?
Famous last words: On 12/3/11 11:47 PM, Timon Gehr wrote: There is nothing wrong with is(XXX), […] David
Re: The current status of D?
On 12/04/2011 12:09 AM, David Nadlinger wrote: Famous last words: On 12/3/11 11:47 PM, Timon Gehr wrote: There is nothing wrong with is(XXX), […] David An explanation would be more helpful.
Re: The current status of D?
On 04.12.2011 00:13, Timon Gehr wrote: On 12/04/2011 12:09 AM, David Nadlinger wrote: Famous last words: On 12/3/11 11:47 PM, Timon Gehr wrote: There is nothing wrong with is(XXX), […] David An explanation would be more helpful. For many years is(xxx) been reviled as the ugliest thing in the language. The simple forms are OK, but features kept getting piled onto it until it became clearly unworkable. And there are stupidities like: alias void delegate () dg; alias void function () fn; static assert(is (dg == delegate)); // true static assert(is (fn == function)); // fails!
Re: The current status of D?
On 12/04/2011 03:10 AM, Don wrote: On 04.12.2011 00:13, Timon Gehr wrote: On 12/04/2011 12:09 AM, David Nadlinger wrote: Famous last words: On 12/3/11 11:47 PM, Timon Gehr wrote: There is nothing wrong with is(XXX), […] David An explanation would be more helpful. For many years is(xxx) been reviled as the ugliest thing in the language. The simple forms are OK, but features kept getting piled onto it until it became clearly unworkable. So why not keep the simple forms and just replace the more obscure functionality that is better expressed by other means? Removing is expressions entirely would break most D code (at least it would break all of mine). And there are stupidities like: alias void delegate () dg; alias void function () fn; static assert(is (dg == delegate)); // true static assert(is (fn == function)); // fails! I'd like to just see that fixed, but then old code would be silently miscompiled...
Re: The current status of D?
On 04.12.2011 03:40, Timon Gehr wrote: On 12/04/2011 03:10 AM, Don wrote: On 04.12.2011 00:13, Timon Gehr wrote: On 12/04/2011 12:09 AM, David Nadlinger wrote: Famous last words: On 12/3/11 11:47 PM, Timon Gehr wrote: There is nothing wrong with is(XXX), […] David An explanation would be more helpful. For many years is(xxx) been reviled as the ugliest thing in the language. The simple forms are OK, but features kept getting piled onto it until it became clearly unworkable. So why not keep the simple forms and just replace the more obscure functionality that is better expressed by other means? Yeah, that's the idea. Removing is expressions entirely would break most D code (at least it would break all of mine). Yes. Nobody's ever proposed complete removal of is expressions. It's the things like: is (foo bar == super) which I think you can't understand without looking up the spec every time. We still don't have a nice way of expressing such things. And there are stupidities like: alias void delegate () dg; alias void function () fn; static assert(is (dg == delegate)); // true static assert(is (fn == function)); // fails! I'd like to just see that fixed, but then old code would be silently miscompiled...
Re: The current status of D?
On 12/04/2011 03:53 AM, Don wrote: On 04.12.2011 03:40, Timon Gehr wrote: On 12/04/2011 03:10 AM, Don wrote: On 04.12.2011 00:13, Timon Gehr wrote: On 12/04/2011 12:09 AM, David Nadlinger wrote: Famous last words: On 12/3/11 11:47 PM, Timon Gehr wrote: There is nothing wrong with is(XXX), […] David An explanation would be more helpful. For many years is(xxx) been reviled as the ugliest thing in the language. The simple forms are OK, but features kept getting piled onto it until it became clearly unworkable. So why not keep the simple forms and just replace the more obscure functionality that is better expressed by other means? Yeah, that's the idea. Removing is expressions entirely would break most D code (at least it would break all of mine). Yes. Nobody's ever proposed complete removal of is expressions. It's the things like: is (foo bar == super) which I think you can't understand without looking up the spec every time. We still don't have a nice way of expressing such things. Ok, thanks. I fully agree that those should be replaced.
Re: The current status of D?
Buk wrote: Simple question, though not necessarily a simple answer: Is D ready for prime time? Sub-questions: 1. How stable is the language specification? 2. How stable is the language implementation? 3. How stable are the standard library specifications? 4. How stable are the standard library implantations? The last time I looked was just after the D1/D2 split, and much of the design was being revamped and the rate of changes and deprecations was (IMO) too high to consider its use for complex, multi-developer projects. Looking around the docs here, I see that some of the libraries are due for deprecation early next year. Barring surprises, are they likely to be the last major changes? Thanks for your time, buk. Don't feed the troll.
Re: The current status of D?
Mehrdad wrote: On 12/1/2011 1:24 PM, Buk wrote: Is D ready for prime time? Idk, the fact that I run across transitive-const-related situations like stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d makes it so I can't use D at all, since it's hard to go around these issues sometimes. As long as the language suffers from const issues, It seems to be a hard problem (const). I mean, if you are in analysis paralyis thinkin about it, yeah, but is it that hard. Do I need to hire a consultant to figure out one little word or concept? If the whole world of programming languages revolves around const, why hasn't D, that purportedly (noting the shyness of it perpatrators) has solved major issues with the also ran C++, figured that out? (BTW, I know the answer, if that makes it any less blashphemous). I think, I think what passes for thinking these days is pretty fucking piss poor lame. But then again, I don't vote for it either. it won't be ready for prime time, since 'const' is supposed to be one of its highest strengths, Seriously? If that is true, I will stop drinking. and at the same time it's part-broken.
Re: The current status of D?
On 12/02/2011 08:25 AM, Mehrdad wrote: On 12/1/2011 1:24 PM, Buk wrote: Is D ready for prime time? Idk, the fact that I run across transitive-const-related situations like stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d makes it so I can't use D at all, since it's hard to go around these issues sometimes. You have to be joking. As long as the language suffers from const issues, I think, it won't be ready for prime time, since 'const' is supposed to be one of its highest strengths, and at the same time it's part-broken. Its design is not broken and the implementation has almost caught up. (there are some obscure implicit conversions that should be allowed and some that shouldn't that DMD does not get right yet.) Please give objective information (as Jesse Phillips did.) Regarding you little problem, why did you think using inout would not work for classes? I just posted an answer on SO that shows that it does. BTW, I think most features in D are 'supposed to be one of its highest strengths', by that measure.
Re: The current status of D?
On Fri, 02 Dec 2011 02:25:26 -0500, Mehrdad wfunct...@hotmail.com wrote:
On 12/1/2011 1:24 PM, Buk wrote:
Is D ready for prime time?
Idk, the fact that I run across transitive-const-related situations like
stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d
http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d
makes it so I can't use D at all, since it's hard to go around these
issues sometimes.
What you are missing is one of the same things I need for dcollections --
tail const for structs.
Essentially, the problem boils down to, I want to be able to have
const(Slice!T) turn implicitly into Slice!const(T). Slice!const(T) is
more usable because only the data pointed at is const, the internal pieces
of the slice are not.
But to solve your original problem, this seems to work on 2.056, but is
weird:
import std.stdio;
struct S
{
int x;
inout this(inout int t)
{
this.x = t;
}
}
void main()
{
int i = 1;
immutable int i2 = 1;
const int i3 = 1;
auto s = S(i);
auto s2 = S(i2);
auto s3 = S(i3);
auto s4 = const(S)(1);
writefln(s: %s, s2: %s, s3: %s, s4: %s, typeof(s).stringof,
typeof(s2).stringof, typeof(s3).stringof, typeof(s4).stringof);
}
outputs:
s: S, s2: immutable(S), s3: const(S), s4: S
The s4 is the weird part, I clearly asked for a const(S), and it gave me
an S due to the inout parameter being mutable. I might file a bug on
this, but to be honest, I never envisioned how inout would work on a
ctor. The s, s2, and s3 parts are pretty cool though :)
As long as the language suffers from const issues, I think, it won't be
ready for prime time, since 'const' is supposed to be one of its highest
strengths, and at the same time it's part-broken.
inout has fixed many of these issues. There is still work to be done, but
I think we're in a much better place than we were before.
-Steve
Re: The current status of D?
On 12/2/2011 4:25 AM, Timon Gehr wrote: You have to be joking. I wasn't, but if it makes you feel better then you can think of it that way. Its design is not broken and the implementation has almost caught up. (there are some obscure implicit conversions that should be allowed and some that shouldn't that DMD does not get right yet.) Please give objective information (as Jesse Phillips did.) I can't see how the question I posted was subjective, but thanks for the suggestion... Regarding you little problem, why did you think using inout would not work for classes? I just posted an answer on SO that shows that it does. Because your example also used inout for opSlice() (in fact, for pretty much everything), something that the original answer had not suggested and which I never envisioned I should do. I guess the documentation should be filled with more/better examples? That was rather obscure. BTW, I think most features in D are 'supposed to be one of its highest strengths', by that measure. lol, http://en.wikipedia.org/wiki/Markov%27s_inequality says this is impossible. --- I never envisioned how inout would work on a ctor. Yeah, neither did I (and especially not the way it was used on opSlice, the way it's used just like 'const'), so I just thought it was impossible. IMO if the documentation doesn't explain these, not everyone will figure things out on their own... inout has fixed many of these issues. There is still work to be done, but I think we're in a much better place than we were before. Yeah, it looks fine when you use inout on everything (instead of const), thanks to both!
Re: The current status of D?
Actually, regarding my little problem, why does this given an
error/what's the proper way to fix it?
class C(T) { inout this(inout(T)) { } }
C!T slice(T)(auto ref T c) { return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
//Test.d(2): Error: cannot implicitly convert expression (new
C(items)) of type inout(C) to Test.C!(int[]).C
Re: The current status of D?
... another bug with inout():
import std.stdio;
//Error: inout on parameter means inout must be on return type as
well (???)
class C { inout(C) foo() inout { writeln(this); return this; } }
void main() { }
IMHO, 'inout' is fundamentally flawed: it should not act like a type
constructor at all, because that makes no sense. But it seems to be what
it's doing here...
So no, I wasn't joking -- getting around these problems gets pretty
annoying (getting rid of one causes another), as trivial as you may make
them out to be. I love D's features as well, but if I have to spend a
nontrivial amount of time working around the D compiler, then I probably
wouldn't use the D compiler at all.
Re: The current status of D?
On Fri, 02 Dec 2011 13:25:02 +0100 Timon Gehr timon.g...@gmx.ch wrote: Its design is not broken and the implementation has almost caught up. (there are some obscure implicit conversions that should be allowed and some that shouldn't that DMD does not get right yet.) Please give objective information (as Jesse Phillips did.) There isn't a need to be objective. Opinion does give insight into things and at times is obviously an opinion. And in fact this is a good example of what a meant by going in blind. There is not implementation of D that is complete and trying to use every feature will get you in cold water. Const is like no other in D, and while it recently got major usability improvements it does have its issues. But not using const is possible in D and is also easy to get around cast().
Re: The current status of D?
On 12/02/2011 05:13 PM, Mehrdad wrote:
Actually, regarding my little problem, why does this given an
error/what's the proper way to fix it?
class C(T) { inout this(inout(T)) { } }
C!T slice(T)(auto ref T c) { return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
//Test.d(2): Error: cannot implicitly convert expression (new C(items))
of type inout(C) to Test.C!(int[]).C
1. File a bug. inout is apparently not resolved properly by DMD in this
case.
2. Apply this workaround to make the compiler shut up (and probably to
make your code less bloated by extraneous template instances as well :o)):
class C(T) { inout this(inout(T)) { } }
inout(C!T) slice(T)(inout T c){ return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
Re: The current status of D?
On Fri, 02 Dec 2011 11:28:45 -0500, Mehrdad wfunct...@hotmail.com wrote:
... another bug with inout():
import std.stdio;
//Error: inout on parameter means inout must be on return type as
well (???)
class C { inout(C) foo() inout { writeln(this); return this; } }
void main() { }
IMHO, 'inout' is fundamentally flawed: it should not act like a type
constructor at all, because that makes no sense. But it seems to be what
it's doing here...
inout must participate in the return value or there is no point in using
inout (use const instead).
However, one thing we did not anticipate is how to do IFTI with inout
values. There is an open bug report on this:
http://d.puremagic.com/issues/show_bug.cgi?id=6809
You can work around by explicitly instantiating with const, or by doing:
writeln(cast(const)this);
So no, I wasn't joking -- getting around these problems gets pretty
annoying (getting rid of one causes another), as trivial as you may make
them out to be. I love D's features as well, but if I have to spend a
nontrivial amount of time working around the D compiler, then I probably
wouldn't use the D compiler at all.
This is understandable. We have some major issues to resolve still. But
if you don't hit those, it's reasonable to work with.
-Steve
Re: The current status of D?
On 12/02/2011 05:57 PM, Jesse Phillips wrote: On Fri, 02 Dec 2011 13:25:02 +0100 Timon Gehrtimon.g...@gmx.ch wrote: Its design is not broken and the implementation has almost caught up. (there are some obscure implicit conversions that should be allowed and some that shouldn't that DMD does not get right yet.) Please give objective information (as Jesse Phillips did.) There isn't a need to be objective. Opinion does give insight into things and at times is obviously an opinion. And in fact this is a good example of what a meant by going in blind. There is not implementation of D that is complete and trying to use every feature will get you in cold water. Oh it is certainly good to have and communicate opinions. It is just that they should be clearly marked as such. I won't even attempt to argue that his point of view is not important. Const is like no other in D, and while it recently got major usability improvements it does have its issues. But not using const is possible in D and is also easy to get around cast(). It is important to make a cut between what is not supposed to work and what is not yet implemented properly. He said 'the _language_ suffers from const issues'. And 'its part-broken'. The design is fundamentally sound. It could maybe be extended to cover more use cases, but the issues with const he addresses have been resolved with inout, and it is likely that the implementation will soon be correct. Also he probably is doing some considerably different stuff than, for example, I am, because I don't run into that kind of productivity-blocker issues.
Re: The current status of D?
On 01.12.2011 22:24, Buk wrote: Simple question, though not necessarily a simple answer: Is D ready for prime time? Sub-questions: 1. How stable is the language specification? 2. How stable is the language implementation? 3. How stable are the standard library specifications? 4. How stable are the standard library implantations? The last time I looked was just after the D1/D2 split, and much of the design was being revamped and the rate of changes and deprecations was (IMO) too high to consider its use for complex, multi-developer projects. Looking around the docs here, I see that some of the libraries are due for deprecation early next year. Barring surprises, are they likely to be the last major changes? Thanks for your time, buk. If you want something that's ready for prime time, D1+Tango is what I would recommend. I think D2 is not there yet. The language has gotten a lot more complex, and as a result of that, they are not quite done figuring out how to get all of it to fit together yet. A least that's my impression. I've used D and followed this newsgroup since 2006, so I don't think I'm completely clueless. Some of the new features are not yet implemented, which others have mentioned. As for Phobos 2, I don't know what to think yet. I find it hard to trust that the template-heavy code is fast, that the compiler can reliably optimize all those layers away.
Re: The current status of D?
On 12/2/2011 10:46 AM, Timon Gehr wrote: Oh it is certainly good to have and communicate opinions. It is just that they should be clearly marked as such. I like how you're leading by example, it makes it so much easier to learn The Right Thing (tm) from you. I won't even attempt to argue that his point of view is not important. This sentence is a lie? It is important to make a cut between what is not supposed to work and what is not yet implemented properly. He said 'the _language_ suffers from const issues'. And 'its part-broken'. The design is fundamentally sound. It could maybe be extended to cover more use cases, but the issues with const he addresses have been resolved with inout, and it is likely that the implementation will soon be correct. The design is fundamentally sound. -- No offense, but maybe it's _you_ who should follow your advice and actually provide some support? At least I'm giving you examples; you're not giving me anything. Oh, sorry, I forgot that your arguments are all objective and correct by definition. I didn't notice that you didn't mark them as subjective. Also he probably is doing some considerably different stuff than, for example, I am, because I don't run into that kind of productivity-blocker issues. And that makes my point of view unimportant. Yes, that's a completely objective and unbiased point of view, it makes perfect sense. Sorry for forcing you to read my unimportant feedback.
Re: The current status of D?
On 12/2/2011 10:41 AM, Steven Schveighoffer wrote: You can work around by explicitly instantiating with const, or by doing: writeln(cast(const)this); I'm trying to avoid cast at all costs in D (even more than in C++), since D's casts are more dangerous than C++ casts. :\ Thanks for the suggestion though! :)
Re: The current status of D?
On 12/2/2011 9:38 AM, Timon Gehr wrote:
On 12/02/2011 05:13 PM, Mehrdad wrote:
Actually, regarding my little problem, why does this given an
error/what's the proper way to fix it?
class C(T) { inout this(inout(T)) { } }
C!T slice(T)(auto ref T c) { return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
//Test.d(2): Error: cannot implicitly convert expression (new C(items))
of type inout(C) to Test.C!(int[]).C
1. File a bug. inout is apparently not resolved properly by DMD in
this case.
http://d.puremagic.com/issues/show_bug.cgi?id=7053
2. Apply this workaround to make the compiler shut up (and probably to
make your code less bloated by extraneous template instances as well
:o)):
class C(T) { inout this(inout(T)) { } }
inout(C!T) slice(T)(inout T c){ return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
That just propagates it up the stack, though...
Re: The current status of D?
On Fri, 02 Dec 2011 15:51:32 -0500, Mehrdad wfunct...@hotmail.com wrote: On 12/2/2011 10:41 AM, Steven Schveighoffer wrote: You can work around by explicitly instantiating with const, or by doing: writeln(cast(const)this); I'm trying to avoid cast at all costs in D (even more than in C++), since D's casts are more dangerous than C++ casts. :\ Thanks for the suggestion though! :) It's understandable. In this case, you are doing something that should be able to be implicit, in order to force IFTI to interpret a certain way. In all reality, writeln should const-ify all its args, but it can't because phobos isn't const correct yet. Another workaround which avoids casts is this: const tmp = this; writeln(tmp); -Steve
Re: The current status of D?
On 12/02/2011 09:50 PM, Mehrdad wrote: On 12/2/2011 10:46 AM, Timon Gehr wrote: Oh it is certainly good to have and communicate opinions. It is just that they should be clearly marked as such. I like how you're leading by example, it makes it so much easier to learn The Right Thing (tm) from you. I won't even attempt to argue that his point of view is not important. This sentence is a lie? No. It is important to make a cut between what is not supposed to work and what is not yet implemented properly. He said 'the _language_ suffers from const issues'. And 'its part-broken'. The design is fundamentally sound. It could maybe be extended to cover more use cases, but the issues with const he addresses have been resolved with inout, and it is likely that the implementation will soon be correct. The design is fundamentally sound. -- No offense, but maybe it's _you_ who should follow your advice and actually provide some support? Sound basically means that it is not broken. Broken means that the type system is inconsistent. It is not. (while DMD does not implement a consistent const system because of array-covariance related bugs.) At least I'm giving you examples; you're not giving me anything. I am resolving/relegating to the compiler implementation the issues you run into. You have yet to point out a problem with the design. Oh, sorry, I forgot that your arguments are all objective and correct by definition. I didn't notice that you didn't mark them as subjective. Also he probably is doing some considerably different stuff than, for example, I am, because I don't run into that kind of productivity-blocker issues. And that makes my point of view unimportant. Well, as I already pointed out before you wrote that: this is not my point of view. Are you reflecting? I do not understand how my post can possibly be interpreted that way, but communicating over the internet has some drawbacks. Again: How can the fact that you apparently do different things than I do make your point of view unimportant? I would say, on the contrary? Yes, that's a completely objective and unbiased point of view, it makes perfect sense. This sentence is a lie? Sorry for forcing you to read my unimportant feedback. No reason to get offended. I am sorry if you were.
Re: The current status of D?
On 12/02/2011 09:57 PM, Mehrdad wrote:
On 12/2/2011 9:38 AM, Timon Gehr wrote:
On 12/02/2011 05:13 PM, Mehrdad wrote:
Actually, regarding my little problem, why does this given an
error/what's the proper way to fix it?
class C(T) { inout this(inout(T)) { } }
C!T slice(T)(auto ref T c) { return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
//Test.d(2): Error: cannot implicitly convert expression (new C(items))
of type inout(C) to Test.C!(int[]).C
1. File a bug. inout is apparently not resolved properly by DMD in
this case.
http://d.puremagic.com/issues/show_bug.cgi?id=7053
2. Apply this workaround to make the compiler shut up (and probably to
make your code less bloated by extraneous template instances as well
:o)):
class C(T) { inout this(inout(T)) { } }
inout(C!T) slice(T)(inout T c){ return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
That just propagates it up the stack, though...
It does not, otherwise I would not have called it a workaround. It seems
only to be a problem for class constructors:
class C(T) { inout this(inout(T)) { } }
inout(C!T) slice(T)(inout T c){ return new C!T(c); }
void main() { static assert(!is(typeof([1, 2, 3, 4, 5].slice())==inout)); }
The current status of D?
Simple question, though not necessarily a simple answer: Is D ready for prime time? Sub-questions: 1. How stable is the language specification? 2. How stable is the language implementation? 3. How stable are the standard library specifications? 4. How stable are the standard library implantations? The last time I looked was just after the D1/D2 split, and much of the design was being revamped and the rate of changes and deprecations was (IMO) too high to consider its use for complex, multi-developer projects. Looking around the docs here, I see that some of the libraries are due for deprecation early next year. Barring surprises, are they likely to be the last major changes? Thanks for your time, buk.
Re: The current status of D?
On Thu, 1 Dec 2011 21:24:40 + (UTC) Buk d.20.browse...@xoxy.net wrote: Simple question, though not necessarily a simple answer: Is D ready for prime time? This is a hard question indeed. It is ready to be used, and even in production, but not blindly. Sub-questions: 1. How stable is the language specification? The specification shouldn't change, but since there is no full implementation of D, really bad choices could get changed. Also, the website is not the best at being up-to-date, submit bug reports. The D Programming language by Andrei is the official word on what D v2 does. 2. How stable is the language implementation? There is a bug here and there, it is in good shape but misses some features. 3. How stable are the standard library specifications? Umm, under quite a bit of change and not really complete. 4. How stable are the standard library implantations? There are some very stable parts but others which are changing. Pages of interest: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
Re: The current status of D?
On 12/1/2011 1:24 PM, Buk wrote: Is D ready for prime time? Idk, the fact that I run across transitive-const-related situations like stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d makes it so I can't use D at all, since it's hard to go around these issues sometimes. As long as the language suffers from const issues, I think, it won't be ready for prime time, since 'const' is supposed to be one of its highest strengths, and at the same time it's part-broken.
