Re: dip1000 state
On Saturday, 3 March 2018 at 02:12:28 UTC, Walter Bright wrote: On 3/2/2018 10:07 AM, carblue wrote: I generally already used -dip1000 since DConf2017 and it served me well, until about 2 month ago, "by accident" code was committed to std.uni that broke my builds, see issue #17961. I invested a lot of time to fix this by PR 6041. The current state is: I don't know any reason why it doesn't get (can be?) merged and now it languishes on page 2 of 3 of PRs and Walter started a new PR 6212 recently after my PR is ready for weeks. In total 4 of my -dip1000 related PRs are stuck and mostly for unknown or arguable reasons. For reference, I submitted: https://github.com/dlang/phobos/pull/6212 which I remarked was puzzlingly different from your PR: https://github.com/dlang/phobos/pull/6041 I would appreciate your advice on that as well. I was unaware of your PR. Sometimes, it's worth while to make some noise if you're feeling overlooked. I just want to get a problem solved, as soon as possible, and std.uni breaking -dip1000 builds happens since at least 2017-11-02 (https://issues.dlang.org/show_bug.cgi?id=17961), seemingly sleeping for 2.5 month until I assigned myself in bugzilla willing to fix this issue. If there is duplication/overlapping in PRs from several people, so what, it just happens - while not as effective as I would like D processes to be. The point I wanted to make here is, that the longer a PR is languishing (farer from PR stack's top), the more likely dup-PRs will be and in this case even PRs marked "Blocking Other Work, Bug Fix" being overlooked. In my situation of growing frustration about 4 stuck, espec. https://github.com/dlang/phobos/pull/6204 and https://github.com/dlang/phobos/pull/6041 (out of 8(9) submitted -dip1000 PRs; #6195 is known to possibly not being wise to merge unchanged), PR 6212 came along, You analyzed puzzling differences, I commented on that 8 days ago and since then nothing changed from my perspective: Now, 4 months after opening 17961, it's still unfixed and possibly not fixed with the next release. It's as simple as: I want my time invested being of any value, and if another PR solves a problem better than my solution and gets merged: Fine and I'll learn from that. Andrei said at DConf2017 sys. panel talk: He intends to be "nice" when NOT saying: This xy-PR won't make it into dlang. To the contrary I explicitly want "negativ/refusal" feedback as well and I feel, retaining this is not "nice". We learn from our faults mostly. Both Andrei and I are way overloaded, and I generally defer to Andrei to watch the Phobos PRs. I know and like Your unobtrusive way to point to overload. I consider delving into dmd code. Perhaps that might once help taking some load from Your shoulders. Sorry for the missing linkages. For reference, here are your open PRs: https://github.com/dlang/phobos/pulls?q=author%3Acarblue+is%3Aopen You've had 4 others that were pulled in the last month; you haven't been totally ignored: https://github.com/dlang/phobos/pulls?q=author%3Acarblue+is%3Aclosed I do appreciate the work you're doing to get -dip1000 working with Phobos. It's important! That's pleasant to hear from the language author, and frankly, I didn't cast doubts on that concerning You, once You take notice, but mostly others are dealing with the PR processing. I can say, I very much appreciate the D language, Andrei's and Your work and pushing DIP1000 even against a wall of indifference. I believe the latter is changing (now) and the sooner - howsoever - #17961 get's fixed, people can use/try -dip1000 again. -dip1000 compilabe phobos is pretty close - as You say - and finalizing helps taking more bricks out of the wall. Okay, I'll give it another try to push that. carblue, Carsten Blüggel
Re: dip1000 state
On Friday, 2 March 2018 at 18:17:02 UTC, Paolo Invernizzi wrote: On Friday, 2 March 2018 at 18:07:34 UTC, carblue wrote: (It may be absolutely unrelated, but there once was a very productive and knowledgeable compiler et. al. contributor, 9rnsr, Hara Kenji; though not contributing to dmd since ~ 1.5 years any more, he's still ranked #1 in number of contributions; I think, he's a busy professor at a Tokyo university, but I'm really curious to know why he stopped coding; I guess, dmd improvement speed still suffers from his decision). https://github.com/dlang/dmd/pull/5239 https://github.com/dlang/dmd/pull/5304 Many thanks for the pointers, Paolo. Just from what I grasped from a short read: It happened that "high-value" contributor Hara Kenji got pissed off in a discussion about code formating style (and probably more background I didn't read about): Incredible, that there was no way for de-escalation. It seems to support my (3.), but I won't appoint myself as a judge and we don't want to lose our BDFL. At least I understand my (1.) better now.
Re: dip1000 state
On Thursday, 22 February 2018 at 14:36:10 UTC, Radu wrote: Whould like to know what's the state of dip1000? The fact that it takes 8 days for any reply, doesn't that say something? @safe is a high ranked technical issue in vision papers (in german we say something like "paper is patient"), but when trying to turn to reality and push forward dip1000 for phobos (as I did in the past ~1.5 month), only a few members like Seb really seem to care a lot. Lately I haven't noticed much activity on it, and at least on the bug front there are about 28 entries opened: https://issues.dlang.org/buglist.cgi?quicksearch=dip1000%20OR%20%5Bscope%5D_id=219758 Look at my #18444 and it's "Depends on" and exclude 18444 from counting: It's just a tracking/organizational issue intended to i.a. perhaps add help for "dmd coder's" priority. No observable reaction there since Feb 15 so far. And there are others that I wouldn't take into account as bugs. My first reaction looking at this list again now is: Most issuers expect "somethíng to happen" on the dmd part. I'm asking this as I am eagerly waiting for it for about 1 year, wanting to use it for a new project that is in pipeline, and no major progress has been made since last year on both finalizing the spec and using the implementation in Phobos/druntime. IIRC, druntime is compiled -dip1000 already and for phobos, have a look into the aa settings in PR 6195: Only "a few" phobos modules are not -dip1000 compilable, currently. I'm also awaiting -dip1000 compilable phobos, and we are now 10 month past Walter Bright's DConf2017 talk "pointers gone wild", where he said "-dip1000 is implemented already" (omitting what's missing). From an eMail conv. with a member I know, Walter is aware of missing pieces in DIP1000.md and implementation and that it's on his TODO-list, probably as many other things are as well. But, except for special cases, there is no reason not to use -dip1000 today: -dip1000 implementation is far better than it's reputation. I generally already used -dip1000 since DConf2017 and it served me well, until about 2 month ago, "by accident" code was committed to std.uni that broke my builds, see issue #17961. I invested a lot of time to fix this by PR 6041. The current state is: I don't know any reason why it doesn't get (can be?) merged and now it languishes on page 2 of 3 of PRs and Walter started a new PR 6212 recently after my PR is ready for weeks. In total 4 of my -dip1000 related PRs are stuck and mostly for unknown or arguable reasons. Knowing my experience now, You won't expect me to contribute for -dip1000 any longer, but of course, You may do so and perhaps have more luck. There's a nice german children's song that comes to my mind here: "Ein Loch ist im Eimer". known in english as: "There's A Hole In My Bucket". It just leaves me stunned, shaking the head. Are there major roadblocks ahead? Or is just a matter of prioritization/budget? I would say (biased as I am), these are roadblocks: 1. Lack of (sufficient/knowledgeable) compiler contributors. 2. Some lack of coordination/enforcement/management: vision <-> make it happen. 3. A tendency to scare away (impatient,) possibly long-time contributors, i.a. - as I perceive that - by lack of appreciation, instead taking for granted volunteer contribution (which shows up in complete unresponsiveness sometimes: When I spend e.g. > 1 day on a non-trivial D-Programming-Deimos issue and there is no reaction to my PR for 2 month, not even a 1 minute response like "sorry no time" or "doesn't LGTM because...": That's at least impoliteness (I take it as lack of appreciation) that I won't accept any more. On the other hand, for "trivial" PRs, You may get very quick replies from 2 members. From DConf2017 talk "Systems Programming Panel" I know, I'm not alone being discouraged. (It may be absolutely unrelated, but there once was a very productive and knowledgeable compiler et. al. contributor, 9rnsr, Hara Kenji; though not contributing to dmd since ~ 1.5 years any more, he's still ranked #1 in number of contributions; I think, he's a busy professor at a Tokyo university, but I'm really curious to know why he stopped coding; I guess, dmd improvement speed still suffers from his decision). Though this might have raised more questions than giving answers (to the time schedule): Was it helpful?
Re: dub test
On Friday, 2 February 2018 at 07:23:54 UTC, Joel wrote:
When I try 'dub test' I get errors like 'Source file
'/Users/joelchristensen/jpro/dpro2/JMiscLib/source/jmisc/base.d' not found in any import path.'
Here's the dub.json file I'm using:
```
{
"name": "timelog",
"targetType": "executable",
"description": "A Joel D program. A D Diary program.",
"copyright": "Copyright © 2018, joelcnz - note: I don't
understand this",
"authors": ["Joel Ezra Christensen"],
"DFLAGS": ["g"],
"sourcePaths" : ["source",
"../JTaskLib/source",
"../JMiscLib/source"
],
"dependencies": {
"dlangui": "~>0.9.56"
}
}
```
Add before e.g. "dependencies"
"importPaths" : ["../JTaskLib/source",
"../JMiscLib/source"
],
Import module base from file ... source/jmisc/base.d by: import
jmisc.base;
and recommended read:
https://code.dlang.org/package-format?lang=json
