On Wednesday, 23 May 2018 at 04:58:17 UTC, rikki cattermole wrote:

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

I'd prefer to not even need to link in libc.  I mean rewrite memcpy, memcmp, malloc, free, and realloc in D.  Once those building blocks exist in D, everything becomes possible without libc.

Mike

On 23/05/2018 5:01 PM, Mike Franklin wrote:
> On Wednesday, 23 May 2018 at 04:58:17 UTC, rikki cattermole wrote:
> 
>> In essence a -betterC libc with wrapper functions for extern(D).
> 
> I'd prefer to not even need to link in libc.  I mean rewrite memcpy, memcmp, malloc, free, and realloc in D.  Once those building blocks exist in D, everything becomes possible without libc.
> 
> Mike

What I meant is that the student(s) would write a portion of a libc from scratch. Just using -betterC D.

So that it is drop in, in other -betterC code :)

Memory management is only one aspect possible.

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

> Let the brainstorming begin!

I've often wondered if D has the right features to implement a borrow-checker in the library.  Something similar to this:

https://www.youtube.com/watch?v=Lj1GppqNr8c
https://gist.github.com/foonathan/023ff0fe923c6b0312dfc15e17ebb595

Probably not, but it would be a fun exercise.

Mike

On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:
> Hello, everyone!
>
> We, at UPB, have initiated D's participation to ROSEdu Summer of Code, see http://soc.rosedu.org/2018/.
>
> I will be mentoring a student over the summer and I was wondering if you have
> any suggestions for a project. If there is a library or feature that you would like
> just drop an idea.
>
> The proposed idea should be something that can be done in 8-10 weeks, though, ideally, we hope that the student/s will continue to contribute to the community after the summer ends.
>
> Let the brainstorming begin!

Maybe this could be a good source of inspiration: https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig

On Wednesday, 23 May 2018 at 03:43:16 UTC, Mike Franklin wrote:
> 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.

Clarification:  It's not just the cross-compiler that we need.  We need the whole toolchain including druntime, phobos, and a linker that can generated both dynamic and static-liked libraries from a host PC.  Including other utilities from binutils, LLVM, and even a debugger for remote-debugging from the host development PC would be ideal.

Mike

All of your suggestions are good ideas, Mike, but they're way too big for an 8-10 week student project. We need something smaller, like making key Phobos functions @nogc/@safe/pure/nothrow/etc.

On 5/22/18 10:00 PM, Mike Franklin wrote:
> On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:
> 
>> Let the brainstorming begin!
> 
> An apprentice for Walter.
> 
> I think Walter needs an apprentice (or 10).  Too much knowledge about D's design decisions, present, and future are locked up in his mind.  He needs to be disseminating his knowledge, training the next generation of D maintainers, and widening the bottleneck that currently exists for fixing bugs and evolving the language.

I was actually thinking, we need really a layman's explanation of how things work in the compiler. I'm not sure this requires apprenticeship, it may just need more documentation.

Common questions I have when looking at dmd code:

Where is this in the source?
How do I know I'm in a function?
How do I know I'm in a template?
What module am I in?
How do I know what has been run?
What is the proper way to generate lowered code?

I recently fixed a bug in DMD for the first time at dconf. The PR still hasn't been merged yet, but I'm confident about the fix.

But I really only was able to fix this because the way the code was written -- essentially it was a string mixin, and I could see where the error was in the string. But it took ALL DAY to find it. Knowing where to look is hugely important (and I would never have found it without the help of several people during the hackathon), but also knowing what you are looking at is hugely important.

-Steve

On 24/05/2018 2:25 AM, Steven Schveighoffer wrote:
> On 5/22/18 10:00 PM, Mike Franklin wrote:
>> On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:
>>
>>> Let the brainstorming begin!
>>
>> An apprentice for Walter.
>>
>> I think Walter needs an apprentice (or 10).  Too much knowledge about D's design decisions, present, and future are locked up in his mind.  He needs to be disseminating his knowledge, training the next generation of D maintainers, and widening the bottleneck that currently exists for fixing bugs and evolving the language.
> 
> I was actually thinking, we need really a layman's explanation of how things work in the compiler. I'm not sure this requires apprenticeship, it may just need more documentation.
> 
> Common questions I have when looking at dmd code:
> 
> Where is this in the source?
> How do I know I'm in a function?
> How do I know I'm in a template?
> What module am I in?
> How do I know what has been run?
> What is the proper way to generate lowered code?
> 
> I recently fixed a bug in DMD for the first time at dconf. The PR still hasn't been merged yet, but I'm confident about the fix.
> 
> But I really only was able to fix this because the way the code was written -- essentially it was a string mixin, and I could see where the error was in the string. But it took ALL DAY to find it. Knowing where to look is hugely important (and I would never have found it without the help of several people during the hackathon), but also knowing what you are looking at is hugely important.
> 
> -Steve

