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

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

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?

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

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)

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?

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.

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

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

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