www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GSOC - Holiday Edition

reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
I was hoping folks to take a brief break from bickering about 
features, and arguing over which posters have been naughty, and 
which have been nice, to get a bit of input on our 2015 Google 
Summer of Code Proposal  ... :o)


First off, I've been able to get some work done on the Idea's 
page, it is here:

http://wiki.dlang.org/GSOC_2015_Ideas

This is the most important part of our submission, but we are 
also supposed to submit a organizational proposal.  I've started 
on this too (still under construction, and have put it on Github 
at:

https://github.com/craig-dillabaugh/dlang-gsoc2015

Any feedback is welcome.


There are currently six project proposals.  I think it would be 
good to have one or two more, and the ones that are there need a 
bit of polishing. A lot of what is there is stuff I have 
'harvested' from previous proposals. For the GDC and Bare Metal 
D/Arm Support projects I am not even sure if the items listed are 
still needed since these are basically cut and paste jobs from 1 
or 2 years ago.

A few specific questions that I need answered.

General Questions

1) I would like to include bio's for the mentors.  I have a very 
short one for Iain (which I stole from DConf) and a line on 
Deadalinx, but that is about that.  If you are a mentor I would 
really appreciate a brief 3-4 line bio. I think this makes our 
'ideas' page stand out from others I have seen. Any mentors 
please provide bios, or if you are uncomfortable with that please 
let me know.

2) For all projects, in addition to mentor bios I want to have a 
section on what students should know (or be willing to learn), 
you can see SDC for an example. Could other potential mentors 
please fill me on your projects.  Basically, if you can give 
pointers to a few good resources for someone interested in your 
project that would be great.

3) I would like to have a 'backup' mentor for each project.  Any 
volunteers! I think we have enough for the Phobos project, but 
other projects could really use something.

4) Finally, I should have a backup administrator.  Any volunteers 
for that.


Questions for Specific Individuals

5) For GDC, can Iain (or someone else related to that project) 
update the wiki, post something here, or get in touch with me to 
update the project proposal.



7) Bruno Medeiros - you suggested a DDT project. I've added it.  
Can you provide me with a few more details, and a bio.   Also, 
under what license is DDT released, I couldn't access any code on 
your GitHub page to check this.



9) For the Phobos proposal, most of this is scrapped from last 
years proposal and from posts on the form by Jens and Russel.  
Are the libraries I've listed indeed the ones in need of the most 
attention. What about std.xml and std.json?

10) Rikki had mentioned a 'Web Development' project, but I don't 
have enough to post on the project ideas page.  Are you still 
interested in doing this.


Hope that everyone has a great 2015, and I look forward to your 
feedback.

Cheers,

Craig
Dec 30 2014
next sibling parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Wednesday, 31 December 2014 at 03:25:53 UTC, Craig Dillabaugh 
wrote:

 7) Bruno Medeiros - you suggested a DDT project. I've added it.
  Can you provide me with a few more details, and a bio.   Also, 
 under what license is DDT released, I couldn't access any code 
 on your GitHub page to check this.
Dec 30 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 31 December 2014 at 03:25:53 UTC, Craig Dillabaugh 
wrote:

 3) I would like to have a 'backup' mentor for each project.  
 Any volunteers! I think we have enough for the Phobos project, 
 but other projects could really use something.


I might be able to do it on pretty much any of them, though I'm 
not excited about the projects nor GSOC itself. (if there's 
something I want, I usually just write it myself...)
Dec 30 2014
parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Wednesday, 31 December 2014 at 03:44:42 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 31 December 2014 at 03:25:53 UTC, Craig 
 Dillabaugh wrote:

 3) I would like to have a 'backup' mentor for each project.  
 Any volunteers! I think we have enough for the Phobos project, 
 but other projects could really use something.


 I might be able to do it on pretty much any of them, though I'm 
 not excited about the projects nor GSOC itself. (if there's 
 something I want, I usually just write it myself...)


