Re: D2 is really that stable as it is claimed to be?
On Sep 25, 2013 8:55 PM, Arjan ar...@ask.me wrote: On Wed, 25 Sep 2013 17:53:41 +0200, Sean Kelly s...@invisibleduck.org wrote: On Sep 24, 2013, at 8:45 PM, deadalnix deadal...@gmail.com wrote: On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote: On 9/24/2013 5:39 PM, deadalnix wrote: It doesn't seem that surprising to me. If you want a compiler that is fast, you use DMC, if you want a compiler that will do coffee, you use GCC or clang recently. I do think the user base you judge on is biased. I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc. That is the exact opposite. People that like feature rich compiler already use another compiler. People that like minimal tooling and speed uses DMC. I don't know. I liked DMC specifically because of the nifty features. I used VC++ for the debugging environment. But then I never worked on a Windows project where compile time was a problem. The really big stuff (ie. millions of LOC) has always been on some variant of Unix. Well we extensively used Symantec C/C++ and later DMC on various large projects om Windows. And I did appreciate the error caret in DMC at the time. I really loved the compiler and IDDE back then. We also used compilers from other vendors (Borland Watcom IBM KAI MS). The most remarkable memories are of course the compile speed but also (for a long time) the performance of the generated code! An other thing we really really really loved was the speed in response on reporting compiler bugs! Almost every time within 2 or 3 days we received a 'fixed' compiler in our inbox from Walter! (Thank You Walter!) Also often times DMC captured programming bugs during compilation not found by the Borland Watcom or MS compilers. It wasn't until 2004/2005 before I switched to VS2003/vS2005 because DMC was getting to much behind and the MS compiler had improved a lot. Arjan I guess moral of the story is: People don't compliment what they take for granted - only complain when it is missing. :) Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 10:54 PM, Luís Marques l...@luismarques.eu wrote: Walter, I'm sorry to hear your frustration on this issue of the error caret, and the lack of recognition you got for your dmc implementation of that concept. For what it's worth the following is my opinion: - I think I first met an error caret in the javac compiler, around 2000. I found it very nice and useful. My positive experience was not preceded by any marketing of that feature, so I think we can conclude that my enjoyment was genuine. - When clang added nice error diagnostics in general (compared to GCC at the time) and the caret in particular that helped shape my perception of that compiler in a positive light, whatever the actual technical merits of that compiler may be. - In general I think dmd is quite a good compiler but I regularly mumble to myself hmm, the compiler could have provided better diagnostics for this error I committed. I can start compiling a list of those errors with less than great error messages, if that's useful. Yes, it is useful. Please do so, and add them to bugzilla. - Based on my experience with javac and clang, providing a caret (and ranges around the offending expressions, as in clang) is very useful *to me*, and I would be very pleased to see them on the D compilers, even if that information was not present in the debugger, so as not to regress compiler performance. Thank you for a very reasonable reply.
Re: D2 is really that stable as it is claimed to be?
On Tuesday, 24 September 2013 at 23:11:24 UTC, Walter Bright wrote: On 9/24/2013 2:23 PM, David Nadlinger wrote: On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright wrote: On 9/23/2013 10:33 AM, Iain Buclaw wrote: GCC has a carat too now. DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. Maybe that's because not one single person actually uses DMC? ;) yes, I've had a fantasy business for the last 30 years. DMC? A compiler which produces obsolete object format which is not produced by anyone else and which is a reason of why dmd users experience problems in windows platform?
Re: D2 is really that stable as it is claimed to be?
On Wednesday, 25 September 2013 at 06:57:52 UTC, Maxim Fomin wrote: On Tuesday, 24 September 2013 at 23:11:24 UTC, Walter Bright wrote: On 9/24/2013 2:23 PM, David Nadlinger wrote: On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright wrote: On 9/23/2013 10:33 AM, Iain Buclaw wrote: DMC? A compiler which produces obsolete object format which is not produced by anyone else and which is a reason of why dmd users experience problems in windows platform? All that might be true, however I feel like is not fair to criticize DMC in such harsh words. First, because one should judge a compiler wrt its pairs (of the same age). Second, because I think it was quite a breakthrough at its time, and history should be respected, even if becomes obsolete (what does not?). One should not criticize IBM PC for being obsolete *today*. Third, because it is real (and hard) work behind that DMC compiler and it is available for free. Maybe not the latest, nor the greatest, but is a contribution to the software world and this should be appreciated. Besides, all work should be respected and appreciated. It is hard to work, and it is even harder to work hard. Fourth, because it attracted C/C++ fans to D. It is my case: I crawled the Internet back then in the search for a free C/C++ compiler, being a bit disappointed by Borland's (I think 5.5 was freed) suite, specifically... its error messages. I gave DMC a try, then got caught into the D thing... Fifth, because as obsolete as DMC might be, it provided Walter a lot of experience and this lead him to D in the first place. Yes, me too I would prefer main focus to shift on GDC or LDC but, at the end of the day, I must acknowledge the fact that if DMC and Walter did not exist, with all shortcomings of DMC, we'd have today no GDC, nor LDC to complain about those not being given priority. Sixth, because from time to time we should express not only harsh truths, but kindness. Kindness, too, is true. We are eager to be harsh with others, but still we hope others to be kind with us.
Re: D2 is really that stable as it is claimed to be?
On 24 September 2013 22:23, David Nadlinger c...@klickverbot.at wrote: On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright wrote: On 9/23/2013 10:33 AM, Iain Buclaw wrote: GCC has a carat too now. DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. Maybe that's because not one single person actually uses DMC? ;) That's a bit below the belt for you David. ;-) Saying that, I don't use dmc... -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: D2 is really that stable as it is claimed to be?
On Wednesday, 25 September 2013 at 07:39:32 UTC, eles wrote: DMC? A compiler which produces obsolete object format which is not produced by anyone else and which is a reason of why dmd users experience problems in windows platform? All that might be true, however I feel like is not fair to criticize DMC in such harsh words. First, because one should judge a compiler wrt its pairs (of the same age). I am not judging DMC compiler. I am essentially judging the author who decided not to invest time and sources into supporting proper object format for dmd on win32. Second, because I think it was quite a breakthrough at its time, and history should be respected, even if becomes obsolete (what does not?). One should not criticize IBM PC for being obsolete *today*. Where and which history did I disrespected? Third, because it is real (and hard) work behind that DMC compiler and it is available for free. Maybe not the latest, nor the greatest, but is a contribution to the software world and this should be appreciated. Besides, all work should be respected and appreciated. It is hard to work, and it is even harder to work hard. Who says that writing a compiler is a picnic? By the way, if you decided to raise the issue, I can say that someone doesn't need to move stuff from one backend file to another without obvious end-user value when there are outcrying problems with D implementation. Fourth, because it attracted C/C++ fans to D. It is my case: I crawled the Internet back then in the search for a free C/C++ compiler, being a bit disappointed by Borland's (I think 5.5 was freed) suite, specifically... its error messages. I gave DMC a try, then got caught into the D thing... Did DMC attracted you to D? That's fine but I doubt it attracted at least 4 more persons. In my opinion most were attracted by completely different reasons. Fifth, because as obsolete as DMC might be, it provided Walter a lot of experience and this lead him to D in the first place. Yes, me too I would prefer main focus to shift on GDC or LDC but, at the end of the day, I must acknowledge the fact that if DMC and Walter did not exist, with all shortcomings of DMC, we'd have today no GDC, nor LDC to complain about those not being given priority. What does this have to do with object format? Sixth, because from time to time we should express not only harsh truths, but kindness. Kindness, too, is true. We are eager to be harsh with others, but still we hope others to be kind with us. What does this have to do with object format?
Re: D2 is really that stable as it is claimed to be?
On 2013-09-24 22:26, Walter Bright wrote: DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. Honestly, I don't care if DMC does it or not. I want DMD to do it. -- /Jacob Carlborg
Re: D2 is really that stable as it is claimed to be?
On 2013-09-25 06:33, Walter Bright wrote: Except that no other compiler at the time did the caret thing. It was a unique feature of DMC. DMC (or Zortech C++, back in the 80's), was the feature rich compiler of its day. Perhaps people didn't care about it back then. But oblivious people care now. You said I'd have a different attitude about it if just one person had ever said cool when I showed them that feature. People _are_ asking for it now. -- /Jacob Carlborg
Re: D2 is really that stable as it is claimed to be?
On 09/25/2013 01:17 AM, Walter Bright wrote: On 9/24/2013 2:56 PM, Andrej Mitrovic wrote: It seems nobody comments on almost anything DMC-related anyway. Isn't this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If it is, there's hardly a single post per month.. You overlook that it's a very old compiler - 30 years. In its day it had maybe 100,000 users. People do still use it today, to compile dmd for Win32 for example, and nobody has yet EVER commented on that feature, unless I prompted them, when I have pointed it out many times over the decades, and the response is always: SO WHAT WHO CARES etc. So please forgive my grumpiness about if clang implements it, suddenly it's the greatest, most useful feature ever. 30 years (pitifully) seems to be a plausible time frame for an idea of merit to become fashionable.
Re: D2 is really that stable as it is claimed to be?
On 9/25/13, Jacob Carlborg d...@me.com wrote: People are asking for it now. Yeah but it's not anonymous people on Reddit asking for it, it's just experienced D developers. It doesn't count.
Re: D2 is really that stable as it is claimed to be?
On 09/25/2013 01:55 AM, Walter Bright wrote: On 9/24/2013 4:43 PM, Dicebot wrote: You may underestimate power of marketing in IT world :) i.e. compiler fashion! It does not matter how useful feature was on its own - clang guys has convinced the crowd it is useful so now it is useful. Its actual merit is irrelevant unless you want to invest into counter-propaganda. Probably the most insightful comment in this thread. It should be noted however, that it is completely vacuous in a context where the goal is to infer something about the actual merit.
Re: D2 is really that stable as it is claimed to be?
On Sep 25, 2013 11:16 AM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 9/25/13, Jacob Carlborg d...@me.com wrote: People are asking for it now. Yeah but it's not anonymous people on Reddit asking for it, it's just experienced D developers. It doesn't count. Manu is not asking for it either. :o) *hugs Manu* Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: D2 is really that stable as it is claimed to be?
21.09.2013 21:41, Zhouxuan пишет: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. Should I continue? Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. A year or two ago it was a lot of wrong-code bugs with lambdas and nested functions making e.g. `std.algorithm` almost unusable. But it's only the beginning. OPTLINK bug causing random linking failures thus making the whole language unusable for real projects was fixed only about half a year ago. And all this time I liked D except the language is stable words. And when half a year ago D become fully usable I become happy. For me enough stability is an ability to grab my copy of tool-chain and work with it without random failures. Since then I had not any real problems with breaking changes or regressions. Generally regressions are fixed quickly and as for me the more breaking changes the better language we get. ) -- Денис В. Шеломовский Denis V. Shelomovskij
Re: D2 is really that stable as it is claimed to be?
On Wednesday, 25 September 2013 at 03:10:20 UTC, Walter Bright wrote: And, dmd users are often dmc users. Are they, still? I can't speak for everyone, but I know I've never used it. I wish I had had it for precisely the feature in question when I was first learning C, even though it would have spoiled me on other compilers until...2013, apparently. :/ Since dmd never had it, and dmc did, wouldn't anyone have suggested hey, I like this dmc feature, why not put it in dmd? But nope. In the few compilers I've used that had it, I've never begrudged its existence; it's usually been helpful, and never harmful. You could say I like it because it offers proper visualisation of the data. I didn't realise it was moving from rare, nice perk to in-demand standard feature until this thread. -Wyatt
Re: D2 is really that stable as it is claimed to be?
Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns. Then you get a bug report where someone does. So raise it to an unsigned short, then, sigh, you get another bug report where someone's entire source file is on one line, and on it goes. I realize putting maximum line length 32767 characters is an arbitrary limit, but if you add that to the language spec and make your column counter an unsigned short you're good forever. This might break some existing code but I can't imagine it would be much. There are advantages to owning the language spec!
Re: D2 is really that stable as it is claimed to be?
On Sep 24, 2013, at 8:45 PM, deadalnix deadal...@gmail.com wrote: On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote: On 9/24/2013 5:39 PM, deadalnix wrote: It doesn't seem that surprising to me. If you want a compiler that is fast, you use DMC, if you want a compiler that will do coffee, you use GCC or clang recently. I do think the user base you judge on is biased. I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc. That is the exact opposite. People that like feature rich compiler already use another compiler. People that like minimal tooling and speed uses DMC. I don't know. I liked DMC specifically because of the nifty features. I used VC++ for the debugging environment. But then I never worked on a Windows project where compile time was a problem. The really big stuff (ie. millions of LOC) has always been on some variant of Unix.
Re: D2 is really that stable as it is claimed to be?
On Sep 24, 2013, at 11:14 PM, Walter Bright newshou...@digitalmars.com wrote: On 9/24/2013 10:54 PM, Luís Marques l...@luismarques.eu wrote: - Based on my experience with javac and clang, providing a caret (and ranges around the offending expressions, as in clang) is very useful *to me*, and I would be very pleased to see them on the D compilers, even if that information was not present in the debugger, so as not to regress compiler performance. Thank you for a very reasonable reply. Yeah, I've never cared about having this information in the debugger. Only at compile time.
Re: D2 is really that stable as it is claimed to be?
On Sep 25, 2013, at 5:43 AM, Wyatt wyatt@gmail.com wrote: On Wednesday, 25 September 2013 at 03:10:20 UTC, Walter Bright wrote: And, dmd users are often dmc users. Are they, still? I can't speak for everyone, but I know I've never used it. I wish I had had it for precisely the feature in question when I was first learning C, even though it would have spoiled me on other compilers until...2013, apparently. :/ If you're mixing D and C/C++ code, it certainly seems like the easiest approach. Does DMC integrate with VisualStudio as well as DMD? That would be the only issue for me if I still developed on Windows.
Re: D2 is really that stable as it is claimed to be?
On 25/09/2013 17:45, Sean Kelly wrote: On Sep 24, 2013, at 11:14 PM, Walter Bright newshou...@digitalmars.com wrote: On 9/24/2013 10:54 PM, Luís Marques l...@luismarques.eu wrote: - Based on my experience with javac and clang, providing a caret (and ranges around the offending expressions, as in clang) is very useful *to me*, and I would be very pleased to see them on the D compilers, even if that information was not present in the debugger, so as not to regress compiler performance. Thank you for a very reasonable reply. Yeah, I've never cared about having this information in the debugger. Only at compile time. What does it even mean to have column/source-range information for errors in the debugger?? There is no notion of language errors or warnings in the debugger in the first place. Unless you mean for an expression evaluator (a pretty advanced feature)? -- Bruno Medeiros - Software Engineer
Re: D2 is really that stable as it is claimed to be?
On Wed, 25 Sep 2013 17:53:41 +0200, Sean Kelly s...@invisibleduck.org wrote: On Sep 24, 2013, at 8:45 PM, deadalnix deadal...@gmail.com wrote: On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote: On 9/24/2013 5:39 PM, deadalnix wrote: It doesn't seem that surprising to me. If you want a compiler that is fast, you use DMC, if you want a compiler that will do coffee, you use GCC or clang recently. I do think the user base you judge on is biased. I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc. That is the exact opposite. People that like feature rich compiler already use another compiler. People that like minimal tooling and speed uses DMC. I don't know. I liked DMC specifically because of the nifty features. I used VC++ for the debugging environment. But then I never worked on a Windows project where compile time was a problem. The really big stuff (ie. millions of LOC) has always been on some variant of Unix. Well we extensively used Symantec C/C++ and later DMC on various large projects om Windows. And I did appreciate the error caret in DMC at the time. I really loved the compiler and IDDE back then. We also used compilers from other vendors (Borland Watcom IBM KAI MS). The most remarkable memories are of course the compile speed but also (for a long time) the performance of the generated code! An other thing we really really really loved was the speed in response on reporting compiler bugs! Almost every time within 2 or 3 days we received a 'fixed' compiler in our inbox from Walter! (Thank You Walter!) Also often times DMC captured programming bugs during compilation not found by the Borland Watcom or MS compilers. It wasn't until 2004/2005 before I switched to VS2003/vS2005 because DMC was getting to much behind and the MS compiler had improved a lot. Arjan
Re: D2 is really that stable as it is claimed to be?
On 9/23/2013 10:29 AM, Sean Kelly wrote: On Sep 21, 2013, at 10:22 PM, Walter Bright newshou...@digitalmars.com wrote: I'm not rejecting the idea outright. I've actually implemented this in the dmc compiler. It's just not terribly useful, and it has costs. I'd consider it in a similar class as the dictionary lookup that occurs when an unknown symbol is encountered. Totally unnecessary, but it's a nice time-saver. It's not in the same category, because that feature has zero cost. Again, it's about the cost of it.
Re: D2 is really that stable as it is claimed to be?
On 9/23/2013 11:38 AM, bearophile wrote: 2) The other improvement I'd like for D error messages and warnings is to give a standard error number. This is a simple improvement, but it makes simpler to write explanation pages for the errors. The C# compiler and other compilers have them. I used to do that, but again, it was a completely unwanted feature, and I abandoned it. It's simple enough to grep for the error message text, and I myself prefer to do the grep method. What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing.
Re: D2 is really that stable as it is claimed to be?
On 9/23/2013 10:33 AM, Iain Buclaw wrote: GCC has a carat too now. DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user.
Re: D2 is really that stable as it is claimed to be?
On 9/23/2013 12:07 PM, Andrej Mitrovic wrote: On 9/23/13, bearophile bearophileh...@lycos.com wrote: 1) One of them is the aka, that is showing both the name of aliases and the aliased types/values: http://d.puremagic.com/issues/show_bug.cgi?id=5004 I have a partial implementation of this in one of my branches, but IIRC it was difficult do cover all cases since the compiler internally inserts a bunch of aliases as well. Those could be marked that they're internal, so that's fixable. Another issue I ran into is that diagnostics are called after the retrieval of the aliased-to type, which basically means by the time the compiler issues errors the alias declaration is gone, the compiler only works on the target symbol. I had a workaround for this, but it's going to take more work to get done. I worry that this is too complicated to be worthwhile.
Re: D2 is really that stable as it is claimed to be?
On 9/23/2013 12:19 PM, Timon Gehr wrote: There is no such thing as a law that obliges compiler writers to add column numbers in debug info when such information is available in frontend error messages. I guarantee that if the error messages have column numbers, people will file bug reports that it doesn't show up in the debugger, and rightfully so.
Re: D2 is really that stable as it is claimed to be?
On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright wrote: On 9/23/2013 10:33 AM, Iain Buclaw wrote: GCC has a carat too now. DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. Maybe that's because not one single person actually uses DMC? ;) I certainly find that feature very helpful in Clang. David
Re: D2 is really that stable as it is claimed to be?
On 9/24/13, Walter Bright newshou...@digitalmars.com wrote: Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. It seems nobody comments on almost anything DMC-related anyway. Isn't this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If it is, there's hardly a single post per month..
Re: D2 is really that stable as it is claimed to be?
On 9/24/13, David Nadlinger c...@klickverbot.at wrote: Maybe that's because not one single person actually uses DMC? ;) It's like building a bridge in the middle of Siberia and then saying that bridges are useless because hardly a dozen people use it a week.
Re: D2 is really that stable as it is claimed to be?
On 9/24/13, Walter Bright newshou...@digitalmars.com wrote: I worry that this is too complicated to be worthwhile. Unfortunately yes, the way the compiler is written right now would mean the feature would have to be implemented as a series of hacks. Perhaps if the implementation simplifies or we get another compiler.. :)
Re: D2 is really that stable as it is claimed to be?
Walter Bright: I worry that this is too complicated to be worthwhile. After seeing the error messages given by Clang I think it could be worthwhile. In C++ it has saved me debugging time. I used to do that, but again, it was a completely unwanted feature, and I abandoned it. It's simple enough to grep for the error message text, and I myself prefer to do the grep method. At the moment in D learn people show the error messages generated by dmd and don't know what to do. An archive of errors, one error for each wiki page, is useful because the user sees a longer description of the error, plus two examples of it (where it could be recognized better if it's really the right error), plus explanations how to fix it, like to use const or inout or to use an alias inside a class etc. The problem with grepping is that it could lead to mistakes, you have to grep for the whole error message, otherwise you risk finding the wrong message. Another problem is that the wording could change, both in different versions of the same compiler and in different compilers, so every compiler needs its own wiki. Also, if you need to use a search, you must have all the error messages in the same page, while with error messages you could just go directly to the page number and you don't need to copy and paste several (all) the words of the error message. Having a standard number across all D compilers allows for a standardization of tools (the IDE has to show the same error tooltips regardless the D compiler you are using). Another advantage of numbers of error messages is that if two different points of the same compiler have to generate the same error, using the same code number there is no risk the error message could go out of sync to each other. This has happened in DMD, where I have seen the same error give different error messages with the same dmd (http://d.puremagic.com/issues/show_bug.cgi?id=11094 ). What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing. I have tried to show, here and in Issue 5004, that's not true. And even if it's just a fashion as you say, I could argue that in computer science and programming there are far worse fashions people cling to. Sometimes when you create an engineering product it's not enough for it to be technically very good, you also have to wrap it in a colourful, fashion-aware and pretty paper. If you miss doing that, you are doing 99% of the necessary work for success but you are missing far more than the 1% of overall appreciation for your product. Bye, bearophile
Re: D2 is really that stable as it is claimed to be?
Andrej Mitrovic: Unfortunately yes, the way the compiler is written right now would mean the feature would have to be implemented as a series of hacks. Perhaps if the implementation simplifies or we get another compiler.. :) You could show somewhere what are the implementation simplifications you need to implement that feature cleanly. Perhaps Kenji will be interested. Issue 5004 is not a fashion-based enhancement request. Don't let the status quo stop the improvement of the D compilers :-) Bye, bearophile
Re: D2 is really that stable as it is claimed to be?
On 09/24/2013 10:48 PM, Walter Bright wrote: On 9/23/2013 12:19 PM, Timon Gehr wrote: There is no such thing as a law that obliges compiler writers to add column numbers in debug info when such information is available in frontend error messages. I guarantee that if the error messages have column numbers, people will file bug reports that it doesn't show up in the debugger, and rightfully so. In case the performance argument is valid, no, they would not be right.
Re: D2 is really that stable as it is claimed to be?
On 09/24/2013 10:26 PM, Walter Bright wrote: On 9/23/2013 10:33 AM, Iain Buclaw wrote: GCC has a carat too now. DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. You have used lack of comments as an indicator of quality in the past.
Re: D2 is really that stable as it is claimed to be?
On 25/09/13 06:29, Walter Bright wrote: On 9/23/2013 11:38 AM, bearophile wrote: 2) The other improvement I'd like for D error messages and warnings is to give a standard error number. This is a simple improvement, but it makes simpler to write explanation pages for the errors. The C# compiler and other compilers have them. I used to do that, but again, it was a completely unwanted feature, and I abandoned it. It's simple enough to grep for the error message text, and I myself prefer to do the grep method. What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing. Grepping the text can be a problem if the output has been localised. I write GUI wrappers for programs such as Mercurial/Git/Quilt and have been forced to use the (equivalent) of the grep to obtain details of the failure of a Mercurial/Git/Quilt command in order to add niceties as offering a refresh and retry option if (say) a quilt push fails because the repository needs to be refreshed. The reason that I have to do this is that the error value returned by the commands isn't very useful (usually just 0 for success and -1 for failure). The downside of this is that if my user has a locale that uses a language other than English my greps fail and the user misses out on the added niceties that would otherwise have been available. The type of error return value I would have liked to have seen implemented in programs (I asked for changes but none were forthcoming) I write wrappers for would be a flag based system (I think that you can only count on 8 bits in the return value) to indicate the major characteristics of the failure. Peter
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 2:23 PM, David Nadlinger wrote: On Tuesday, 24 September 2013 at 20:26:54 UTC, Walter Bright wrote: On 9/23/2013 10:33 AM, Iain Buclaw wrote: GCC has a carat too now. DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. Maybe that's because not one single person actually uses DMC? ;) yes, I've had a fantasy business for the last 30 years.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 2:56 PM, Andrej Mitrovic wrote: It seems nobody comments on almost anything DMC-related anyway. Isn't this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If it is, there's hardly a single post per month.. You overlook that it's a very old compiler - 30 years. In its day it had maybe 100,000 users. People do still use it today, to compile dmd for Win32 for example, and nobody has yet EVER commented on that feature, unless I prompted them, when I have pointed it out many times over the decades, and the response is always: SO WHAT WHO CARES etc. So please forgive my grumpiness about if clang implements it, suddenly it's the greatest, most useful feature ever.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 3:27 PM, Timon Gehr wrote: You have used lack of comments as an indicator of quality in the past. Lack of comments does mean something. BTW, as I wrote in another post here, I've prompted people about it, due to the silence. Read there what their response was.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 3:04 PM, bearophile wrote: The problem with grepping is that it could lead to mistakes, you have to grep for the whole error message, otherwise you risk finding the wrong message. It's hardly a risk. If you get 2 hits, you skip the one that's a mismatch. Another problem is that the wording could change, both in different versions of the same compiler and in different compilers, so every compiler needs its own wiki. That problem is MUCH WORSE with error numbers. Remember, I have tried it in the past. Also, if you need to use a search, you must have all the error messages in the same page, while with error messages you could just go directly to the page number and you don't need to copy and paste several (all) the words of the error message. Having a standard number across all D compilers allows for a standardization of tools (the IDE has to show the same error tooltips regardless the D compiler you are using). Another advantage of numbers of error messages is that if two different points of the same compiler have to generate the same error, using the same code number there is no risk the error message could go out of sync to each other. This has happened in DMD, where I have seen the same error give different error messages with the same dmd (http://d.puremagic.com/issues/show_bug.cgi?id=11094 ). Standardization of error messages, let alone standardization of error message numbers, is a very bad idea. It presumes all implementations are identical, and hamstrings attempts at innovation. What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing. I have tried to show, here and in Issue 5004, that's not true. I don't believe it, based on plenty of experience with grass is greener compiler ephemera.
Re: D2 is really that stable as it is claimed to be?
On 9/24/13 1:29 PM, Walter Bright wrote: On 9/23/2013 11:38 AM, bearophile wrote: 2) The other improvement I'd like for D error messages and warnings is to give a standard error number. This is a simple improvement, but it makes simpler to write explanation pages for the errors. The C# compiler and other compilers have them. I used to do that, but again, it was a completely unwanted feature, and I abandoned it. It's simple enough to grep for the error message text, and I myself prefer to do the grep method. What makes me grumpy is people only want these things when some other compiler does it, sort of a bandwagon thing. I think it's less a bandwagon thing and more a the bar has been raised thing. 30 years ago ide's were essentially unheard of. Tooling around compilers and languages was almost non-existent. The picture and expectations about user friendliness today are drastically different. The past is not a perfect predictor of the present.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 4:17 PM, Walter Bright wrote: So please forgive my grumpiness about if clang implements it, suddenly it's the greatest, most useful feature ever. Don't get me wrong, I'm not automatically against anything that clang does. The spell-checking on undefined symbols is a nice idea, and we've now got our own version of it in dmd (and in dmc!).
Re: D2 is really that stable as it is claimed to be?
On Tuesday, 24 September 2013 at 23:19:24 UTC, Walter Bright wrote: On 9/24/2013 3:27 PM, Timon Gehr wrote: You have used lack of comments as an indicator of quality in the past. Lack of comments does mean something. BTW, as I wrote in another post here, I've prompted people about it, due to the silence. Read there what their response was. You may underestimate power of marketing in IT world :) It does not matter how useful feature was on its own - clang guys has convinced the crowd it is useful so now it is useful. Its actual merit is irrelevant unless you want to invest into counter-propaganda.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 4:38 PM, Brad Roberts wrote: I think it's less a bandwagon thing and more a the bar has been raised thing. 30 years ago ide's were essentially unheard of. Tooling around compilers and languages was almost non-existent. The picture and expectations about user friendliness today are drastically different. The past is not a perfect predictor of the present. Borland pretty much invented the modern IDE back in the 80's, and before then Emacs served as an IDE (it was able to parse compiler output and display the location of errors and the associated messages). Besides, the ^ thing was for those who didn't use IDEs, not for people who do. I'd have a different attitude about it if just one person had ever said cool when I showed them that feature, and even in the (several) times this has come up before in this ng, and I point out that dmc does it, the reaction seems to be faint annoyance that dmc did it decades before clang :-) grump grump grump BTW, I don't really recall if dmc invented the feature or if I'd seen it before on some other compiler. Too long ago.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 4:43 PM, Dicebot wrote: You may underestimate power of marketing in IT world :) i.e. compiler fashion! It does not matter how useful feature was on its own - clang guys has convinced the crowd it is useful so now it is useful. Its actual merit is irrelevant unless you want to invest into counter-propaganda. Probably the most insightful comment in this thread.
Re: D2 is really that stable as it is claimed to be?
Walter Bright: I don't believe it, based on plenty of experience with grass is greener compiler ephemera. Thank you for your answers Walter. (In this thread we are discussing three possible improvements for error messages, but of the three the only one I have asked in Bugzilla is Issue 5004, because it's the only one I am kinda sure it's an improvement for me). Bye, bearophile
Re: D2 is really that stable as it is claimed to be?
On Sep 24, 2013, at 1:26 PM, Walter Bright newshou...@digitalmars.com wrote: On 9/23/2013 10:33 AM, Iain Buclaw wrote: GCC has a carat too now. DMC has had a carat for 30 years now. int x x; ^ test2.c(2) : Error: missing ',' between declaration of 'x' and 'x' Nobody ever gave a damn about that feature, i.e. not one single person commented on it, including not a single D user. I'm sure you know this, but no one ever comments on stuff they like. Only stuff they don't.
Re: D2 is really that stable as it is claimed to be?
On Tuesday, 24 September 2013 at 23:17:57 UTC, Walter Bright wrote: On 9/24/2013 2:56 PM, Andrej Mitrovic wrote: It seems nobody comments on almost anything DMC-related anyway. Isn't this the DMC newsgroup: http://forum.dlang.org/group/c++ ? If it is, there's hardly a single post per month.. You overlook that it's a very old compiler - 30 years. In its day it had maybe 100,000 users. People do still use it today, to compile dmd for Win32 for example, and nobody has yet EVER commented on that feature, unless I prompted them, when I have pointed it out many times over the decades, and the response is always: SO WHAT WHO CARES etc. So please forgive my grumpiness about if clang implements it, suddenly it's the greatest, most useful feature ever. It doesn't seem that surprising to me. If you want a compiler that is fast, you use DMC, if you want a compiler that will do coffee, you use GCC or clang recently. I do think the user base you judge on is biased.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 4:59 PM, Sean Kelly wrote: I'm sure you know this, but no one ever comments on stuff they like. Only stuff they don't. Except that people often did comment on things they liked about dmc, like its compile speed. Sure, not as often, but it's been 30 years. And, dmd users are often dmc users. Since dmd never had it, and dmc did, wouldn't anyone have suggested hey, I like this dmc feature, why not put it in dmd? But nope.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 5:39 PM, deadalnix wrote: It doesn't seem that surprising to me. If you want a compiler that is fast, you use DMC, if you want a compiler that will do coffee, you use GCC or clang recently. I do think the user base you judge on is biased. I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc.
Re: D2 is really that stable as it is claimed to be?
On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote: On 9/24/2013 5:39 PM, deadalnix wrote: It doesn't seem that surprising to me. If you want a compiler that is fast, you use DMC, if you want a compiler that will do coffee, you use GCC or clang recently. I do think the user base you judge on is biased. I'm sorry, I don't believe the dmc user base secretly loved that feature. Which is why I dropped it from dmd, despite having spent significant time making it work nice in dmc. That is the exact opposite. People that like feature rich compiler already use another compiler. People that like minimal tooling and speed uses DMC.
Re: D2 is really that stable as it is claimed to be?
On 9/24/2013 8:45 PM, deadalnix wrote: That is the exact opposite. People that like feature rich compiler already use another compiler. People that like minimal tooling and speed uses DMC. Except that no other compiler at the time did the caret thing. It was a unique feature of DMC. DMC (or Zortech C++, back in the 80's), was the feature rich compiler of its day.
Re: D2 is really that stable as it is claimed to be?
Walter, I'm sorry to hear your frustration on this issue of the error caret, and the lack of recognition you got for your dmc implementation of that concept. For what it's worth the following is my opinion: - I think I first met an error caret in the javac compiler, around 2000. I found it very nice and useful. My positive experience was not preceded by any marketing of that feature, so I think we can conclude that my enjoyment was genuine. - When clang added nice error diagnostics in general (compared to GCC at the time) and the caret in particular that helped shape my perception of that compiler in a positive light, whatever the actual technical merits of that compiler may be. - In general I think dmd is quite a good compiler but I regularly mumble to myself hmm, the compiler could have provided better diagnostics for this error I committed. I can start compiling a list of those errors with less than great error messages, if that's useful. - Based on my experience with javac and clang, providing a caret (and ranges around the offending expressions, as in clang) is very useful *to me*, and I would be very pleased to see them on the D compilers, even if that information was not present in the debugger, so as not to regress compiler performance.
Re: D2 is really that stable as it is claimed to be?
On 2013-09-21 21:47, Walter Bright wrote: That's gcc, and 4 is the line number (and the wrong line number) of the error. No column number. It's time you start using clang instead of gcc. -- /Jacob Carlborg
Re: D2 is really that stable as it is claimed to be?
On 2013-09-22 07:22, Walter Bright wrote: I'm not rejecting the idea outright. I've actually implemented this in the dmc compiler. It's just not terribly useful, and it has costs. Several people has asked for it and the LLVM community thinks it's worth it. -- /Jacob Carlborg
Re: D2 is really that stable as it is claimed to be?
On 2013-09-22 04:38, Paul Jurczak wrote: That would do: 255 means column 256 or higher (256+). You would please more than 99.99% of users :-) We have lines with over 400 columns at work. Yes I know, horrible. -- /Jacob Carlborg
Re: D2 is really that stable as it is claimed to be?
On Sep 23, 2013 6:30 PM, Sean Kelly s...@invisibleduck.org wrote: On Sep 21, 2013, at 10:22 PM, Walter Bright newshou...@digitalmars.com wrote: On 9/21/2013 8:54 PM, Michel Fortin wrote: I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion. I'm not rejecting the idea outright. I've actually implemented this in the dmc compiler. It's just not terribly useful, and it has costs. I'd consider it in a similar class as the dictionary lookup that occurs when an unknown symbol is encountered. Totally unnecessary, but it's a nice time-saver. Is it clang that displays the line in error with a carat underneath the error? Though if there really isn't an efficient way to do it in DMD then I don't think it's worthwhile. I was only thinking of the parser when I mentioned the beginning-of-line pointer. I hadn't considered the AST. GCC has a carat too now. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: D2 is really that stable as it is claimed to be?
On Sep 21, 2013, at 10:22 PM, Walter Bright newshou...@digitalmars.com wrote: On 9/21/2013 8:54 PM, Michel Fortin wrote: I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion. I'm not rejecting the idea outright. I've actually implemented this in the dmc compiler. It's just not terribly useful, and it has costs. I'd consider it in a similar class as the dictionary lookup that occurs when an unknown symbol is encountered. Totally unnecessary, but it's a nice time-saver. Is it clang that displays the line in error with a carat underneath the error? Though if there really isn't an efficient way to do it in DMD then I don't think it's worthwhile. I was only thinking of the parser when I mentioned the beginning-of-line pointer. I hadn't considered the AST.
Re: D2 is really that stable as it is claimed to be?
Regarding the improving the error messages of D compilers, I think having the column number is nice, but there are two improvements that I think are more important: 1) One of them is the aka, that is showing both the name of aliases and the aliased types/values: http://d.puremagic.com/issues/show_bug.cgi?id=5004 2) The other improvement I'd like for D error messages and warnings is to give a standard error number. This is a simple improvement, but it makes simpler to write explanation pages for the errors. The C# compiler and other compilers have them. Bye, bearophile
Re: D2 is really that stable as it is claimed to be?
On 9/23/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I have a partial implementation of this in one of my branches Also, I will not continue work on this unless Walter greenlights it. I'm not going to put any work that's inevitably going to be thrown away.
Re: D2 is really that stable as it is claimed to be?
On 9/23/13, bearophile bearophileh...@lycos.com wrote: 1) One of them is the aka, that is showing both the name of aliases and the aliased types/values: http://d.puremagic.com/issues/show_bug.cgi?id=5004 I have a partial implementation of this in one of my branches, but IIRC it was difficult do cover all cases since the compiler internally inserts a bunch of aliases as well. Those could be marked that they're internal, so that's fixable. Another issue I ran into is that diagnostics are called after the retrieval of the aliased-to type, which basically means by the time the compiler issues errors the alias declaration is gone, the compiler only works on the target symbol. I had a workaround for this, but it's going to take more work to get done.
Re: D2 is really that stable as it is claimed to be?
On 2013-09-21 23:12, Andrei Alexandrescu wrote: I'm ambivalent because the matter is fuzzy. It is factually true that new releases will break code. On the other hand, that is the case with most compiler releases even for mature languages (at Facebook upgrading across minor gcc releases _always_ entails significant disruption). On the third hand (sic), there are companies and projects using D in the real world so stating that is unstable would do little else than either shoo people away for no good reason. Some of these companies still use D1. About the code breakage. I think it's still an issue that bugfixes and language changes occur in the same release. No notation of major, minor and patch releases. -- /Jacob Carlborg
Re: D2 is really that stable as it is claimed to be?
On 09/22/2013 09:27 PM, Walter Bright wrote:
On 9/22/2013 11:43 AM, Timon Gehr wrote:
Tracking line numbers is likely worth it. I don't believe that
providing column
numbers in error messages necessitates a slowdown though.
Please consider that:
IT ISN'T JUST FOR ERROR MESSAGES
It would go in the symbolic debug info, too, where it will be required
everywhere and will be right there on the fast path through the
lexer/compiler.
...
There is no such thing as a law that obliges compiler writers to add
column numbers in debug info when such information is available in
frontend error messages. The trade-offs involved in both cases may be
different and deserve separate consideration.
Now consider the lexer doing a fast skip over comment text (this ranks
fairly high in the profile). This operation gets a lot slower if you're
also keeping track of column number.
I am not keeping track of column number.
Please note that:
COLUMN NUMBER ISN'T THE OFFSET FROM THE START OF THE LINE
...
Obviously. I compute the correct column number exactly in the case when
an error message should actually be printed. It is not necessary to do
any of this on the fast path. The additional memory word per location
that I waste in comparison to DMD could be shaved off by using more
computation in the error case (or by giving up support for exact
underlining), but the project has not yet reached a stage where this is
worth considering/measuring.
Excerpts from actual code I wrote roughly two years ago:
class Source{
// computes a slice of the entire first line
// where some given slice occurs in the source buffer.
// this allows to recover column information on the fly, and we
// will also be able to print the line where an error occurred
// without storing it explicitly.
// running time is linear in output length
string getLineOf(string rep)in{/*...*/}out{/*...*/}body{
string before=code[0..rep.ptr-code.ptr];
string after=code[rep.ptr-code.ptr..$];
immutable(char)* start=code.ptr, end=code.ptr+code.length;
// It is fine to skip decoding here, because we are just
// searching for ASCII characters.
// TODO: support unicode line breaks?
foreach_reverse(ref c; before)
if(c=='\n'||c=='\r'){start = c+1; break;}
foreach(ref c; after)
if(c=='\n'||c=='\r'){end = c; break;}
return start[0..end-start];
}
// ...
}
struct Location{
string rep;// slice of the code representing the Location
int line; // line number at start of location
@property Source source()const{
auto src = Source.get(rep); // (currently just a linear search)
assert(src, source for '~rep~' not found!);
return src;
}
// ...
}
int getColumn(Location loc, int tabsize){
int res=1;
auto l=loc.source.getLineOf(loc.rep);
for(;!l.emptyl[0]l.ptrloc.rep.ptr; l.popFront()){
if(l.front=='\t') res=res-res%tabsize+tabsize;
else res++;
}
return res;
}
Re: D2 is really that stable as it is claimed to be?
On Saturday, September 21, 2013 23:54:26 Michel Fortin wrote: On 2013-09-22 03:32:26 +, Jonathan M Davis jmdavisp...@gmx.com said: On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote: Column values are of interest in an IDE because it can pinpoint the error more precisely. The IDE can show exactly where the error is (for instance with a dotted red underline), often allowing you to fix the error without even reading the error message (especially when it's a typo). With a background-compilation-as-you-type system you know almost immediately when you make an error, and you know where it is. A lexer being used by an IDE definitely needs the column number, but the normal compiler doesn't. I was referring to how the IDE can show the compiler's error messages better when the column number is available, not to how it does syntax highlighting. Xcode uses this a lot, and clang's error log provides full character ranges for errors, not just a column number, making the visualization of errors much better and pleasant to work with. But indeed, no one *needs* that. Like everything else, it's just a convenience. I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion. I don't think that it's at all worth it for compiling with the compiler on the command line. The situation changes somewhat when an IDE gets involved. - Jonathan M Davis
Re: D2 is really that stable as it is claimed to be?
2013/9/22 Zhouxuan pyc...@qq.com http://d.puremagic.com/**issues/show_bug.cgi?id=10970http://d.puremagic.com/issues/show_bug.cgi?id=10970 That is a long-standing bug around AA value setting and opAssign, and fortunately I recently tried to fix it by determining the language semantics. https://github.com/D-Programming-Language/dmd/pull/2539 Kenji Hara
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote: On 9/21/2013 9:34 PM, deadalnix wrote: Most issue are being worked on. That being said, changing semantic in a programming language is always a difficult matter, as people code relying on the old bugguy behavior may break. And often the same people who want semantic changes are the ones who complain when new features break things :-( Guilty here :D
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote: On 9/21/2013 5:11 PM, Sean Kelly wrote: someone's entire source file is on one line, and on it goes. OTOH, this is exactly the showcase where such a feature would be *really* useful.
Re: D2 is really that stable as it is claimed to be?
On Saturday, 21 September 2013 at 22:08:23 UTC, Andrej Mitrovic wrote: On 9/21/13, Maxim Fomin ma...@maxim-fomin.ru wrote: (like AAs, scope, shared) are at risk to be seriously changed which is a serious problem to the user. These are already a serious problem to the user when they're broken and under-implemented. I'm really hoping for an improvement of shared and the concurrency field. It's a pity having someone that having read the concurrency chapter of TDPL (for free, also!) start toying with shared and... hey, it does not works that way? where's the actual documentation then? what is the timeline? what? no timeline? gheeez (really happened, BTY) /Paolo
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote: On 9/21/2013 5:11 PM, Sean Kelly wrote: Tracking the column number is certainly doable, but it comes at a cost of memory consumption and some compile speed, since it has to be tracked in every token. I used to do it in the Digital Mars C compiler, but it was of only marginal utility and I dropped it. Can't you just hold a pointer to the beginning of the line and subtract to find the column? I agree that it's generally of marginal utility though. Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs Unicode). Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns. Then you get a bug report where someone does. So raise it to an unsigned short, then, sigh, you get another bug report where someone's entire source file is on one line, and on it goes. I'll go for a byte, and a well written 256 in the message when necessary... a very good compromise I'll tell! /P
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote: On 9/21/2013 9:34 PM, deadalnix wrote: Most issue are being worked on. That being said, changing semantic in a programming language is always a difficult matter, as people code relying on the old bugguy behavior may break. And often the same people who want semantic changes are the ones who complain when new features break things :-( That is expected, logical and described to you several times :P
Re: D2 is really that stable as it is claimed to be?
On 09/22/2013 02:33 AM, Walter Bright wrote:
On 9/21/2013 5:11 PM, Sean Kelly wrote:
Tracking the column number is certainly doable, but it comes at a
cost of
memory consumption and some compile speed, since it has to be tracked in
every token. I used to do it in the Digital Mars C compiler, but it
was of
only marginal utility and I dropped it.
Can't you just hold a pointer to the beginning of the line and
subtract to
find the column? I agree that it's generally of marginal utility though.
Holding the pointer has a cost of memory consumption and compile speed
:-)
(The current scheme is not optimal either.)
struct Loc
{
const char *filename; // --
unsigned linnum;
Replace this pointer by a pointer or (global) offset to the first
character in the source file buffer corresponding to the AST node. The
file name can be recovered from this using an appropriate data structure.
In order to find the first column index, decode backwards until you hit
a newline character or the beginning of the source file.
In order to find the last column index if that is wanted, re-invoke the
parser. (Personally, I just store a slice into the source buffer.)
This allows the compiler to underline the location where an error occurred:
tt.d:7:14: error: need 'this' to access field 'S.member'
auto x = S.member;
^~~~
tt.d:3:5: note: field was declared here
int member;
^~~
Editors understand this format and can quickly jump to the location.
You could also get rid of linnum by splitting the source file buffer
into lines on demand and using binary search.
as well as having to have the source file buffer stay around
throughout the compile ...
Which, as far as I understand, DMD does anyway? If you do not want to
keep it around, release it and reload it on demand if an error actually
occurs in that buffer. (Time taken to spit out an error message does not
need to be optimized that much.)
Re: D2 is really that stable as it is claimed to be?
On 9/22/13, Jonathan M Davis jmdavisp...@gmx.com wrote: Except that most of us don't care about the column number. It's of marginal benefit at best, and it harms compilation speed, so it's not worth it IMHO. You've never ran into lexer errors before have you? test.d(10): Error: found ',' when expecting ')' Now good luck finding where you forgot to put a closing brace in a statement that uses traits or is(typeof( checks, such as this: static assert(0, format(%s does not implement '%s', __traits(identifier, typeof(this))), __FUNCTION__); It should have been: static assert(0, format(%s does not implement '%s', __traits(identifier, typeof(this)), __FUNCTION__)); That's just a trivial case though. I run into these all the time, and I have to spend half a minute scanning left and right trying to figure out where the damn missing brace went. Marginal benefit my ass.
Re: D2 is really that stable as it is claimed to be?
On 9/21/13 11:42 PM, deadalnix wrote: On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote: On 9/21/2013 9:34 PM, deadalnix wrote: Most issue are being worked on. That being said, changing semantic in a programming language is always a difficult matter, as people code relying on the old bugguy behavior may break. And often the same people who want semantic changes are the ones who complain when new features break things :-( Guilty here :D We all are. Andrei
Re: D2 is really that stable as it is claimed to be?
On 9/22/13 1:12 AM, Paolo Invernizzi wrote: On Saturday, 21 September 2013 at 22:08:23 UTC, Andrej Mitrovic wrote: On 9/21/13, Maxim Fomin ma...@maxim-fomin.ru wrote: (like AAs, scope, shared) are at risk to be seriously changed which is a serious problem to the user. These are already a serious problem to the user when they're broken and under-implemented. I'm really hoping for an improvement of shared and the concurrency field. It's a pity having someone that having read the concurrency chapter of TDPL (for free, also!) start toying with shared and... hey, it does not works that way? where's the actual documentation then? what is the timeline? what? no timeline? gheeez (really happened, BTY) /Paolo Probably this should be the next focal area. Andrei
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 12:24:03 UTC, Timon Gehr wrote: You could also get rid of linnum by splitting the source file buffer into lines on demand and using binary search. Does that work with #line?
Re: D2 is really that stable as it is claimed to be?
On 09/22/2013 12:36 AM, Walter Bright wrote:
On 9/21/2013 3:11 PM, Maxim Fomin wrote:
On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright wrote:
On 9/21/2013 2:40 PM, Maxim Fomin wrote:
Thanks, that is clear. Unfortunately, I cannot say that the
explanation improves
my attidute to the language - dmd still breaks too often code and some
significant features (like AAs, scope, shared) are at risk to be
seriously
changed which is a serious problem to the user.
I'm curious - was there a logic bug in your code with the overflow,
or had
that been the intended behavior?
This was bug in gtkd sources when I tried to compile its most recent
version
(tried even from github) with git-head dmd. I think it is a problem of
gtkd
developers rather than dmd.
Ok, so it found a latent bug in the source code - I don't think that's a
good example of dmd being unstable - it was a good change.
I've reduced the code causing the error to this:
```
public enum GTokenType
{
NONE,
}
public enum GtkRcTokenType
{
INVALID = GTokenType.NONE,
INCLUDE,
}
```
In this case the value of INVALID + 1 isn't large enough the overflow an
int.
In the actual code:
https://github.com/gtkd-developers/GtkD/blob/master/src/gtkc/glibtypes.d#L1310
Setting NONE to a value lower than 87 makes it so the code compiles
without error, which only makes things weirder.
--
Mike Wey
Re: D2 is really that stable as it is claimed to be?
On 9/22/2013 10:16 AM, Mike Wey wrote: I've reduced the code causing the error to this: http://d.puremagic.com/issues/show_bug.cgi?id=11101
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 17:15:15 UTC, Mike Wey wrote:
I've reduced the code causing the error to this:
```
public enum GTokenType
{
NONE,
}
public enum GtkRcTokenType
{
INVALID = GTokenType.NONE,
INCLUDE,
}
```
In this case the value of INVALID + 1 isn't large enough the
overflow an int.
In the actual code:
https://github.com/gtkd-developers/GtkD/blob/master/src/gtkc/glibtypes.d#L1310
Setting NONE to a value lower than 87 makes it so the code
compiles without error, which only makes things weirder.
Thanks, that's helpful.
Re: D2 is really that stable as it is claimed to be?
On 9/22/2013 5:24 AM, Timon Gehr wrote: [...] Your proposal has a serious shortcoming: The fast path through the compiler is the one where people generate symbolic debug info. This requires file/line numbers for everything. Adding an arbitrarily expensive computation to get them makes for slow compiles.
Re: D2 is really that stable as it is claimed to be?
On 9/22/2013 7:50 AM, Andrej Mitrovic wrote:
I run into these all the time, and I have to spend half a minute
scanning left and right trying to figure out where the damn missing
brace went. Marginal benefit my ass.
I programmed into my editor (MicroEmacs) the F3 command. F3, when sitting on one
of ()[]{} will find the matching character, even if nested. If it is not on
one of those characters, it finds the next occurrence of that character.
As a bonus, if it is on the # character at the beginning of the line, it will
find the matching #if, #ifdef, #elif, #else, or #endif :-)
I find it very, very handy.
It's based on an elithp macro written for Emacs back in the 1980's. If your
editor has any ability to have user-written extensions, this is a simple one,
and I highly recommend it. Here's the corresponding MicroEmacs implementation:
---
/*
* Examine line at '.'.
* Returns:
* HASH_xxx
* 0 anything else
*/
#define HASH_IF 1
#define HASH_ELIF 2
#define HASH_ELSE 3
#define HASH_ENDIF 4
static int ifhash(clp)
LINE *clp;
{
register int len;
register int i,h;
static char *hash[] = {if,elif,else,endif};
len = llength(clp);
if (len 3 || lgetc(clp,0) != '#')
goto ret0;
for (i = 1; ; i++)
{
if (i = len)
goto ret0;
if (!isspace(lgetc(clp,i)))
break;
}
for (h = 0; h arraysize(hash); h++)
if (len - i = strlen(hash[h])
memcmp(clp-l_text[i],hash[h],strlen(hash[h])) == 0)
return h + 1;
ret0:
return 0;
}
/*
* Search for the next occurence of the character at '.'.
* If character is a (){}[], search for matching bracket.
* If '.' is on #if, #elif, or #else search for next #elif, #else or #endif.
* If '.' is on #endif, search backwards for corresponding #if.
*/
int search_paren(f, n)
{
register LINE *clp;
register int cbo;
register int len;
register int i;
char chinc,chdec,ch;
int count;
int forward;
int h;
static char bracket[][2] = {{'(',')'},{'',''},{'[',']'},{'{','}'}};
clp = curwp-w_dotp; /* get pointer to current line */
cbo = curwp-w_doto; /* and offset into that line*/
count = 0;
len = llength(clp);
if (cbo = len)
chinc = '\n';
else
chinc = lgetc(clp,cbo);
if (cbo == 0 (h = ifhash(clp)) != 0)
{ forward = h != HASH_ENDIF;
}
else
{
if (inword())
{ // Search for word the cursor is currently on
int s;
do
s = backchar(FALSE, 1);
while (s inword());
if (s forwchar(FALSE, 1))
{
int start = curwp-w_doto;
if (word_forw(FALSE, 1))
{
cbo = curwp-w_doto;
int i;
for (i = 0; i NPAT - 1 start + i cbo; i++)
{
pat[i] = lgetc(clp, start + i);
}
pat[i] = 0;
if (Dsearchagain(f, n))
return backchar(FALSE, 1);
}
}
mlwrite(Not found);
return FALSE;
}
forward = TRUE; /* forward */
h = 0;
chdec = chinc;
for (i = 0; i 4; i++)
if (bracket[i][0] == chinc)
{ chdec = bracket[i][1];
break;
}
for (i = 0; i 4; i++)
if (bracket[i][1] == chinc)
{ chdec = bracket[i][0];
forward = FALSE;/* search backwards */
break;
}
}
while (1) /* while not end of buffer */
{
if (forward)
{
if (h || cbo = len)
{
clp = lforw(clp);
if (clp == curbp-b_linep) /* if end of buffer */
break;
len = llength(clp);
cbo = 0;
}
else
cbo++;
}
else /* backward */
{
if (h || cbo == 0)
{
clp = lback(clp);
if (clp == curbp-b_linep)
break;
len = llength(clp);
cbo = len;
}
else
--cbo;
}
if (h)
{ int h2;
cbo = 0;
h2 = ifhash(clp);
if (h2)
{ if (h == HASH_ENDIF)
{
if (h2 == HASH_ENDIF)
count++;
else if (h2 == HASH_IF)
{ if (count-- == 0)
goto
Re: D2 is really that stable as it is claimed to be?
On 09/22/2013 07:51 PM, Walter Bright wrote: ... The fast path through the compiler is the one where people generate symbolic debug info. This requires file/line numbers for everything. Typically the file names of AST nodes that are processed consecutively coincide, and testing whether a location is in a given file is easy, so it is possible that this is not an issue at all. Line numbers can be stored without increasing the memory footprint in comparison with the current scheme. Adding an arbitrarily expensive computation to get them makes for slow compiles. Tracking line numbers is likely worth it. I don't believe that providing column numbers in error messages necessitates a slowdown though. (Probably we should just implement/optimize and measure.)
Re: D2 is really that stable as it is claimed to be?
On 09/22/2013 05:24 PM, Peter Alexander wrote: On Sunday, 22 September 2013 at 12:24:03 UTC, Timon Gehr wrote: You could also get rid of linnum by splitting the source file buffer into lines on demand and using binary search. Does that work with #line? Well, yes. Eg. collect their locations/line number pairs into an array while lexing and then process that during line splitting.
Re: D2 is really that stable as it is claimed to be?
On 9/22/2013 11:43 AM, Timon Gehr wrote: Tracking line numbers is likely worth it. I don't believe that providing column numbers in error messages necessitates a slowdown though. Please consider that: IT ISN'T JUST FOR ERROR MESSAGES It would go in the symbolic debug info, too, where it will be required everywhere and will be right there on the fast path through the lexer/compiler. Now consider the lexer doing a fast skip over comment text (this ranks fairly high in the profile). This operation gets a lot slower if you're also keeping track of column number. Please note that: COLUMN NUMBER ISN'T THE OFFSET FROM THE START OF THE LINE because of tabs and UTF-8 sequences. Any proposal for column number tracking must take these issues into account. Also note that g++ and clang are hardly noted for their fast compile speeds. Also note that g++'s compile speed has dropped significantly lately - I don't know why, but it also added column number support recently (!).
Re: D2 is really that stable as it is claimed to be?
Walter Bright: Any proposal for column number tracking must take these issues into account. Also note that g++ and clang are hardly noted for their fast compile speeds. Also note that g++'s compile speed has dropped significantly lately - I don't know why, but it also added column number support recently (!). If someone writes a front-end patch to show column numbers we'll have to benchmark it and decide how much complex/buggy it is and how much extra memory/time it asks for. Bye, bearophile
Re: D2 is really that stable as it is claimed to be?
On Sunday, September 22, 2013 09:36:45 eles wrote: On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote: On 9/21/2013 5:11 PM, Sean Kelly wrote: someone's entire source file is on one line, and on it goes. OTOH, this is exactly the showcase where such a feature would be *really* useful. True, but it's also a use case which is completely unreasonable and for which it would make no sense to even help out with, let alone optimize for. Anyone who writes source like that deserves to have problems finding where in the code an error is. - Jonathan M Davis
Re: D2 is really that stable as it is claimed to be?
On Saturday, 21 September 2013 at 21:17:13 UTC, Paulo Pinto wrote: Am 21.09.2013 23:03, schrieb eles: On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright wrote: On 9/21/2013 12:38 PM, eles wrote: On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote: On 9/21/2013 11:03 AM, Maxim Fomin wrote: The funny thing is that this was already supported since a few years in the form of colorgcc. Yes, but it is only recently that gcc started to improve error messages, with 4.9 OTOH, column was displayed even before, but in plain text. For those using dmd or gdc and looking for something a bit on the line of colorgcc (albeit a coarser approach), check this piece of software: https://github.com/dmoulding/hilite/blob/master/hilite.c
Re: D2 is really that stable as it is claimed to be?
On 9/22/2013 1:30 PM, bearophile wrote: If someone writes a front-end patch to show column numbers we'll have to benchmark it and decide how much complex/buggy it is and how much extra memory/time it asks for. Sure.
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote: On 9/21/2013 5:11 PM, Sean Kelly wrote: as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs Unicode). trade-off: print the offending line as seen in the analyzed file (after you process tabsunicode), and refer the column wrt its beginning. Then display a caret on the next line. Even if not identical with the line in the original file, at least it's better than nothing.
Re: D2 is really that stable as it is claimed to be?
On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote: On 9/22/13, Jonathan M Davis jmdavisp...@gmx.com wrote: Except that most of us don't care about the column number. It's of marginal benefit at best, and it harms compilation speed, so it's not worth it IMHO. You've never ran into lexer errors before have you? test.d(10): Error: found ',' when expecting ')' Now good luck finding where you forgot to put a closing brace in a statement that uses traits or is(typeof( checks, such as this: static assert(0, format(%s does not implement '%s', __traits(identifier, typeof(this))), __FUNCTION__); It should have been: static assert(0, format(%s does not implement '%s', __traits(identifier, typeof(this)), __FUNCTION__)); That's just a trivial case though. I run into these all the time, and I have to spend half a minute scanning left and right trying to figure out where the damn missing brace went. Marginal benefit my ass. Except that because the compiler doesn't know where the terminator should have been, it can't give you a column number anyway. In that case, it can't even give you the correct line number. At best, it can tell you the line number where the unmatched symbol was, and that's often not helpful (especially with braces). And even with parens, because the compiler doesn't know what you actually meant to do, it's not like it can tell you where exactly in the expression or statement you need to fix your code anyway. I really don't think that a column number would help much here. - Jonathan M Davis
Re: D2 is really that stable as it is claimed to be?
On Sunday, 22 September 2013 at 21:12:22 UTC, Jonathan M Davis wrote: On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote: On 9/22/13, Jonathan M Davis jmdavisp...@gmx.com wrote: braces). And even with parens, because the compiler doesn't know what you actually meant to do, it's not like it can tell you where Maybe, but at least it can say: HERE, you see, HERE, this is the exact place where I was expecting a ')' and found a ','. I mean, HERE means the third comma on this line, not the second, not the fifth. It is an important information when you have a LOC with 10 ')' and 20 commas. Which comma is the trouble?
Re: D2 is really that stable as it is claimed to be?
On 9/22/2013 2:17 PM, eles wrote: It is an important information when you have a LOC with 10 ')' and 20 commas. Fortunately, D is not Lithp :-)
Re: D2 is really that stable as it is claimed to be?
On 22 September 2013 20:27, Walter Bright newshou...@digitalmars.com wrote: On 9/22/2013 11:43 AM, Timon Gehr wrote: Tracking line numbers is likely worth it. I don't believe that providing column numbers in error messages necessitates a slowdown though. Please consider that: IT ISN'T JUST FOR ERROR MESSAGES It would go in the symbolic debug info, too, where it will be required everywhere and will be right there on the fast path through the lexer/compiler. Now consider the lexer doing a fast skip over comment text (this ranks fairly high in the profile). This operation gets a lot slower if you're also keeping track of column number. Please note that: COLUMN NUMBER ISN'T THE OFFSET FROM THE START OF THE LINE because of tabs and UTF-8 sequences. Any proposal for column number tracking must take these issues into account. Also note that g++ and clang are hardly noted for their fast compile speeds. Also note that g++'s compile speed has dropped significantly lately - I don't know why, but it also added column number support recently (!). Depends on what you mean by recently. GCC has certainly gained a fair few compilation/optimisation passes over the past few releases. 4.3 - 223 passes (2008) 4.4 - 225 passes (2009) 4.5 - 239 passes (2010) 4.6 - 241 passes (2011) 4.7 - 252 passes (2012) 4.8 - 268 passes (2013) 4.9 - 269 passes (development) And showing column numbers has been turned on since gcc-4.4 (released in 2009). Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: D2 is really that stable as it is claimed to be?
On 9/22/2013 10:43 AM, Walter Bright wrote: On 9/22/2013 10:16 AM, Mike Wey wrote: I've reduced the code causing the error to this: http://d.puremagic.com/issues/show_bug.cgi?id=11101 Upon looking at it more closely, the bug is invalid, and the compiler is correct. See the report for the explanation.
Re: D2 is really that stable as it is claimed to be?
On 23/09/13 07:12, Jonathan M Davis wrote: On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote: On 9/22/13, Jonathan M Davis jmdavisp...@gmx.com wrote: Except that most of us don't care about the column number. It's of marginal benefit at best, and it harms compilation speed, so it's not worth it IMHO. You've never ran into lexer errors before have you? test.d(10): Error: found ',' when expecting ')' Now good luck finding where you forgot to put a closing brace in a statement that uses traits or is(typeof( checks, such as this: static assert(0, format(%s does not implement '%s', __traits(identifier, typeof(this))), __FUNCTION__); It should have been: static assert(0, format(%s does not implement '%s', __traits(identifier, typeof(this)), __FUNCTION__)); That's just a trivial case though. I run into these all the time, and I have to spend half a minute scanning left and right trying to figure out where the damn missing brace went. Marginal benefit my ass. Except that because the compiler doesn't know where the terminator should have been, it can't give you a column number anyway. In that case, it can't even give you the correct line number. At best, it can tell you the line number where the unmatched symbol was, and that's often not helpful (especially with braces). And even with parens, because the compiler doesn't know what you actually meant to do, it's not like it can tell you where exactly in the expression or statement you need to fix your code anyway. I really don't think that a column number would help much here. With my dunnart LALR(1) parser generator, the lexer that's generated as part of the generated parser passes its tokens as class instances that give access to the line number and column at which the token was found in the text and the exact slice of the input text that was matched to form the token. That information travels with the token (rather than being something you have ask the lexer for in most lexers e.g. flex) so it's always available no matter where the token pops up in the parser. Similarly, when the parser does a reduce, the non terminal grammar symbol acquires the positional data for the first token in the reduced sequence. Peter
Re: D2 is really that stable as it is claimed to be?
On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. Should I continue? Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. Yes, it is unstable and still is advertized as being so. There are significant misfunctioning features which would break code when are fixed, let alone each release breaks something minor. For example, I was pissed off two days ago when git-head dmd rejected to compile large code base due to some 'enum overflow' error. Being watching bugzilla and github for two years, that change was neither expected nor clear for me. Now I see, that two years ago when I abandoned not reach for features but fully stable lang, I was undervaluing neccessity of a lang to be a stable.
Re: D2 is really that stable as it is claimed to be?
Zhouxuan: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. D is not claimed to be stable, or those claims are wrong. About three years ago I used to find a new compiler bug about every 20 lines of my code. Now the situation is improved a lot and I am able to write more lines before hitting bugs. They have fixed hundreds of the bugs I have submitted, so dmd is now more debugged for the code patterns I usually write. If your code patterns are different from mine, you will see significantly more bugs than me :-) Should I continue? Of course you should continue to submit bugs. Fixing 100+ bugs in every D release is having positive visible effects on the language+compiler. If you submit bugs and they get fixed in some days/weeks/months/years, your code patterns will work more and more. Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. There is no official roadmap because D is not developed in that way, and because there is not enough workforce. Perhaps someday a roadmap will be present. Bye, bearophile
Re: D2 is really that stable as it is claimed to be?
On 9/21/2013 11:03 AM, Maxim Fomin wrote:
For example, I was pissed off two days ago when
git-head dmd rejected to compile large code base due to some 'enum overflow'
error. Being watching bugzilla and github for two years, that change was neither
expected nor clear for me.
Enum members with no initializer are defined to be set to the previous enum
member's value + 1. This, of course, can overflow if the previous value is the
max value for the type. For example,
enum E {
A = int.max,
B
}
C:\cbx\marsdmd test
test.d(3): Error: enum member test.E.B overflow of enum value cast(E)2147483647
This change was made because the behavior of ignoring the overflow was listed as
a bug.
Since you said it was unclear, how could this be made clear?
As C code:
enum E {
A = 2147483647,
B
};
and gcc reports:
test.c:4: error: overflow in enumeration values
Re: D2 is really that stable as it is claimed to be?
On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. Should I continue? Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. D is not what I would call stable, but it is very usable. Apparently D is used at Facebook in some capacity, but Andrei won't tell us more than that :-) Not long ago I would find bugs every hour or so, but now I rarely find bugs. Perhaps I have just learned to write code in the subset of D that works well, but the language is definitely a lot more stable. Please continue to submit bugs. The D contributors do fix bugs very rapidly in general.
Re: D2 is really that stable as it is claimed to be?
On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. Should I continue? I have had similar feelings when I started with D i think. Well, as soon as you see a language which has so many capabilities you've never seen before in one place (reflection and native code - yay!) you start pushing it to the limit. Sometimes you're doing a thing noone even thought about before :). Exercising the capabilites of D is fun but there are some things which do not work yet. After some experience I've settled on using a simpler subset of D functionality; both because I think simpler sollutions are better and because simpler parts of D tend to work very well. Go ahead and report more bugs, this is improving the situation in longer term. People which will use D after you will be glad you've spent a little time on doing that because their experience will be smoother. It'd be nice if D was perfect already but things simply take a lot of time and effort to be done. It's hard to compete with already mature enviroments because of that. Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. As for containers there's std.container and builtin arrays and hasmaps - that's somewhat a poor set, but you can use container libraries from github. Containers as planned for phobos need solving the issue of allocators for them. Andrei which is working on them is probably stuck in void somewhere between compiletime and runtime worlds :)
Re: D2 is really that stable as it is claimed to be?
On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote: On 9/21/2013 11:03 AM, Maxim Fomin wrote: test.c:4: error: overflow in enumeration values It would be difficult to make the front-end track also the column number where it encountered (estimated) the error? This will make error messages a bit more clear (and in the line of thos in gcc), especially for long code lines (where you could have, for example, several instructions on the line). At the beginning, until the feature is really implemented, the front-end could always provide column=1, ie stick with current approach. But this will help the gdc/ldc-implementations to be in line with the messages provided by gcc and clang.
Re: D2 is really that stable as it is claimed to be?
On 9/21/2013 12:38 PM, eles wrote: On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote: On 9/21/2013 11:03 AM, Maxim Fomin wrote: test.c:4: error: overflow in enumeration values It would be difficult to make the front-end track also the column number where it encountered (estimated) the error? That's gcc, and 4 is the line number (and the wrong line number) of the error. No column number. This will make error messages a bit more clear (and in the line of thos in gcc), especially for long code lines (where you could have, for example, several instructions on the line). At the beginning, until the feature is really implemented, the front-end could always provide column=1, ie stick with current approach. But this will help the gdc/ldc-implementations to be in line with the messages provided by gcc and clang. Tracking the column number is certainly doable, but it comes at a cost of memory consumption and some compile speed, since it has to be tracked in every token. I used to do it in the Digital Mars C compiler, but it was of only marginal utility and I dropped it.
Re: D2 is really that stable as it is claimed to be?
On 9/21/2013 10:41 AM, Zhouxuan wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11086 http://d.puremagic.com/issues/show_bug.cgi?id=11010 http://d.puremagic.com/issues/show_bug.cgi?id=10970 I've found and reported these bugs after about merely 100 LOCs written down. Should I continue? Despite these tiny issues, I see a lot of people complain about container, GC etc, but I can't found any offical reply, also no roadmap at all. Thanks for taking the time to make some nice bug reports. They're a big help.
