www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - GSoC 2018 - Your project ideas

reply Seb <seb wilzba.ch> writes:
Hi all,

Google Summer of Code (GSoC) 2018 is about to start soon [1] (the 
application period for organizations is in January 2018).
Hence, I would very happy about any project ideas you have or 
projects which are important to you.
And, of course, if you would be willing to mentor a student, 
please don't forget to tell me.
You can always reach me via mail (seb [at] wilzba [dot] ch) or on 
Slack (dlang.slack.com). There's also a special #gsoc channel.

I have also started to work over the ideas from last year [2], 
but this page is currently WIP.

 Students: if you have any questions or maybe have an idea for a 
project yourself, please feel free to contact me. I'm more than 
happy to help!

I am looking forward to hearing (1) what you think can be done in 
three months by a student and (2) will have a huge impact on the 
D ecosystem.

Cheers,

Seb

[1] https://developers.google.com/open-source/gsoc/timeline
[2] https://wiki.dlang.org/GSOC_2018_Ideas
Dec 05 2017
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 I am looking forward to hearing (1) what you think can be done 
 in three months by a student and (2) will have a huge impact on 
 the D ecosystem.

 [2] https://wiki.dlang.org/GSOC_2018_Ideas


I see there is a dub section in [2]. Maybe another issue that has 
been brought up repeatedly fits in that category, namely 
extending code.dlang.org in various ways?
Dec 07 2017
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 7 December 2017 at 22:26:08 UTC, Bastiaan Veelo 
wrote:

 I see there is a dub section in [2]. Maybe another issue that 
 has been brought up repeatedly fits in that category, namely 
 extending code.dlang.org in various ways?


I had thought I had followed one of the links somewhere and it 
mentioned it, but it probably should be listed on that GSOC page.

It might be worthwhile to add some more structure to this page. 
Right now the outline is grouped broadly by project. It might be 
a little clearer to group the different projects by category 
(e.g. compiler, phobos [already there], tooling, library).

Also, it might be useful to add some information on expected 
difficulty or time intensiveness. I recall from the last time 
some of the students maybe bit off more than they could chew 
(i.e., there's no reason taking std.experimental.xml to the 
finish line or work on a precise garbage collector couldn't be 
GSOC projects for 2018). For instance, I imagine improvements to 
code.dlang.org require less knowledge than Lowerer.

Something I would add:
Jupyter kernel (could depend on either d-repl or dabble, not sure 
which is better)
Dec 07 2017
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Thursday, 7 December 2017 at 22:26:08 UTC, Bastiaan Veelo 
wrote:

 On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 I am looking forward to hearing (1) what you think can be done 
 in three months by a student and (2) will have a huge impact 
 on the D ecosystem.

 [2] https://wiki.dlang.org/GSOC_2018_Ideas


 I see there is a dub section in [2]. Maybe another issue that 
 has been brought up repeatedly fits in that category, namely 
 extending code.dlang.org in various ways?


+1111

Indeed enhancing user experience of code.dlang.org such as 
showing github stars and e.g. downloads per month would be way 
more important then build tool itself.
Dec 07 2017
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Friday, 8 December 2017 at 06:43:22 UTC, Dmitry Olshansky 
wrote:

 On Thursday, 7 December 2017 at 22:26:08 UTC, Bastiaan Veelo 
 wrote:

 On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 I am looking forward to hearing (1) what you think can be 
 done in three months by a student and (2) will have a huge 
 impact on the D ecosystem.

 [2] https://wiki.dlang.org/GSOC_2018_Ideas


 I see there is a dub section in [2]. Maybe another issue that 
 has been brought up repeatedly fits in that category, namely 
 extending code.dlang.org in various ways?


 +1111

 Indeed enhancing user experience of code.dlang.org such as 
 showing github stars and e.g. downloads per month would be way 
 more important then build tool itself.


+10^^4

I recommend to add a "donate for button", and to evaluate and 
visualize how many people are donating, for a certain package. 
This might give strong evidence where to invest more time - man 
power.
In the first step the D Foundation should get all money and 
should try to use it to support the most often selected packages, 
to avoid loosing focus.
Dec 11 2017
next sibling parent rjframe <dlang ryanjframe.com> writes:
On Mon, 11 Dec 2017 09:14:29 +0000, Martin Tschierschke wrote:


 I recommend to add a "donate for button", and to evaluate and visualize
 how many people are donating, for a certain package. This might give
 strong evidence where to invest more time - man power.
 In the first step the D Foundation should get all money and should try
 to use it to support the most often selected packages,
 to avoid loosing focus.


