Re: D IDE Coedit - version 3 beta 3
On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" Yet another update...should be of interest for those who tried D for the first time, using CE and experienced a crash https://www.reddit.com/r/d_language/comments/5t5oum/d_ide_coedit_version_3_beta_4/
Re: two points
On Thursday, 9 February 2017 at 17:45:15 UTC, Nick Sabalausky wrote: No. There should be appropriate checks and reviews, yes. But, no, every little fix and improvement shouldn't feel like trying to get somewhere in a year-long tabs vs spaces debate or making a big-budget sales pitch to Indecisives Anonymous. Yep! There are currently 165 poor sinners in DMD PR purgatory. The oldest is going on 5 years, waiting on someone to make a decision whether to use "-version", "-versions", "-dversion", or "-version=?". Then, it would have to be rebased, and languish again for another indeterminate amount of time. I wouldn't be at all surprised if the original contributor has moved on; I would have 4 years ago. Mike
Re: Questionnaire
On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote: I would probably say libraries is most important. Mir is a great advance. I've been applauding your work all the way through. There are two things that I think Mir needs most (and we've talked about them before as things you were thinking about) and then a third is a nice-to-have 1) A higher level layer with more convenient syntax for Mir-Glas 2) Lapack support (eigenvalues, svd, & cholesky/qr decompositions) 3) D compute support (would be nice to easily offload big computations to GPU) number 3 is in the pipeline. LDC should be able to produce .ptx and .spv (the intermediate formats for CUDA and OpenCL respectively, with host code all at the same time!) RealSoon™ (I hope by the end of the month). From there it's all just plain D API bashing, which will be easily automated with .mangleof and templates. I am hoping to give a DConf talk about this.
Re: two points
On 2/9/2017 1:45 PM, Jon Degenhardt wrote: However, when a PR associated with the issue is created, the ticket itself is normally not updated until after the review is finished and the PR closed, to late to help out. It normally is. I do it for all mine and for others I notice that have not so.
Re: two points
On 2/9/2017 1:06 PM, Joseph Rushton Wakeling wrote: On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote: *Anyone* in this community can step up and do that. Anyone can make observations and proposals, but not everyone has the authority to effect change. Anyone can proactively look at, review, analyze, etc. any PR. I appreciate how frustrating it must be to have people saying, 'Hey, do this! Do that!' without necessarily volunteering their own efforts in support, but organizational improvements so very often fail unless they are eagerly pursued at a leadership level. There are 29 people with commit privileges on Phobos: https://github.com/orgs/dlang/teams/team-phobos What do you suggest? What are you willing to step up and do?
Re: two points
On Thursday, 9 February 2017 at 16:48:16 UTC, Joseph Rushton Wakeling wrote: There's clearly in part a scaling problem here (in terms of how many people are available in general, and in terms of how many people have expertise on particular parts of the library) but it also feels like a few simple things (like making sure every PR author is given a reliable contact or two who they can feel entitled to chase up) could make a big difference. Regarding the scaling problem - Perhaps the bug system could be used to help engage a wider community of reviewers. Specifically, update the bugzilla ticket early in the PR lifecycle as an alerting mechanism. This idea comes from my experiences so far. I've found any number of bugs and enhancements in the bug system that directly interact with things I'm implementing. I typically add myself to CC list so I hear about changes. In many of these cases I'd be willing to help with reviewing. However, when a PR associated with the issue is created, the ticket itself is normally not updated until after the review is finished and the PR closed, to late to help out. Of course, someone like myself, a part-timer to the community at best, should not be a primary reviewer. However, for specific issues, it's often the case that I've studied the area of code involved. If there is a wider set of people in a similar situation perhaps this might help engage a wider set of people. --Jon
Re: two points
On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote: *Anyone* in this community can step up and do that. Anyone can make observations and proposals, but not everyone has the authority to effect change. I appreciate how frustrating it must be to have people saying, 'Hey, do this! Do that!' without necessarily volunteering their own efforts in support, but organizational improvements so very often fail unless they are eagerly pursued at a leadership level.
Re: two points
On Thursday, 9 February 2017 at 16:48:16 UTC, Joseph Rushton Wakeling wrote: which is that after some initial interest and feedback, the PR just got left alone with no decision to accept or reject it, and no indication of why. This is why I only contribute to Phobos to be quite honest. I count ten active reviewers with pull rights on Phobos. The other repos, tools: one dmd: three druntime: three dlang.org: two
Re: two points
Dne 9.2.2017 v 21:43 Walter Bright via Digitalmars-d-announce napsal(a): On 2/9/2017 12:29 PM, Joseph Rushton Wakeling wrote: Yes, but it could be good to examine what can be done to more pro-actively look at open PRs that have had no recent follow-up. *Anyone* in this community can step up and do that. This obviously does not work :(
Re: two points
On 2/9/2017 12:29 PM, Joseph Rushton Wakeling wrote: Yes, but it could be good to examine what can be done to more pro-actively look at open PRs that have had no recent follow-up. *Anyone* in this community can step up and do that.
Re: two points
On Thursday, 9 February 2017 at 19:53:37 UTC, Walter Bright wrote: There's a lot going on needing attention, and sometimes a bit of championing is needed by their proponents. Yes, but it could be good to examine what can be done to more pro-actively look at open PRs that have had no recent follow-up. It's not really going to work that well if attention gets given substantially on the basis of who's most eagerly seeking it. People like that metaphor "It's the squeaky wheel that gets the grease", but as a first aid trainer once pointed out to me, the quieter patient may be the one more in need of immediate attention. Also, please keep in mind that the smaller and more focussed a PR is, the more likely it'll have a quick resolution. Unfortunately my current one is large with good reason. But I think you'll find I also provided very detailed commit messages to explain and justify all my changes ;-)
Re: two points
On Thursday, 9 February 2017 at 19:58:57 UTC, Seb wrote: We gave this a try a couple of months ago with Facebook's mention-bot: Example: https://github.com/dlang/phobos/pull/4318#issuecomment-241817191 Repo: https://github.com/dlang-bots/mention-bot Eventually I disabled it because people complained about the added noise. It's great that you gave this a go. Seriously, people considered one small informative post in the PR to be "added noise"? :-( Out of curiosity: is it typical that it would not post until some way into the discussion (as in that example)? I could see why it would be irritating if it popped up once discussion and review had already started happening. Assuming that the bot can be relied on to be 'first responder' to any PR, I'm happy to try to draft an alternative text for it to post (and maybe also look at what texts it can link to).
Re: two points
On Thursday, 9 February 2017 at 19:42:03 UTC, Jack Stouffer wrote: On Thursday, 9 February 2017 at 19:36:52 UTC, Walter Bright wrote: Good idea! Please investigate how to get github to generate such emails. In the meantime, the PR guidelines are here: We gave this a try a couple of months ago with Facebook's mention-bot: Example: https://github.com/dlang/phobos/pull/4318#issuecomment-241817191 Repo: https://github.com/dlang-bots/mention-bot Eventually I disabled it because people complained about the added noise. This is already somewhat done with the PR bot we have. The DlangBot notifies reviewers on the DMD repo, but not Phobos for some reason. All it does on Phobos is auto close bugzilla issues when a bug fix PR is pulled into master. It does a bit more (e.g. since a couple of weeks it can also automatically merge PR once all CI status checks pass) I say enable the bot for Phobos. It would be a small task to also have the bot post the PR guidelines. As mentioned above, the bot is already enabled and it receives all interesting hook events from Phobos, see e.g.: https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/app.d#L124 I think Martin is the maintainer of the bot. You can find the code here: https://github.com/dlang-bots/dlang-bot
Re: two points
On 2/9/2017 8:55 AM, Joseph Rushton Wakeling wrote: On Thursday, 9 February 2017 at 09:49:53 UTC, Walter Bright wrote: In any case, shouldn't it be an uphill battle to merge things? There are a lot of things that need to be satisfied to merge something. Being too hasty leads to legacy code that we come to regret, angry people whose code was broken, and technical debt. There's a difference between it being an uphill battle because review and feedback are careful, cautious, in-depth and strict (as they should be!), versus it being an uphill battle because no feedback or interest is being offered and PRs are left to bitrot. :-( That certainly does happen, but it isn't quite the case with Nick's PRs. I accept that there are a lot of things that need to be satisfied to merge something. Personally speaking, I'm willing to endure any number of rebases and conflict-fixes, so long as I'm getting feedback and engagement that allows my PR to become better code. It's when I'm _not_ getting any indicators as to what needs to be satisfied that things become problematic. There's a lot going on needing attention, and sometimes a bit of championing is needed by their proponents. Also, please keep in mind that the smaller and more focussed a PR is, the more likely it'll have a quick resolution.
Re: two points
On Thursday, 9 February 2017 at 19:36:52 UTC, Walter Bright wrote: Good idea! Please investigate how to get github to generate such emails. In the meantime, the PR guidelines are here: This is already somewhat done with the PR bot we have. The DlangBot notifies reviewers on the DMD repo, but not Phobos for some reason. All it does on Phobos is auto close bugzilla issues when a bug fix PR is pulled into master. I say enable the bot for Phobos. It would be a small task to also have the bot post the PR guidelines. I think Martin is the maintainer of the bot.
Re: vibe.d 0.8.0 and 0.7.31 beta releases
Am 09.02.2017 um 18:00 schrieb Kagamin:
On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:
The problem is that there are two affected call stacks - the @system
API function that registers the @system callback, wrapping/casting it
as @trusted, and the event handler that later on actually calls the
callback. The latter place is where the hidden violation of the @safe
guarantees happens.
Hidden from whom? Since it's user, who supplies @system code to vibe, he
knows that the resulting program doesn't provide @safe guarantees.
It can be communicated at the API level:
int f(@safe void delegate() dg) @safe
{ code }
int f(@system void delegate() dg) @system
{ return f(cast(@safe void delegate())dg); }
So that unsafe overload would be only callable from unsafe code.
Hidden from the code that calls the callback. This may be an acceptable
trade off in this particular case, because this is crossing a library
border, but in general this is just misuse of the safety system, since
the effects of the cast leave the scope of @system/@trusted.
I don't know, I don't really like this, but maybe I should just postpone
the `deprecated` attribute to be added for 0.8.1 to leave more room for
a final decision.
Re: two points
On 2/9/2017 8:48 AM, Joseph Rushton Wakeling wrote: Contrast this with the experience I had the one time I submitted a (tiny, trivial) patch to rust: immediately after submitting the PR I got a message from their 'highfive' robot that included: * a friendly thank you for the PR; * the GitHub ID of a contact who I could expect to be taking responsibility for the PR, who was also assigned as a reviewer; * some helpful notes on how to add changes to the PR if requested; * a link to the contributor guidelines. By contrast with a Phobos PR it's not clear who to contact if review or decision-making is not forthcoming. Good idea! Please investigate how to get github to generate such emails. In the meantime, the PR guidelines are here: http://wiki.dlang.org/Starting_as_a_Contributor#Create_a_pull_request The teams can be found here: https://github.com/orgs/dlang/teams Please help improve the guidelines.
Re: Questionnaire
On Thursday, 9 February 2017 at 18:38:32 UTC, John Colvin wrote: On Thursday, 9 February 2017 at 18:34:44 UTC, bachmeier wrote: On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote: Other stuff I would find useful: 1) R integration (I know someone's done work on this, but it's hard to find and I don't remember if it works on Windows. Really just needs a champion) Me. The latest version is here: https://bitbucket.org/bachmeil/embedr It's Linux-only because that's all I know or use. Others that I work with use it on Windows and OS X trivially with Docker, but for someone that understands development on those OSes, it shouldn't take much to get it working natively. Everything is handled internally by the R package manager, and the package itself has functions to take care of all steps for compilation. I don't promote it because I don't have time to run an open source project properly. However, I am happy to help in any way if someone else wants to use it. I am flexible on the license, so that's not an issue. There's a possibility of some commercial need for R <-> D where I'm working, so hopefully we'll be able to help here. I believe you have my email address. Send me a message if something comes up. I redid everything a few months ago, so if you looked at an earlier version, this is much improved. Getting it to work on Windows/OS X or integrating Dub is something that can be done in an afternoon by someone with the appropriate background.
Re: Questionnaire
On Thursday, 9 February 2017 at 18:34:44 UTC, bachmeier wrote: On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote: Other stuff I would find useful: 1) R integration (I know someone's done work on this, but it's hard to find and I don't remember if it works on Windows. Really just needs a champion) Me. The latest version is here: https://bitbucket.org/bachmeil/embedr It's Linux-only because that's all I know or use. Others that I work with use it on Windows and OS X trivially with Docker, but for someone that understands development on those OSes, it shouldn't take much to get it working natively. Everything is handled internally by the R package manager, and the package itself has functions to take care of all steps for compilation. I don't promote it because I don't have time to run an open source project properly. However, I am happy to help in any way if someone else wants to use it. I am flexible on the license, so that's not an issue. There's a possibility of some commercial need for R <-> D where I'm working, so hopefully we'll be able to help here.
Re: Questionnaire
On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote: Other stuff I would find useful: 1) R integration (I know someone's done work on this, but it's hard to find and I don't remember if it works on Windows. Really just needs a champion) Me. The latest version is here: https://bitbucket.org/bachmeil/embedr It's Linux-only because that's all I know or use. Others that I work with use it on Windows and OS X trivially with Docker, but for someone that understands development on those OSes, it shouldn't take much to get it working natively. Everything is handled internally by the R package manager, and the package itself has functions to take care of all steps for compilation. I don't promote it because I don't have time to run an open source project properly. However, I am happy to help in any way if someone else wants to use it. I am flexible on the license, so that's not an issue.
Re: two points
On 02/09/2017 04:49 AM, Walter Bright wrote: On 2/8/2017 11:09 PM, Nick Sabalausky wrote: And any PRs I have managed to get through were all uphill battles the whole way. You have contributed 5 PRs to dmd: https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa 1 is open (it's controversial) 1 closed (today by me) Well, I suppose I brought that one on myself by complaining about it being ignored :/ 3 merged 1 in 6 days 2 in 1 day Overall, I think you've done well. Note that those quickly merged ones were several years ago, back before the battles to get anything accepted reached ridiculous levels. In any case, shouldn't it be an uphill battle to merge things? No. There should be appropriate checks and reviews, yes. But, no, every little fix and improvement shouldn't feel like trying to get somewhere in a year-long tabs vs spaces debate or making a big-budget sales pitch to Indecisives Anonymous.
Re: Questionnaire
On Thursday, 9 February 2017 at 16:33:18 UTC, bachmeier wrote: Make extensions that others can use within their current workflow, and they will use it. Leave it as a Dub package and they won't touch it. You've done a lot of good work, but it's kind of a dead end to target the standalone D program market right now. +1!
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: 1. Why your company uses D? a. D is the best b. We like D c. I like D and my company allowed me to use D d. My head like D e. Because marketing reasons f. Because my company can be more efficient with D for some tasks then with any other system language I'm the only person I personally know who uses D. I mainly use it for personal projects. I like it because the other languages I more often use, like R or Python, are just not sufficient for some purposes. I've tried C++, but I like D a lot more. 2. Does your company uses C/C++, Java, Scala, Go, Rust? Not my group, but I imagine other parts. 3. If yes, what the reasons to do not use D instead? 2. Have you use one of the following Mir projects in production: a. https://github.com/libmir/mir b. https://github.com/libmir/mir-algorithm c. https://github.com/libmir/mir-cpuid d. https://github.com/libmir/mir-random e. https://github.com/libmir/dcv - D Computer Vision Library f. std.experimental.ndslice Not in production, but in personal projects. 5. What D misses to be commercially successful languages? I would probably say libraries is most important. Mir is a great advance. I've been applauding your work all the way through. There are two things that I think Mir needs most (and we've talked about them before as things you were thinking about) and then a third is a nice-to-have 1) A higher level layer with more convenient syntax for Mir-Glas 2) Lapack support (eigenvalues, svd, & cholesky/qr decompositions) 3) D compute support (would be nice to easily offload big computations to GPU) Other stuff I would find useful: 1) R integration (I know someone's done work on this, but it's hard to find and I don't remember if it works on Windows. Really just needs a champion) 2) Stan (http://mc-stan.org/) interface = All my current D project are finished. Probably I will use other languages for production this year, Java/Go/whatever. Mir libraries are amazing and good quality. If you use them this would be a good motivation for us to improve the docs and provide regular updates. Plus, it can be enchanted during the GSoC 2017. I agree on GSOC 2017, but you should provide some sort of guidance or support. I hope Mir gets more attention!
Updated LDC snap package with link-time optimization (LTO) support
Revision 3 of the ldc2 snap package is now available in the
'edge' channel of the snap store. This still provides LDC 1.1.0,
but with the following important changes:
* the backend is provided by LLVM 3.9.1
* support for LDC's experimental link-time optimization
(the -flto={full,thin} flag) has been included
I would be very grateful if people could try out these new
features and report back on whether or not they work (and if any
problems are encountered, on which distro and version).
-- to install --
This package should be possible to install on Ubuntu 16.04 or
later, or Ubuntu 14.04, as well as any other distro making
available a recent version of snapd (2.21 or later):
https://snapcraft.io/docs/core/install
Once snapd is installed (on Ubuntu or Debian, `sudo apt install
snapd`), the ldc2 snap can be installed with:
sudo snap install --classic --edge ldc2
If you already have a version installed, you can upgrade it with:
sudo snap refresh --classic --edge ldc2
Note, if this version breaks something for you, you can downgrade
to revision 2 with:
sudo snap refresh --classic --edge --revision=2 ldc2
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:
The problem is that there are two affected call stacks - the
@system API function that registers the @system callback,
wrapping/casting it as @trusted, and the event handler that
later on actually calls the callback. The latter place is where
the hidden violation of the @safe guarantees happens.
Hidden from whom? Since it's user, who supplies @system code to
vibe, he knows that the resulting program doesn't provide @safe
guarantees.
It can be communicated at the API level:
int f(@safe void delegate() dg) @safe
{ code }
int f(@system void delegate() dg) @system
{ return f(cast(@safe void delegate())dg); }
So that unsafe overload would be only callable from unsafe code.
Re: two points
On Thursday, 9 February 2017 at 09:49:53 UTC, Walter Bright wrote: In any case, shouldn't it be an uphill battle to merge things? There are a lot of things that need to be satisfied to merge something. Being too hasty leads to legacy code that we come to regret, angry people whose code was broken, and technical debt. There's a difference between it being an uphill battle because review and feedback are careful, cautious, in-depth and strict (as they should be!), versus it being an uphill battle because no feedback or interest is being offered and PRs are left to bitrot. :-( I accept that there are a lot of things that need to be satisfied to merge something. Personally speaking, I'm willing to endure any number of rebases and conflict-fixes, so long as I'm getting feedback and engagement that allows my PR to become better code. It's when I'm _not_ getting any indicators as to what needs to be satisfied that things become problematic.
Re: two points
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote: The PR in question: https://github.com/dlang/dmd/pull/4745 It took me a while to find it, because you were using a pseudonym that I did not recognize. There are a number of frequent contributors to D using pseudonyms, and all have this issue with varying degrees. This is a fair point in its own right, but it's completely orthogonal to the issue Nick is complaining about -- which is that after some initial interest and feedback, the PR just got left alone with no decision to accept or reject it, and no indication of why. That's really a very unpleasant situation to face, regardless of whether the contributor in question is a well-known name or some complete anonymous stranger. I have a PR of my own that's been in this situation for (only!) a month now, and it's distinctly frustrating, particularly because it was a contribution that Andrei specifically called for on these forums: https://github.com/dlang/phobos/pull/5011 (... Andrei's request: https://forum.dlang.org/post/o1cqdb$245o$1...@digitalmars.com) Contrast this with the experience I had the one time I submitted a (tiny, trivial) patch to rust: immediately after submitting the PR I got a message from their 'highfive' robot that included: * a friendly thank you for the PR; * the GitHub ID of a contact who I could expect to be taking responsibility for the PR, who was also assigned as a reviewer; * some helpful notes on how to add changes to the PR if requested; * a link to the contributor guidelines. By contrast with a Phobos PR it's not clear who to contact if review or decision-making is not forthcoming. There's clearly in part a scaling problem here (in terms of how many people are available in general, and in terms of how many people have expertise on particular parts of the library) but it also feels like a few simple things (like making sure every PR author is given a reliable contact or two who they can feel entitled to chase up) could make a big difference.
Game Website Server Side
Hello All! We have a multiplayer game website which uses D programming language for server side instant interactions. I need someone professional who is able to make some changes on request. We are the company and we will allocate money for these tasks. It is not only one time task , we are seeking person who is able to work with us for a long time. Please contact or type on this thread who interested. KinD Regards Orkhan
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: 2. Have you use one of the following Mir projects in production: a. https://github.com/libmir/mir b. https://github.com/libmir/mir-algorithm c. https://github.com/libmir/mir-cpuid d. https://github.com/libmir/mir-random e. https://github.com/libmir/dcv - D Computer Vision Library f. std.experimental.ndslice I wasn't going to comment, since I'm not part of the target group, but I have enough familiarity with commercial usage to give you an answer to this question. Why would someone in an "enterprise" situation want to use Mir? If you create a nice R package to make Mir functionality available to Rcpp users, and you provide new functionality not currently available in other R packages (with good performance to boot), you will see commercial usage. But it has to be a package they can install from CRAN/Github/Bitbucket using the R package manager. They're not going to mess around with Dub. The same is true for Matlab/Octave/Python. Make extensions that others can use within their current workflow, and they will use it. Leave it as a Dub package and they won't touch it. You've done a lot of good work, but it's kind of a dead end to target the standalone D program market right now.
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: 1. Why your company uses D? a. D is the best b. We like D c. I like D and my company allowed me to use D d. My head like D e. Because marketing reasons f. Because my company can be more efficient with D for some tasks then with any other system language My company doesn't use D. 2. Does your company uses C/C++, Java, Scala, Go, Rust? My company uses what the customers ask for, we don't get to choose that much. iOS projects - Objective-C, Swift Java projects - Java, Scala, Clojure Windows projects - C#, VB.NET Web Projects - JavaScript on frontend with a Java or .NET stack on backend Android projects - Java Hybrid development across iOS and Android - Cordova, Ionic Traversal to all projects, C++ as infrastructure language for performance reasons or integration of C and C++ libraries. 3. If yes, what the reasons to do not use D instead? Customers don't ask for it on their RPF to allow its use. 2. Have you use one of the following Mir projects in production: a. https://github.com/libmir/mir b. https://github.com/libmir/mir-algorithm c. https://github.com/libmir/mir-cpuid d. https://github.com/libmir/mir-random e. https://github.com/libmir/dcv - D Computer Vision Library f. std.experimental.ndslice No, as they don't follow on the typical enterprise computing projects we work on. 3. If Yes, can Mir community use your company's logo in a section "Used by" or similar. 4. Have you use one of the following Tamedia projects in your production: a. https://github.com/tamediadigital/asdf b. https://github.com/tamediadigital/je c. https://github.com/tamediadigital/lincount No, I wasn't aware of their existence. 5. What D misses to be commercially successful languages? A GC that can compete with Java and .NET ones. The IDE tooling at the same level of the InteliJ and Visual Studio. Above all, a killer project that makes customers ask us about employees with D skils. As an example, Docker and Kubernetes success means our devops guys are slowly improving their Go skills in the newly introduced internal training. 6. Why many topnotch system projects use C programming language nowadays? Due to existing tooling, libraries and that for many companies using a managed language + C, is good enough and allows for cheaper developers. Also many developers born after memory safe system languages lost the market to UNIX + C, think that C was the first one to exist for system programming. = All my current D project are finished. Probably I will use other languages for production this year, Java/Go/whatever. Mir libraries are amazing and good quality. If you use them this would be a good motivation for us to improve the docs and provide regular updates. Plus, it can be enchanted during the GSoC 2017. Thanks, Ilya
Re: two points
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote: I suppose I could write a cheat sheet and tape it to the wall of my office, but why not just use your name? It shouldn't matter who wrote it. Review the code, not the author, especially on small ones like this which new contributors might be using to test the waters.
Re: Questionnaire
On Thursday, 9 February 2017 at 10:38:11 UTC, Johannes Pfau wrote: But OTOH I'm an electrical engineer as well ;-) Haha! Then this (https://www.youtube.com/watch?v=D7Sd8A6_fYU&feature=youtu.be&t=2389) is for you ;-) "What we know is that C code will compile all sorts of bugs, more so than most languages, and C programmers know this and accept this. This is the world that they live in. So it breeds a very unfortunate mindeset which is: 'Let's just get the code to compile so we can get to the real work which is debugging.'" -- Dan Saks But you're right, C++ is a very complex language and can easily turn into a monstrosity if not done tastefully. Mike
Re: Questionnaire
Am Wed, 08 Feb 2017 21:41:24 + schrieb Mike : > On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko > wrote: > > 1. Why your company uses D? > > We don't use D. > > > 2. Does your company uses C/C++, Java, Scala, Go, Rust? > > C/C++. Currently exploring Rust. > > > 3. If yes, what the reasons to do not use D instead? > > * The powers that be in my company are the kind of C programmers > that can't understand why anyone would want to use C++ (i.e. > Electrical engineers that write software). I always felt like C is the better designed language when compared to C++. Of course C misses many features of C++ and C also has some badly designed features (preprocessor, header/include system, function pointer syntax, array [n] not attached to the type but to the variable identifier). But among some useful features C++ also adds much more noise on top of the already existing C misfeatures: ugly template syntax, iostreams/pipe syntax, operator overloading for controversial operators, c++ namespaces, multiple inheritance, ... Of course C has limited means for abstraction and therefore is not suitable for certain projects. But the language feels 'cleaner' imho, C++ sources files using templates and similar features are often hard to read. But OTOH I'm an electrical engineer as well ;-) -- Johannes
Re: Questionnaire
1. Why your company uses D? I can use D only for very small apps in my job. My own project use D because it was the best language what I found when I started developing OS from scratch 5 years ago. 2. Does your company uses C/C++, Java, Scala, Go, Rust? We use C/C++, Java 3. If yes, what the reasons to do not use D instead? Replacement as C++: There is problem to find and hire C++ programmers so how could we find D programmers... Nobody here wants to learn new programming language... Many of ours projects/libraries are already written in C/C++. Replacement as Java: Making GUI apps in D (with Qt) is pain in the a$$. We need good IDE, Drag'n'Drop GUI builder and framework with stuff like in Java or .NET first. 2. Have you use one of the following Mir projects in production: No 4. Have you use one of the following Tamedia projects in your production: No 5. What D misses to be commercially successful languages? Native GUI IDE with D'n'D interface builder Framework with all stuff in (like .NET) Maybe more understandable documentation with more examples. More syntactic sugar in D? Like maybe monad, tuples, etc. 6. Why many topnotch system projects use C programming language nowadays? Small and fast programs with no runtime.
Re: two points
On 2/8/2017 11:09 PM, Nick Sabalausky wrote: And any PRs I have managed to get through were all uphill battles the whole way. You have contributed 5 PRs to dmd: https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa 1 is open (it's controversial) 1 closed (today by me) 3 merged 1 in 6 days 2 in 1 day Overall, I think you've done well. https://github.com/dlang/druntime/pulls?q=is%3Apr+author%3Aabscissa 5 PRs, 3 merged. https://github.com/dlang/phobos/pulls?q=is%3Apr+author%3Aabscissa 14 PRs, 1 merged. (I didn't check all the reviews, but the ones I did looked fair.) --- In any case, shouldn't it be an uphill battle to merge things? There are a lot of things that need to be satisfied to merge something. Being too hasty leads to legacy code that we come to regret, angry people whose code was broken, and technical debt. Check out our current list of regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=213638&query_format=advanced Hasty merges wind up there, and usually someone other than the one who broke it has to fix it.
Re: two points
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote: I do not understand using pseudonyms on github. It can hardly be a privacy issue, as github doesn't hide your name. But it definitely impedes your "brand", i.e. your reputation, as it becomes divided in two. Github does not provide a "reverse phone book" where I can search for a PR under your name, nor does it provide any sort of cross reference. Searching (via github) the dmd repository for your name turns up nothing. One of the reasons could be simply because one is known under a nickname on a bunch of other resources where he posts to, and that now working for the reputation too - because posting something with other name could get you banned or just people looking with suspicious for any code and links posted. Now, since we on D forum and that "other" world reputation doesn't matter here or any other reasons, some will prefer just using "real" name. Some people also avoid using their work-associated emails with personal/fan projects. Because of same thing with reputation/proffesionalism/etc., (unnecesary questions from employer too? just a guess, whatever) And more, and more... Things are complicated.
Re: Questionnaire
On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote: * "Minimal Runtime" is the building block of systems programming. If this is not a core feature of a language, it will never compete with C. Systems programmers in my field need to incrementally opt-in to features in a pay-as-you-go fashion to make precise tradeoffs for their unique requirements and hardware platforms. Rust is the only modern language that I'm aware of that's getting this right. Whiley is in early stages, but I believe they have optional Rust-like memory management implemented (proof-of-concept?) to enable embedded programming situations. http://whiley.org/2016/05/28/reference-lifetimes-in-whiley/ It isn't a production ready language, but well worth following.
Re: two points
On 2/8/2017 11:09 PM, Nick Sabalausky wrote: I fixed an issue where "///"-style doc comments resulted in excessive paragraph breaks...must've been over a year ago. Simple fix for a nagging bug. The fix worked. Caused no problems. No controversy. And to this day, just went completely ignored despite my periodic nagging about it. Eventually got tired wasting my time babysitting the constant need for rebasing and manual merge fixes just for something that proved guaranteed to be ignored. And any PRs I have managed to get through were all uphill battles the whole way. The PR in question: https://github.com/dlang/dmd/pull/4745 It took me a while to find it, because you were using a pseudonym that I did not recognize. There are a number of frequent contributors to D using pseudonyms, and all have this issue with varying degrees. I do not understand using pseudonyms on github. It can hardly be a privacy issue, as github doesn't hide your name. But it definitely impedes your "brand", i.e. your reputation, as it becomes divided in two. Github does not provide a "reverse phone book" where I can search for a PR under your name, nor does it provide any sort of cross reference. Searching (via github) the dmd repository for your name turns up nothing. I found it by searching the notification emails I get from github, which ironically are sent using your name rather than Abscissa (further confusing matters). I suppose I could write a cheat sheet and tape it to the wall of my office, but why not just use your name?
