On Tuesday, 23 May 2017 at 15:37:39 UTC, Stefan Koch wrote:
> The compiler does indeed seem to optimize the code somewhat.
> Although the generated asm still looks wired.
> http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3

The jbe (jump-below-equal)
does check the overflow flag (and redundantly the zero-flag) here
and sets the bool which represents overflow to one.

On Tuesday, 23 May 2017 at 15:43:24 UTC, Andrei Alexandrescu wrote:
> On 05/23/2017 11:37 AM, Stefan Koch wrote:
>> 
>> The compiler does indeed seem to optimize the code somewhat.
>> Although the generated asm still looks wired.
>> http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3
>
> That call enters a different overload:
>
> pragma(inline, true)
> uint mulu(uint x, uint y, ref bool overflow)
> {
>     ulong r = ulong(x) * ulong(y);
>     if (r > uint.max)
>         overflow = true;
>     return cast(uint)r;
> }
>
> which is of efficiency comparable with code using seto. I'm not too worried about that. https://goo.gl/eRXUpr is of interest.
>
>
> Andrei

Well ....
Since core.checkedint is in druntime, we _could_ detected the checking operations and generate better code for them.
But right now, I am convinced it is worth the effort.

On Tuesday, 23 May 2017 at 15:54:42 UTC, Stefan Koch wrote:
>
> Well ....
> Since core.checkedint is in druntime, we _could_ detected the checking operations and generate better code for them.
> But right now, I am [NOT] convinced it is worth the effort.

On Tuesday, 23 May 2017 at 08:18:26 UTC, Iain Buclaw wrote:
>
> So for LDC to be as good as GDC, you need to need to compile with -enable-ldc-amazing-feature-cross-module-inlining?

In this case, yep.