Thanks. I'll take that as a yes (albeit a tepid one) and add you 
to my backup list. Hopefully there will be no work for the backup 
mentors, but its good to have some solid people to fill in just 
in case.
Dec 30 2014
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
31-Dec-2014 06:25, Craig Dillabaugh пишет:

 I was hoping folks to take a brief break from bickering about features,
 and arguing over which posters have been naughty, and which have been
 nice, to get a bit of input on our 2015 Google Summer of Code Proposal
 ... :o)


 First off, I've been able to get some work done on the Idea's page, it
 is here:

 http://wiki.dlang.org/GSOC_2015_Ideas

 This is the most important part of our submission, but we are also
 supposed to submit a organizational proposal.  I've started on this too
 (still under construction, and have put it on Github at:

 https://github.com/craig-dillabaugh/dlang-gsoc2015

 Any feedback is welcome.


 There are currently six project proposals.  I think it would be good to
 have one or two more, and the ones that are there need a bit of
 polishing. A lot of what is there is stuff I have 'harvested' from
 previous proposals. For the GDC and Bare Metal D/Arm Support projects I
 am not even sure if the items listed are still needed since these are
 basically cut and paste jobs from 1 or 2 years ago.


I'd gladly serve as backup mentor for Bare Metal D project. In fact I 
recall wording as something I might have written a year ago.

Besides I have a small fleet of ARM boards sitting on my table, gotta 
make them useful.

The key guy to get in touch though is Michael Franklin:
http://dconf.org/2014/talks/franklin.html
Would be great to know if he open-sourced some of his stuff.





I probably could expand on that if desired.



-- 
Dmitry Olshansky
Dec 31 2014
next sibling parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Wednesday, 31 December 2014 at 11:24:00 UTC, Dmitry Olshansky 
wrote:

 31-Dec-2014 06:25, Craig Dillabaugh пишет:

 I was hoping folks to take a brief break from bickering about 
 features,
 and arguing over which posters have been naughty, and which 
 have been
 nice, to get a bit of input on our 2015 Google Summer of Code 
 Proposal
 ... :o)


 First off, I've been able to get some work done on the Idea's 
 page, it
 is here:

 http://wiki.dlang.org/GSOC_2015_Ideas

 This is the most important part of our submission, but we are 
 also
 supposed to submit a organizational proposal.  I've started on 
 this too
 (still under construction, and have put it on Github at:

 https://github.com/craig-dillabaugh/dlang-gsoc2015

 Any feedback is welcome.


 There are currently six project proposals.  I think it would 
 be good to
 have one or two more, and the ones that are there need a bit of
 polishing. A lot of what is there is stuff I have 'harvested' 
 from
 previous proposals. For the GDC and Bare Metal D/Arm Support 
 projects I
 am not even sure if the items listed are still needed since 
 these are
 basically cut and paste jobs from 1 or 2 years ago.


 I'd gladly serve as backup mentor for Bare Metal D project. In 
 fact I recall wording as something I might have written a year 
 ago.

 Besides I have a small fleet of ARM boards sitting on my table, 
 gotta make them useful.

 The key guy to get in touch though is Michael Franklin:
 http://dconf.org/2014/talks/franklin.html
 Would be great to know if he open-sourced some of his stuff.





 I probably could expand on that if desired.


That is great.  I will add you to my backup mentors list and I 
will check out Michael Franklin's talk.  If you want to make any 
updates to the Wiki section, please feel free.
Dec 31 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Wednesday, 31 December 2014 at 11:24:00 UTC, Dmitry Olshansky 
wrote:

 The key guy to get in touch though is Michael Franklin:
 http://dconf.org/2014/talks/franklin.html
 Would be great to know if he open-sourced some of his stuff.


My experiments in trying to "minimize" D for the ARM Cortex-M is 
here:
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study

The memory-mapped I/O pattern that was the key part of my 
presentation at DConf is here:
https://github.com/JinShil/memory_mapped_io
It was modeled after this paper:
http://yogiken.files.wordpress.com/2010/02/c-register-access.pdf

The few STM32 peripherals that I created with the memory-mapped 
I/O pattern for testing the proof of concept is here:
https://github.com/JinShil/stm32_registers

The code generator that I used to automate conversion of the 
datasheet from PDF to D code is here:
https://github.com/JinShil/stm32_datasheet_to_d

The minimal "Hello World" for ARM Cortex-M is here:
http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

Instructions for building a GDC ARM Cortex-M cross compiler is 
here:
http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler

Dicebot includes the ARM Cortex-M backend for LDC is the Arch 
Linux package:
https://www.archlinux.org/packages/community/x86_64/ldc/
Thanks Dicebot, I used it many times.

Those interested in using D for ARM Cortex-M microcontroller 
program should probably look at minlibd 
(https://bitbucket.org/timosi/minlibd)

Over the past year, my hopes for D gradually diminished.  I don't 
see a way to use D for microcontroller programming without making 
many concessions and compromises, wrapping C, or forking the D 
compiler/runtime and making your own dialect of the language.  
So, I'm sorry to say I'm bowing out of the D scene, at least for 
now.

Mike Franklin
Dec 31 2014
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 1 January 2015 at 02:18:40 UTC, Mike wrote:

 On Wednesday, 31 December 2014 at 11:24:00 UTC, Dmitry 
 Olshansky wrote:

 The key guy to get in touch though is Michael Franklin:
 http://dconf.org/2014/talks/franklin.html
 Would be great to know if he open-sourced some of his stuff.


 My experiments in trying to "minimize" D for the ARM Cortex-M 
 is here:
 https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study

 The memory-mapped I/O pattern that was the key part of my 
 presentation at DConf is here:
 https://github.com/JinShil/memory_mapped_io
 It was modeled after this paper:
 http://yogiken.files.wordpress.com/2010/02/c-register-access.pdf

 The few STM32 peripherals that I created with the memory-mapped 
 I/O pattern for testing the proof of concept is here:
 https://github.com/JinShil/stm32_registers

 The code generator that I used to automate conversion of the 
 datasheet from PDF to D code is here:
 https://github.com/JinShil/stm32_datasheet_to_d

 The minimal "Hello World" for ARM Cortex-M is here:
 http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

 Instructions for building a GDC ARM Cortex-M cross compiler is 
 here:
 http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler

 Dicebot includes the ARM Cortex-M backend for LDC is the Arch 
 Linux package:
 https://www.archlinux.org/packages/community/x86_64/ldc/
 Thanks Dicebot, I used it many times.

 Those interested in using D for ARM Cortex-M microcontroller 
 program should probably look at minlibd 
 (https://bitbucket.org/timosi/minlibd)

 Over the past year, my hopes for D gradually diminished.  I 
 don't see a way to use D for microcontroller programming 
 without making many concessions and compromises, wrapping C, or 
 forking the D compiler/runtime and making your own dialect of 
 the language.  So, I'm sorry to say I'm bowing out of the D 
 scene, at least for now.

 Mike Franklin


Thanks for all the links, and sorry to hear that things haven't 
gone well.  Do you think it would be worthwhile having a 'Bare 
Metal D' project for this year, or do you think we would just be 
wasting the time of some student?
Jan 02 2015
parent reply "Mike" <none none.com> writes:
On Friday, 2 January 2015 at 15:28:58 UTC, Craig Dillabaugh wrote:


 Thanks for all the links, and sorry to hear that things haven't 
 gone well.  Do you think it would be worthwhile having a 'Bare 
 Metal D' project for this year, or do you think we would just 
 be wasting the time of some student?


I think, without a few fundamental changes to the language and 
the runtime, bare-metal programming in D will always be playing 
second fiddle to C, and that significantly diminishes its appeal. 
  As I and others have shown, it can be done, but without the 
aforementioned changes, it will always feel hackish and be viewed 
as little more than an interesting experiment. The changes I'm 
thinking of would be very few, but fundamental breaking changes, 
and that doesn't sit well with this community.  Anyone pursuing 
bare-metal programming in D will need to create a slightly 
different dialect of the language if they want it to be a tool 
rather than a toy.

...and perhaps that would be a better GSOC project.  That is, to 
fork the compiler and runtime and try to make it more suitable 
for systems programming, with "systems programming" being defined 
as creating the first layer of hardware abstraction.  
Unfortunately, such a project would probably not be very 
interesting to those who enjoy bare-metal programming, but rather 
more for those that have interest in compilers.  I would not 
market it as bare-metal programming in D, but as creating a 
bare-metal dialect of D.

That's unfortunate, because if D were designed with bare-metal in 
mind from the start, it would scale well to all programming 
disciplines.  But since it was designed more as an efficient 
applications programming language, you have to hammer to fit, 
weld to fill, paint to cover to get it to scale down to 
bare-metal.

Long story short:  Bare-metal programming in the current state of 
D would be a fun and educational experiment, but would not be 
something you could sell seriously to industry.  If fun and 
education is all you're after then go for it. but a bare-metal 
dialect of D is what's really needed for it to be taken seriously.

Mike
Jan 02 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 3 January 2015 at 05:25:17 UTC, Mike wrote:

 I think, without a few fundamental changes to the language and 
 the runtime, bare-metal programming in D will always be playing 
 second fiddle to C, and that significantly diminishes its 
 appeal.


What changes did you have in mind? When I played with it, it was 
mostly using the C-like subset, but I still think it was worth it 
because bits like operator overloading and slicing are really 
convenient.

What I've wanted before is better ability to remove dependency on 
stuff like moduleinfo. Though that isn't a big deal on something 
like x86 where an extra 30 KB is fine, I think it would be really 
important on something like a arduino. (Which I intend to play 
with - finally have one here - but haven't gotten around to yet.)
Jan 03 2015
next sibling parent reply "Mike" <none none.com> writes:
On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:


 What changes did you have in mind? When I played with it, it 
 was mostly using the C-like subset, but I still think it was 
 worth it because bits like operator overloading and slicing are 
 really convenient.

 What I've wanted before is better ability to remove dependency 
 on stuff like moduleinfo. Though that isn't a big deal on 
 something like x86 where an extra 30 KB is fine, I think it 
 would be really important on something like a arduino. (Which I 
 intend to play with - finally have one here - but haven't 
 gotten around to yet.)


Indeed, by using a C-like subset of D you have a much more 
powerful and convenient language than C.  But the compiler is not 
aware of that subset, so it's not a professional experience.  
That's why it plays second fiddle to C.  I need that polished 
experience before I can sell D to my employer, my customers, or 
even myself.

Right now if you step outside of the aforementioned subset, 
you'll only get a linker error.  Furthermore, you have limited 
facilities outside of hacks and creative linker scripting to 
reign in code generation.  And programmers have to create their 
own port of the runtime to provide that subset, but there is no 
hope in that port every making it upstream, so 
bare-metal/embedded/kernel programmers will always be forced to 
their own corner of the world, with a different dialect of the 
language.

There have been suggestions to create compiler flag in order 
restrict compilation to a minimal subset of D, but I don't think 
that's the right solution.  Programmers will define "minimal" 
differently. For example, I would like to be able to use 
exceptions, but I don't want that to implicitly require the 
garbage collector.  A better approach would be to modularize the 
language so users can start with something very minimal and add 
features (rather than remove features) to scale the language to 
their needs.

Here are some of the changes I had in mind:

1.  Move the runtime hook definitions out of the compiler to .di 
files so programmers wanting to create a subset of the language 
can decorate those definitions, or omit them, in order to get 
compiler errors instead of linker errors when they explicitly or 
implicitly use an unimplemented language feature.

2.  Add toolchain support (compiler and especially linker) to 
reign in all the implicit code generation and remove dead code.  
This is crucial for microcontroller programming.

3. The GC, and other automatic memory management strategies, 
should be opt-in library features, instead of default language 
features one has to avoid.  Other emerging languages have shown 
that D can have much more elegant lifetime management if it broke 
with the past, but it's clear that's not going to happen.

4. But it's not just a laundry list of individual features that's 
needed.  The community and the language leaders need a change in 
perspective.  Even if the above were addressed, a port (or 
potentially ports) of the runtime would still be required.  But, 
the current runtime is designed in such a way that it implicitly 
expects an underlying operating system.  I don't think that's a 
characteristic of a systems programming language.  All the 
platform-specific code and language features that are provided by 
the OS need to be moved to libraries and encapsulated.  I would 
like to see "language", "library", and "platform" clearly 
separated so the language can be modularized and we can choose 
what features of the language to support in our ports.  
Unfortunately, this has proven to be very unpopular in this 
community.

I've tried a few things, but it's clear I need to learn the 
compiler in order to do anything significant, and that's not 
really within my interest or ability.  Furthermore, the 
controversy surrounding some of my most trivial ideas has left me 
feeling that even if I rolled up my sleeves and implemented a few 
things, it would be such an uphill battle justifying it to this 
community that my time would be far better spent studying 
compiler implementation and going my own way.

Again, using D for bare-metal/embedded/kernel programming shows 
huge potential as you know, but it's currently not a professional 
experience, and getting it there would be a difficult, 
frustrating, and likely doomed experience.  I think users serious 
about using D for such programming should fork and go their own 
way, or start over with D as an inspiration...and that would be a 
good GSOC bare-metal project.

Mike
Jan 03 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/04/2015 04:50 AM, Mike wrote:

 On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:

 What changes did you have in mind? When I played with it, it was
 mostly using the C-like subset, but I still think it was worth it
 because bits like operator overloading and slicing are really convenient.

 What I've wanted before is better ability to remove dependency on
 stuff like moduleinfo. Though that isn't a big deal on something like
 x86 where an extra 30 KB is fine, I think it would be really important
 on something like a arduino. (Which I intend to play with - finally
 have one here - but haven't gotten around to yet.)


 Indeed, by using a C-like subset of D you have a much more powerful and
 convenient language than C.  But the compiler is not aware of that
 subset, so it's not a professional experience. That's why it plays
 second fiddle to C.  I need that polished experience before I can sell D
 to my employer, my customers, or even myself.

 Right now if you step outside of the aforementioned subset, you'll only
 get a linker error.  Furthermore, you have limited facilities outside of
 hacks and creative linker scripting to reign in code generation.  And
 programmers have to create their own port of the runtime to provide that
 subset, but there is no hope in that port every making it upstream, so
 bare-metal/embedded/kernel programmers will always be forced to their
 own corner of the world, with a different dialect of the language.


The situation is similar to C where you have a specialized nanolib 
runtime, have to come up with your own linker script and need to avoid 
big dependencies (like printf with float support).

https://launchpad.net/gcc-arm-embedded

We already have a designated -betterC compiler switch that should avoid 
all dependencies (it's incomplete though). Overall I think this is 
fairly trivial to achieve.

I don't see what part of the runtime would be needed for an embedded 
target, except for maybe 2 hooks http://wiki.dlang.org/Runtime_Hooks or so.
If you're using C++, you also need to fill in some missing runtime 
functions (__init_array, __cxa_pure_virtual, _sbrk).


 There have been suggestions to create compiler flag in order restrict
 compilation to a minimal subset of D, but I don't think that's the right
 solution.  Programmers will define "minimal" differently. For example, I
 would like to be able to use exceptions, but I don't want that to
 implicitly require the garbage collector.


Exceptions on MC sounds like a bad idea, you can avoid the GC by 
throwing static instances of exceptions.


 Here are some of the changes I had in mind:

 1.  Move the runtime hook definitions out of the compiler to .di files
 so programmers wanting to create a subset of the language can decorate
 those definitions, or omit them, in order to get compiler errors instead
 of linker errors when they explicitly or implicitly use an unimplemented
 language feature.


Maybe for a polished experience, but it's worth the trouble in the 
beginning.


 2.  Add toolchain support (compiler and especially linker) to reign in
 all the implicit code generation and remove dead code. This is crucial
 for microcontroller programming.


Last time I build an embedded ARM project the resulting D binary was as 
small as the C++ one.


 3. The GC, and other automatic memory management strategies, should be
 opt-in library features, instead of default language features one has to
 avoid.  Other emerging languages have shown that D can have much more
 elegant lifetime management if it broke with the past, but it's clear
 that's not going to happen.


It's a known issue that certain language constructs require memory 
management. That's not a big deal, you can't use C++'s std::map either.


 4. But it's not just a laundry list of individual features that's
 needed.  The community and the language leaders need a change in
 perspective.


A group of people that builds the infrastructure is needed.

I can't strictly follow your conclusion, that half of the language needs 
to be change.
The only thing I needed to do last time, was to disable ModuleInfo 
generation in the compiler.
Jan 04 2015
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 04 Jan 2015 18:25:32 +0100
schrieb Martin Nowak <code+news.digitalmars dawg.eu>:


 On 01/04/2015 04:50 AM, Mike wrote:

 On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:

 What changes did you have in mind? When I played with it, it was
 mostly using the C-like subset, but I still think it was worth it
 because bits like operator overloading and slicing are really
 convenient.

 What I've wanted before is better ability to remove dependency on
 stuff like moduleinfo. Though that isn't a big deal on something
 like x86 where an extra 30 KB is fine, I think it would be really
 important on something like a arduino. (Which I intend to play
 with - finally have one here - but haven't gotten around to yet.)


 Indeed, by using a C-like subset of D you have a much more powerful
 and convenient language than C.  But the compiler is not aware of
 that subset, so it's not a professional experience. That's why it
 plays second fiddle to C.  I need that polished experience before I
 can sell D to my employer, my customers, or even myself.

 Right now if you step outside of the aforementioned subset, you'll
 only get a linker error.  Furthermore, you have limited facilities
 outside of hacks and creative linker scripting to reign in code
 generation.  And programmers have to create their own port of the
 runtime to provide that subset, but there is no hope in that port
 every making it upstream, so bare-metal/embedded/kernel programmers
 will always be forced to their own corner of the world, with a
 different dialect of the language.


 
 The situation is similar to C where you have a specialized nanolib 
 runtime, have to come up with your own linker script and need to
 avoid big dependencies (like printf with float support).
 
 https://launchpad.net/gcc-arm-embedded
 
 We already have a designated -betterC compiler switch that should
 avoid all dependencies (it's incomplete though). Overall I think this
 is fairly trivial to achieve.
 
 I don't see what part of the runtime would be needed for an embedded 
 target, except for maybe 2 hooks http://wiki.dlang.org/Runtime_Hooks
 or so. If you're using C++, you also need to fill in some missing
 runtime functions (__init_array, __cxa_pure_virtual, _sbrk).
 

 There have been suggestions to create compiler flag in order
 restrict compilation to a minimal subset of D, but I don't think
 that's the right solution.  Programmers will define "minimal"
 differently. For example, I would like to be able to use
 exceptions, but I don't want that to implicitly require the garbage
 collector.


 
 Exceptions on MC sounds like a bad idea, you can avoid the GC by 
 throwing static instances of exceptions.
 

 Here are some of the changes I had in mind:

 1.  Move the runtime hook definitions out of the compiler to .di
 files so programmers wanting to create a subset of the language can
 decorate those definitions, or omit them, in order to get compiler
 errors instead of linker errors when they explicitly or implicitly
 use an unimplemented language feature.


 
 Maybe for a polished experience, but it's worth the trouble in the 
 beginning.
 

 2.  Add toolchain support (compiler and especially linker) to reign
 in all the implicit code generation and remove dead code. This is
 crucial for microcontroller programming.


 
 Last time I build an embedded ARM project the resulting D binary was
 as small as the C++ one.
 

 3. The GC, and other automatic memory management strategies, should
 be opt-in library features, instead of default language features
 one has to avoid.  Other emerging languages have shown that D can
 have much more elegant lifetime management if it broke with the
 past, but it's clear that's not going to happen.


 
 It's a known issue that certain language constructs require memory 
 management. That's not a big deal, you can't use C++'s std::map
 either.
 

 4. But it's not just a laundry list of individual features that's
 needed.  The community and the language leaders need a change in
 perspective.


 
 A group of people that builds the infrastructure is needed.
 
 I can't strictly follow your conclusion, that half of the language
 needs to be change.
 The only thing I needed to do last time, was to disable ModuleInfo 
 generation in the compiler.
 


The question is basically if you want a 100% polished experience or if
you just want something that works with some effort.

One example of many: If you disable ModuleInfo we still happily compile
module constructors, they'll never be called though. Sure you can avoid
this if you know about it, but we can't promote D as a reasonable
replacement for C as long as these issues exist.

I agree that such changes are not really big language changes.
Jan 04 2015
parent reply "Mike" <none none.com> writes:
On Sunday, 4 January 2015 at 19:50:48 UTC, Johannes Pfau wrote:


 One example of many: If you disable ModuleInfo we still happily 
 compile
 module constructors, they'll never be called though. Sure you 
 can avoid
 this if you know about it, but we can't promote D as a 
 reasonable
 replacement for C as long as these issues exist.


Exactly, that's good example.
Jan 04 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/05/2015 04:50 AM, Mike wrote:

 Exactly, that's good example.


Can we please file those as betterC bugs in https://issues.dlang.org/.
If we sort those out, it will be much easier next time.
Jan 05 2015
parent Johannes Pfau <nospam example.com> writes:
Am Mon, 05 Jan 2015 15:08:32 +0100
schrieb Martin Nowak <code+news.digitalmars dawg.eu>:


 On 01/05/2015 04:50 AM, Mike wrote:

 Exactly, that's good example.


 
 Can we please file those as betterC bugs in https://issues.dlang.org/.
 If we sort those out, it will be much easier next time.


I'm working on a private GDC branch running on 8bit AVRs and I fix
these issues as I encounter them. I intend to backport all changes
to DMD in the next few months, so filing bug reports only makes sense if
somebody else wants to fix/upstream fixes them faster than I do ;-)
Jan 05 2015
prev sibling next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Sunday, 4 January 2015 at 17:25:49 UTC, Martin Nowak wrote:

 On 01/04/2015 04:50 AM, Mike wrote:

 On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe 
 wrote:




clip

 It's a known issue that certain language constructs require 
 memory management. That's not a big deal, you can't use C++'s 
 std::map either.


 4. But it's not just a laundry list of individual features 
 that's
 needed.  The community and the language leaders need a change 
 in
 perspective.


 A group of people that builds the infrastructure is needed.

 I can't strictly follow your conclusion, that half of the 
 language needs to be change.
 The only thing I needed to do last time, was to disable 
 ModuleInfo generation in the compiler.


Martin.  While it seems that some are not so keen on Bare Metal D,
you still seem fairly positive on it.  Not that I can really
follow all the debate,  I am just an administrator after all.

Do you feel the current posting on the Wiki accurately best 
reflects
what work needs to be done on this project.
Jan 04 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/05/2015 02:59 AM, Craig Dillabaugh wrote:

 Do you feel the current posting on the Wiki accurately best reflects
 what work needs to be done on this project.


Yeah, it's pretty good.
I've thrown out the hosted ARM project (AFAIK gdc and ldc are almost 
done) and filled in some details for the bare-metal project.
Jan 05 2015
next sibling parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Monday, 5 January 2015 at 14:46:25 UTC, Martin Nowak wrote:

 On 01/05/2015 02:59 AM, Craig Dillabaugh wrote:

 Do you feel the current posting on the Wiki accurately best 
 reflects
 what work needs to be done on this project.


 Yeah, it's pretty good.
 I've thrown out the hosted ARM project (AFAIK gdc and ldc are 
 almost done) and filled in some details for the bare-metal 
 project.


Thanks.
Jan 05 2015
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 January 2015 at 14:46, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 01/05/2015 02:59 AM, Craig Dillabaugh wrote:

 Do you feel the current posting on the Wiki accurately best reflects
 what work needs to be done on this project.



 Yeah, it's pretty good.
 I've thrown out the hosted ARM project (AFAIK gdc and ldc are almost done)
 and filled in some details for the bare-metal project.


Around the time of Dconf 2013, gdc's ARM port was passing the (as of
then) D2 testsuite.  Things might have changed since though.

Regards
Iain
Jan 05 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Sunday, 4 January 2015 at 17:25:49 UTC, Martin Nowak wrote:


 Exceptions on MC sounds like a bad idea,


That is a bias of old.  It is entirely dependent on the 
application.  Many modern uses of microcontrollers are not hard 
real-time, and while my work was primarily on ARM 
microcontrollers, my previous comments were about using D for 
bare-metal and systems programming in general.


 Last time I build an embedded ARM project the resulting D 
 binary was as small as the C++ one.


Yes, my "Hello World!" was 56 bytes, but, it's not only about 
getting something to work.


 A group of people that builds the infrastructure is needed.

 I can't strictly follow your conclusion, that half of the 
 language needs to be change.
 The only thing I needed to do last time, was to disable 
 ModuleInfo generation in the compiler.


My conclusion is not that half the language needs to change.  As 
I said in a previous post, the changes needed are likely few, but 
fundamental, and can't be implemented in infrastructure alone if 
you want the result to be more than "Hey, I got it to work".

The original thread prompting this discussion was about having a 
bare-metal GSOC project.  As I and others have shown, such a 
project is possible, interesting, entertaining and educational, 
but it will always be just that without 
language/compiler/toolchain support.

A more worthwhile GSOC project would be to add those few, yet 
fundamental, language/compiler/toolchain changes to make the 
experience feel like the language was designed with intent for 
the purpose of systems programming.  But I don't think that will 
be of much interest to embedded/kernel/bare-metal programmers, 
but rather more for those with an interest in language and 
compiler design.

Mike
Jan 04 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 5 January 2015 at 03:33:15 UTC, Mike wrote:

 On Sunday, 4 January 2015 at 17:25:49 UTC, Martin Nowak wrote:


 Exceptions on MC sounds like a bad idea,


 That is a bias of old.  It is entirely dependent on the 
 application.  Many modern uses of microcontrollers are not hard 
 real-time, and while my work was primarily on ARM 
 microcontrollers, my previous comments were about using D for 
 bare-metal and systems programming in general.


 Last time I build an embedded ARM project the resulting D 
 binary was as small as the C++ one.


 Yes, my "Hello World!" was 56 bytes, but, it's not only about 
 getting something to work.


 A group of people that builds the infrastructure is needed.

 I can't strictly follow your conclusion, that half of the 
 language needs to be change.
 The only thing I needed to do last time, was to disable 
 ModuleInfo generation in the compiler.


 My conclusion is not that half the language needs to change.  
 As I said in a previous post, the changes needed are likely 
 few, but fundamental, and can't be implemented in 
 infrastructure alone if you want the result to be more than 
 "Hey, I got it to work".

 The original thread prompting this discussion was about having 
 a bare-metal GSOC project.  As I and others have shown, such a 
 project is possible, interesting, entertaining and educational, 
 but it will always be just that without 
 language/compiler/toolchain support.

 A more worthwhile GSOC project would be to add those few, yet 
 fundamental, language/compiler/toolchain changes to make the 
 experience feel like the language was designed with intent for 
 the purpose of systems programming.  But I don't think that 
 will be of much interest to embedded/kernel/bare-metal 
 programmers, but rather more for those with an interest in 
 language and compiler design.

 Mike


Personally I would chose Netduino and MicroEJ capable boards if I 
ever do any electronics again as hobby.

Given your experience wouldn't D be capable to target such 
systems as well?

..
Paulo
Jan 05 2015
parent "Mike" <none none.com> writes:
On Monday, 5 January 2015 at 11:38:17 UTC, Paulo  Pinto wrote:

 Personally I would chose Netduino and MicroEJ capable boards if 
 I ever do any electronics again as hobby.

 Given your experience wouldn't D be capable to target such 
 systems as well?


Yes, D is perfectly capable of targeting those boards using GDC 
and potentially even LDC, although LDC still has a few strange 
bugs [1].  In fact, with the right hackery, I assume D will 
generate far better code (smaller and faster) than the .Net Micro 
Framework or MicroEJ.

Another interesting offering is the Intel Edison/Galileo boards 
[2].  I'm under the impression that DMD would be able to generate 
code for those boards as well.  Although those boards are less 
like microcontrollers and more like micro PCs (e.g. Raspberry Pi, 
BeagleBone Black)

As a hobby, I highly recommend anyone interested getting 
themselves a board and trying it out.  The boards are 
surprisingly inexpensive.  With the right knowledge, it takes 
very little to get started, and can be quite rewarding to see the 
hardware "come alive" with your code.

1. Get yourself a GDC cross-compiler [3], and whatever tools are 
needed to interface a PC to your board (OpenOCD, or 
vendor-supplied tools).
2. Throw out Phobos and D Runtime, and create a small object.d 
with a few stubs as your runtime.
4. Write a simple program (e.g. blinky, semi-hosted "hello world" 
[4])
5. Create a linker script for your board.  This can be difficult 
the first time as you need an intimate understanding of your 
hardware and how the compiler generates code.
6. Use OpenOCD or your vendor's tools to upload the binary to 
your board, and bask in the satisfaction of bringing the board to 
life.

You won't be able to use classes, dynamic arrays, and a multitude 
of other language features unless you find a way to implement 
them in your runtime, but you will be able to write C-like code 
only with added bonuses like CTFE, templates, and mixins.

I'm sure those that actually take the plunge will find it to be a 
fun, educational, and rewarding exploration.

Mike

[1] - https://github.com/ldc-developers/ldc/issues/781
[2] - 
http://www.intel.com/content/www/us/en/do-it-yourself/maker.html
[3] - 
http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler
[4] - 
http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22
Jan 05 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:


 What changes did you have in mind?


I forgot to mention in my last post your proposal for moving 
TypeInfo to the runtime [1] is also one of the changes I had in 
mind. It would be an excellent start, an important precedent, and 
would avoid the ridiculous TypeInfo-faking hack necessary to get 
a build.

It's exactly silly hacks like that that degrade the experience. I 
don't have the skills to fix it, and even if I did, I'm confident 
it wouldn't be welcome due to the aversion to change in the 
leadership and community.  This is why I'm saying bare-metal 
programming in D will need to fork and break with this community 
and its current philosophy for it to be a real contender with 
C/C++ in this domain.

Mike

[1] 
http://forum.dlang.org/thread/bug-12270-3 https.d.puremagic.com%2Fissues%2F
Jan 04 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/05/2015 04:38 AM, Mike wrote:

 I forgot to mention in my last post your proposal for moving TypeInfo to
 the runtime [1] is also one of the changes I had in mind. It would be an
 excellent start, an important precedent, and would avoid the ridiculous
 TypeInfo-faking hack necessary to get a build.


And again, you have a good chance to convince people that -betterC 
shouldn't generate TypeInfo.
Jan 05 2015
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
03-Jan-2015 08:25, Mike пишет:

 On Friday, 2 January 2015 at 15:28:58 UTC, Craig Dillabaugh wrote:


 Thanks for all the links, and sorry to hear that things haven't gone
 well.  Do you think it would be worthwhile having a 'Bare Metal D'
 project for this year, or do you think we would just be wasting the
 time of some student?


 I think, without a few fundamental changes to the language and the
 runtime, bare-metal programming in D will always be playing second
 fiddle to C, and that significantly diminishes its appeal.  As I and
 others have shown, it can be done, but without the aforementioned
 changes, it will always feel hackish and be viewed as little more than
 an interesting experiment. The changes I'm thinking of would be very
 few, but fundamental breaking changes,


Truth be told none of listed in this thread feel fundamental to me. It 
looks more like a set of patches to each specific problem in the 
compiler or run-time. Yeah, run-time would better be more customizable, 
but it's just our *current* run-time it's not the language.


 and that doesn't sit well with
 this community.  Anyone pursuing bare-metal programming in D will need
 to create a slightly different dialect of the language if they want it
 to be a tool rather than a toy.


The only difference of this to e.g. AVR-GCC (used in Arduinos and such) 
toolkits is that all hacks (most are upstream but not all) are already 
done, and packaged in a nice shrink-wrapped box.


 ...and perhaps that would be a better GSOC project.  That is, to fork
 the compiler and runtime and try to make it more suitable for systems
 programming, with "systems programming" being defined as creating the
 first layer of hardware abstraction. Unfortunately, such a project would
 probably not be very interesting to those who enjoy bare-metal
 programming, but rather more for those that have interest in compilers.
 I would not market it as bare-metal programming in D, but as creating a
 bare-metal dialect of D.


To clarify a bit my original intents on this project.
In short the goal is to make a toolkit to program a popular range of MCU 
(the list may grow with time) in a subset of D (aka Bare-Metal D).

There is no denying the fact that embedded C/C++ is nothing like normal 
desktop/server ones. C library is barbarically truncated, I'm not even 
saying STL and RTTI, and then countless vendor extensions.

Thus I do not believe that immediate upstreaming of everything 
bare-metal is even a good thing in principle. In my opinion a Bare-Metal 
D project can live its life along the upstream D by providing bare-metal 
versions of each successive version. In fact, we do not have all that 
many embedded guys in core team.

All generally useful patches should find their way in upstream, of 
course, but it takes time and should *not* be a prerequisite.

A toolkit will need to provide e.g build/fetch with a bootstrap script:
- a ready to-go D cross-compiler(s) might be with some patches to 
disable language features for better experience etc.
- a stripped run-time instead of Phobos (come on C/C++ folks use 
something much unlike standard library either)
- linker scripts for a (growing) set of MCUs
- I/O library and register definitions for MCUs (preferably a tool to 
auto-generate such)
- a modified driver that passes all kinds of right options for a given MCU

That's a minimum for other Bare Metal D projects to even start to take 
off. Ideally other tools include debugger, high-level libraries for 
peripherals (HAL), ports or bindings to C FAT, IP, ... libraries and so on.

Speaking of GSOC: a student is not fighting this fight alone, so mentor 
ought to bring issues to the core team. Secondly a project may consider 
completing top priority goals and secondary goals(goodies). Depending on 
student it can be geared more towards language or more towards embedded 
stuff.

Filing an issues and getting community to help with compiler is totally 
expected.


 That's unfortunate, because if D were designed with bare-metal in mind
 from the start, it would scale well to all programming disciplines.  But
 since it was designed more as an efficient applications programming
 language, you have to hammer to fit, weld to fill, paint to cover to get
 it to scale down to bare-metal.


Forth would be excellent then ;) Yet somehow it didn't scale up.


 Long story short:  Bare-metal programming in the current state of D
 would be a fun and educational experiment, but would not be something
 you could sell seriously to industry.  If fun and education is all
 you're after then go for it.



 but a bare-metal dialect of D is what's
 really needed for it to be taken seriously.


That's more or less the goal. Though I'd rather stay on the subset of D 
line rather then dialect.

-- 
Dmitry Olshansky
Jan 07 2015
parent reply "Mike" <none none.com> writes:
On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky 
wrote:


 Truth be told none of listed in this thread feel fundamental to 
 me. It looks more like a set of patches to each specific 
 problem in the compiler or run-time. Yeah, run-time would 
 better be more customizable, but it's just our *current* 
 run-time it's not the language.


Perhaps "high-impact" would be a better word than "fundamental".  
I think moving runtime hooks out of the compiler to .di files and 
Adam Ruppe's proposal to move TypeInfo to the runtime are great 
ideas.

Enhancement 11666 [1] is another.  That really highlighted a 
design problem in the runtime for me.  If the runtime had better 
separation of language, platform (OS and architecture) and 
library, the ports would simply have their own folder in the 
runtime rather than their own repository.  The controversy that 
followed the pull requests in an attempt address 11666 clearly 
shows the problems that high coupling to the platform can cause.  
If the platform were encapsulated and decoupled from the language 
implementation, we'd already be well on our way.

[1] - https://issues.dlang.org/show_bug.cgi?id=11666

But I've been watching how such changes are perceived here, and 
I'm skeptical they would be accepted because so much in the 
language is potentially affected by them.  Due to the fact that 
they only benefit a few bare-metal folks, but impact the full 
language, I'm quite confident they would be shunned, and that's 
been very discouraging.


 Thus I do not believe that immediate upstreaming of everything 
 bare-metal is even a good thing in principle. In my opinion a 
 Bare-Metal D project can live its life along the upstream D by 
 providing bare-metal versions of each successive version. In 
 fact, we do not have all that many embedded guys in core team.

 All generally useful patches should find their way in upstream, 
 of course, but it takes time and should *not* be a prerequisite.


Sure the bare-metal stuff can exist along-side the upstream 
repository.  That's actually what I alluded to in my previous 
posts, that bare-metal programming in D will likely need to fork. 
  In fact, due to the lack of support, I don't see it happening 
any other way.


 A toolkit will need to provide e.g build/fetch with a bootstrap 
 script:
 - a ready to-go D cross-compiler(s) might be with some patches 
 to disable language features for better experience etc.


That's more-or-less what I've suggested in this thread.  If that 
happened, I could get behind the items you listed below.  But I 
don't know how to proceed with the compiler, that's not my 
interest nor within my current ability.  Johannes has been 
exploring this territory, however, which is encouraging.


 - a stripped run-time instead of Phobos (come on C/C++ folks 
 use something much unlike standard library either)
 - linker scripts for a (growing) set of MCUs
 - I/O library and register definitions for MCUs (preferably a 
 tool to auto-generate such)
 - a modified driver that passes all kinds of right options for 
 a given MCU

 That's a minimum for other Bare Metal D projects to even start 
 to take off. Ideally other tools include debugger, high-level 
 libraries for peripherals (HAL), ports or bindings to C FAT, 
 IP, ... libraries and so on.


Let me add that I think the -betterC switch, or similar, is too 
blunt an instrument.  I'd like to have the flexibility to fine 
tune the language features (even on individual types) for the 
platform and/or application I'm building.  And while compiler 
switches and attributes may help, I think delegating features 
from the compiler to the runtime is a better investment.

Mike
Jan 08 2015
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Jan-2015 05:07, Mike пишет:

 On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky wrote:


 Truth be told none of listed in this thread feel fundamental to me. It
 looks more like a set of patches to each specific problem in the
 compiler or run-time. Yeah, run-time would better be more
 customizable, but it's just our *current* run-time it's not the language.


 Perhaps "high-impact" would be a better word than "fundamental". I think
 moving runtime hooks out of the compiler to .di files and Adam Ruppe's
 proposal to move TypeInfo to the runtime are great ideas.


These are good. I expect more customization points to come as bare-metal 
stuff moves along.

"high-impact" - I'm not sure I follow? Nobody would notice much except 
those messing with the compiler and custom run-times. The change itself 
might be a couple dozen of lines worth.

I could understand horror that tweaking something in a compiler may 
instill but D's compiler is rapidly evolving. I see nothing fundamental 
in how it depends on run-time and vise-versa, everything is tweakable 
and we break binary compatibility (and not only that) with every release.


 Enhancement 11666 [1] is another.  That really highlighted a design
 problem in the runtime for me.  If the runtime had better separation of
 language, platform (OS and architecture) and library, the ports would
 simply have their own folder in the runtime rather than their own
 repository.  The controversy that followed the pull requests in an
 attempt address 11666 clearly shows the problems that high coupling to
 the platform can cause. If the platform were encapsulated and decoupled
 from the language implementation, we'd already be well on our way.

 [1] - https://issues.dlang.org/show_bug.cgi?id=11666


This issue mostly affects embedded targets that run full-fledged OS.

Somehow I see it as a minor issue. No matter how we pile up 
platform-specific headers - somebody got to put it somewhere. A couple 
of conventions were discussed with various drawbacks. Many C projects do 
this in ad-hoc fashion and survive just fine. There is no inherent 
design problem or something "unfixable" - we just need more ports.

Also I'm thinking that bare-metal stuff would simply have its own 
run-time complying with some _spec_ of what compiler expects. Working 
out that spec and importantly language feature sets would be awesome.


 But I've been watching how such changes are perceived here, and I'm
 skeptical they would be accepted because so much in the language is
 potentially affected by them.


We can just ask for them again and see. It's important to voice concerns 
because there is so much of stuff going on that some important issues 
may easily slip under radar.

What usually works best in prioritizing stuff is highlighting that some 
actual project is having a problem with issue X, Y and Z.


 Due to the fact that they only benefit a
 few bare-metal folks, but impact the full language


Again I'm not sure how? In fact nobody would notice a damn thing. Layout 
of internals of D run-time are just that.



 A toolkit will need to provide e.g build/fetch with a bootstrap script:
 - a ready to-go D cross-compiler(s) might be with some patches to
 disable language features for better experience etc.


 That's more-or-less what I've suggested in this thread.  If that
 happened, I could get behind the items you listed below.  But I don't
 know how to proceed with the compiler, that's not my interest nor within
 my current ability.  Johannes has been exploring this territory,
 however, which is encouraging.


Great. This helps me understand what is the main impediment at the 
moment. With that in mind I think we can formulate our GSOC plan better.

As far as I can tell it can focus on 2 paths:

a) Get embedded-savy student to work on MCU support and stuff while 
delegating most compiler tweaks to mentor(s) and core team.

b) Get a student interested in compilers to deliver on getting robust 
cross-compiler with minimal run-time. Getting actual boards to work is 
then delegated to mentors.

I am in favor of a).


 - a stripped run-time instead of Phobos (come on C/C++ folks use
 something much unlike standard library either)
 - linker scripts for a (growing) set of MCUs
 - I/O library and register definitions for MCUs (preferably a tool to
 auto-generate such)
 - a modified driver that passes all kinds of right options for a given
 MCU

 That's a minimum for other Bare Metal D projects to even start to take
 off. Ideally other tools include debugger, high-level libraries for
 peripherals (HAL), ports or bindings to C FAT, IP, ... libraries and
 so on.


 Let me add that I think the -betterC switch, or similar, is too blunt an
 instrument.  I'd like to have the flexibility to fine tune the language
 features (even on individual types) for the platform and/or application
 I'm building.  And while compiler switches and attributes may help, I
 think delegating features from the compiler to the runtime is a better
 investment.

 Mike


