On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
> 20.10.2017 17:46, Martin Nowak пишет:
> My 2 cent:
> 1. dub needs ability to work with other repository than standard ones.

You mount or clone whatever you want and use `dub add-local`.

> 2. multicore building - entire project in D builds faster than C++ one (I have two implementation of the same), but in case of incremental building C++ faster.

I always assumed this to be the main point why people are asking for a better build tool, but it's not sth. dub can do atm. It's a limitation of the compiler that requires various changes and a slight redesign of our build model.

In C++ incremental rebuilds are simple as you compile each file individually anyhow, but that's the crux for why C++ compilations are so slow in the first place.
Compiling multiple modules at once provides lots of speedups as you do not have to reparse and analyze common/mutual imports, but on the downside it cannot be parallelized that well.

Dub could parallelize building individual packages/sub-packages (target + dependencies) right now though.

> 3. dub single build mode does not caches builds so it builds entire project every time.

Could you please file an issue with a test case for that.
Why do you use single build mode in the first place?

On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote:
> In C++ incremental rebuilds are simple as you compile each file individually anyhow, but that's the crux for why C++ compilations are so slow in the first place.
> Compiling multiple modules at once provides lots of speedups as you do not have to reparse and analyze common/mutual imports, but on the downside it cannot be parallelized that well.

dub supports --buildMode=singleFile --parallel to mimic that, but it's very wasteful.

For example gtk-d took way over a minute with single file compilation, but only a few seconds when being compiled at once

On Sunday, 22 October 2017 at 22:00:19 UTC, bitwise wrote:
> I hope resumable functions for for generator/coroutine style usage are also part of the plan. Allocator support would be nice too.

Please see https://forum.dlang.org/post/pbnthucxpvbgzzuigtrq@forum.dlang.org for how this could be implemented and why this is not much of a priority right now.
If someone wants to pull this off, the effort would be very welcome.

