September 07, 2018
On Wednesday, 5 September 2018 at 07:00:49 UTC, Joakim wrote:
> The D foundation is planning to add a way for us to pay for changes we'd like to see in D and its ecosystem, rather than having to code everything we need ourselves or find and hire a D dev to do it:
>
> $50 - Parallelize the compiler, particularly ldc, so that I can pass it -j5 and have it use five cores _and_ not have the bloat of separate compiler invocation for each module/package, ie taking up more memory or time.
>
> $30 - Implement H.S. Teoh's suggestion of having an automated build system to periodically check which dub packages are building with official compiler releases:
>
> https://forum.dlang.org/post/mailman.3611.1536126324.29801.digitalmars-d@puremagic.com
>
> $25 - Enable GC for the DMD frontend, so that dmd/gdc/ldc use less memory
>
> I would also stake smaller amounts on various smaller bugs, if there were a better interface than bountysource and people were actually using it, ie users knew about and were staking money and D core devs were fixing those bugs and claiming that money.
>
> 2. Would you be okay with the patches you fund not being open-sourced for a limited time, with the time limit or funding threshold for open source release specified ahead of time, to ensure that funding targets are hit?
>
> Yes, as long as everything is open-sourced eventually, I'm good.

The list of issues i have with D will probably bankrupt me.

But i will put my money where my mouth is:

** 750$ **

For a build in working high performance documented http server ( with all the basic necessities needed for web development ). Not just vibe.d as some module that breaks every time somebody sneezes!

It needs to be simple as:

import core.http;
import core.http.mysql;
import core.http.postgresql;
...

And with a time limit of 3 months. Because i know how D works, its no use to have bounties when they idle for years. And that is also the time limit i have for the start of a new project.

Its the only way to get a reliably http server with database access in my opinion. Because any issues are forced to be fixed on every DMD release! And its just idiotic that D does not have a build in HTTP server. This is a massive selling point for several of the competing languages.

And if i like what i see, there can be more on the table as i am creating my company next month. Hooray for tax deductibles.

And yes, i know 750$ is **way** too cheap, but that is what i am comfortable putting on the table for now with the history of D.

So think of this putting my butt on the line. If D can start to show the correct type of progress in the next months ( user friendliness, bug fixes, no more specialized enhancements, string fixes, API stability work, ...), i am even willing to hire some people in N-Spain for D development and they can help also help out with D its progress.

I must be a idiot to put my money on D with its issues *sigh*... So the next guy that dares to say "put up money or shut up", here it is.
September 07, 2018
On Friday, 7 September 2018 at 06:07:11 UTC, Joakim wrote:
[snip]
> Given the anemic response to this thread and the Opencollective so far, I suspect we wouldn't raise much though. OTOH, maybe the people who would pay don't read the forum.
>

Guess why there is an "anemic response". Of course it's because people who would pay don't read the forum, of course...but maybe...

[snip]


September 07, 2018
On Friday, 7 September 2018 at 10:51:28 UTC, RhyS wrote:
> ** 750$ **
>
> For a build in working high performance documented http server ( with all the basic necessities needed for web development ).

cha-ching

https://github.com/adamdruppe/arsd

just copy/paste code out of there, it works and has worked for many years.

But I have zero interest in dealing with dangeresque Phobos politics. I work alone. Except when I work with Renaldo... which is always.

You'll also have to define "high performance" with something concrete.
September 07, 2018
On Friday, 7 September 2018 at 11:27:04 UTC, Adam D. Ruppe wrote:
> cha-ching
>
> https://github.com/adamdruppe/arsd
>
> just copy/paste code out of there, it works and has worked for many years.

... Sorry Adam but if you consider a collection of lose code production ready for D, then we have different ideas. ;)

* Not included into D / External maintained by one dev.
* Not "user friendly" / Documentation is ... be honest Adam ;)

> But I have zero interest in dealing with dangeresque Phobos politics. I work alone. Except when I work with Renaldo... which is always.

I know Phobos politics have "issues" but its up to D to get their act together so people like you can contribute.

> You'll also have to define "high performance" with something concrete.

https://www.techempower.com/benchmarks/#section=test&runid=bd2d23c9-3d8c-4b6c-b7a2-cb900ed27e95

Its the most neutral and realistic benchmark for Web related content. When PHP with its bootstrapping fire and forget approach beats D by 50%, you know D has a issue. I am not including Swoole/PHP as a example. D needs to be closer to Go by its nature, then this low. Its just massive amount of performance that is wasted because of issues with the drivers and missing optimizations.
September 07, 2018
On Friday, 7 September 2018 at 11:48:47 UTC, RhyS wrote:
> ... Sorry Adam but if you consider a collection of lose code production ready for D, then we have different ideas. ;)