Agreed.

-- 
Dmitry Olshansky
Jan 09 2015
parent "Mike" <none none.com> writes:
On Friday, 9 January 2015 at 20:24:55 UTC, Dmitry Olshansky wrote:


 Great. This helps me understand what is the main impediment at 
 the moment. With that in mind I think we can formulate our GSOC 
 plan better.

 As far as I can tell it can focus on 2 paths:

 a) Get embedded-savy student to work on MCU support and stuff 
 while delegating most compiler tweaks to mentor(s) and core 
 team.

 b) Get a student interested in compilers to deliver on getting 
 robust cross-compiler with minimal run-time. Getting actual 
 boards to work is then delegated to mentors.

 I am in favor of a).


I've found that I can only get so far with a), unless you are 
willing to be rather tolerant with what D currently offers.  It 
could be enough for a summer project, though, and I suppose it 
could help highlight some of D's current shortcomings in this 
domain.  Eventually, though, a) will need b), and I think b) 
cannot be done properly without changes in the compiler.

Mike
Jan 09 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/12/2014 4:25 p.m., Craig Dillabaugh wrote:

 I was hoping folks to take a brief break from bickering about features,
 and arguing over which posters have been naughty, and which have been
 nice, to get a bit of input on our 2015 Google Summer of Code Proposal
 ... :o)


 First off, I've been able to get some work done on the Idea's page, it
 is here:

 http://wiki.dlang.org/GSOC_2015_Ideas

 This is the most important part of our submission, but we are also
 supposed to submit a organizational proposal.  I've started on this too
 (still under construction, and have put it on Github at:

 https://github.com/craig-dillabaugh/dlang-gsoc2015

 Any feedback is welcome.


 There are currently six project proposals.  I think it would be good to
 have one or two more, and the ones that are there need a bit of
 polishing. A lot of what is there is stuff I have 'harvested' from
 previous proposals. For the GDC and Bare Metal D/Arm Support projects I
 am not even sure if the items listed are still needed since these are
 basically cut and paste jobs from 1 or 2 years ago.

 A few specific questions that I need answered.

 General Questions

 1) I would like to include bio's for the mentors.  I have a very short
 one for Iain (which I stole from DConf) and a line on Deadalinx, but
 that is about that.  If you are a mentor I would really appreciate a
 brief 3-4 line bio. I think this makes our 'ideas' page stand out from
 others I have seen. Any mentors please provide bios, or if you are
 uncomfortable with that please let me know.

 2) For all projects, in addition to mentor bios I want to have a section
 on what students should know (or be willing to learn), you can see SDC
 for an example. Could other potential mentors please fill me on your
 projects.  Basically, if you can give pointers to a few good resources
 for someone interested in your project that would be great.

 3) I would like to have a 'backup' mentor for each project.  Any
 volunteers! I think we have enough for the Phobos project, but other
 projects could really use something.

 4) Finally, I should have a backup administrator.  Any volunteers for that.


 Questions for Specific Individuals

 5) For GDC, can Iain (or someone else related to that project) update
 the wiki, post something here, or get in touch with me to update the
 project proposal.



 7) Bruno Medeiros - you suggested a DDT project. I've added it. Can you
 provide me with a few more details, and a bio.   Also, under what
 license is DDT released, I couldn't access any code on your GitHub page
 to check this.



 9) For the Phobos proposal, most of this is scrapped from last years
 proposal and from posts on the form by Jens and Russel. Are the
 libraries I've listed indeed the ones in need of the most attention.
 What about std.xml and std.json?

 10) Rikki had mentioned a 'Web Development' project, but I don't have
 enough to post on the project ideas page.  Are you still interested in
 doing this.


