Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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)
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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 RD 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.
Re: GSOC - Holiday Edition
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 RD 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
Re: GSOC - Holiday Edition
On Sunday, 11 January 2015 at 12:53:53 UTC, Russel Winder via Digitalmars-d wrote: On Sat, 2015-01-10 at 19:30 +, 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/hapeegrotkazppwdn...@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.
Re: GSOC - Holiday Edition
On Mon, 2015-01-12 at 15:16 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: GSOC - Holiday Edition
On Monday, 12 January 2015 at 15:28:01 UTC, Russel Winder via Digitalmars-d wrote: On Mon, 2015-01-12 at 15:16 +, 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.
Re: GSOC - Holiday Edition
On Sat, 2015-01-10 at 19:30 +, 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/hapeegrotkazppwdn...@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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: GSOC - Holiday Edition
8) Russel Winder and QML ... see #4. Should we drop QML support from our GSOC due to: http://forum.dlang.org/thread/hapeegrotkazppwdn...@forum.dlang.org
Re: Bare-metal programming in D (was GSOC - Holiday Edition)
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
Re: Bare-metal programming in D (was GSOC - Holiday Edition)
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
Bare-metal programming in D (was GSOC - Holiday Edition)
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
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
Am Mon, 05 Jan 2015 15:08:32 +0100 schrieb Martin Nowak code+news.digitalm...@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 ;-)
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
Am Sun, 04 Jan 2015 18:25:32 +0100 schrieb Martin Nowak code+news.digitalm...@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.
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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-1227...@https.d.puremagic.com%2Fissues%2F
Re: GSOC - Holiday Edition
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 ?
Re: GSOC - Holiday Edition
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.)
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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?
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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.
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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. 6) See #2 for Martin Nowak and the Bare Metal D/Arm projects. I probably could expand on that if desired. -- Dmitry Olshansky
Re: GSOC - Holiday Edition
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. 6) See #2 for Martin Nowak and the Bare Metal D/Arm projects. 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.
Re: GSOC - Holiday Edition
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
Re: GSOC - Holiday Edition
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. 6) See #2 for Martin Nowak and the Bare Metal D/Arm projects. 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. 8) Russel Winder and QML ... see #4. 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
GSOC - Holiday Edition
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. 6) See #2 for Martin Nowak and the Bare Metal D/Arm projects. 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. 8) Russel Winder and QML ... see #4. 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
Re: GSOC - Holiday Edition
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. 8) Russel Winder and QML ... see #4. When I said see #4, I meant #7.
Re: GSOC - Holiday Edition
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...)
Re: GSOC - Holiday Edition
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.