All libraries are collections of loose code, except the bad ones, which are tightly coupled collections of code that break with random dependency updates.

My code hasn't had serious breakage for years. Every so often, a new dmd release will through up a deprecation warning, but I fix those and keep it working on both old and new. I actively test compiling cgi.d, for example, on D 2.069, which is from 2015! It works there as well as the newest release this week.

That's the power of loosely coupled, conservatively-coded modules: they are hard to break. You pick and choose the parts you need, without pulling in a huge, fragile dependency tree.

I (and others) have also used it on real-world applications continuously since 2011.

> * Not included into D / External maintained by one dev.

You don't need a huge dev team when you have a stable, encapsulated codebase - maintenance is easy since things don't randomly break!

> * Not "user friendly" / Documentation is ... be honest Adam ;)

http://arsd-official.dpldocs.info/arsd.cgi.html

I rank it as... OK. But it is also generally simple so there's not that much to look at.

> Its the most neutral and realistic benchmark for Web related content. When PHP with its bootstrapping fire and forget approach beats D by 50%, you know D has a issue.

well, plain php is actually hard to beat for simple things. But yeah, vibe's performance there is poor. I wonder if I'd beat it, despite my policy being compatibility, stability and simplicity over performance.
September 07, 2018
On Friday, 7 September 2018 at 10:51:28 UTC, RhyS wrote:
> And with a time limit of 3 months. Because i know how D works, its no use to have bounties when they idle for years. And that is also the time limit i have for the start of a new project.
>

Idling for years isn't without reason. Usually, from what I've seen, the reason project gets stalled because it's almost ready to be accepted into Phobos. But then, someone shows up saying that it doesn't support the FancyXYZRange interface, also it has complicated relationship with XYZAllocator and Container API, which is almost ready. The author decides to wait until the spec for these technologies gets released, but it doesn't really get released, and so doesn't the main project.

Check out https://wiki.dlang.org/Review_Queue for some blast from the past
September 07, 2018
On Friday, 7 September 2018 at 04:36:20 UTC, Mike Franklin wrote:
> On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc wrote:
>> https://issues.dlang.org/show_bug.cgi?id=19179
>> https://issues.dlang.org/show_bug.cgi?id=5570
>> https://issues.dlang.org/show_bug.cgi?id=13957
>
> According to BountySource (https://www.bountysource.com/teams/d/issues?tracker_ids=383571) Issue 5570 already has a bounty of $445.  With the addition of your $500 that would make the bounty $945, which isn't bad.

Must be pretty hard to fix though if yebblies couldn't do it.
November 01, 2018
On Friday, 7 September 2018 at 04:36:20 UTC, Mike Franklin wrote:
> On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc wrote:
>
>> $500.00 to fix these three together - they may well be essentially the same bug:
>>
>> https://issues.dlang.org/show_bug.cgi?id=19179
>> https://issues.dlang.org/show_bug.cgi?id=5570
>> https://issues.dlang.org/show_bug.cgi?id=13957
>
> According to BountySource (https://www.bountysource.com/teams/d/issues?tracker_ids=383571) Issue 5570 already has a bounty of $445.  With the addition of your $500 that would make the bounty $945, which isn't bad.
>
> Mike

Sounds like a good bounty to me. I was planning to work on the non-global template problem but I think I'll start with this one.
November 01, 2018
On Thursday, 1 November 2018 at 01:42:23 UTC, soula�man wrote:
> On Friday, 7 September 2018 at 04:36:20 UTC, Mike Franklin wrote:
>> On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc wrote:
>>
>>> $500.00 to fix these three together - they may well be essentially the same bug:
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=19179
>>> https://issues.dlang.org/show_bug.cgi?id=5570
>>> https://issues.dlang.org/show_bug.cgi?id=13957
>>
>> According to BountySource (https://www.bountysource.com/teams/d/issues?tracker_ids=383571) Issue 5570 already has a bounty of $445.  With the addition of your $500 that would make the bounty $945, which isn't bad.
>>
>> Mike
>
> Sounds like a good bounty to me. I was planning to work on the non-global template problem but I think I'll start with this one.

Please see https://github.com/dlang/dmd/pull/8837 which is an upstreaming of those issues for LDC.
November 01, 2018
On Thursday, 1 November 2018 at 01:52:45 UTC, Nicholas Wilson wrote:
> Please see https://github.com/dlang/dmd/pull/8837 which is an upstreaming of those issues for LDC.
Thank you for pointing that out. That is definitely good progress It saves some work on the DMD side. It seems to fix the SysV 64bit ABI related issues for LDC but there is still some work for DMD as it was pointed out by Walter in the comments. I think I'll start there build on that for the DMD implementation.