Yes I am.
I don't know what I'm doing in the near future (need a job) so I can't 
explore this too much.
But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to your feedback.

 Cheers,

 Craig
Dec 31 2014
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki Cattermole 
wrote:
clip


 10) Rikki had mentioned a 'Web Development' project, but I 
 don't have
 enough to post on the project ideas page.  Are you still 
 interested in
 doing this.


 Yes I am.
 I don't know what I'm doing in the near future (need a job) so 
 I can't explore this too much.
 But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to 
 your feedback.

 Cheers,

 Craig




It would be great to have you as a mentor, but we definitely need 
fairly solidly defined projects.  Any chance you can come up with 
something by the end of January.

Craig
Jan 02 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/01/2015 4:30 a.m., Craig Dillabaugh wrote:

 On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki Cattermole wrote:
 clip


 10) Rikki had mentioned a 'Web Development' project, but I don't have
 enough to post on the project ideas page.  Are you still interested in
 doing this.


 Yes I am.
 I don't know what I'm doing in the near future (need a job) so I can't
 explore this too much.
 But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to your
 feedback.

 Cheers,

 Craig




 It would be great to have you as a mentor, but we definitely need fairly
 solidly defined projects.  Any chance you can come up with something by
 the end of January.

 Craig


Indeed.
I created a list for Cmsed 
https://github.com/rikkimax/Cmsed/wiki/Road-map#what-does-other-web-service-frameworks-offer
Right now it basically comes down to e.g. QR code, bar code, PDF.
QR and bar code isn't that hard. Not really a GSOC project.
PDF definitely is worthy.