> If you want a hint (though it's not my place to say), LLVM I'm told is a reasonably OK compiler, and any reasonably OK compiler should come with overflow intrinsics - try using them directly.

Pleasantly surprised that you think so highly of LDC and LLVM that you assume we are able to get the `seto` instruction in this case without using an overflow intrinsic.

- Johan

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:
> http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ -- Andrei

That was a great read, thanks!

At the end, you mention a successful serial entrepreneur who counsels pursuing the great rather than the good ideas being advanced in the D community. Did he happen to mention which ideas were great, and which just good?

On 2017-05-22 17:05, Andrei Alexandrescu wrote:
> http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/
> -- Andrei

About the custom attributes that are mentioned, like "has acquired a lock" attribute. This would be a perfect candidate for a UDA and using the compiler as a library to implement a domain specific checker for this feature. When the regular compiler sees this attribute it has no meaning to the compiler. But when running the custom checker it will perform some additional checks to verify that the code behaves according to the specific domain requirements.

Without knowing any details, it might be possible to implement similar checks today by modifying druntime and replace the RTInfo template with a custom implementation that performs some additional checks.

-- 
/Jacob Carlborg

On 5/22/17 6:53 PM, cym13 wrote:
> On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:
>> http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ -- Andrei
> 
> Now that you are back and could take some time to think this over, would you say your trip will influence how you see D's and the D community evolution? In what way?

In several ways. To an extent it was a confirmation of things already known: We do well on things we focus on (language core, standard library, quality of implementation), and less so on things we focus less on (soft skills, community building, leadership). I got a clearer notion that the latter is an important ingredient.

One thing that several of those people emphasized is we need to improve leadership and decision. "You are trying to do democracy and democracy doesn't work here" (by a successful serial entrepreneur). Walter and I have implicitly fostered a kind of meritocracy whereby it's the point/argument that matters. It should be meritocracy of the person - good proven contributors have more weight and new people must prove themselves before aspiring to influence. Historically, anyone with any level of involvement with D could hop on the forum and engage the community and its leadership in debate. Subsequently, they'd be frustrated with the ensuing disagreement and also get a sense of cheapness - if I got to carry this unsatisfactory debate with the language creator himself, what kind of an operation is this?

Since anything can be debated by anyone, everything gets debated by everyone. Anyone can question any decision at any time and expect a response. It's the moral equivalent of everyone in a 5000-person company building can expect to stop the CEO on the way to his/her office and engage them in a conversation of any length. The net consequence is slower progress.

Where we need to be is fostering strong contributions and contributors. The strength of one's say is multiplied by his/her contributions (and that simply means pulled PRs, successful DIPs - not "won" debates). Many successful OSS projects have been quoted as implementing this policy successfully.

Every person in the room took a significant fraction of the meeting time to tear me a new one about dub and http://code.dlang.org. Each in a different place :o). I got to the point where I consider every day spent with code.lang.org just sitting there with no ranking, no statistics, no voting, no notion of what are the good projects to look at - every such day is a liability for us. We really need to improve on that, it is of utmost importance and urgency. Martin said he'll be on that in June, but we could really use more hands on deck there.

Documentation of vibe.d was also mentioned as an important problem. More precisely, it's the contrast between the quality of the project and that of the documentation - someone said his team ended up with a different (and arguably inferior) product that was better documented. Literally they had the same engineer try each for a day. Reportedly it was very difficult to even figure whether vibe.d does some specific thing, let alone tutorials and examples of how to do it.

Back to community: Successful OSS projects have a hierarchy and follow formalized paths and processes for communicating up and down. People are willing to work/wait for months on a proposal because they have a sense of process and a confidence their proposal, if properly done, will get a fair shake. These are good ideas to follow (and indeed I got more confirmation that investing in our new DIP process is a good thing to do).

We need to improve the collaboration and tone in the forums and github. (I was amazed at how well these business and community leaders knew who's who in our community.) We can only assume in the future people will peruse our forums/github to decide whether to use D in their enterprise. We need to improve on the current disposition toward fruitless debate not concluding in decision making. What hurts us the most and stands like a sore thumb is the occasional use of abusive language. We need to stop that.

Many of these things I had a good sense of before entering the meeting, and was on the way toward improving on them. The meeting provided a strong confirmation of the importance of these matters, and good ideas toward doing better.


Andrei

On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:
> What hurts us the most and stands like a sore thumb is the occasional use of abusive language. We need to stop that.

Interesting. Are there any examples you're willing to provide? It seems to me that stuff like this is immediately condemned, but only if it comes from somebody who is new or doesn't post here often. There's been a few cases I can think of where a regular contributor/frequent poster said something that I'd consider "abusive language" and it's allowed to slide without (public) reprimand or apology, but again it's not completely clear what you have in mind when you say "abusive language".

On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:
> One thing that several of those people emphasized is we need to improve leadership and decision. "You are trying to do democracy and democracy doesn't work here" (by a successful serial entrepreneur).

I'm pretty sure nobody actually involved with D would call it a democracy.  We may get to say our piece, but ultimately the core team decides.

> Walter and I have implicitly fostered a kind of meritocracy whereby it's the point/argument that matters.

That's because that's all that matters.  It is what almost every worthwhile organization aspires to, though very few get there.  Doing anything else would be a mistake.

> It should be meritocracy of the person - good proven contributors have more weight and new people must prove themselves before aspiring to influence.

Certainly you can weight their opinion more because they know the code better, but otherwise it is precisely this personal influence taking precedence over the particular argument that sinks most organizations.

> Historically, anyone with any level of involvement with D could hop on
> the forum and engage the community and its leadership in debate. Subsequently, they'd be frustrated with the ensuing disagreement and also get a sense of cheapness - if I got to carry this unsatisfactory debate with the language creator himself, what kind of an operation is this?

Or they were inspired that their feedback was taken into account, if not followed, and decide to pitch in.

> Since anything can be debated by anyone, everything gets debated by everyone. Anyone can question any decision at any time and expect a response. It's the moral equivalent of everyone in a 5000-person company building can expect to stop the CEO on the way to his/her office and engage them in a conversation of any length. The net consequence is slower progress.

If you're going in the wrong direction, slower progress is to be lauded.

I think you're overly critical of the culture of debate that is a part of open source and especially this project.  I know I decided to pitch in after years of lurking in the newsgroup, I doubt I'm the only one.

Of course, like anything, debate can be overdone and you're probably right that it has been at times here.  But an open source project is a fundamentally different thing than a startup, it requires much more community involvement and deliberation.  I recommend reading this chapter from this book on open source development:

"Public discussion generally takes longer to make a decision than a proprietary development group does, but because the diversity of the viewpoints is greater for an open-source effort the resulting decision is likely to be of higher quality. This can translate into a shorter overall development cycle, because subsequent work will probably not need to be discarded because the real issues came up after, rather than during, the discussion period."
http://dreamsongs.com/IHE/IHE-54.html#pgfId-956812

> Where we need to be is fostering strong contributions and contributors. The strength of one's say is multiplied by his/her contributions (and that simply means pulled PRs, successful DIPs - not "won" debates). Many successful OSS projects have been quoted as implementing this policy successfully.

There are different ways to contribute.  One may not have time to work on a bunch of PRs/DIPs or may be better suited to discussion of the technical design.

I agree that we need more people contributing rather than just talking, but I don't think this is the way to do it.

> Every person in the room took a significant fraction of the meeting time to tear me a new one about dub and http://code.dlang.org. Each in a different place :o). I got to the point where I consider every day spent with code.lang.org just sitting there with no ranking, no statistics, no voting, no notion of what are the good projects to look at - every such day is a liability for us. We really need to improve on that, it is of utmost importance and urgency. Martin said he'll be on that in June, but we could really use more hands on deck there.

Yeah, I mentioned this need before too.

> Documentation of vibe.d was also mentioned as an important problem. More precisely, it's the contrast between the quality of the project and that of the documentation - someone said his team ended up with a different (and arguably inferior) product that was better documented. Literally they had the same engineer try each for a day. Reportedly it was very difficult to even figure whether vibe.d does some specific thing, let alone tutorials and examples of how to do it.

Eh, documentation is going to be sparse for a non-corporate OSS project.  If they're building products with vibe.d, presumably they can throw some consulting dollars Sonke's way and get him to help.

> Back to community: Successful OSS projects have a hierarchy and follow formalized paths and processes for communicating up and down. People are willing to work/wait for months on a proposal because they have a sense of process and a confidence their proposal, if properly done, will get a fair shake. These are good ideas to follow (and indeed I got more confirmation that investing in our new DIP process is a good thing to do).

Rather, it is a blend, some hierarchy on top of a wide herd of cats. ;) But sure, improving the process will help.

> We need to improve the collaboration and tone in the forums and github. (I was amazed at how well these business and community leaders knew who's who in our community.) We can only assume in the future people will peruse our forums/github to decide whether to use D in their enterprise. We need to improve on the current disposition toward fruitless debate not concluding in decision making.

As I said above, even "fruitless" debate can help, but like anything else, it can be overdone.

> What hurts us the most and stands like a sore thumb is the occasional use of abusive language. We need to stop that.

Any large community is going to have it, tough to police.

> Many of these things I had a good sense of before entering the meeting, and was on the way toward improving on them. The meeting provided a strong confirmation of the importance of these matters, and good ideas toward doing better.

I'm sure there was some good advice, but I'd caution that these entrepreneurs were not running an open source project, which requires a much lighter touch.

On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:
> Every person in the room took a significant fraction of the meeting time to tear me a new one about dub and http://code.dlang.org. Each in a different place

Just a couple days ago, people asked me if my libs were on dub... this was annoying because they shouldn't have to ask *me*, they should just ask the website, but even basic search and listing is broken.

I've complained about this before... https://github.com/dlang/dub-registry/issues/123 in Sept 2015.


I'm not a dub user, so I don't particularly care to maintain it myself... but does NOBODY care?

It is also embarrassingly slow to even load the code.dlang.org homepage.

> Documentation of vibe.d was also mentioned as an important problem.

Documentation in general is a big problem.