www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ideas for students' summer projects

reply Eduard Staniloiu <edi33416 gmail.com> writes:
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!
May 22 2018
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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!


GSOC ideas would obviously be a good place to start.
https://wiki.dlang.org/GSOC_2018_Ideas
May 22 2018
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/22/18 1:39 PM, jmh530 wrote:

 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!


 
 GSOC ideas would obviously be a good place to start.
 https://wiki.dlang.org/GSOC_2018_Ideas


We're looking at those, plus any fresh ideas.
May 22 2018
prev sibling next sibling parent Gheorghe Gabriel <knoppy273 live.com> writes:
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


Awsome! Come to Titu Maiorescu University too. Here, we love D, 
some of us at least. :)
May 22 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


 Let the brainstorming begin!


I would like to see a dependency-less Phobos-like library that 
can be used by the DMD compiler, druntime, -betterC, and other 
runtime-less/phobos-less use cases.  It would have no 
dependencies whatsoever.

There's a lot of useful stuff in Phobos that does not need to be 
dependent on other Phobos modules or Druntime.  std.meta is the 
first that likely comes to mind, but then there's also traits, 
typecons, demangle, etc..

As a contrived illustration, take a look at the code in 
https://github.com/dlang/druntime/blob/master/src/core/internal/string.d  Those
same features are also in Phobos.

Such a library would make more D idioms available to the 
compilers, druntime, and those that are programming runtime-less 
applications like bare-metal, operating systems, 
microcontrollers, or libraries used from other languages.

I already started a project at https://github.com/JinShil/utiliD 
just a few days ago.  It'd be great is someone else could do the 
work instead :-)

Mike
May 22 2018
next sibling parent Meta <jared771 gmail.com> writes:
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.
May 23 2018
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 23 May 2018 at 01:33:19 UTC, Mike Franklin wrote:

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


 Let the brainstorming begin!


 I would like to see a dependency-less Phobos-like library that 
 can be used by the DMD compiler, druntime, -betterC, and other 
 runtime-less/phobos-less use cases.  It would have no 
 dependencies whatsoever.


 As a contrived illustration, take a look at the code in 
 https://github.com/dlang/druntime/blob/master/src/core/internal/string.d 
Those same features are also in Phobos.


OT, numberDigits enters an infinite loop if radix == 1.
May 24 2018
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 24 May 2018 at 18:07:53 UTC, Patrick Schluter wrote:

 On Wednesday, 23 May 2018 at 01:33:19 UTC, Mike Franklin wrote:

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


 Let the brainstorming begin!


 I would like to see a dependency-less Phobos-like library that 
 can be used by the DMD compiler, druntime, -betterC, and other 
 runtime-less/phobos-less use cases.  It would have no 
 dependencies whatsoever.


 As a contrived illustration, take a look at the code in 
 https://github.com/dlang/druntime/blob/master/src/core/internal/string.d 
Those same features are also in Phobos.


 OT, numberDigits enters an infinite loop if radix == 1.


and crashes for radix == 0
May 24 2018
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 24 May 2018 at 18:08:35 UTC, Patrick Schluter wrote:


 As a contrived illustration, take a look at the code in 
 https://github.com/dlang/druntime/blob/master/src/core/internal/string.d 
Those same features are also in Phobos.


 OT, numberDigits enters an infinite loop if radix == 1.


 and crashes for radix == 0


All the more reason to implement my proposal.
May 24 2018
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/24/18 2:21 PM, Mike Franklin wrote:

 On Thursday, 24 May 2018 at 18:08:35 UTC, Patrick Schluter wrote:
 

 As a contrived illustration, take a look at the code in 
 https://github.com/dlang/druntime/blob/master/src/core/internal/string.d  
 Those same features are also in Phobos.


 OT, numberDigits enters an infinite loop if radix == 1.


 and crashes for radix == 0


 
 All the more reason to implement my proposal.


Why? they are just bugs.

https://github.com/dlang/druntime/pull/2192

-Steve
May 24 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


 Let the brainstorming begin!