If something looks like donating money is going to support the development 
of a project, then any many received needs to actually support that 
project. A home page with a "support the D Foundation" link is fine; the 
foundation receiving the money from a donate button on vibe-d's project 
page is not, unless the vibe-d maintainer(s) make that decision.
Dec 11 2017
prev sibling parent Craig Dillabaugh <craig.dillabaugh gmail.com> writes:
On Monday, 11 December 2017 at 09:14:29 UTC, Martin Tschierschke 
wrote:

 On Friday, 8 December 2017 at 06:43:22 UTC, Dmitry Olshansky 
 wrote:

 On Thursday, 7 December 2017 at 22:26:08 UTC, Bastiaan Veelo 
 wrote:

 On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 I am looking forward to hearing (1) what you think can be 
 done in three months by a student and (2) will have a huge 
 impact on the D ecosystem.

 [2] https://wiki.dlang.org/GSOC_2018_Ideas


 I see there is a dub section in [2]. Maybe another issue that 
 has been brought up repeatedly fits in that category, namely 
 extending code.dlang.org in various ways?


 +1111

 Indeed enhancing user experience of code.dlang.org such as 
 showing github stars and e.g. downloads per month would be way 
 more important then build tool itself.


 +10^^4

 I recommend to add a "donate for button", and to evaluate and 
 visualize how many people are donating, for a certain package. 
 This might give strong evidence where to invest more time - man 
 power.
 In the first step the D Foundation should get all money and 
 should try to use it to support the most often selected 
 packages, to avoid loosing focus.


Martin, I am replying to your post specifically, but this reply 
is targeted at the 'code.dlang.org' discussion in general.

Improvements to code.dlang.org are going to be borderline 
ineligible for a GSoC project.  Any such project would have to be 
carefully crafted so that it is a development project and not a 
website maintenance/upgrading project. In any case this work can 
likely be made into something valid, but the project would need 
involve a cohesive development effort and not a series of minor 
improvements (even if they mostly involved coding).
Dec 11 2017
prev sibling next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 12/5/17 10:20, Seb wrote:

 Hi all,

 Google Summer of Code (GSoC) 2018 is about to start soon [1] (the
 application period for organizations is in January 2018).
 Hence, I would very happy about any project ideas you have or projects
 which are important to you.
 And, of course, if you would be willing to mentor a student, please
 don't forget to tell me.
 You can always reach me via mail (seb [at] wilzba [dot] ch) or on Slack
 (dlang.slack.com). There's also a special #gsoc channel.

 I have also started to work over the ideas from last year [2], but this
 page is currently WIP.

  Students: if you have any questions or maybe have an idea for a project
 yourself, please feel free to contact me. I'm more than happy to help!

 I am looking forward to hearing (1) what you think can be done in three
 months by a student and (2) will have a huge impact on the D ecosystem.

 Cheers,

 Seb

 [1] https://developers.google.com/open-source/gsoc/timeline
 [2] https://wiki.dlang.org/GSOC_2018_Ideas


I am absolutely up for mentoring this year and there are some fantastic 
projects on this list. The ones I'd be willing to mentor are:

std.database - I've done a significant amount of work on this (not on 
github yet). And I have almost two decades of experience with various 
SQL interface libraries. I've seen the good, the bad, and the ugly, and 
would be able to work very closely with the student. :)

std.eventloop - This will be needed if I am ever going to get 
Async/Await off the ground.

std.decimal - I need this for some personal projects.

Garbage Collector - It's not on the list but somebody mentioned it. 
There are actually two PR's outstanding for a precise GC from the 2016 
GSoC I mentored; here: https://github.com/dlang/druntime/pull/1603 and 
here: https://github.com/dlang/druntime/pull/1977. But there is still a 
ton of room for improvement. There are more areas that precision could 
be expanded too. The 2016 student started playing around with a 
type-based pooling collector. There are a number of ideas we could 
explore. Note that I'm not a big fan of the fork()-based GC idea since 
it's limited to *nix based systems

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
Dec 07 2017
parent Jeremy DeHaan <dehaan.jeremiah gmail.com> writes:
On Friday, 8 December 2017 at 00:28:11 UTC, Adam Wilson wrote:

 The 2016 student started playing around with a type-based 
 pooling collector.