PDF is an interesting case, it needs e.g. PostScript support. And 
preferably image and font loading/exporting.
So it might be a good worth while project. As it expands out into 
numerous other projects.
Jan 02 2015
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Saturday, 3 January 2015 at 00:15:42 UTC, Rikki Cattermole 
wrote:

 On 3/01/2015 4:30 a.m., Craig Dillabaugh wrote:

 On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki Cattermole 
 wrote:
 clip


 10) Rikki had mentioned a 'Web Development' project, but I 
 don't have
 enough to post on the project ideas page.  Are you still 
 interested in
 doing this.


 Yes I am.
 I don't know what I'm doing in the near future (need a job) 
 so I can't
 explore this too much.
 But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to 
 your
 feedback.

 Cheers,

 Craig




 It would be great to have you as a mentor, but we definitely 
 need fairly
 solidly defined projects.  Any chance you can come up with 
 something by
 the end of January.

 Craig


 Indeed.
 I created a list for Cmsed 
 https://github.com/rikkimax/Cmsed/wiki/Road-map#what-does-other-web-service-frameworks-offer
 Right now it basically comes down to e.g. QR code, bar code, 
 PDF.
 QR and bar code isn't that hard. Not really a GSOC project.
 PDF definitely is worthy.

 PDF is an interesting case, it needs e.g. PostScript support. 
 And preferably image and font loading/exporting.
 So it might be a good worth while project. As it expands out 
 into numerous other projects.


