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