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.

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

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.

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

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.)

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 ?

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

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.

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.

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.