Thanks.  Would you like to add something to the Wiki, or would 
you prefer if I did so.  Also, what license are you using?

Cheers,
Craig
Jan 02 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/01/2015 3:59 p.m., Craig Dillabaugh wrote:

 On Saturday, 3 January 2015 at 00:15:42 UTC, Rikki Cattermole wrote:

 On 3/01/2015 4:30 a.m., Craig Dillabaugh wrote:

 On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki Cattermole wrote:
 clip


 10) Rikki had mentioned a 'Web Development' project, but I don't have
 enough to post on the project ideas page.  Are you still interested in
 doing this.


 Yes I am.
 I don't know what I'm doing in the near future (need a job) so I can't
 explore this too much.
 But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to your
 feedback.

 Cheers,

 Craig




 It would be great to have you as a mentor, but we definitely need fairly
 solidly defined projects.  Any chance you can come up with something by
 the end of January.

 Craig


 Indeed.
 I created a list for Cmsed
 https://github.com/rikkimax/Cmsed/wiki/Road-map#what-does-other-web-service-frameworks-offer

 Right now it basically comes down to e.g. QR code, bar code, PDF.
 QR and bar code isn't that hard. Not really a GSOC project.
 PDF definitely is worthy.

 PDF is an interesting case, it needs e.g. PostScript support. And
 preferably image and font loading/exporting.
 So it might be a good worth while project. As it expands out into
 numerous other projects.


 Thanks.  Would you like to add something to the Wiki, or would you
 prefer if I did so.  Also, what license are you using?

 Cheers,
 Craig