It might be useful for measuring D's progress if we had some kind 
of stats about D updated on a daily basis.

This is the most useful page I know of at the moment:  
https://auto-tester.puremagic.com/chart.ghtml?projectid=1

Some stats that would be nice to see:
   * Pull Requests per hour/day/week/month/year
   * PR reviews per hour/day/week/month/year
   * Stats about website (basically the kind of stuff you'd get 
from google analytics dashboard)
   * Number of D repositories on Github/Bitbucket/whatever
   * Number of contributions to D repositories per 
hour/day/week/month/year

Those are just things that popped into my head while writing this 
post.  I'm sure someone invested in such a project could come up 
with more useful stats.

We just want some data to measure progress (or lack thereof) so 
we can inform where to allocate resources.

Mike
May 22 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


 Let the brainstorming begin!


Make WebAssembly a thing in D.

See 
https://forum.dlang.org/post/ejplfelcqsvjmdvxtsnq forum.dlang.org

Currently C++ and Rust dominate that domain.  D could kick some 
web asm there too.

Mike
May 22 2018
next sibling parent Jonathan <JonathanILevi gmail.com> writes:
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 (:
May 22 2018
prev sibling parent reply meppl <mephisto nordhoff-online.de> writes:
On Wednesday, 23 May 2018 at 01:51:35 UTC, Mike Franklin wrote:

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


 Let the brainstorming begin!


 Make WebAssembly a thing in D.

 See 
 https://forum.dlang.org/post/ejplfelcqsvjmdvxtsnq forum.dlang.org

 Currently C++ and Rust dominate that domain.  D could kick some 
 web asm there too.

 Mike


I am curious about binary size of microservies on webpages. 
D-binaries tend to be bigger and the D garbage collector needs to 
be within them. Then we would have to rely on LLVM drastically 
reducing the binary size of static compiled apps.

If we say "its only for betterc" or "its only for bigger webapps 
and nodejs-webassembly", it would be half assed - and in my 
humble opinion too much of a disadvantage compared to rust. I 
might be wrong of course
May 25 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 26/05/2018 2:13 AM, meppl wrote:

 On Wednesday, 23 May 2018 at 01:51:35 UTC, Mike Franklin wrote:

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


 Let the brainstorming begin!


 Make WebAssembly a thing in D.

 See https://forum.dlang.org/post/ejplfelcqsvjmdvxtsnq forum.dlang.org

 Currently C++ and Rust dominate that domain.  D could kick some web 
 asm there too.

 Mike


 
 I am curious about binary size of microservies on webpages. D-binaries 
 tend to be bigger and the D garbage collector needs to be within them. 
 Then we would have to rely on LLVM drastically reducing the binary size 
 of static compiled apps.
 
 If we say "its only for betterc" or "its only for bigger webapps and 
 nodejs-webassembly", it would be half assed - and in my humble opinion 
 too much of a disadvantage compared to rust. I might be wrong of course


Until web assembly's GC interface and TLS is designed, -betterC would be 
the correct solution for us going forward.
May 25 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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.

Mike
May 22 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 23/05/2018 2: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.
 
 Mike


That requires hiring somebody full time, I don't think that should be 
taken lightly (not that I disagree with the idea of it).
May 22 2018
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
May 23 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
May 23 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
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
May 23 2018
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 23 May 2018 at 14:25:44 UTC, Steven Schveighoffer 
wrote:


 How do I know I'm in a function?


I don't think you're ever actually "in a function". The code is 
just data passing through the compiler.  I think what your may be 
asking is "How do I know I'm working on a function?". That 
depends on what stage in the the code->binary translation process 
your at (parsing, semantic, {not sure about others}).  Usually 
this is done with a `visit(` method.  grep for 
`visit(FuncDeclaration` or `visit(FuncExp`.  You may be deep in 
the body of a function, processing some other expression, though. 
  For that, you'll want to turn on the logging features in DMD 
when you do a build so you can see output each time an expression 
is visited; grep for `LOGSEMANTIC`.



 How do I know I'm in a template?


Same principle as above.  grep for `visit(TemplateInstance` or 
`visit(TemplateDeclaration`.


 What module am I in?


grep `visit(Module`, maybe?

I think for all of my answers above, you can also navigate up the 
AST using the `.parent` property of a symbol; see the 
dmd.dsymbol.Dsybmol class.


 How do I know what has been run?


I'd say by turning on logging in the various source files.


 What is the proper way to generate lowered code?


You're basically writing D code with D code.  The `Expression` 
class and it's derived classes are where its at.  See my failed 
attempt at lowering array literals to template here:  
https://github.com/dlang/dmd/pull/8245/files

Also my Binary Assignment Operators PR is an exemplary exercise 
in lowering:  https://github.com/dlang/dmd/pull/7079/files

Hope that helps at least a little.  It'll probably just generate 
more questions, but keep them coming.

Mike
May 23 2018
parent reply Jacob Carlborg <doob me.com> writes:
On Thursday, 24 May 2018 at 02:07:28 UTC, Mike Franklin wrote:


 Hope that helps at least a little.  It'll probably just 
 generate more questions, but keep them coming.


This is all great, but nobody is going to be able to find the 
answers here in the forum. I recommend a Markdown document in the 
"docs" directory in the DMD project [1] and a link in the readme 
to that document.

[1] https://github.com/dlang/dmd/tree/master/docs

--
/Jacob Carlborg
May 24 2018
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/24/18 5:13 AM, Jacob Carlborg wrote:

 On Thursday, 24 May 2018 at 02:07:28 UTC, Mike Franklin wrote:
 

 Hope that helps at least a little.  It'll probably just generate more 
 questions, but keep them coming.


 
 This is all great, but nobody is going to be able to find the answers 
 here in the forum. I recommend a Markdown document in the "docs" 
 directory in the DMD project [1] and a link in the readme to that document.
 
 [1] https://github.com/dlang/dmd/tree/master/docs


Honestly, we need this somewhere on the web site, like in a nice 
tutorial/FAQ. Even stuffing it in the wiki is going to get lost, it 
should really be linked from the front page.

I think we should have contribution guides for Phobos, Druntime, and DMD 
all right on the front page.

-Steve
May 24 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote:


 Let the brainstorming begin!


Get some help allocated to GDC.

It seems progress on GDC has stalled for reasons I'm not quite 
sure of.  I'm trying to help, but it's becoming more apparent 
that I'm not the right person for the job.  Getting GDC up to 
date as much as possible with DMD's frontend and getting GDC 
merged into the next GCC release would be a boon for D.  Is there 
something we can do to move that along?

Mike
May 22 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 23 May 2018 at 02:38:17 UTC, Mike Franklin wrote:

 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


I am still working on newCTFE, creating a fork would needlessly 
duplicate effort.
And is most likely very wasteful, consider that I have much more 
experience with the code.

I feel offended by the notion that newCTFE is stagnating.
Jun 21 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
parent Mike Franklin <slavo5150 yahoo.com> writes:
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-entwic
lung-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
May 23 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 23 May 2018 at 03:56:32 UTC, Mike Franklin wrote:

 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


Yep, `test/run.d` is a first step in this direction and apart 
from the few shell tests, it should allow running the DMD 
testsuite without the prior hassles. Though for the shell tests, 
just using the shell shipped with the Windows version of Git is 
enough.

I just gave converting the DMD Make build script to D a quick 
shot and it doesn't look too complicated:

https://github.com/dlang/dmd/pull/8293
May 25 2018
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 25 May 2018 at 12:23:35 UTC, Seb wrote:


 I just gave converting the DMD Make build script to D a quick 
 shot and it doesn't look too complicated:


Very Nice!  Many thumbs up!  And, welcome back!

Mike
May 25 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
next sibling parent reply 12345swordy <12345swordy 12345swordy.com> writes:
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.
May 22 2018
parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
May 23 2018
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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).
May 22 2018
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
May 22 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
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
May 22 2018
prev sibling parent Andrea Fontana <nospam example.com> writes:
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
May 23 2018