On Thursday, 28 January 2016 at 21:07:58 UTC, Jacob Carlborg wrote:
> * 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

Could be cool project to make dstep compilable with clang bindings converted with dstep - and run tests with both.

On Thu, 2016-01-28 at 22:01 +0100, Jacob Carlborg via Digitalmars-d wrote:
> 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.

Given I have an interest in making DStep better (so as to wrap the Linux DVB API and libdvbv5) and Jacob is not wanting to be formal mentor, and yet can support, I can offer myself as mentor so as to try and ensure the project moves.

-- 
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, 28 January 2016 at 22:26:44 UTC, Russel Winder wrote:
> On Thu, 2016-01-28 at 22:01 +0100, Jacob Carlborg via Digitalmars-d wrote:
>> 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.
>
> Given I have an interest in making DStep better (so as to wrap the Linux DVB API and libdvbv5) and Jacob is not wanting to be formal mentor, and yet can support, I can offer myself as mentor so as to try and ensure the project moves.

Thanks Russel, Jacob, and Dicebot for your suggestions. I will add DStep to our list of projects with Russel as Mentor.

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'm not sure what you have in mind but handling something like #if seems very complicated. Example:

#if __APPLE__
// some declarations
#elif linux
// some declarations
#endif

The problems I see with the above:

1. It's not possible to enable/disable these preprocessor symbols. For example enabling both

2. If the above would be possible the compiler would need to have access to the SDK of the other platform. Is this what cross-compilers do?

3. Even if the above two points work the compiler would still need to choose one of the two paths. I guess it would need to at least lex the other path. But just lexing the other path would not need to be enough. It need to parse and to the semantic analysis as well to be useful

Just thinking about this brings up new problems and gives me a headache :)

-- 
/Jacob Carlborg

On Friday, 15 January 2016 at 03:33:23 UTC, Andrei Alexandrescu wrote:
> On 01/14/2016 01:56 PM, Craig Dillabaugh wrote:
>> Deadline is getting closer, any new project ideas are welcome. Starting
>> to get some contact from students now.
>
> A few quick ideas:
>
> * Bringing a parser generator library into phobos, either based on pegged or independent
>
> * SQL parser, binder, validator
>
> * Improving the GC
>
> clip
>
> Andrei

I wanted to follow up on a few of Andrei's ideas.

Is there any work ongoing on the GC, I know there has been lots of talk from time to time, but are there any concrete efforts out there that a student could start from?

Also I've seen lots of discussion on improving SQL support, and good starting points.

For the parser generator there is currently Pegged, that could be integrated into Phobos.  Would that be enough work for a full project.

https://github.com/PhilippeSigaud/Pegged

Also, anyone interested in mentoring projects related to these topics.

On Thursday, 28 January 2016 at 13:57:06 UTC, Rikki Cattermole wrote:
> On 29/01/16 2:53 AM, Craig Dillabaugh wrote:
>> [...]
>
> 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

Rikki, how would this improve upon what we have with Dstep (apart from it being fun since it is in D).

On Friday, 15 January 2016 at 20:46:59 UTC, Tavi wrote:
> On Friday, 15 January 2016 at 16:06:00 UTC, Craig Dillabaugh wrote:
>> On Friday, 15 January 2016 at 15:11:39 UTC, Tavi wrote:
>>> On Thursday, 14 January 2016 at 18:56:21 UTC, Craig Dillabaugh wrote:
>>>> Deadline is getting closer, any new project ideas are welcome. Starting to get some contact from students now.
>>>
>>>
>>> FlatBuffers for DLang - http://google.github.io/flatbuffers/
>>
>> Are you volunteering as a potential mentor :o)
>
> I haven't started anything seriously in D yet, so I would not be qualified for such mentoring.
> Being an efficient cross platform serialization library started at Google (already supporting C++, Java, C#, Go, Python and JavaScript), may be a good candidate for GSOC.

Anyone interested and capable of mentor a student interested in doing FlatBuffers for D.

On Saturday, 6 February 2016 at 20:18:57 UTC, Craig Dillabaugh wrote:
> Anyone interested and capable of mentor a student interested in doing FlatBuffers for D.

I could do that. Currently, as a side project, I'm working on adding D support for Protocol Buffers v3 [1].

Main goals of the new design:
- integration in the upstream project
- simple readable generated code
- range based solution

Of course, the same can be applied for the FlatBuffers.

[1] https://github.com/dcarp/protobuf/tree/dlang_support

On Sunday, 7 February 2016 at 12:14:24 UTC, Dragos Carp wrote:
> On Saturday, 6 February 2016 at 20:18:57 UTC, Craig Dillabaugh wrote:
>> Anyone interested and capable of mentor a student interested in doing FlatBuffers for D.
>
> I could do that. Currently, as a side project, I'm working on adding D support for Protocol Buffers v3 [1].
>
> Main goals of the new design:
> - integration in the upstream project
> - simple readable generated code
> - range based solution
>
> Of course, the same can be applied for the FlatBuffers.
>
> [1] https://github.com/dcarp/protobuf/tree/dlang_support

Awesome! Thanks.  I will write up something on the idea's page in the next day or two (which you are welcome to edit of course).  Also, if a student were interested in working on Protocol Buffers, would there be opportunities there too?

I also ask Mentor's to write a little bit about themselves on the mentor's page:

http://wiki.dlang.org/GSOC_mentors

On Monday, 8 February 2016 at 13:25:38 UTC, CraigDillabaugh wrote:
> Awesome! Thanks.  I will write up something on the idea's page in the next day or two (which you are welcome to edit of course).  Also, if a student were interested in working on Protocol Buffers, would there be opportunities there too?

There is still some pending work regarding Protocol Buffers:
- native support for the so called "well known" types
- optimization of non-recursive messages
- comments and deprecate field handling
- benchmarking
- json support