January 26, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to CraigDillabaugh | On 01/26/2016 01:45 PM, CraigDillabaugh wrote:
> I would like to get confirmation from each of you if you can mentor this
> year (and if your name is attached to a project, can that still be a go).
Affirmative. -- Andrei
|
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to CraigDillabaugh Attachments:
| On Tue, 2016-01-26 at 18:45 +0000, CraigDillabaugh via Digitalmars-d wrote: > […] > > I would like to get confirmation from each of you if you can > mentor this year (and if your name is attached to a project, can > that still be a go). If I don't have confirmation I will have to I believe I will be able to. I haven't been able to check the projects and propose new ones, sorry. Mayhap at the end of next week. Sorry for the delay… things. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | On Thursday, 31 December 2015 at 23:58:32 UTC, Craig Dillabaugh wrote: > The deadline for the Google Summer of Code, 2016 is February 19th. Which means we have about a month and a half to put something together. For the time being I've recycled last years projects (with one dropped so far): > > http://wiki.dlang.org/GSOC_2016_Ideas#Ideas > clip > > http://wiki.dlang.org/GSOC_mentors > We have had another student inquiry on the GSOC front. I am going from memory, which is always a bit sketchy, but it seems that there is a bit of an increase in student interest this year. Would there be any interest in a project to automate binding generation from C files (or perhaps even a full conversion tool)? This could be done either as a new project, or possibly building on dstep - if there is meaningful work that can still be done to improve that project. Alternately, the student suggested using pycparser (https://github.com/eliben/pycparse) as the basis for such a tool? Jacob, are you sure you don't want to Mentor? It seems like you are involved in all the interesting projects from a student perspective :o) Is there work that can be done to improve dstep? |
January 29, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | On 29/01/16 2:53 AM, Craig Dillabaugh wrote: > On Thursday, 31 December 2015 at 23:58:32 UTC, Craig Dillabaugh wrote: >> The deadline for the Google Summer of Code, 2016 is February 19th. >> Which means we have about a month and a half to put something >> together. For the time being I've recycled last years projects (with >> one dropped so far): >> >> http://wiki.dlang.org/GSOC_2016_Ideas#Ideas >> > clip >> >> http://wiki.dlang.org/GSOC_mentors >> > > We have had another student inquiry on the GSOC front. I am going from > memory, which is always a bit sketchy, but it seems that there is a bit > of an increase in student interest this year. > > Would there be any interest in a project to automate binding generation > from C files (or perhaps even a full conversion tool)? This could be > done either as a new project, or possibly building on dstep - if there > is meaningful work that can still be done to improve that project. > Alternately, the student suggested using pycparser > (https://github.com/eliben/pycparse) as the basis for such a tool? > > Jacob, are you sure you don't want to Mentor? It seems like you are > involved in all the interesting projects from a student perspective :o) > > Is there work that can be done to improve dstep? I have a c phase 1-3 implemented in D. I would be willing to give up the source if I keep the rights (but code can be open just not an open source license). Could be used to fully translate c code to D without too much work I would think. http://en.cppreference.com/w/c/language/translation_phases |
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | On Thursday, 28 January 2016 at 13:53:30 UTC, Craig Dillabaugh wrote:
> Would there be any interest in a project to automate binding generation from C files (or perhaps even a full conversion tool)?
> This could be done either as a new project, or possibly building on dstep - if there is meaningful work that can still be done to improve that project. Alternately, the student suggested using pycparser (https://github.com/eliben/pycparse) as the basis for such a tool?
I think it is very important to focus on polishing dstep instead of creating more and more imperfect tools. In the end any approach which doesn't use existing mature C compiler frontend is doomed to make binding mistakes.
Random suggestions for improving dstep:
- implement support for C++ clang API using new shiny dmd features (it tends to have more features than C one)
- implement automatic generation of idiomatic D code for raw bindings (i.e. stripping redundant namespace prefixes)
- remove/minimize dependencies apart from Phobos/libclang (will make much easier including it into standard tools)
|
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Thursday, 28 January 2016 at 15:20:12 UTC, Dicebot wrote: > On Thursday, 28 January 2016 at 13:53:30 UTC, Craig Dillabaugh wrote: >> Would there be any interest in a project to automate binding generation from C files (or perhaps even a full conversion tool)? >> This could be done either as a new project, or possibly building on dstep - if there is meaningful work that can still be done to improve that project. Alternately, the student suggested using pycparser (https://github.com/eliben/pycparse) as the basis for such a tool? > > I think it is very important to focus on polishing dstep instead of creating more and more imperfect tools. In the end any approach which doesn't use existing mature C compiler frontend is doomed to make binding mistakes. > > Random suggestions for improving dstep: > - implement support for C++ clang API using new shiny dmd features (it tends to have more features than C one) > - implement automatic generation of idiomatic D code for raw bindings (i.e. stripping redundant namespace prefixes) > - remove/minimize dependencies apart from Phobos/libclang (will make much easier including it into standard tools) Seems like there should be enough there for a project. Also looking at: https://github.com/jacob-carlborg/dstep in the list of limitations is, 'Doesn't translate preprocessor macros of any kind", that seems like a good challenge. So if Jacob can't mentor this, is there anyone who would be comfortable with that type of project? |
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | On Thursday, 28 January 2016 at 17:15:17 UTC, Craig Dillabaugh wrote: > Seems like there should be enough there for a project. Also looking at: > > https://github.com/jacob-carlborg/dstep > > in the list of limitations is, 'Doesn't translate preprocessor macros of any kind", that seems like a good challenge. AFAIK this is blocked on having C++ API bindings because preprocessor isn't exposed to plain C ones (this is exactly why I have mentioned it in list). > So if Jacob can't mentor this, is there anyone who would be comfortable with that type of project? I may volunteer but need to check my availability and mentor duties :) Will respond shortly. But of course it should be Jacob. |
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | On 2016-01-28 14:53, Craig Dillabaugh wrote: > Jacob, are you sure you don't want to Mentor? It seems like you are > involved in all the interesting projects from a student perspective :o) I can absolutely help out with all of my projects and projects I'm involved in. But I have no interested in being an official mentor. -- /Jacob Carlborg |
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 2016-01-28 16:20, Dicebot wrote: > I think it is very important to focus on polishing dstep instead of > creating more and more imperfect tools. In the end any approach which > doesn't use existing mature C compiler frontend is doomed to make > binding mistakes. > > Random suggestions for improving dstep: > - implement support for C++ clang API using new shiny dmd features (it > tends to have more features than C one) I would like to avoid this until there's absolutely no other way to do it. A couple of other ideas: * Getting the D code more looking like the C code. For example, the same order for the symbols as the C code has. Currently it outputs all variables first, then all types and all functions last * Add support for comments * Generated libclang bindings. These are now manually created, mostly for the above two reasons. Ideally it would be possible to generate bindings almost exactly like the manually created ones [1] [1] https://github.com/jacob-carlborg/dstep/blob/master/clang/c/Index.d -- /Jacob Carlborg |
January 28, 2016 Re: Google Summer of Code 2016 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 2016-01-28 18:19, Dicebot wrote: > AFAIK this is blocked on having C++ API bindings because preprocessor > isn't exposed to plain C ones (this is exactly why I have mentioned it > in list). I would first try the translation unit option "CXTranslationUnit_DetailedPreprocessingRecord". The documentation says: "Used to indicate that the parser should construct a "detailed" preprocessing record, including all macro definitions and instantiations" If that doesn't work I would prefer improving the C bindings to add functionality for working with the preprocessor. But perhaps no one is interested in doing that. One huge advantage is that C API for libclang is a stable API. -- /Jacob Carlborg |
Copyright © 1999-2021 by the D Language Foundation