I actually ran with this idea and wrote a garbage collector from 
scratch for an independent study at my university. I haven't made 
much noise about it since I didn't have time to get it to pass 
all tests, but it had performance about on par with the current 
GC and it has a precise heap like in the open PR's.

I'm going to continue working on it in the spring, so who knows 
what'll happen? I would submit a proposal to continue working on 
it during the summer, but I don't think I can participate in 
another GSoC (I graduate as the summer starts).
Dec 09 2017
prev sibling next sibling parent reply Mengu <mengukagan gmail.com> writes:
On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 Hi all,

 Google Summer of Code (GSoC) 2018 is about to start soon [1] 
 (the application period for organizations is in January 2018).
 Hence, I would very happy about any project ideas you have or 
 projects which are important to you.
 And, of course, if you would be willing to mentor a student, 
 please don't forget to tell me.
 You can always reach me via mail (seb [at] wilzba [dot] ch) or 
 on Slack (dlang.slack.com). There's also a special #gsoc 
 channel.

 [...]


do i have to be an actual student in order to participate?
Dec 10 2017
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 10 December 2017 at 13:01:43 UTC, Mengu wrote:

 On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 Hi all,

 Google Summer of Code (GSoC) 2018 is about to start soon [1] 
 (the application period for organizations is in January 2018).
 Hence, I would very happy about any project ideas you have or 
 projects which are important to you.
 And, of course, if you would be willing to mentor a student, 
 please don't forget to tell me.
 You can always reach me via mail (seb [at] wilzba [dot] ch) or 
 on Slack (dlang.slack.com). There's also a special #gsoc 
 channel.

 [...]


 do i have to be an actual student in order to participate?


I redirect your question to Google's official FAQ: 
https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility_requirements_for_participation

I hope this answers your question.
Dec 10 2017
parent Mengu <mengukagan gmail.com> writes:
On Sunday, 10 December 2017 at 19:04:54 UTC, Seb wrote:

 On Sunday, 10 December 2017 at 13:01:43 UTC, Mengu wrote:

 On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 [...]


 do i have to be an actual student in order to participate?


 I redirect your question to Google's official FAQ: 
 https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility_requirements_for_participation

 I hope this answers your question.


indeed it did, thanks.
Dec 10 2017
prev sibling next sibling parent roman <rto aol.com> writes:
On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 Hi all,

 Google Summer of Code (GSoC) 2018 is about to start soon [1] 
 (the application period for organizations is in January 2018).
 Hence, I would very happy about any project ideas you have or 
 projects which are important to you.
 And, of course, if you would be willing to mentor a student, 
 please don't forget to tell me.
 You can always reach me via mail (seb [at] wilzba [dot] ch) or 
 on Slack (dlang.slack.com). There's also a special #gsoc 
 channel.

 [...]


working, unrestricted DLL's for windows
Dec 10 2017
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 Hi all,

 Google Summer of Code (GSoC) 2018 is about to start soon [1] 
 [...]
 I am looking forward to hearing (1) what you think can be done 
 in three months by a student and (2) will have a huge impact on 
 the D ecosystem.

 Cheers,

 Seb

 [1] https://developers.google.com/open-source/gsoc/timeline
 [2] https://wiki.dlang.org/GSOC_2018_Ideas


My two cents:



1. I think that this project is too abstract, there's no concrete 
application.
2. Issue 5051 is mentioned but i think that many features listed 
in this project are actually **already** done when the switch 
"-vcg-ast" is used (scope lowering(), foreach() lowering, ...)



- std.units: no there are user libs for that, particularly one by 
klickverbot and one of its fork that is more maintained IIRC.
- std.serialization: yes, this is the idea i like the more, 
although we can regret that std.xml2 would have been good to be 
there as supported file format.
- std.container: skeptical, changes are announced for the 
allocators, Big(O) notation was planned in another container 
project that should have been made by Alexandrescu (although this 
was announced something like 2 years ago already).
- std.decimal: I've seen that J.Stouffler has just started an 
stdx project for this.



There are good ideas. A proper plan is needed.



I think it's a bad idea.