On Saturday, 21 October 2017 at 18:52:15 UTC, bitwise wrote:
> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>
>> async/await (vibe.d is nice but useless in comparison to C# or js async/await idiom)
>
>
>> Reference counting when we cannot use GC...
>
>
> If I understand correctly, both of these depend on implementation of 'scope' which is being worked on right now.

Scope is about preventing pointer escaping, ref-counting also needs to make use-after-free safe which is currently in the early spec phase.
Whether or not that is going to be a compile-time or runtime check has yet to be figured out. If you have a great idea that we should consider, let us know.

The recent IOPipe window invalidation discussion was a good example of what such a mechanism would hopefully be able to handle (https://gist.github.com/MartinNowak/b406a6b7aa6d0964147c107771b64333#file-safety_dance-d-L43-L45).

> I think reference counting needs 'scope' to be made safe. RC also benefits from scope in that many of the increments/decrements of the ref count can be elided. The performance gain can be significant, and even more so when you use atomic reference counting (like C++ shared_ptr) for thread safety.

Well, there can be RC and shared(RC), only the latter would need to do atomic ref-counting.

> Async/Await needs to allocate state for the function's local variables. When it's detected that the function's state/enumerator won't escape it's current scope, it can be put on the stack, which is a pretty big optimization.

We should figure out how to allocate RC/unique delegate contexts.
Not that with async/await you always escape the local context, as it's the callback in the returned Promise/Task.

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
> dub is great for simple solutions but useless in big projects with multiple targets, configurations, etc.

Works here. Closed source can be handled with path-based dependencies and private checkouts.

Configurations are handled by... dub configurations.
Targets? by dub targets.

> Still cannot easily develop closed source dlls on Windows. On Linux every symbol is public by default, but on Windows not so it's needed to export them manually.

Not anymore, you can use the "export" keyword for Windows (eg with LDC >= 1.2).

Every-symbol-public-by-default in Posix is annoying though :)


> For me, it seems like Walter is solving edge case problems like return ref parameters and return functions but is unable to add some basic stuff.

Because **everyone has its own, different opinion of what the "basic stuff which is absolutely needed" is**, and adding all of that would be 3x the size of D and unpleasant.
For starters, some of us would like stuff to be _removed_, not added.

It's like a tradition: each new generation of D users ask for the additional, "must-have" features of the day.

On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>> Hi,
>> I had been using D for almost 6 years and I want to share my opinion with you.
>> I don't want to blame anyone but I'll focus more on bad things and possible improvements.
>> And this is just how I see D from my perspective.
>> (Sorry for my English, I'm too lazy to take the lessons).
>>
>> [...]
>
> Whats about this one?
>
> auto foo = 42;
> auto bar = "bar";
> writeln(`Foo is {foo} and bar is {bar}`);

String interpolation could be done in a library.

    fmt!("Foo is ${foo} and bar is ${bar}", foo, bar)

At the moment you'd just use format.

    format!"Foo is %1$s and bar is %2$s"(foo, bar);

While both are a bit more verbose, it seems to me that interpolated strings aren't that big a deal.
Collecting arguments and design ideas in a DIP would still be worthwhile and very welcome.
Even if ends up not being approved, it would ensure a good decision base and avoid future discussions.

Sth. like

  s"Foo is ${foo} and bar is ${bar ~ `bla`}"

to be lowered to

 format!"Foo is %1$s and bar is %2$s"(foo, bar ~ `bla`).

could be a feasible approach on a first thought.

On Monday, 23 October 2017 at 11:23:18 UTC, Guillaume Piolat wrote:
> Not anymore, you can use the "export" keyword for Windows (eg with LDC >= 1.2).

With what semantic?

> Every-symbol-public-by-default in Posix is annoying though :)

We agreed on hidden visibility by default for everything that's not exported.
This requires export to be fixed on non-Windows machines first.

By any means, if someone wants to help here, get in touch with Benjamin Thaut and me.
This has been lingering around for way to long, and Benjamin alone has a hard time pushing this.

23.10.2017 14:02, Martin Nowak пишет:
> On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
>> 20.10.2017 17:46, Martin Nowak пишет:
>> My 2 cent:
>> 1. dub needs ability to work with other repository than standard ones.
> 
> You mount or clone whatever you want and use `dub add-local`.
This is workaround. Now I have bash script that does all I need, but it would be better if I should only specify my inhouse repos.

> 
>> 2. multicore building - entire project in D builds faster than C++ one (I have two implementation of the same), but in case of incremental building C++ faster.
> 
> I always assumed this to be the main point why people are asking for a better build tool, but it's not sth. dub can do atm. It's a limitation of the compiler that requires various changes and a slight redesign of our build model.
> 
> In C++ incremental rebuilds are simple as you compile each file individually anyhow, but that's the crux for why C++ compilations are so slow in the first place.
> Compiling multiple modules at once provides lots of speedups as you do not have to reparse and analyze common/mutual imports, but on the downside it cannot be parallelized that well.
I just build my project and it's silly to look at `top` output where seven cores idles while build takes tens of seconds. While building C++ project loads cores fully. I have no clear and robust opinion on this, considering you wrote above, but nevertheless.
> 
> Dub could parallelize building individual packages/sub-packages (target + dependencies) right now though.
I should try it.
> 
>> 3. dub single build mode does not caches builds so it builds entire project every time.
> 
> Could you please file an issue with a test case for that.
> Why do you use single build mode in the first place?
I have several utilities each of them is about 50 lines (including comment to enable single build mode) and I think this is case for single mode exactly. They are wrappers of rather fat library and building them takes about a minute what is too long for D.

I do not state that it prevents D from enterprises etc, not at all. I'm sure that restructuring my project can improve building time too, for example. Just directions where we can do more to improve tooling.

On Friday, 20 October 2017 at 15:38:53 UTC, Martin Nowak wrote:
>> Commercial usage, shared libraries and stuff
>> There isn't any handy tool to download, manage and publish closed source stuff.
>> dub is great for simple solutions but useless in big projects with multiple targets, configurations, etc.
>> Everything is primary focused on opensource development (but everyone here wants to see D as a next successor of C++ in commercial sphere).
>
> Well, dub is a package manager to share code, so obviously OSS it the main target. You can easily `dub add-local` packages or run your private registry.


https://github.com/dlang/dub/pull/985
"A common use-case (that I currently have) is a large project with many dub packages in it, which much be registered with dub, but don't have any purpose outside that project. It also allows any dependencies to be easily packaged inside a project in order to allow building an application without an internet connection, by just running dub upgrade --root=$APP_PROJECT_DIR --defaultRepoPath=$PROJECT_ROOT/deps/ on the dev machine, then dub build --root=$APP_PROJECT_DIR --defaultRepoPath=$PROJECT_ROOT/deps/ --skip-registry=all on the target machine."

We've submitted a PR for our internal dub fork that we use to build a decent-sized project (not as big as Weka, but not much smaller).  Sadly it required quite a few changes and was hard to break into bite-sized ones.

If you're working on a big internal project, I'd say that it's worth thinking about things from a medium-term perspective.  With D you have higher costs to get the build system etc right, but you gain and keep gaining from having more concise, clearer, more maintainable, and more plastic code.  The costs are front-loaded though.  If one's able to take a medium-term perspective and the changes you want to see in dub are not all that much, it may well be worth finding someone in the D community you can pay to help make those changes.  A little money goes a long way because here you have strong programmers - who like programming! - from all over the world, and not everyone is in a situation that makes their opportunity cost as high as what it might be within the company (not just payroll, but overheads, co-ordination costs etc).

And you may find other commercial users are willing to split the costs - that's something a large media company asked me about, and that we would be open to also if it's something that will fit with what we need.

> And of course there are various other options like Make, CMake, Meson, or Raggae.

(Reggae).  We use Reggae for building proprietary codebase.  If there's a feature missing, please do say - maybe we would benefit from it, and since Atila works with us, it's something easy to consider when time.


> As unfortunately with almost any OSS project, we're not that many people, and each of us is investing a huge amount of time into this.

Also - for example with dub.  Dub and vibe constitute an amazing achievement for one man.  I don't mean to diminish the contribution of others, but I guess Sonke has been the creative spirit behind them and has done most of the work.  There's one challenge that arises when you can benefit from the work of unusually productive people (of whom there seem to be many in the D community - I just take Sonke as one example), is that for that same reason they end up getting responsibility in the commercial parts of their lives, which might mean less time available to devote to open-source at certain points.

There are 39 pull requests open on dub currently. It's not a super-complicated code base, but I guess the people responsible for dub have quite a lot on their plates.  I don't know how others might be able to help, but maybe that is one area that would benefit the language ecosystem more generally.  (I get the impression sometimes that people want to help, but they don't completely know how).

There's no mention of dub here, for example:
https://wiki.dlang.org/Get_involved

Now there is.. (I just added it).
https://wiki.dlang.org/Get_involved#Review_pull_requests

> But again your best bet on getting sth. done is working on it, be it writing a DIP, organizing the discussion, or actually implementing it.

Bountysource went quiet, though I started contributing to it.  I wonder if there is a better way for commercial users to say what they might be willing to pay for and how much.  I don't think that keeping patches private for a while really fits.  It doesn't hurt me if some other D user benefits from work I sponsored.  In fact it helps me if it is incorporated into the main codebase, because that means I don't need to worry about maintaining it.  And that's in any case way too selfish a perspective - not smart commercially: if D flourishes, it helps us too.


Laeeth.

On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>> Hi,
>> I had been using D for almost 6 years and I want to share my opinion with you.
>> I don't want to blame anyone but I'll focus more on bad things and possible improvements.
>> And this is just how I see D from my perspective.
>> (Sorry for my English, I'm too lazy to take the lessons).
>>
>> [...]
>
> Whats about this one?
>
> auto foo = 42;
> auto bar = "bar";
> writeln(`Foo is {foo} and bar is {bar}`);

writeln("Foo is ", foo, "and bar is ", bar");

Two more characters.

Atila