When it comes to my open source code bases I have two rules.
- If you use it commercially at the very least donate what its worth to you.
- For non commercial, as long as I'm not held liable you are free to use 
it in any way you want. At the very least, get involved e.g. PR's, issues.
So liberal licenses like MIT, BSD. Which are compatible with e.g. BOOST.

Please do write up a skeleton for me on the wiki. I can pad it out. Will 
help to keep things consistent.
Jan 02 2015
next sibling parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Saturday, 3 January 2015 at 03:33:29 UTC, Rikki Cattermole 
wrote:

 On 3/01/2015 3:59 p.m., Craig Dillabaugh wrote:

 On Saturday, 3 January 2015 at 00:15:42 UTC, Rikki Cattermole 
 wrote:

 On 3/01/2015 4:30 a.m., Craig Dillabaugh wrote:

 On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki 
 Cattermole wrote:
 clip


 10) Rikki had mentioned a 'Web Development' project, but I 
 don't have
 enough to post on the project ideas page.  Are you still 
 interested in
 doing this.


 Yes I am.
 I don't know what I'm doing in the near future (need a job) 
 so I can't
 explore this too much.
 But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to 
 your
 feedback.

 Cheers,

 Craig




 It would be great to have you as a mentor, but we definitely 
 need fairly
 solidly defined projects.  Any chance you can come up with 
 something by
 the end of January.

 Craig


 Indeed.
 I created a list for Cmsed
 https://github.com/rikkimax/Cmsed/wiki/Road-map#what-does-other-web-service-frameworks-offer

 Right now it basically comes down to e.g. QR code, bar code, 
 PDF.
 QR and bar code isn't that hard. Not really a GSOC project.
 PDF definitely is worthy.

 PDF is an interesting case, it needs e.g. PostScript support. 
 And
 preferably image and font loading/exporting.
 So it might be a good worth while project. As it expands out 
 into
 numerous other projects.


 Thanks.  Would you like to add something to the Wiki, or would 
 you
 prefer if I did so.  Also, what license are you using?

 Cheers,
 Craig


 When it comes to my open source code bases I have two rules.
 - If you use it commercially at the very least donate what its 
 worth to you.
 - For non commercial, as long as I'm not held liable you are 
 free to use it in any way you want. At the very least, get 
 involved e.g. PR's, issues.
 So liberal licenses like MIT, BSD. Which are compatible with 
 e.g. BOOST.

 Please do write up a skeleton for me on the wiki. I can pad it 
 out. Will help to keep things consistent.


I will try to add something in the coming days (hopefully by 
mid-week). However, I believe you have to pick a specific OSI 
approved license for the project for it to be considered for GSOC.
Jan 05 2015
prev sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Saturday, 3 January 2015 at 03:33:29 UTC, Rikki Cattermole 
wrote:

 On 3/01/2015 3:59 p.m., Craig Dillabaugh wrote:

 On Saturday, 3 January 2015 at 00:15:42 UTC, Rikki Cattermole 
 wrote:

 On 3/01/2015 4:30 a.m., Craig Dillabaugh wrote:

 On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki 
 Cattermole wrote:
 clip


 10) Rikki had mentioned a 'Web Development' project, but I 
 don't have
 enough to post on the project ideas page.  Are you still 
 interested in
 doing this.


 Yes I am.
 I don't know what I'm doing in the near future (need a job) 
 so I can't
 explore this too much.
 But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to 
 your
 feedback.

 Cheers,

 Craig




 It would be great to have you as a mentor, but we definitely 
 need fairly
 solidly defined projects.  Any chance you can come up with 
 something by
 the end of January.

 Craig


 Indeed.
 I created a list for Cmsed
 https://github.com/rikkimax/Cmsed/wiki/Road-map#what-does-other-web-service-frameworks-offer

 Right now it basically comes down to e.g. QR code, bar code, 
 PDF.
 QR and bar code isn't that hard. Not really a GSOC project.
 PDF definitely is worthy.

 PDF is an interesting case, it needs e.g. PostScript support. 
 And
 preferably image and font loading/exporting.
 So it might be a good worth while project. As it expands out 
 into
 numerous other projects.


 Thanks.  Would you like to add something to the Wiki, or would 
 you
 prefer if I did so.  Also, what license are you using?

 Cheers,
 Craig


 When it comes to my open source code bases I have two rules.
 - If you use it commercially at the very least donate what its 
 worth to you.
 - For non commercial, as long as I'm not held liable you are 
 free to use it in any way you want. At the very least, get 
 involved e.g. PR's, issues.
 So liberal licenses like MIT, BSD. Which are compatible with 
 e.g. BOOST.

 Please do write up a skeleton for me on the wiki. I can pad it 
 out. Will help to keep things consistent.


Rikki.  I've updated the Wiki to include a Cmsed entry:

http://wiki.dlang.org/GSOC_2015_Ideas#Cmsed

Please have a look and fill it out a bit more.  Also, I added a 
stub for your bio - you may want to update (and possibly correct) 
it :o)
Jan 17 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 18/01/2015 3:57 p.m., Craig Dillabaugh wrote:

 On Saturday, 3 January 2015 at 03:33:29 UTC, Rikki Cattermole wrote:

 On 3/01/2015 3:59 p.m., Craig Dillabaugh wrote:

 On Saturday, 3 January 2015 at 00:15:42 UTC, Rikki Cattermole wrote:

 On 3/01/2015 4:30 a.m., Craig Dillabaugh wrote:

 On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki Cattermole wrote:
 clip


 10) Rikki had mentioned a 'Web Development' project, but I don't
 have
 enough to post on the project ideas page.  Are you still
 interested in
 doing this.


 Yes I am.
 I don't know what I'm doing in the near future (need a job) so I
 can't
 explore this too much.
 But I know I will be able to mentor for it.


 Hope that everyone has a great 2015, and I look forward to your
 feedback.

 Cheers,

 Craig




 It would be great to have you as a mentor, but we definitely need
 fairly
 solidly defined projects.  Any chance you can come up with
 something by
 the end of January.

 Craig


 Indeed.
 I created a list for Cmsed
 https://github.com/rikkimax/Cmsed/wiki/Road-map#what-does-other-web-service-frameworks-offer


 Right now it basically comes down to e.g. QR code, bar code, PDF.
 QR and bar code isn't that hard. Not really a GSOC project.
 PDF definitely is worthy.

 PDF is an interesting case, it needs e.g. PostScript support. And
 preferably image and font loading/exporting.
 So it might be a good worth while project. As it expands out into
 numerous other projects.


 Thanks.  Would you like to add something to the Wiki, or would you
 prefer if I did so.  Also, what license are you using?

 Cheers,
 Craig


 When it comes to my open source code bases I have two rules.
 - If you use it commercially at the very least donate what its worth
 to you.
 - For non commercial, as long as I'm not held liable you are free to
 use it in any way you want. At the very least, get involved e.g. PR's,
 issues.
 So liberal licenses like MIT, BSD. Which are compatible with e.g. BOOST.

 Please do write up a skeleton for me on the wiki. I can pad it out.
 Will help to keep things consistent.


 Rikki.  I've updated the Wiki to include a Cmsed entry:

 http://wiki.dlang.org/GSOC_2015_Ideas#Cmsed

 Please have a look and fill it out a bit more.  Also, I added a stub for
 your bio - you may want to update (and possibly correct) it :o)


Fun fact, we have more cows now then sheep.
Sorry to disappoint.
Jan 18 2015
parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Sunday, 18 January 2015 at 09:09:19 UTC, Rikki Cattermole
wrote:

 Rikki.  I've updated the Wiki to include a Cmsed entry:

 http://wiki.dlang.org/GSOC_2015_Ideas#Cmsed

 Please have a look and fill it out a bit more.  Also, I added 
 a stub for
 your bio - you may want to update (and possibly correct) it :o)


 Fun fact, we have more cows now then sheep.
 Sorry to disappoint.


No way!  Well, I learned something new.  You will have to work
that into your Bio.

Thanks.
Craig
Jan 18 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 19/01/2015 12:29 p.m., CraigDillabaugh wrote:

 On Sunday, 18 January 2015 at 09:09:19 UTC, Rikki Cattermole
 wrote:

 Rikki.  I've updated the Wiki to include a Cmsed entry:

 http://wiki.dlang.org/GSOC_2015_Ideas#Cmsed

 Please have a look and fill it out a bit more.  Also, I added a stub for
 your bio - you may want to update (and possibly correct) it :o)


 Fun fact, we have more cows now then sheep.
 Sorry to disappoint.


 No way!  Well, I learned something new.  You will have to work
 that into your Bio.

 Thanks.
 Craig


