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: ## Lowerer 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, ...) ## Phobos: D Standard Library - 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. ## DUB There are good ideas. A proper plan is needed. ## Linux debugger 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:
 ## Linux debugger

 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