Re: Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community
On Tuesday, 16 May 2017 at 22:03:17 UTC, Daniel Kozak wrote: Nice, I have wait so many months until I decided to fork yamkeys because of d-yaml. Now I can delete it thanks. This makes my live easier. This is something I want to propose many times, that there is something like dlang-community. Btw. is there some more info about it. Because I miss it somehow On Tue, May 16, 2017 at 10:46 PM, Basile B. via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: Following Brian Schott Announce [1] about the migration of his projects to the dlang-community, I'm pleased to announce that the most popular repository from Ferdinand Majerech are now also hosted there. - D-YAML, a YAML parser and emitter for D (native D implementation) is at https://github.com/dlang-community/D-YAML - harbored-mod, a D documentation generator based on harbored is at https://github.com/dlang-community/harbored-mod So far we pushed the commits done in several forks and the two projects are up to date, tested by TravisCI, buildable with either make or DUB. Note about D-Yaml: People who forked D-Yaml for their projects are encouraged to push their change to dlang-community and give up their fork ! [1]: http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org AFAIK, the idea was born when we (André/stonemaster, Sebastian/wilzbach and me) had issues with dlang-tour [0] when DMD 2.072.0 was released and become the default on Travis-CI and I had to fork D-YAML [1] and other project(s) in order to get my fixes merged [2]. Sebastian: Maybe it's not a bad idea to have a couple of important D packages like this one a community namespace, s.t. it doesn't depend on one maintainer? Me: I've also thought about that. Maybe a common github organization where all prominent members of the community have merge rights, though individual projects would still be driven by their authors. Similar to phobos experimental, but not tied to dmd releases, and with more lax requirements for entry and respectively a bit less guarantees. But most importantly, Sebastian actually created the github organization and started the discussion [4], [5]. [0]: https://github.com/stonemaster/dlang-tour/pull/471#issuecomment-258311882 [1]: https://github.com/stonemaster/dlang-tour/pull/487 [2]: https://github.com/dlang-community/D-YAML/pull/49 [3]: https://github.com/wilzbach/yaml/pull/6#issuecomment-266241628 [4]: https://github.com/dlang-community/discussions/issues/2 [5]: https://github.com/dlang-community/D-Scanner/issues/421
Re: Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community
On Tuesday, 16 May 2017 at 22:03:17 UTC, Daniel Kozak wrote: Nice, I have wait so many months until I decided to fork yamkeys because of d-yaml. Now I can delete it thanks. This makes my live easier. This is something I want to propose many times, that there is something like dlang-community. Btw. is there some more info about it. Because I miss it somehow It's an organization that was formed to avoid exactly this issue of needing to fork popular repositories all the time. As Basile mentioned this means that instead of waiting for months a bug fix can be merged and released within minutes and thus actual development and improvement can happen - instead of wasting a lot of time recreating the same fix or being annoyed broken dependencies. Due to being quite young, there's much public visibility or information yet. However, if you have a project that you would like to be part of this org or just want to talk to us, please feel free to open an issue here: https://github.com/dlang-community/discussions (we abuse GH issues as a public mailing list)
Re: Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community
Nice, I have wait so many months until I decided to fork yamkeys because of d-yaml. Now I can delete it thanks. This makes my live easier. This is something I want to propose many times, that there is something like dlang-community. Btw. is there some more info about it. Because I miss it somehow On Tue, May 16, 2017 at 10:46 PM, Basile B. via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > Following Brian Schott Announce [1] about the migration of his projects to > the dlang-community, I'm pleased to announce that the most popular > repository from Ferdinand Majerech are now also hosted there. > > - D-YAML, a YAML parser and emitter for D (native D implementation) > is at https://github.com/dlang-community/D-YAML > > - harbored-mod, a D documentation generator based on harbored > is at https://github.com/dlang-community/harbored-mod > > So far we pushed the commits done in several forks and the two projects > are up to date, tested by TravisCI, buildable with either make or DUB. > > Note about D-Yaml: People who forked D-Yaml for their projects are > encouraged to push their change to dlang-community and give up their fork ! > > [1]: http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org >
Re: Snap packages for DMD and DUB
On Tuesday, 16 May 2017 at 20:35:51 UTC, Joseph Rushton Wakeling wrote: On Tuesday, 16 May 2017 at 19:56:56 UTC, Joseph Rushton Wakeling wrote: With your patch in the repo, the packages should be automatically rebuilt and uploaded some time in the next hours. I'll follow up with an announcement here once that has happened. Patches with Petar's PIC fix in them have now been uploaded to the store. I've tested on Ubuntu 16.10 and 17.04 and they seem to work well. Nice, thanks for the quick merge :)
Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community
Following Brian Schott Announce [1] about the migration of his projects to the dlang-community, I'm pleased to announce that the most popular repository from Ferdinand Majerech are now also hosted there. - D-YAML, a YAML parser and emitter for D (native D implementation) is at https://github.com/dlang-community/D-YAML - harbored-mod, a D documentation generator based on harbored is at https://github.com/dlang-community/harbored-mod So far we pushed the commits done in several forks and the two projects are up to date, tested by TravisCI, buildable with either make or DUB. Note about D-Yaml: People who forked D-Yaml for their projects are encouraged to push their change to dlang-community and give up their fork ! [1]: http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org
Re: Snap packages for DMD and DUB
On Tuesday, 16 May 2017 at 19:56:56 UTC, Joseph Rushton Wakeling wrote: With your patch in the repo, the packages should be automatically rebuilt and uploaded some time in the next hours. I'll follow up with an announcement here once that has happened. Patches with Petar's PIC fix in them have now been uploaded to the store. I've tested on Ubuntu 16.10 and 17.04 and they seem to work well.
Re: Snap packages for DMD and DUB
On Monday, 15 May 2017 at 21:07:05 UTC, Petar Kirov [ZombineDev] wrote: This should fix it: https://github.com/dlang-snaps/dmd.snap/pull/7 Thanks ever so much for that. It's really nice to have the first not-by-me patch in that repo, especially when it comes with such a nicely-written commit message :-) 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 D'oh! Thanks again for taking that time. I think I'm going to hold some of the shorter-term effects of DConf responsible for the misplaced PICs ... :-P With your patch in the repo, the packages should be automatically rebuilt and uploaded some time in the next hours. I'll follow up with an announcement here once that has happened.
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. Nice. But color highlighting should always be configurable (otherwise it's half done), because there are a lot of people who like colors, but can't distinguish between certain color combinations, because of a color disability. Or they might have poor displays or viewing conditions etc. I guess this should be simple to add, just output the colors into an .ini file and read them back if the file exists.
Re: Andrei's "Design by Introspection" talk now on Hacker News
On 5/16/2017 8:24 AM, Walter Bright wrote: Look under the [new] tab. It appeared at about 8:00AM PST. and reddit: https://www.reddit.com/r/programming/comments/6bhnss/andrei_alexandrescu_design_by_introspection_talk/
Re: DMD now has colorized syntax highlighting in error messages
On Tuesday, 16 May 2017 at 15:38:53 UTC, Walter Bright wrote: It includes DOS and Windows consoles. Only under specific circumstances. On the VGA hardware, underline shares a bit with blue and needs a register tweaked to make it visible (the default 16 color VGA text mode does NOT display the underline), and only worked on CJK multibyte output on Windows 2000 through Windows 10. Only recently, with the one of the updates to windows 10, was console underlining added to Windows for English text, as part of their Linux terminal compatibility flag (see: ENABLE_VIRTUAL_TERMINAL_PROCESSING). Then yours is a unique snowflake, as it's standard for VT-100 emulation (xterm). It isn't really unique, rxvt treats it as bold and xterm can have it compiled out. I do recognize the sequence and even set the bit (see: https://github.com/adamdruppe/terminal-emulator/blob/master/terminalemulator.d#L1724 ) but then ignore it on the drawing side since blinking is a pointless distraction. In practice, basic color support is pretty broad and reliable, given you remember that there's a human reading it who can't see poor contrast easily and a large percentage of them cannot reliably tell all colors apart. Underline, however, is not broadly supported by the computer console apis.
rdub V2 released
V2 accepts multiple files and wildcard *.d on the command line. https://code.dlang.org/packages/rdub RDUB is a front end for DUB, a D language build tool. It's designed to build source files specified on the command line, without having to edit the dub files: dub.json, dub.sdl, src/app.d, source/app.d This tool is great for running examples and building/testing small projects! It's used in my other projects, dlang-beginners and dwtlib. $ rdmd rdub -h rdub is a front end for DUB, a D language build tool rdub [-h] [path/foo.d ... path/fooN.d] | [path/*.d] [dub args] -h --help This help information rdub = run dub with defaults ./src/app.d or ./source/app.d rdub path/foo.d = run dub as follows: 1. If first run, copy src to srcbak, and source to sourcebak 2. Delete src/ and source/ to avoid more than one main() file 3. Copy path/foo.d to ./src/foo.d 4. Run dub to build and run ./src/foo.d 5. Pass all [dub args] to dub, except: -h
Re: DMD now has colorized syntax highlighting in error messages
On 5/16/2017 8:25 AM, Adam D. Ruppe wrote: It's also possible to use underlining. Yeah, on some systems, but not really on Windows or even all linux terminals. Color has broader support, though you do want to be careful not to *depend* on color either. I've never met an ASCII console that didn't support underlining. This includes the ones I used back in the 1970's, and includes the tty I designed and built myself for a class project. It includes DOS and Windows consoles. Underlining enjoys much broader support than color does. Color became fairly ubiquitous rather late, in 1990 or so. The VT-100 control sequences have effectively replaced all the other ones. > my terminal emulator doesn't support blinking Then yours is a unique snowflake, as it's standard for VT-100 emulation (xterm).
Re: DMD now has colorized syntax highlighting in error messages
On Tuesday, May 16, 2017 08:11:21 Walter Bright via Digitalmars-d-announce wrote: > On 5/16/2017 7:17 AM, Adam D. Ruppe wrote: > > So again it is NOT color that bothers me. It is OVERUSE of color for > > stuff that isn't important to read the message which dilutes the > > meaning of color. It isn't special anymore. > > Perhaps. I know I have some trouble distinguishing code from explanatory > text in error messages, particularly when the code looks like english, as > in: > > error: undefined identifier maybe > > Colorizing code distinguishes it from text. > > The initial color choices I picked are garish on purpose, it's to try > things out. I expect to change it to more muted ones (turn off the > intensity bit at least). It's also possible to use underlining. > > I'm working on the next PR that will auto-detect if Adam is running the > compiler, and will highlight code with blinking text. LOL. Or you could have it just say: "I'm sorry, Adam. I'm afraid I can't do that." :) https://www.youtube.com/watch?v=OEu4Iq5KL-Q - Jonathan M Davis
Re: DMD now has colorized syntax highlighting in error messages
On Tuesday, 16 May 2017 at 15:11:21 UTC, Walter Bright wrote: error: undefined identifier maybe Colorizing code distinguishes it from text. What's important there? The generic syntax that you get from a syntax highlighter or the fact that it is the user input? Drawing attention to `maybe` there is a good idea! But that's not because it is syntax highlighted, it is because that's the most important word in the message. (btw I think it already has attention because of its placement, it doesn't need additional color. but the case I keep going back to, function overloading, puts important stuff in the middle of the message and that would be nice to stand out, as long as what's important - the mismatched arguments - are what stand out) It's also possible to use underlining. Yeah, on some systems, but not really on Windows or even all linux terminals. Color has broader support, though you do want to be careful not to *depend* on color either. I'm working on the next PR that will auto-detect if Adam is running the compiler, and will highlight code with blinking text. I'm afraid that won't work, my terminal emulator doesn't support blinking. But if it detected it was me and outputted XML error messages, oh boy, I'd be excited about that! I honestly very much would love xml error messages.
Re: DMD now has colorized syntax highlighting in error messages
On Tue, May 16, 2017 at 08:11:21AM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 5/16/2017 7:17 AM, Adam D. Ruppe wrote: > > So again it is NOT color that bothers me. It is OVERUSE of color for > > stuff that isn't important to read the message which dilutes the > > meaning of color. It isn't special anymore. > > Perhaps. I know I have some trouble distinguishing code from > explanatory text in error messages, particularly when the code looks > like english, as in: > > error: undefined identifier maybe > > Colorizing code distinguishes it from text. [...] Simpler solution: print the identifier in quotes, e.g.: error: undefined identifier 'maybe' There: instantly clear without needing any colors. T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: DMD now has colorized syntax highlighting in error messages
On 5/16/2017 7:17 AM, Adam D. Ruppe wrote: So again it is NOT color that bothers me. It is OVERUSE of color for stuff that isn't important to read the message which dilutes the meaning of color. It isn't special anymore. Perhaps. I know I have some trouble distinguishing code from explanatory text in error messages, particularly when the code looks like english, as in: error: undefined identifier maybe Colorizing code distinguishes it from text. The initial color choices I picked are garish on purpose, it's to try things out. I expect to change it to more muted ones (turn off the intensity bit at least). It's also possible to use underlining. I'm working on the next PR that will auto-detect if Adam is running the compiler, and will highlight code with blinking text.
Re: Andre's Google Tel Aviv Talk
On 16/05/2017 4:05 PM, rikki cattermole wrote: On 16/05/2017 4:04 PM, Andrei Alexandrescu wrote: On 05/16/2017 11:02 AM, Walter Bright wrote: On 5/16/2017 7:00 AM, Andrei Alexandrescu wrote: Same material as my DConf talk, better delivery. Longer, too, however. -- Andrei I.e. the Director's Cut. It's been also on https://news.ycombinator.com/newest as of a few minutes ago. -- Andrei https://www.reddit.com/r/programming/comments/6bhnss/andrei_alexandrescu_design_by_introspection_talk/ (Not by me) My bad, already been posted dangit.
Re: Andre's Google Tel Aviv Talk
On 16/05/2017 4:04 PM, Andrei Alexandrescu wrote: On 05/16/2017 11:02 AM, Walter Bright wrote: On 5/16/2017 7:00 AM, Andrei Alexandrescu wrote: Same material as my DConf talk, better delivery. Longer, too, however. -- Andrei I.e. the Director's Cut. It's been also on https://news.ycombinator.com/newest as of a few minutes ago. -- Andrei https://www.reddit.com/r/programming/comments/6bhnss/andrei_alexandrescu_design_by_introspection_talk/ (Not by me)
Re: Andre's Google Tel Aviv Talk
On 05/16/2017 11:02 AM, Walter Bright wrote: On 5/16/2017 7:00 AM, Andrei Alexandrescu wrote: Same material as my DConf talk, better delivery. Longer, too, however. -- Andrei I.e. the Director's Cut. It's been also on https://news.ycombinator.com/newest as of a few minutes ago. -- Andrei
Re: Andre's Google Tel Aviv Talk
On 5/16/2017 7:00 AM, Andrei Alexandrescu wrote: Same material as my DConf talk, better delivery. Longer, too, however. -- Andrei I.e. the Director's Cut.
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. The next step is Color D... https://github.com/narke/colorForth -=mike=-
Re: DMD now has colorized syntax highlighting in error messages
On Tuesday, 16 May 2017 at 14:04:34 UTC, Walter Bright wrote: With all the complaints about color, note that dmd already has been using color in error messages for years with no complaints My complaint isn't about the presence of color* but rather about the OVERUSE of it. The old way of coloring the message header helps you quickly find the beginning of an error among output spam. It stands out. But now, with color being all over the place, you can't visually scan for it anymore. It loses its special meaning. Similarly, what I want to see in the future is highlighting of specific parts of code where the error applies. Error: No overload for foo(int), candidates are: foo(string); foo(int, string); In my perfect world, `Error` is colored, like it is now, you can scan for it and find that. Then, the first `string` is also highlighted as a mismatch of the overload, and the `int` in the candidate signature is also highlighted as a match of the overload. Then, your eyes can just look for the color and realize which candidate is the best match and immediately see what you're missing. With syntax highlighting though, string and int will be highlighted as types or keywords... which is irrelevant to the issue of matching the correct overload. It stands out, but means nothing. And if everything is colored, yikes, then nothing stands out since you can't even eye scan it at all. So again it is NOT color that bothers me. It is OVERUSE of color for stuff that isn't important to read the message which dilutes the meaning of color. It isn't special anymore. * I did hate it for a while though because the contrast was poor, but I fixed that with some hack to my terminal emulator code to give it a superior adaptive palette. Perhaps tilix's author will want to do this too: mine has a different yellow when printed on white than on black, different blue, different teal. The application outputs the same sequence but my thing is aware of the background and adapts. Even if the application tries to output unreadable stuff explicitly, my terminal emulator won't allow it. Big, big win on my eyes.
Re: Andre's Google Tel Aviv Talk
On Tuesday, 16 May 2017 at 13:51:34 UTC, Mike Parker wrote: Weka.IO invited Andrei to talk at a meetup at Google Tel Aviv last week. The video of the talk is online: https://www.youtube.com/watch?v=es6U7WAlKpQ=youtu.be https://www.reddit.com/r/programming/comments/6bhnss/andrei_alexandrescu_design_by_introspection_talk/
Re: DMD now has colorized syntax highlighting in error messages
On 5/16/2017 1:07 AM, Ali Çehreli wrote: Color is informative to humans, so I'm all for it. I agree with others that it may be hard to please everyone. Is it possible to use the default scheme of the terminal? With all the complaints about color, note that dmd already has been using color in error messages for years with no complaints, and there is this switch: http://dlang.org/dmd-windows.html#switch-color
Re: Andre's Google Tel Aviv Talk
On 05/16/2017 09:51 AM, Mike Parker wrote: Weka.IO invited Andrei to talk at a meetup at Google Tel Aviv last week. The video of the talk is online: https://www.youtube.com/watch?v=es6U7WAlKpQ=youtu.be Same material as my DConf talk, better delivery. Longer, too, however. -- Andrei
Andre's Google Tel Aviv Talk
Weka.IO invited Andrei to talk at a meetup at Google Tel Aviv last week. The video of the talk is online: https://www.youtube.com/watch?v=es6U7WAlKpQ=youtu.be
Re: DMD now has colorized syntax highlighting in error messages
On Monday, 15 May 2017 at 08:08:20 UTC, Paolo Invernizzi wrote:
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...
He may be right that working on something harder like better
error messages for template constraints would be more useful, but
Walter likely needs to work on some easy stuff once in awhile
too, and this colored syntax will help. Git just enabled colored
highlighting of branch commits for git log and I've found it
useful.
I didn't think he was rude- he did say sorry several times in the
original post, expecting this response for his criticism- but
misguided to criticize this change, for not always matching the
user's settings, and to always expect Walter to work on the hard
stuff. Everybody needs to mix in some easy stuff, including
Walter I bet, to stay motivated and get some easy wins.
Re: DMD now has colorized syntax highlighting in error messages
On 05/14/2017 07:07 AM, 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. Color is informative to humans, so I'm all for it. I agree with others that it may be hard to please everyone. Is it possible to use the default scheme of the terminal? I had the good fortune of sitting with Chandler Carruth and other C++ people during dinner here at C++Now. We did talk about error reporting and although it's mostly agreed that clang's errors are a big improvement, Chandler said that no matter how short or informative, people still don't read error messages! I'm not surprised: people are people. (I'm one and proud of it. :) ) According to Chandler, Rust got this right: Apparently, Rust shows the code *first*, then the error message underneath it. Chandler said that this trivial change in error reporting has been transformative and now people are very happy with Rust's error messages. Ali
Re: DMD now has colorized syntax highlighting in error messages
On 2017-05-15 23:33, Adam D. Ruppe wrote: On Monday, 15 May 2017 at 15:40:58 UTC, Walter Bright wrote: That's why such needs to be turned into a generic module, instead of constantly being reinvented. What I'm saying is that it IS a generic module... in fact, there's several of them: http://code.dlang.org/search?q=color colorize, consoled, rainbow, and drlutil are all competing in this space. My terminal library (which is also included in the consoled dub package) is another. Now, I don't think you should use a library for this. Basic console color output is trivial and not worth the cost of a dependency (especially not a fat one like mine, which is full-featured console stuff when you just need simple color)... but I also don't think you should add yet another module to do it out there in public. It could be added as a subpackage to the upcoming Dub file [1]. [1] https://github.com/dlang/dmd/pull/6771 -- /Jacob Carlborg
Re: "Programming in D" is up-to-date
On 05/16/2017 12:47 AM, Suliman wrote: Big thanks!!! Thank you all! I'm very happy that it's useful. Ali
Re: "Programming in D" is up-to-date
On Saturday, 13 May 2017 at 23:22:41 UTC, Ali Çehreli wrote: I've updated the book to 2.074.0. I've updated all paper and electronic versions at all publishers. However, I recommend that you wait a week or so before ordering (e.g. from Amazon) so that you get the latest version. (The copyright and Preface pages should say May 2017.) You can download the up-to-date versions here: http://ddili.org/ders/d.en/index.html The fonts are indeed embedded in the PDF, EPUB, and AZW3 formats. You may have to experiment with configuration settings of your e-reader to enable the embedded fonts. YMMV. :/ Ali Big thanks!!!
