Re: Snap packages for DMD and DUB
On Thursday, 11 May 2017 at 22:52:54 UTC, Joseph Rushton Wakeling wrote: On Thursday, 11 May 2017 at 22:30:52 UTC, Joseph Rushton Wakeling wrote: OK, looks like `-fPIC` was missing from some of the druntime and phobos build commands. I've pushed a patch to the `dmd` package definition that should fix this. Hmm, no dice. I'll look into this further in the next days. This should fix it: https://github.com/dlang-snaps/dmd.snap/pull/7 It seems that you added PIC on the tools repo, instead of druntime. I missed that too when debugging the snapcraft build myself. Looking at the diff without expanding it on github (https://github.com/dlang-snaps/dmd.snap/commit/b82fb60cb33e6ed42534e36f8703f75702f2c9fb) can be quite confusing. I came back to that file only after reading the druntime, phobos and tools makefiles several times and scratching my head for about an hour :D
Re: DMD now has colorized syntax highlighting in error messages
On 5/15/2017 8:35 AM, Adam D. Ruppe wrote: On Monday, 15 May 2017 at 14:18:30 UTC, Walter Bright wrote: I eventually want to make the console color package into a generic module, it could improve a number of console apps. FYI we already have a few D modules that do console color (among other things) like consoled or my terminal.d. I have console programs that do it, too. That's why such needs to be turned into a generic module, instead of constantly being reinvented.
Re: DMD now has colorized syntax highlighting in error messages
On Monday, 15 May 2017 at 14:31:20 UTC, Walter Bright wrote: I'm glad this sparks interest in improving the error message display, this is good. I've been meaning to do this for years... I want overload resolution and template constraints to tell which conditions were passed, failed, and short-circuited. Colorizing them in the output (green for pass, red for fail, default for short-circuited, for example) is one of the candidates ideas I have for concisely displaying that information to the user. Problem is just that the compiler discards those details before it gets to the error message display and keeping it up the call chain is non-trivial (or did, last time I tried to implement it). One thing I have noticed while doing this is how unhelpful many of the error messages are. Indeed, D's error messages are awful and I'd prefer we all spend time improving this more than anything else: make overload and constraint messages readable. Make size errors tell index and length in all cases (compile and runtime). Make inferred attribute errors tell you where and why the inferrence didn't match expectations. And yes, I've written about all this in bugzilla already.
Re: DMD now has colorized syntax highlighting in error messages
On Monday, 15 May 2017 at 14:18:30 UTC, Walter Bright wrote: I eventually want to make the console color package into a generic module, it could improve a number of console apps. FYI we already have a few D modules that do console color (among other things) like consoled or my terminal.d.
Re: Libdivide ported to D
On 5/15/2017 3:51 AM, Jonathan M Davis via Digitalmars-d-announce wrote: Liran was telling me last year about how the folks at Weka had used this to speed up the stuff in core.time and std.datetime in their local branch and wanted me to look into updating the official implementation to use it (unfortunately, I haven't had the time to spend on D that I would have liked and haven't managed to look into that yet - though that would require putting at least some of this in druntime). I confess though that I was highly confused about the whole thing, because it sounded like this was an optimization that the compiler already did, and yet the Weka guys were having to use libdivide some portion of the time. I suppose that it makes sense though if the issue is that the divisor is not known until runtime. But unfortunately, my understanding of compiler optimizations like this is fairly poor. One can do things like this: if (divisor == 10) foreach (i; 1..1000) result += i / 10; // compiler generates faster code here else foreach (i; 1..1000) result += i / divisor; if one knows in advance popular values of divisor. This sort of thing is already done in Phobos when converting numbers <==> strings (optimizing for radix==10).
Re: DMD now has colorized syntax highlighting in error messages
On 5/15/2017 6:10 AM, Adam D. Ruppe wrote: Suppose I, or someone else, were to write a PR eliminating your syntax highlighting in favor of semantic highlighting - colorizing to add more detail about the error message instead of about the lexer's output. Will you accept it? I'm glad this sparks interest in improving the error message display, this is good. I can't say I'd accept something given the handwavy description, you'll need to create examples of how it would look. One thing I have noticed while doing this is how unhelpful many of the error messages are. Consider the first one in traits.d: error(loc, "size overflow for type `%s`", t.toChars()); What was the size, and what was the maximum size? The compiler has this information, but does not supply it in the message. This is all low hanging fruit that anyone can help with.
Re: DMD now has colorized syntax highlighting in error messages
On 5/15/2017 1:05 AM, Jonathan M Davis via Digitalmars-d-announce wrote: I haven't gotten the chance to look at the dmd error messages yet to see how they look, They're a little garish at the moment, but that's just to make sure it's working correctly. I expect to tune it a bit, especially once I fix the console color package to be more useful. I eventually want to make the console color package into a generic module, it could improve a number of console apps.
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote: The only downside is now we have to rather tediously tweak the error message texts so they use backticks. It also dilutes the meaning of color. I've been wanting to see highlighted matches and failures in overload resolution and constraint checks (this has been on my todo list for a while since every attempt so far has failed; as I'm sure you know, it isn't trivial to implement in the current compiler). Such highlights would now have to compete with unnecessary syntax coloration; you can't visually scan for color anymore since it doesn't mean anything special. Terminal color choices are also painful, though I kinda believe this is the terminal's fault. I ended up doing hacky code in mine to ensure a legible palette, but still, not everyone has done that. Suppose I, or someone else, were to write a PR eliminating your syntax highlighting in favor of semantic highlighting - colorizing to add more detail about the error message instead of about the lexer's output. Will you accept it?
Re: Libdivide ported to D
On Sunday, May 14, 2017 16:20:21 David Nadlinger via Digitalmars-d-announce wrote: > On Sunday, 14 May 2017 at 15:30:19 UTC, Walter Bright wrote: > > On 5/14/2017 3:39 AM, Tomer Filiba wrote: > >> Of course it only applies to runtime division -- the compiler > >> can do the same if > >> the divisor is known in compile time. > > > > I hate to say this, but modern compilers already do this for > > generated runtime code when dividing by a constant. […] > > As Tomer points out, a runtime implementation can still be useful > if the divisor is only known dynamically (but constant across > number of operations). Liran was telling me last year about how the folks at Weka had used this to speed up the stuff in core.time and std.datetime in their local branch and wanted me to look into updating the official implementation to use it (unfortunately, I haven't had the time to spend on D that I would have liked and haven't managed to look into that yet - though that would require putting at least some of this in druntime). I confess though that I was highly confused about the whole thing, because it sounded like this was an optimization that the compiler already did, and yet the Weka guys were having to use libdivide some portion of the time. I suppose that it makes sense though if the issue is that the divisor is not known until runtime. But unfortunately, my understanding of compiler optimizations like this is fairly poor. - Jonathan M Davis
Re: Invitation to review new DIP PR
On Monday, 15 May 2017 at 06:03:27 UTC, Mike Parker wrote: There's a PR for a new DIP titled "Delegatable Functions" [1]. If you have time, I invite you to review the PR to make sure it's in the best state possible for moving forward to a merge and preliminary review. At this stage, we're looking for copy edits (grammar, spelling, vocabulary), line edits (rephrasing sentences, restructuring paragraphs) and content (are there any major holes in the proposal, unanswered questions). Thanks in advance to any and all who participate. [1] https://github.com/dlang/DIPs/pull/61 Abstract: "It is therefore proposed to add sematics to define functions" "n" is missing in "semantics".
Re: Invitation to review new DIP PR
On Monday, 15 May 2017 at 06:03:27 UTC, Mike Parker wrote: There's a PR for a new DIP titled "Delegatable Functions" [1]. If you have time, I invite you to review the PR to make sure it's in the best state possible for moving forward to a merge and preliminary review. At this stage, we're looking for copy edits (grammar, spelling, vocabulary), line edits (rephrasing sentences, restructuring paragraphs) and content (are there any major holes in the proposal, unanswered questions). Thanks in advance to any and all who participate. [1] https://github.com/dlang/DIPs/pull/61 Looks good to me.
Re: DMD now has colorized syntax highlighting in error messages
On Monday, 15 May 2017 at 04:33:39 UTC, ketmar wrote:
On Monday, 15 May 2017 at 03:09:09 UTC, Walter Bright wrote:
On 5/14/2017 7:44 PM, ketmar wrote:
sorry for being rude,
Then please do not post rude comments. We expect professional
decorum here.
sorry. i never got any money for using D, so i'm certainly not
a professional ('cause professionals are the people which get
payment for their work). sorry again for polluting NG with my
unprofessional writings. i will stop doing that immediately
after this post.
Rude or not, I think ketmar is right...
/P
Re: DMD now has colorized syntax highlighting in error messages
On 2017-05-15 01:17, Vladimir Panteleev wrote: No problem, it could only print out the line if the output is a terminal, same as for how it decides whether to output colors by default. Ah, that would be fine. -- /Jacob Carlborg
Invitation to review new DIP PR
There's a PR for a new DIP titled "Delegatable Functions" [1]. If you have time, I invite you to review the PR to make sure it's in the best state possible for moving forward to a merge and preliminary review. At this stage, we're looking for copy edits (grammar, spelling, vocabulary), line edits (rephrasing sentences, restructuring paragraphs) and content (are there any major holes in the proposal, unanswered questions). Thanks in advance to any and all who participate. [1] https://github.com/dlang/DIPs/pull/61