1. because of the 3 months. Would it be usable despite of being 
an interesting for the student ?
2. what will it do better than GDB ?
3. I.Buclaw is the official maintainer for the D support in GDB, 
so why not doing something in GDB instead (yeah but what... )


So in short, i see only two good projects:
- std.serializer
- DUB

The others, excepted those i find useless or unrealistic or 
existing, are just "meh", but it's a personal point of view. It's 
a problem of balance: it must be interesting and motivating for 
the student but also useful for the community.
Dec 11 2017
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 11 December 2017 at 21:15, Basile B. via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:



 I think it's a bad idea.

 1. because of the 3 months. Would it be usable despite of being an
 interesting for the student ?
 2. what will it do better than GDB ?
 3. I.Buclaw is the official maintainer for the D support in GDB, so why not
 doing something in GDB instead (yeah but what... )


There are still things that GDB supports, but DMD doesn't generate
proper debug info in order to leverage it.
Dec 11 2017
prev sibling parent reply bpr <brogoff gmail.com> writes:
On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:

 I am looking forward to hearing (1) what you think can be done 
 in three months by a student and (2) will have a huge impact on 
 the D ecosystem.


Of the projects in [2], I like the general purpose betterC 
libraries most, and I think it's something where students could 
make a real impact in that time period.


 [1] https://developers.google.com/open-source/gsoc/timeline
 [2] https://wiki.dlang.org/GSOC_2018_Ideas
Dec 13 2017
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Dec 13, 2017 at 07:50:44PM +0000, bpr via Digitalmars-d-announce wrote:

 On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:


[...]

 Of the projects in [2], I like the general purpose betterC libraries
 most, and I think it's something where students could make a real
 impact in that time period.


[...]

 [2] https://wiki.dlang.org/GSOC_2018_Ideas




The "Who's (using) who?" project can use my symbol dependency tool as a
starting point:

	https://github.com/quickfur/symdep

Basically, as it stands, it can extract the list of symbols from the
program, and which symbol references which other symbols, where "A
references B" means the disassembled code between A and the next symbol
in the executable contains a reference to an address somewhere between B
and the next symbol after B.  This is done by inspecting the output of
the `objdump` tool.  A list of dependencies can be produced in either
text format or in GraphViz .dot format, which can be passed to graphviz
or neato to produce a graphical chart of symbol dependencies.

As of now, the following are possible points of improvement:

- Make it work on Windows and other OSes that don't have the `objdump`
  utility;

- Add better capability to limit the output to a subgraph of the full
  graph. Because of the huge number of symbols in a typical D program,
  outputting the entire dependency graph will produce a graph far too
  large to be easily understood.

  Currently, symdep has the capability of restricting the output to the
  subgraph of symbols reachable from a certain given symbol (useful for
  answering "what does function foo call?"), or the subgraph of symbols
  NOT reachable from a certain given symbol (e.g., "what are the symbols
  that aren't reachable from _Dmain?").  However, in medium-to-large D
  programs, the resulting subgraph is still far too large to be useful,
  so a better way of selecting a subgraph would be nice.  Perhaps
  implementing a maximum recursion level to the existing subgraph
  functions might be a good start, i.e., "what are the symbols
  referenced by _Dmain up to 3 levels down the call chain / reference
  graph?".

- Better accuracy for dependency detection. Currently, it may not
  produce the most accurate results because if there are private /
  static symbols in a module that don't export a public symbol in the
  executable, symdep won't know if a reference is actually to that
  private symbol, and will blindly assume that it's actually referencing
  the closest public symbol that comes before the private symbol in the
  executable.  This makes the output graph inaccurate.

  Also, some references that go through indirection may not be detected
  correctly, e.g., if function F calls function G via a function pointer
  table or thunk. (I think the function table case should still work, as
  long as the function table itself has a public symbol; it will just
  show up in the output as F -> tableSym -> G. But this has not been
  rigorously tested.)

- Currently, symdep does not distinguish between code symbols and data
  symbols.  For its stated purpose (i.e., find unexpected dependencies
  to Phobos modules that seemingly aren't used), this is not necessarily
  a bad thing. But being able to tell the difference helps to make the
  output more readable, e.g., use different node shapes for code vs.
  data symbols; it also allows subgraph queries to be restricted to a
  particular node type (show me the call graph vs. show me the data
  dependency graph), etc..


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada
Dec 13 2017