On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:

> Let the brainstorming begin!

Find a way to improve the performance of our CIs.  See https://forum.dlang.org/post/mailman.1018.1526887297.29801.digitalmars-d@puremagic.com

The more time a PR is "green" the higher the likelihood it will be reviewed.  Having a more performant CI infrastructure could help with our review bottleneck, and also make the experience for contributors less frustrating.

GDC is using Buildbot (https://buildbot.net/) for some of its CIs.  I've been wondering if it might be less costly and more performant to create a distributed Buildbot CI for the dlang repositories, and allow community members volunteer their hardware resources to bring down the cost and increase the throughput of our testing.

Mike

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:

> Let the brainstorming begin!

Fork newCTFE and bring it to completion:

https://dlang.org/blog/2017/04/10/the-new-ctfe-engine/

Mike

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:

> Let the brainstorming begin!

I haven't looked into this myself, but I vaguely remember an ongoing problem with DMDs performance (especially memory usage) gradually degrading with time.  I think it would be a nice exercise for someone to do some profiling on DMD and make some recommendations, or under the guidance of Walter, do some refactoring to improve DMDs performance.

Mike

On Wednesday, 23 May 2018 at 01:51:35 UTC, Mike Franklin wrote:
> Make WebAssembly a thing in D.

Yes please!

I would love to help with WebAssembly in D but frankly it is a little it overwhelming me and my lack of knowledge.  If anyone does take the bull by the horns, let me know if you need a noobs help (:

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:

> Let the brainstorming begin!

An LDC or GDC cross-compiler generator for the Raspberry Pi.

There are already some instructions out there (e.g. http://d-land.sepany.de/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc.html), but what we really need are shell scripts for Linux and Windows that we can download and run, and out pops a read-to-use compiler that can generate binaries on either Windows or Linux for the Raspberry Pi.

See my GDC cross-compiler generator at https://github.com/JinShil/arm-none-eabi-gdc

I do a lot of support for scientists, engineers, and entrepreneurs of other non-software-related disciplines.  The all need to write code and all want to create embedded systems for their research or their product.  I believe many of them would enjoy D (due to their current knowledge of C) for their work if there wasn't such a high barrier to entry just to get the development tooling set up.

Mike

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:

> Let the brainstorming begin!

Building and running the DMD test suite on vanilla Windows is a pain.  I never succeeded but it appears to require the user to first set up a posix environment and then battle environment configuration, and other vague dependencies such as whether you are building for 32-bit or 64-bit and whether Visual Studio 2017 is installed.

I believe most contribute to D with a Linux development machine, but sometimes there are Windows-only issues that need to be solved.  For that we need to be able to build and test our changes on Windows without hassle.

I'd like to see the requirement for a posix environment lifted by porting all makefiles to D, so the same code (with appropriate `version`ing of course) could be used to compile and build dlang repositories on all platforms without a lot of environment setup and configuration.  All that would be required a recent D compiler in one's PATH.

See https://github.com/dlang/dmd/pull/8162 for some working moving in that direction.

Mike

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:

> Let the brainstorming begin!

Try to replace some of the basic software building blocks (memcpy, memcmp, malloc, free, realloc) that are currently leveraged from the platform's C library with counterparts, and provide a D API that uses `T[]` instead of void* and provides some of D's compile-time guarantees like safety, purity, and nothrow.

Implementation would take into consideration a platform's unique features such a SIMD.

Determine if there are any special features of D that can actually improve the performance of the highly optimized C implementations, perhaps leveraging information known at compile-time.

The project would provide an exemplary illustration of D's capabilities with benchmarks comparing it with C, and hopefully demonstrate that we don't need to have artificial dependencies on libc anymore.

Mike

On Wednesday, 23 May 2018 at 04:17:19 UTC, Mike Franklin wrote:
>
> Try to replace some of the basic software building blocks (memcpy, memcmp, malloc, free, realloc) that are currently leveraged from the platform's C library with counterparts, and provide a D API that uses `T[]` instead of void* and provides some of D's compile-time guarantees like safety, purity, and nothrow.
>

Knock it off with sex talk here.

On Wednesday, 23 May 2018 at 04:17:19 UTC, Mike Franklin wrote:
> On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:
>
>> Let the brainstorming begin!
>
> Try to replace some of the basic software building blocks (memcpy, memcmp, malloc, free, realloc) that are currently leveraged from the platform's C library with counterparts, and

Sorry, I didn't really complete my thought well in that sentence.  I meant to say "... with counterparts written in D".

Mike

On 23/05/2018 4:56 PM, Mike Franklin wrote:
> On Wednesday, 23 May 2018 at 04:17:19 UTC, Mike Franklin wrote:
>> On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:
>>
>>> Let the brainstorming begin!
>>
>> Try to replace some of the basic software building blocks (memcpy, memcmp, malloc, free, realloc) that are currently leveraged from the platform's C library with counterparts, and
> 
> Sorry, I didn't really complete my thought well in that sentence.  I meant to say "... with counterparts written in D".
> 
> Mike

In essence a -betterC libc with wrapper functions for extern(D).