I think I did pretty good with how it is right now.
So I think I'll leave that part out.
Jan 18 2015
prev sibling next sibling parent reply "Mathias LANG" <geod24 gmail.com> writes:
On Wednesday, 31 December 2014 at 03:25:53 UTC, Craig Dillabaugh 
wrote:

 I was hoping folks to take a brief break from bickering about 
 features, and arguing over which posters have been naughty, and 
 which have been nice, to get a bit of input on our 2015 Google 
 Summer of Code Proposal  ... :o)


Thanks for doing this, we definitely need more manpower.
I would be willing to mentor something related to Vibe.d, however 
I don't have anything to propose ATM. Bt if you find something, 
feel free to email me.

There was a discussion about redesigning the dlang.org. It looks 
like there's some WIP ( https://github.com/w0rp/new-dlang.org ), 
but I didn't follow the discussion closely enough (and it's now 
around 400 posts).
Could it be a possible project, provided that such project would 
have to be done in D ?
Jan 03 2015
parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Saturday, 3 January 2015 at 16:17:44 UTC, Mathias LANG wrote:

 On Wednesday, 31 December 2014 at 03:25:53 UTC, Craig 
 Dillabaugh wrote:

 I was hoping folks to take a brief break from bickering about 
 features, and arguing over which posters have been naughty, 
 and which have been nice, to get a bit of input on our 2015 
 Google Summer of Code Proposal  ... :o)


 Thanks for doing this, we definitely need more manpower.
 I would be willing to mentor something related to Vibe.d, 
 however I don't have anything to propose ATM. Bt if you find 
 something, feel free to email me.

 There was a discussion about redesigning the dlang.org. It 
 looks like there's some WIP ( 
 https://github.com/w0rp/new-dlang.org ), but I didn't follow 
 the discussion closely enough (and it's now around 400 posts).
 Could it be a possible project, provided that such project 
 would have to be done in D ?


Rikki wants to do D web development (see this thread), and his
project is using Vibe D.  Perhaps you can check it out.  Do you
think you might be interested in serving as the backup mentor for
that one?

As for the web page, that would possibly be a tough sell to Google
if they consider it more of a 'documentation' project than a
'coding' project, since they explicitly state that documentation
projects are not allowed (I was considering suggesting a Phobos
documentation project submission, so did a bit of research on 
that).

However, there has been some talk of improvements to DDOC around 
here,
maybe something could be cooked up there ... we still have a bit
more than a month to get projects lined up.
Jan 05 2015
prev sibling next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:



Should we drop QML support from our GSOC due to:

http://forum.dlang.org/thread/hapeegrotkazppwdnstk forum.dlang.org
Jan 10 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2015-01-10 at 19:30 +0000, Craig Dillabaugh via Digitalmars-d wrote:

 

 


 Should we drop QML support from our GSOC due to:
 
 http://forum.dlang.org/thread/hapeegrotkazppwdnstk forum.dlang.org
 


Or promote it even more with "filcuc" as a co-mentor as it is active 
and something can come of it?

-- 
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
Jan 11 2015
parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Sunday, 11 January 2015 at 12:53:53 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Sat, 2015-01-10 at 19:30 +0000, Craig Dillabaugh via 
 Digitalmars-d wrote:

 

 


 Should we drop QML support from our GSOC due to:
 
 http://forum.dlang.org/thread/hapeegrotkazppwdnstk forum.dlang.org
 


 Or promote it even more with "filcuc" as a co-mentor as it is 
 active
 and something can come of it?


Sounds good.  I will see if filcuc is interested in being a 
Mentor.
Jan 12 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2015-01-12 at 15:16 +0000, CraigDillabaugh via Digitalmars-d wrote:

 […]
 
 Sounds good.  I will see if filcuc is interested in being a Mentor.


I am happy to be the backup mentor for this one.

-- 
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
Jan 12 2015
parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Monday, 12 January 2015 at 15:28:01 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Mon, 2015-01-12 at 15:16 +0000, CraigDillabaugh via 
 Digitalmars-d wrote:

 […]
 
 Sounds good.  I will see if filcuc is interested in being a 
 Mentor.


 I am happy to be the backup mentor for this one.


Great.  Thank you.
Jan 12 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 31/12/2014 03:25, Craig Dillabaugh wrote:

 7) Bruno Medeiros - you suggested a DDT project. I've added it. Can you
 provide me with a few more details, and a bio.   Also, under what
 license is DDT released, I couldn't access any code on your GitHub page
 to check this.


Bio:
Lead developer of DDT - the Eclipse D IDE - on and off from as far back 
as 2008. Has an interest in toolchain development for upcoming languages 
such as D, particularly the development of IDEs and IDE semantic 
functionality. Professionally, works mainly with core Java and Eclipse 
RCP technologies - currently on R&D projects.


DDT is released under the Eclipse Public License. (one tiny component is 
Apache License)  And yup, several source files still need to be cleaned 
up to include the license info, I've been a bit lax with that in the past.


DDT core engine ideas (only core Java knowledge needed):
* Make the DDT semantic engine available as a command-line daemon tool 
(similar to DCD).
* Add support for source formatting (with formatting options).
* Add support for semantic search in the semantic engine (search symbols 
by name and type (for example: "where in my code is the function 
std.stdio.writeln called?", or "which classes in my code subclass this 
given class?") .
* Improve semantic engine / code completion capabilities (for example, 
understand template instantiation, function overloads, etc.)


DDT Eclipse specific ideas:
* Improve/add UI support for DUB multiple build configurations + launch.
* Reduce usages of DLTK code, possibly refactoring or rewriting DLTK 
functionality into an IDE-neutral layer (LangEclipseIDE).
* Add support for continuous build mode (build and report errors on the 
fly).

Some of the items in both lists are a bit small for GSoC, so they might 
have to be combined with others.

The good news is that this year with DDT there is a lot more 
opportunities with core Java tasks only, which should make it easier for 
a newbie to join in and contribute. But realistically, it's a long shot 
that we'll get a candidate of quality for this proposal - Java interest 
doesn't rank high in the D community... ^_^'

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jan 13 2015
next sibling parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 13 January 2015 at 12:23:16 UTC, Bruno Medeiros wrote:

 On 31/12/2014 03:25, Craig Dillabaugh wrote:

 7) Bruno Medeiros - you suggested a DDT project. I've added 
 it. Can you
 provide me with a few more details, and a bio.   Also, under 
 what
 license is DDT released, I couldn't access any code on your 
 GitHub page
 to check this.


 Bio:
 Lead developer of DDT - the Eclipse D IDE - on and off from as 
 far back as 2008. Has an interest in toolchain development for 
 upcoming languages such as D, particularly the development of 
 IDEs and IDE semantic functionality. Professionally, works 
 mainly with core Java and Eclipse RCP technologies - currently 
 on R&D projects.


 DDT is released under the Eclipse Public License. (one tiny 
 component is Apache License)  And yup, several source files 
 still need to be cleaned up to include the license info, I've 
 been a bit lax with that in the past.


 DDT core engine ideas (only core Java knowledge needed):
 * Make the DDT semantic engine available as a command-line 
 daemon tool (similar to DCD).
 * Add support for source formatting (with formatting options).
 * Add support for semantic search in the semantic engine 
 (search symbols by name and type (for example: "where in my 
 code is the function std.stdio.writeln called?", or "which 
 classes in my code subclass this given class?") .
 * Improve semantic engine / code completion capabilities (for 
 example, understand template instantiation, function overloads, 
 etc.)


 DDT Eclipse specific ideas:
 * Improve/add UI support for DUB multiple build configurations 
 + launch.
 * Reduce usages of DLTK code, possibly refactoring or rewriting 
 DLTK functionality into an IDE-neutral layer (LangEclipseIDE).
 * Add support for continuous build mode (build and report 
 errors on the fly).

 Some of the items in both lists are a bit small for GSoC, so 
 they might have to be combined with others.

 The good news is that this year with DDT there is a lot more 
 opportunities with core Java tasks only, which should make it 
 easier for a newbie to join in and contribute. But 
 realistically, it's a long shot that we'll get a candidate of 
 quality for this proposal - Java interest doesn't rank high in 
 the D community... ^_^'


Thank you very much.
Jan 13 2015
prev sibling parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 13 January 2015 at 12:23:16 UTC, Bruno Medeiros wrote:

 On 31/12/2014 03:25, Craig Dillabaugh wrote:

 7) Bruno Medeiros - you suggested a DDT project. I've added 
 it. Can you
 provide me with a few more details, and a bio.   Also, under 
 what
 license is DDT released, I couldn't access any code on your 
 GitHub page
 to check this.


 The good news is that this year with DDT there is a lot more 
 opportunities with core Java tasks only, which should make it 
 easier for a newbie to join in and contribute. But 
 realistically, it's a long shot that we'll get a candidate of 
 quality for this proposal - Java interest doesn't rank high in 
 the D community... ^_^'


Hey, but if you are a glass half full type, then you would say 
that we have a much better chance of getting a good candidate for 
this project because there are so many Java programmers out there.
Jan 13 2015