I would love to help fix this.

Problem is, my PR which helps make the lexer (de)initializable hasn't been reviewed by anybody who can actually confirm my statements about its usefulness and the fact that once the parser is done too, we can out right switch the compiler to it (and hence not needing tests ext.).

Sadly I have another ready to go (bug fix) and then there is another after that planned. Getting parser/AST up to scratch won't be pleasant and will require a lot of breaking changes compared.

On Wednesday, 23 May 2018 at 04:30:28 UTC, 12345swordy wrote:
> 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.
I know that you impersonating me here.

On Wednesday, 23 May 2018 at 14:25:44 UTC, Steven Schveighoffer wrote:

> Common questions I have when looking at dmd code:
>
> Where is this in the source?
> How do I know I'm in a function?
> How do I know I'm in a template?
> What module am I in?
> How do I know what has been run?
> What is the proper way to generate lowered code?

I hear you, I think most of us have been there.  Razvan also mentioned this in the beginning of his DConf talk.  The only documentation that I know of is https://wiki.dlang.org/DMD_Source_Guide.  I believe its very outdated, but probably still helpful.  You get to it from the from page of the wiki by going to "Compilers & Tools" --> "DMD".

I'll share how I got started, as I think it might serve as a path for others.
1.  I filed this issue about `static alias this`:  https://issues.dlang.org/show_bug.cgi?id=17684
2.  Vladimir identified it as a regression, and posted the PR that broke it.
3.  The PR that broke it was super simple, so I figured if it was simple to break, it would be simple to fix.
4.  Yep, after a lot of grepping, it was pretty simple to fix: https://github.com/dlang/dmd/pull/7055
5.  It got a little euphoric about fixing this and that motivated me to do more.  And it just took off from there.

I recognize not everyone will have a simple fix like this to get them past the barrier to entry.  And fewer will get their PR reviewed and merged like mine was (Thanks Petar).

I actually learned a lot by studying other people's PRs, trying to learn what they were doing any why.  If you have a bug you'd like to fix, search through the open and closed PRs and see if you can find something similar.  Study it and see if you can extrapolate any understanding from it.

I also received a LOT of help from Iain when I attempted this ambitions fix:  https://github.com/dlang/dmd/pull/7079.  Again, few people will receive such valuable help, so I am very fortunate, but it may be a strategy to just try, knowing your fix is wrong, and hope in the review process you'll get the information you need to make it correct.  But you could also irritate a lot of people if such a PR shows little effort on your part.

A few questions I had when I got started:
Q.  How do I build the compiler?
A:  `make -f posix.mak -j4`

Q:  How do I run the test suite locally?
A:  `make -C test/ -f Makefile -j4`

Finally, if anyone needs help, please ask questions on the forum (General or Internals for compiler devs), slack, IRC, etc.  If you don't get an answer, it doesn't mean you're being ignored; not many people know how to answer such questions.

That all being said, here's the kicker which both Steven and Rikki alluded to:  We have a review bottleneck, not a contribution bottleneck.  If we could attract more talent with the domain expertise needed to certify a PR, then the contributions would increase organically.  That's a terrible reality, but I fear that if anyone heeds any of what I said and starts making PRs, their PRs will just rot in the PR queue waiting for a review.  Finding minuscule problems with a PR is easy, being able to say "yes, this is the right fix" is hard...very hard, and comes with consequences if you're wrong. Unfortunately, those with the expertise to certify difficult PRs tend to be very part-time reviewers, and sorry, I'm not one of them.

There are a few characteristics of a PR that will increase likelihood of review:
  * Has tests and passes the test suite
  * Is noncontroversial
  * Benefit is obvious (i.e. Fixes a bug, especially a regression, and is not an enhancement).  This is preventing me from certifying Rikki's PR.
  * Has clear explanation of the problem and the fix so anyone can understand it.  Not everyone has an intimate understanding of the problem like you, help them out.  This is what is preventing me from reviewing and certifying Steven's and Rikki's PRs.
  * It's simple.  The fewer lines of change, the better.

There are few characteristics of a PR that will decrease likelihood of a review:
  * No tests and/or test suite shows a red X
  * Is controversial or benefit is not obvious
  * Reviewer has to spend a lot of time studying the code to figure out why and what
  * Has a lot of refactoring changes that aren't needed for the actual fix

I was thinking about making a set of videos about how to get started contributing to the compiler, but I decided it wouldn't be a good idea until we can do something about our PR bottleneck; it'd probably just fill the PR queue making matters worse.

Anyway, that's my two-cents.  Take everything I've said with a grain of salt (as they say); I'm often wrong.

Mike