Re: D support in Exuberant Ctags 5.8 for Windows
On Tuesday, 11 November 2014 at 18:44:23 UTC, ANtlord wrote: Wake up dead topic! :) On Tuesday, 25 September 2012 at 04:22:13 UTC, p.crimsonsphere wrote: Hi there. So, anyway, have you found any live link to download Ctags 5.8 working for D programming language? I found here http://pastie.org/971968 and applied it to http://dfrank.ru/ctags581 I downloaded compiler for Ctags, I mean, BCC32 and failed to compile it. If anyone has a Ctags 5.8 or 5.81 for D language, please~ Regards. If it is actually, you can use that https://github.com/snosov1/ctags-d. I wanted to suggest this link as well (snosov1 is me). It is ctags 5.8 with the aforementioned patch applied and few other fixes on top. It's not perfect, but works reasonable. I didn't use Dscanner for that functionality much, but I expect it to have better quality.
Re: the traits trap
On Friday, 21 November 2014 at 04:08:52 UTC, Steven Schveighoffer wrote: Can anyone figure out a good solution to this problem? I like template constraints, but they are just too black-boxy. Would we have to signify that some enum is actually a trait and so the compiler would know to spit out the junk of compiling? Would it make sense to add some __traits function that allows one to signify that this is a special trait thing? This is one area that D's templates are very user-unfriendly. -Steve I would second this. Personally, I have the same "not very pleasant" experience debugging template constraints. Since more often than not the constraints have the form of: if (clause1 && clause2 && clause3 ...) my naive proposal would be to show which clause was first to be false in the error message. However, I have no idea if this could be implemented easily.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 08:57:56 UTC, Walter Bright wrote: I've debugged a lot of D code with no debugger at all (how else could I port it to various platforms like Win64?). I've actually not found debuggers to be of much use other than telling me where the seg fault was and giving a stack trace. I think the most valuable point Manu made is that there are "excellent" and "good" programmers. The difference is not so much in the actual skills, but in the willing to spend time on programming. "Excellent programmers" spend a great amount of time learning things. It takes a huge part of their free time and it really takes a lot of passion and diligence. But most of the professional programmers are simply "good". They code at work and that's it. They don't spend any time beyond that on programming and, especially, learning new things. If we're speaking about "excellent programmers" category, then almost everything about D is already good enough for these people. You can tell it by a number of truly fascinating D projects. And it looks like the guys who work on D are mostly "excellent programmers", which speak pretty different language compared to the "good programmers". Probably, this is the main cause of misunderstanding. In the "debugger" case, Manu's point is that it's unusable. And Walter's implied point is "debuggers aren't that useful anyway, so why it was a showstopper?". My personal observation is that "excellent programmers" share the Walter's point on debuggers - they practically don't use it. And the uselessness is so obvious, that there's nothing even to talk about. At the same time, "good programmers" use it extensively, especially on Windows. It is so useful to them, that there's nothing even to talk about! So, Manu speaks from the "good programmer" position, and Walter speaks from the "excellent programmer" position, implying "if you'd become a better programmer, you wouldn't have no problems using D". This implication is mostly true. But it's orthogonal to Manu's point - "good programmers" have troubles using D. The probable solution to this is to attract some "good" programmers to point out and work on the aforementioned issues - site, documentation, tooling, etc. But I'm not sure it's possible to do this for D with volunteer efforts.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 11:16:41 UTC, Walter Bright wrote: On 12/19/2014 2:47 AM, Sergei Nosov wrote: The probable solution to this is to attract some "good" programmers to point out and work on the aforementioned issues - site, documentation, tooling, etc. But I'm not sure it's possible to do this for D with volunteer efforts. Sure it's possible - but the issues have to be specific. "Need more examples", for example (!), is nice but not helpful to anyone trying to improve the documentation. Saying "I need an example for std.foo.bar()" is an actionable item. I'm afraid, the answer to this specific question is - "Every function needs an example". Consider, e.g. http://en.cppreference.com/w/ or http://www.cplusplus.com/reference/ It's hard to find a function that doesn't have a usage example. Granted, the mentioned references are most likely volunteer effort (are they?). But it took C++ something like 20 years and a wide corporate adoption for that to happen. I guess, it took less time for other languages, like Python or Ruby, but that's, probably, because those languages looked really interesting and fun at their times. So they attracted a lot of "good" programmers. D poses itself as a more serious language (at least it's how it looks like). And, probably, nobody will say that it's bad. But, as a consequence, it makes it less attractive to "good" programmers. Especially now, when there's lot of successful "toy" languages. D is not "flashy" enough these days.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via Digitalmars-d wrote: On Fri, 19 Dec 2014 10:47:27 + Sergei Nosov via Digitalmars-d wrote: In the "debugger" case, Manu's point is that it's unusable. And Walter's implied point is "debuggers aren't that useful anyway, so why it was a showstopper?". My personal observation is that "excellent programmers" share the Walter's point on debuggers - they practically don't use it. And the uselessness is so obvious, that there's nothing even to talk about. At the same time, "good programmers" use it extensively, especially on Windows. It is so useful to them, that there's nothing even to talk about! one of the things one can do if he is in corresponding position is to ban debuggers. i found that after month or two people start producing better code with better documentation and "control knobs". and surprisingly faster. debugger is just a kind of bad habit, and when people faced the fact that they will not be payed for work simulation (and why should we?), they either go or becomes more productive. Exactly. But you also imply something like "it would be great if every good programmer became excellent", which is not very realistic. The example is a little abstract, but smoking is also a bad habit. However, there's no way you can fight it and win for the observable future.
Re: DIP61: redone to do extern(C++,N) syntax
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Quote:
Unlike C++, namespaces in D will be 'closed' meaning that new
declarations cannot be inserted into a namespace after the
closing }. C++ Argument Dependent Lookup (aka "Koenig Lookup")
will not be supported.
Do I understand it correctly, that if I have namespace members
defined in different files, like
// a.cpp
namespace ns { int foo(); }
// b.cpp
namespace ns { int bar(); }
I have the only option to put those in a single D file, like
// c.d
extern (C++, ns) { int foo(); int bar(); }
?
And the only way it's more flexible than the hypothetical
extern(C++) module ns; is that you can put several namespaces to
a single file?
Re: A Briefer Syntax for Using Concepts
On Wednesday, 7 May 2014 at 11:57:51 UTC, w0rp wrote: Here is a question, is it possible for D, or any future language, to eventually take something like this... void foo(InputRange)(InputRange range) if(isInputRange!InputRange); ...and to instead be able to write it like this? void foo(InputRange range); Where the latter expands into something like the former, and InputRange is not a type. How to declare such a thing in the first place doesn't matter that much. There are many ways that could be done. I'm just wondering if the above is possible at all. C++ concepts has similar syntax. http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s template void sort(Cont& container); I don't think making InputRange behave as you suggest in void foo(InputRange range); is a valid options, since - how do you handle the situation when you want to accept 2 InputRanges of possibly distinct types? void foo(InputRange range1, InputRange range2); // how to specify that InputRange should be exactly the same type? or possibly distinct types?
Re: AST like coding syntax. Easy upgrade!
On Monday, 7 September 2015 at 02:50:06 UTC, Adam D. Ruppe wrote: On Sunday, 6 September 2015 at 23:33:17 UTC, Walter Bright wrote: I'd always thought Javascript was an ideal extension language for a text editor. Well, I don't think *ideal*, but indeed, it wouldn't be bad. C'mon, kind sirs! Haven't you heard anything about Emacs Lisp? =)
Re: Apparently there's some dlang action in spacemacs
On Thursday, 13 October 2016 at 13:32:42 UTC, Andrei Alexandrescu wrote: https://github.com/syl20bnr/spacemacs/issues/7374 Anyone familiar with the editor? It's basically a sophisticated "config file" for GNU Emacs that aims to provide a "modern text editor" experience out-of-the-box within Emacs (the vanilla Emacs looks pretty alien to a newcomer/come-by-er). As far as I can tell, the thing is pretty popular within Emacs community (my guess is ~10,000 users - based on the "number of downloads" jump after one of my packages was included into spacemacs). The project is also well-documented and well-maintained, communication with maintainers is always a pleasure.
