[OFF TOPIC] Re: DMD now has colorized syntax highlighting in error messages
On Sun, 2017-05-14 at 20:09 -0700, Walter Bright via Digitalmars-d- announce 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. But in politics lying and being rude is completely the norm. Also, as yet, software development is not a profession. I think "respect for others" and "empathy" are better lines to take. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DMD now has colorized syntax highlighting in error messages
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.
Re: DMD now has colorized syntax highlighting in error messages
On Mon, 2017-05-15 at 05:44 +0300, ketmar via Digitalmars-d-announce wrote: > […] > sorry for being rude, but this is exactly the example of things > programmers > like to write: fun, quite easy, and absolutely useless. most of the > time it > will be filtered away by ide/editor, and otherwise it is *harder* to > read, > 'cause it will almost certainly not match editor's syntax coloring > settings, > so reader will have to mentally strip the colors first. Also the default colours chosen by the developer usually work well for the them and their (and if you are lucky reviewers) terminal settings and are totally useless for a huge section of using audience (most of whom remain silent for various reasons). Take Git for example. I end up having to run: git … | more to get rid of the colours. The default colours might work for the Git developers but fail dismally for me. I cannot be bothered to get into the detail of how to change the Git colouring so I use more to get rid of it. I like having colours, for exactly the same reason colouring is good in source code editing, they can apply semantic (albeit often syntactic) coding, but all too often the colour choices are dreadful and too difficult to change. Hence all too often I have to: emacs --color=no I still like colouring, it is just that mostly it is done for a given terminal setting, and/or in a way too difficult to change locally. > while much harder task -- showing which exactly template failed in > template > constraint -- is very hard to implement (i tried it, i know it), but > will > immediately benefit *anyone*, and will be really useful. > > i'm not trying to say that you should drop the things you like to > work on, > and switch to the things i like, of course. but this patch, IMO, > doesn't > deserve a dedicated NG post. > > sorry again, i'm frustrated by dmd inability to generate valid .o > file from > completely valid source, so can be harsh today. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DMD now has colorized syntax highlighting in error messages
Walter Bright wrote: https://github.com/dlang/dmd/pull/6777 It turned out to be unexpectedly easy to implement. The only downside is now we have to rather tediously tweak the error message texts so they use backticks. sorry for being rude, but this is exactly the example of things programmers like to write: fun, quite easy, and absolutely useless. most of the time it will be filtered away by ide/editor, and otherwise it is *harder* to read, 'cause it will almost certainly not match editor's syntax coloring settings, so reader will have to mentally strip the colors first. while much harder task -- showing which exactly template failed in template constraint -- is very hard to implement (i tried it, i know it), but will immediately benefit *anyone*, and will be really useful. i'm not trying to say that you should drop the things you like to work on, and switch to the things i like, of course. but this patch, IMO, doesn't deserve a dedicated NG post. sorry again, i'm frustrated by dmd inability to generate valid .o file from completely valid source, so can be harsh today.
Re: Mir Algorithm v0.5.16: @safe ndslice; shortcuts; topology.pairwise instead of isSorted and isStrictlyMonotonic
On Sunday, 14 May 2017 at 17:29:44 UTC, jmh530 wrote: On Saturday, 13 May 2017 at 08:10:20 UTC, 9il wrote: https://github.com/libmir/mir-algorithm/releases/tag/v0.5.16 The documentation for mir.functional might need an update based on the refTuple change. The links at the top are missing refTuple and RefTuple. tuple doesn't go anywhere, also ref doesn't either. Thanks, fixed. I didn't really realize these were in there. How does it compare to std.typecons.Tuple? I was thinking about doing some work with std.typecons.Tuple's that hold mir.slices and not sure if I should use RefTuple instead. 1. RefTuple can hold pointers instead of values. For example Mir's zip, cartesian use RefTuples. This makes zip faster and more flexible, because it is partially mutable compared with Tuple. 2. Ndslice composed of RefTuples has special syntax with Map, for example "a + b" instead of "a[0] + a[0]" . 3. RefTuple does not ha ` [0]` syntax or other names then `a`, `b`, `c`. 4. RefTuple is faster to compile, though Example: auto s = zip(mask, b, c).map!"a ? b : c"; Loads either a or b.
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 23:17:42 UTC, Vladimir Panteleev wrote: On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote: Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch. 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. Yes that another option. But maybe my answer was a bit excessive. Let's wait and see how it looks.
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote: Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch. 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.
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 16:25:36 UTC, Walter Bright wrote: On 5/14/2017 9:04 AM, Andre Pany wrote: Thanks a lot. In my opinion these kind of changes are small but have huge impact on the acceptance of a language. I agree. A couple other improvements needed for error messages: In the PR you say that someone with a better color sense ought to choose the default colors. I don't have such a sense myself. But I recognize that as a real task for which help should be sought. Maybe this thread is a good place to get a volunteer?
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote: On Sunday, 14 May 2017 at 17:54:38 UTC, Jacob Carlborg wrote: On 2017-05-14 18:25, Walter Bright wrote: 1. print out the offending line I hope this one will be optional/configurable. I don't think it necessary to print the offending line within an editor/IDE. They usually can already map the error to the offending line. Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch. Can't the IDE remove the line itself if it troubles him? I don't think such a small thing should burden the compiler with a flag just for the sake of a tool.
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 17:54:38 UTC, Jacob Carlborg wrote: On 2017-05-14 18:25, Walter Bright wrote: 1. print out the offending line I hope this one will be optional/configurable. I don't think it necessary to print the offending line within an editor/IDE. They usually can already map the error to the offending line. Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch.
Re: DMD now has colorized syntax highlighting in error messages
On 2017-05-14 18:25, Walter Bright wrote: 1. print out the offending line I hope this one will be optional/configurable. I don't think it necessary to print the offending line within an editor/IDE. They usually can already map the error to the offending line. -- /Jacob Carlborg
Re: Mir Algorithm v0.5.16: @safe ndslice; shortcuts; topology.pairwise instead of isSorted and isStrictlyMonotonic
On Saturday, 13 May 2017 at 08:10:20 UTC, 9il wrote: https://github.com/libmir/mir-algorithm/releases/tag/v0.5.16 The documentation for mir.functional might need an update based on the refTuple change. The links at the top are missing refTuple and RefTuple. tuple doesn't go anywhere, also ref doesn't either. I didn't really realize these were in there. How does it compare to std.typecons.Tuple? I was thinking about doing some work with std.typecons.Tuple's that hold mir.slices and not sure if I should use RefTuple instead.
Re: DMD now has colorized syntax highlighting in error messages
On 5/14/2017 9:04 AM, Andre Pany wrote: Thanks a lot. In my opinion these kind of changes are small but have huge impact on the acceptance of a language. I agree. A couple other improvements needed for error messages: 1. print out the offending line 2. have a clickable link to a more exhaustive explanation on dlang.org Anyone interested in taking either of these on?
Re: Libdivide ported to D
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). — David
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote: https://github.com/dlang/dmd/pull/6777 It turned out to be unexpectedly easy to implement. The only downside is now we have to rather tediously tweak the error message texts so they use backticks. Thanks a lot. In my opinion these kind of changes are small but have huge impact on the acceptance of a language. Kind regards André
Re: Libdivide ported to D
On 5/14/2017 3:39 AM, Tomer Filiba wrote: https://code.dlang.org/packages/divide Libdivide (http://libdivide.com/) allows converting the DIV instruction (in runtime) to a series of shifts and MULs, which is much more efficient in execution time. It works by taking a number (the divisor or "denominator") and doing some preprocessing to it, after which dividing by it can be ~8 times faster (my own measurements). I use it to divide CPU cycles by the CPU frequency (i.e., two big ugly numbers) to obtain wall time from it. 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. Here's dmd's version: https://github.com/dlang/dmd/blob/master/src/ddmd/backend/divcoeff.c
DMD now has colorized syntax highlighting in error messages
https://github.com/dlang/dmd/pull/6777 It turned out to be unexpectedly easy to implement. The only downside is now we have to rather tediously tweak the error message texts so they use backticks.
Libdivide ported to D
https://code.dlang.org/packages/divide Libdivide (http://libdivide.com/) allows converting the DIV instruction (in runtime) to a series of shifts and MULs, which is much more efficient in execution time. It works by taking a number (the divisor or "denominator") and doing some preprocessing to it, after which dividing by it can be ~8 times faster (my own measurements). I use it to divide CPU cycles by the CPU frequency (i.e., two big ugly numbers) to obtain wall time from it. Of course it only applies to runtime division -- the compiler can do the same if the divisor is known in compile time. Notes: * It's a header-only library so I ported the code itself * I tried to keep my port as mechanical as possible; I can't really say I know what's going on there * I only ported the POSIX x86-64 code because that's what I needed * Signes-ness is a big issue, be sure you use the right variant -tomer
Re: Serialization in D
On Friday, 12 May 2017 at 18:06:32 UTC, qznc wrote: Nice. Coincidentally, I also just published an article. It shows how Lua binding are magically concise thanks to D meta programming. My blog: http://beza1e1.tuxen.de/into_luad.html Reddit: https://www.reddit.com/r/programming/comments/6asxnc/how_to_generate_lua_boilerplate_with_d/ Maybe some people are interested into the traffic patterns. I posted my article roughly at the same time to HN, reddit, and lobste.rs. HN is by far the most traffic. Nothing new here. http://imgur.com/a/LGCE3 graph by Piwik From 2830 visitors 25 people clicked through to dlang.org.
