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.

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

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

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

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

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

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

>
> 8) Russel Winder and QML ... see #4.
>
Should we drop QML support from our GSOC due to:

http://forum.dlang.org/thread/hapeegrotkazppwdnstk@forum.dlang.org

On Sat, 2015-01-10 at 19:30 +0000, Craig Dillabaugh via Digitalmars-d wrote:
> > 
> > 8) Russel Winder and QML ... see #4.
> > 
> 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

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:
>> > 
>> > 8) Russel Winder and QML ... see #4.
>> > 
>> 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.