Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye
On Saturday, 5 August 2017 at 20:08:39 UTC, WebFreak001 wrote: I just clicked through some random files in the example folder, this line seems broken: https://github.com/JinShil/svd_to_d/blob/master/examples/atsamd21g18a/AC.d#L13 Fixed. Thanks!
Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye
On Tuesday, 1 August 2017 at 20:11:13 UTC, Taylor Hillegeist wrote: Reminds me of something I put together a while ago. https://github.com/taylorh140/SVD_TO_D But this looks much nicer, nice work! ha ha! Even the pattern used in our code is similar. I swear I never saw it before. Looking at your code though, I probably should have used Adam's dom.d too; std.xml was weird to say the least. Mike
Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye
On Tuesday, 1 August 2017 at 19:04:44 UTC, Johannes Pfau wrote: SVD seems to be an ARM standard / initiative? Yeah, ARM appears to maintain the XML schema, but the SVD files are usually created and distributed by the silicon vendors, in varying levels of quality, unfortunately. Mike
Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye
On Tuesday, 1 August 2017 at 14:52:51 UTC, Steven Schveighoffer wrote: Mike, I have to say still your talk in 2014 was one of my favorites. One of the things that was so impressive to me was the way you scraped the PDF to generate all the registers automatically. Having worked with STM chips (not ARM, but really basic 8-bit versions), I can definitely appreciate all the work this saves. I'm not sure my work is worthy of such kind words, but thank you. The PDF screen utility is here: https://github.com/JinShil/stm32_datasheet_to_d. I'm not sure if it still compiles and works, but I might need to update it someday. It generates much better code and more complete documentation than svd_to_d. Most silicon vendors don't appear to invest much into their SVD files, so the SVD files are often incomplete and lacking the documentation that makes "good code + a good IDE = a substitute for the datasheet". If I were creating a professional product, I'd probably prefer scraping the PDF over using the SVD files, or maybe some way to merge the two. Mike
Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye
On Monday, 31 July 2017 at 08:51:16 UTC, Mike wrote: The code generated by SVD_to_D depends on this memory-mapped-IO library: https://github.com/JinShil/memory_mapped_io That library uses D's CTFE and meta-programming features to generate highly optimized code (for both size and speed) at compile-time with additional features such as type safety and compile-time-enforced mutability. By the way, there are a couple of bugs that are preventing me from perfecting the memory-mapped-IO library. It'd be great to have them addressed. https://issues.dlang.org/show_bug.cgi?id=12496 https://issues.dlang.org/show_bug.cgi?id=17684 Thanks, Mike
SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye
https://github.com/JinShil/svd_to_d SVD_to_D is a command-line utility that generates D code from ARM Cortex-M SVD files. SVD files are XML files that describe, in great detail, the memory layout and characteristics of registers in an ARM Cortex-M microcontroller. See https://github.com/posborne/cmsis-svd/tree/master/data for a curated list of SVD files for many ARM Cortex-M microcontrollers from various silicon vendeors. From the information in an SVD file, code for accessing the microcontroller's memory-mapped-io registers can be automatically generated, and SVD_to_D does exactly that. For a large microcontroller like the SM32F7, the amount of code generated can be more than 100k lines. See an example of generated D code here: https://github.com/JinShil/svd_to_d/tree/master/examples/stm32f7x9 The code generated by SVD_to_D depends on this memory-mapped-IO library: https://github.com/JinShil/memory_mapped_io That library uses D's CTFE and meta-programming features to generate highly optimized code (for both size and speed) at compile-time with additional features such as type safety and compile-time-enforced mutability. Enjoy! Mike
Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept
On Thursday, 20 July 2017 at 17:09:40 UTC, Mr.D wrote: Thanks for your work with bare metal MCUs! I am dreaming that someday I can program smart house IoT automation on D. You already can; it just may not be the most professional experience. If you have the hardware and the time, do it! Mike
Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept
A few years ago I created a bare metal demo on an ARM Cortex-M4 microcontroller entirely in D. It was just a demonstration that one could do bare metal programming for microcontrollers in D without any dependencies on C or assembly. It was also a proof of some ideas I had about leveraging compile-time features of D to generate highly-optimized code (both small and fast) for these resource constrained systems. I hit a wall, however, with Issue 14758[0], and ultimately abandoned D for other alternatives. Well, that issue was recently fixed in GDC [1]. In addition, he GDC developers did some work to reduce the number of phony stubs one had to add to the runtime to get a build [2], removed the "shared is volatile" hack, and implemented the `volatileLoad/Store` intrinsics so I no longer need to do volatile access in assembly. So, I decided to give it another try, and updated that demo. You can see the results at https://github.com/JinShil/stm32f42_discovery_demo A few observations: * It is a better experience than it was a few years ago. Fewer dirty hacks are required, and the resulting binary is small and fast. * Everything is in D (inline assembly is D). There's no need for any C or assembly startup code, and no need for silly things like -betterC (i.e. -worseD). If you don't want the overhead from a feature of D, don't use it. * Compile times are quite slow (about 1 minute to get a 3kB binary). Some discussion about that is taking place on the GDC forum [4]. * -O2 and -O3 give me a broken binary, but -O0, -O1, and -Os work well. I'm not sure where I'll go from here. I'm interested in helping an amputee play the drums again, and building my own mechanical keyboard, so I probably won't be spending much more time on this LCD demo, except maybe to help compiler devs debug some issues. However, I might spend some more time with D in the near future, and see how far I can take this. I'm still not as excited as I once was, but it's nice to see these improvements. Anyway, Well done, GDC! Mike [0] - TypeInfo causes excessive binary bloat - https://issues.dlang.org/show_bug.cgi?id=14758 [1] - Put the TypeInfo name field into a static var - https://github.com/D-Programming-GDC/GDC/pull/505 [2] - Refactor and reformat typeinfo.cc - https://github.com/D-Programming-GDC/GDC/pull/456 [3] - Slow compile-time discussion at GDC forum - http://forum.dlang.org/post/iqryqssxooypdnszm...@forum.dlang.org
Re: two points
On Thursday, 9 February 2017 at 17:45:15 UTC, Nick Sabalausky wrote: No. There should be appropriate checks and reviews, yes. But, no, every little fix and improvement shouldn't feel like trying to get somewhere in a year-long tabs vs spaces debate or making a big-budget sales pitch to Indecisives Anonymous. Yep! There are currently 165 poor sinners in DMD PR purgatory. The oldest is going on 5 years, waiting on someone to make a decision whether to use "-version", "-versions", "-dversion", or "-version=?". Then, it would have to be rebased, and languish again for another indeterminate amount of time. I wouldn't be at all surprised if the original contributor has moved on; I would have 4 years ago. Mike
Re: Questionnaire
On Thursday, 9 February 2017 at 10:38:11 UTC, Johannes Pfau wrote: But OTOH I'm an electrical engineer as well ;-) Haha! Then this (https://www.youtube.com/watch?v=D7Sd8A6_fYU=youtu.be=2389) is for you ;-) "What we know is that C code will compile all sorts of bugs, more so than most languages, and C programmers know this and accept this. This is the world that they live in. So it breeds a very unfortunate mindeset which is: 'Let's just get the code to compile so we can get to the real work which is debugging.'" -- Dan Saks But you're right, C++ is a very complex language and can easily turn into a monstrosity if not done tastefully. Mike
Re: Questionnaire
On Wednesday, 8 February 2017 at 22:52:36 UTC, bpr wrote: On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote: Suggesting D would be an exercise in futility, unless I can create a notable project in D in my spare time that demonstrates its advantages and appeal to the masses. I tried to do this 2 years ago, but D failed me, primarily due to https://issues.dlang.org/show_bug.cgi?id=14758 I read this comment from you on another thread too, and (caveat: I'm not working in such resource constrained domains as you are) it seems sensible. It seems like it may be a good GSOC project to modify dmd as you suggest elsewhere. Have you considered trying to find someone to do that? First, for that to happen, the D leadership would need to chime in with a plan on how they want to address this problem. Second, for me to allocate any more of my resources, I'd have to be convinced that their plan is a good solution to the problem. A -betterC switch is not at all attractive to me. I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory. So, I would not recommend it as a project for anyone until the D leadership decides to get involved. I'd love to see a D3, but that seems unlikely, and more unlikely if D2 languishes. It seems though that your issues are with the implementation, not the language itself, so if you got your wishes below Instead I suggest following through on things like https://issues.dlang.org/show_bug.cgi?id=12270 and considering this proposal (http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org) instead. wouldn't you be mostly satisfied with D2? Correct, my issue is not really with the language, but with its implementation. Resolving issue 12270 and implementing my proposal for decoupling the compiler and druntime would prompt me to further explore D. I'd also like to see how the recent DIP25 and DIP1000 could be leveraged. I'm looking forward to an article on the topic, or Walter's talk at DConf2017 before I dedicate any of my time to it. At first glance, however, it seems like a lot of attribute patchwork. It's become apparent to me that D just hasn't been designed with bare-metal systems programming in mind, so I'm skeptical that even if issue 12270 and my decoupling proposal were implemented, I'd still run into other disappointments. But I'd at least be willing to give it another try, and would be thrilled to be proven wrong. Mike
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: 1. Why your company uses D? We don't use D. 2. Does your company uses C/C++, Java, Scala, Go, Rust? C/C++. Currently exploring Rust. 3. If yes, what the reasons to do not use D instead? * The powers that be in my company are the kind of C programmers that can't understand why anyone would want to use C++ (i.e. Electrical engineers that write software). Suggesting D would be an exercise in futility, unless I can create a notable project in D in my spare time that demonstrates its advantages and appeal to the masses. I tried to do this 2 years ago, but D failed me, primarily due to https://issues.dlang.org/show_bug.cgi?id=14758 * Our customers don't use D. Some of our products are libraries and tools that our customers use. It doesn't make sense to program them in D if our customers don't use D. Though, if D had a minimal runtime, we could write them in D and distribute them with bindings to other languages. * For us, binary size efficiency and minimal runtime are important features. D is not pay-as-you-go; many heavy-weight features are opt-out instead of opt-in. In contrast Rust has "minimal runtime" as one of its pillars making it a much better alternative language choice for us than D. 2. Have you use one of the following Mir projects in production: No 3. If Yes, can Mir community use your company's logo in a section "Used by" or similar. N/A 4. Have you use one of the following Tamedia projects in your production: No 5. What D misses to be commercially successful languages? I believe D has the potential to bury all other emerging languages out there, but only if it drops its historical baggage. At the moment, I'm of the opinion that D will remain an obscure language until someone forks D and takes it in a different direction (unlikely), or the D Foundation decides to "reboot" and start working on D3 with a new, updated perspective (more unlikely). 6. Why many topnotch system projects use C programming language nowadays? Which topnotch system projects? * C is the lowest common denominator. All modern languages that I'm aware of can interface with C. If one wants to write a library for mass adoption, the best way to do so is to write it in C and create bindings for other languages. D could be a good substitute for this if it had a "minimal runtime" philosophy. * C is a simple, efficient, and powerful language. Some equate language complexity and heavy runtimes to bloat and inefficiency. Some see too much language complexity as an impediment to productivity. C creates the appearance of simplicity with efficiency. * "Minimal Runtime" is the building block of systems programming. If this is not a core feature of a language, it will never compete with C. Systems programmers in my field need to incrementally opt-in to features in a pay-as-you-go fashion to make precise tradeoffs for their unique requirements and hardware platforms. Rust is the only modern language that I'm aware of that's getting this right. * You may also be interested Dan Sak's recent talk "extern c: Talking to C Programmers about C++": https://www.youtube.com/watch?v=D7Sd8A6_fYU=2631s
Re: Linker-hacking out the D runtime
On Sunday, 8 January 2017 at 22:14:36 UTC, Iain Buclaw wrote: 1) -fno-rtti should be a flag that is honoured by the compiler. The more I think about it the more I dislike the whole idea of -fno-rtti. All I've ever wanted from the D compiler is to not put code in my binary that has not chance of ever being used. Or, to generate it in a way that can be garbage collected by the linker. If that dream came true, I could avoid RTTI by simply avoiding any feature that needed it (REALLY needed it!) and -fno-rtti would be of no value, except to enforce policy.
Re: Vision document for H1 2017
On Thursday, 5 January 2017 at 02:32:00 UTC, Chris Wright wrote: Templatize dmd <-> druntime API I'm curious as to why. I'm guessing this is for things like creating runtime type information? This thread (http://forum.dlang.org/post/mr7a65$2hc$1...@digitalmars.com) should provide some context. Mike
Re: Linker-hacking out the D runtime
On Monday, 19 December 2016 at 19:53:06 UTC, Iain Buclaw wrote: The compiler doesn't actually generate any code that peeks inside TypeInfo. It only generates the reference to the right typeinfo to pass to library runtime functions - or on request via typeid(). It doesn't actually care about the data stored inside. And that's the angle I've taken when laying out the actual data - if you provide the fields we want to populate, then we'll populate them. If you omit a few, then the compiler won't bother with them. Because at the end of the day, it's druntime library that uses and makes sense of the TypeInfo data provided. The compile just says: "Well, this is as much as I'm willing to tell you about the type." Ok, that's interesting, but what if you don't want TypeInfo at all? Can you omit the TypeInfo structure entirely from object.d? Or perhaps you still need to declare it in object.d, but since the compiler doesn't find any fields to populate, it results in an empty struct? I'd really hate to have to add empty TypeInfo_XXX classes to my object.d though. I'm still wondering about what the programmer would see if they tried to do a dyamic cast (for example) and there was no (or an incomplete) TypeInfo in the runtime. You see, when I started with D, I had a grand plan that I could create a product like Arduino. I would provide a PCB and an accompanying API/SDK to my customers, and they would do the programming. I would have wanted them to have a polished experience when programming my product, so if they were doing something that wasn't supported by the platform, they would receive a friendly compiler message telling them so. I thought that this would be possible if the compiler resolved druntime symbols at compile-time in the same way it does any other library: by reading .di header files. If a symbol was not found, they would get a compiler error telling them so. I could also add templates, static-ifs, and static asserts to the .di files for, not only generating highly optimized code, but also to notify the programmer with more helpful and precise compile-time messages. I also envisioned products with very high resource constraints (like ARM Cortex-M0) without threading, but for high performance microcontrollers (like ARM Cortex-M4/7) I could leverage D's built-in understanding of thead as my RTOS. Each product would, therefore, have very different druntime implementations. I think what you're proposing here by tagging fields is certainly better than what we currently have, and would be desirable for other D users (especially those of late), but does it scale well if I want to deliver a polished programming experience (with optimized code generation) to my customers when my platform only has a subset of D's rich feature set? Mike
Re: Linker-hacking out the D runtime
On Sunday, 18 December 2016 at 12:57:08 UTC, Iain Buclaw wrote: On 18 December 2016 at 03:37, Mike via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote: On Sunday, 18 December 2016 at 00:04:54 UTC, sarn wrote: I thought I'd write something up to help other people experiment with this stuff: https://theartofmachinery.com/2016/12/18/d_without_runtime.html Thanks for this. I abandoned D sometime ago largely because of https://issues.dlang.org/show_bug.cgi?id=14758 (but there were other reasons), so your blog post is interesting to me. It is unfortunate that we have to resort to such hackery, but its nice to have such tools at our disposal regardless. As a response to my last message in that thread, the changes for classinfo generation is now ready to go in master. Just built GDC from the gdc-6 branch. The commit history says master was merged in 24 hours ago, so I'm assuming your ClassInfo changes are there. Anyway the build produces the same result: TypeInfo strings for each an every type in the .rodata section. The binary should be about 6K, but is instead about 600K. Perhaps I'll try again at a later date. Mike
Re: Linker-hacking out the D runtime
On Sunday, 18 December 2016 at 12:57:08 UTC, Iain Buclaw wrote:
As a response to my last message in that thread, the changes
for classinfo generation is now ready to go in master.
Ok, I'll give it a test in the next week or so.
However I already have ideas for future implementation that is
not so naive when it comes to looking up fields to assign data.
How does a kind of tagging system sound?
i.e:
class TypeInfo_Class
{
@name
string classname;
@init
byte[] initializer;
}
I'm assuming this idea addresses the issue with porting druntime
and leaving some features unimplemented. If I understand your
intention, this looks akin to Rust's Lang Items feature
(https://doc.rust-lang.org/book/lang-items.html). Please correct
me if I'm wrong.
I'm not sure what you're envisioning here, so I'd like to hear
more. Would the user get compile-time errors if they used a D
feature that required a druntime implementation, but the
implementation did not exist?
Mike
Re: DIP1000: Scoped Pointers
On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:
If DIP1000 is implemented, it will change that behavior, so
the
allocation will instead be on the GC heap, but the compiler
will do some
flow-control analysis to prevent escaping references. Is that
right?
Mike
Not correct, the class would still be on the stack so we can
have reference semantics during assignment etc, but the
instance is on the stack so its faster and the function the
code is inside can optionally be nogc.
DIP1000 will just make the compiler check that a stack instance
does not escape its scope (though it doesn't cover all cases).
struct Astruct {} // - on stack by default
class Aclass {} // - on heap by default
void main() {
Astruct a = new Astruct; // override, now Astruct is on the
heap
(because of "new")
Aclass c = new Aclass; // on the heap as per-usual
scope Aclass c1 = new Aclass; // override, now class is on
the stack
(most obvious use: to make all references use the same instance)
}
Got it! Thank you! But it still appears that what's illustrated
on the deprecations page is not being deprecated.
Mike
Re: DIP1000: Scoped Pointers
On Wednesday, 17 August 2016 at 07:04:26 UTC, Mike wrote: Or perhaps DIP1000 changes the current behavior of the `scope` storage class. My understanding is that the `scope` storage class currently allocates a class on the stack (though its usage for this purpose is deprecated in favor of std.typecons.scoped). If DIP1000 is implemented, it will change that behavior, so the allocation will instead be on the GC heap, but the compiler will do some flow-control analysis to prevent escaping references. Is that right? I may have found my answer in the DIP, but there is some ambiguity: "Currently, scope is ignored except that a new class use to initialize a scope variable allocates the class instance on the stack. Fortunately, this can work with this new proposal, with an optimization that recognizes that if a new class is unique, and assigned to a scope variable, then that instance can be placed on the stack." "can be placed on the stack", or "will be placed on the stack"? And only "if the new class is unique"? I'm assuming unique mean a new instance with a reference count (for lack of a better word) no greater than 1. Mike
Re: DIP1000: Scoped Pointers
On Wednesday, 17 August 2016 at 06:44:41 UTC, Mike wrote:
On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire
wrote:
Basically DIP1000 makes it so that:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been destroyed
}
Will not compile.
Ok, that makes sense. But then the feature illustrated on the
deprecations page is wrong. I think what has been deprecated
is `scope` as a type modifier, not `scope` as a storage class,
but the example on the deprecations page illustrates the
`scope` storage class, not the type modifier.
I believe what the deprecations page intended to say was that
this has been deprecated:
scope class A
{
this(int x) { }
}
And DIP1000 finally implements the `scope` storage class
properly:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a; // compile-time error. Good!
}
assert(obj.x == 1); // or is it usage that triggers
the compile-time error?
}
Mike
Or perhaps DIP1000 changes the current behavior of the `scope`
storage class.
My understanding is that the `scope` storage class currently
allocates a class on the stack (though its usage for this purpose
is deprecated in favor of std.typecons.scoped). If DIP1000 is
implemented, it will change that behavior, so the allocation will
instead be on the GC heap, but the compiler will do some
flow-control analysis to prevent escaping references. Is that
right?
Mike
Re: DIP1000: Scoped Pointers
On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire wrote:
Basically DIP1000 makes it so that:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been destroyed
}
Will not compile.
Ok, that makes sense. But then the feature illustrated on the
deprecations page is wrong. I think what has been deprecated is
`scope` as a type modifier, not `scope` as a storage class, but
the example on the deprecations page illustrates the `scope`
storage class, not the type modifier.
I believe what the deprecations page intended to say was that
this has been deprecated:
scope class A
{
this(int x) { }
}
And DIP1000 finally implements the `scope` storage class properly:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a; // compile-time error. Good!
}
assert(obj.x == 1); // or is it usage that triggers the
compile-time error?
}
Mike
Re: DIP1000: Scoped Pointers
On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote:
Can you please clarify the current implementation `scope`, and
what DIP1000
proposes to change with respect to the current implementation?
It just adds to the existing compiler implementation of
'scope'. It has nothing to do with std.typecons.scoped.
Ok, but the deprecations page [1] gives this example...
class A
{
int x;
this(int x) { this.x = x; }
}
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been destroyed
}
... as a deprecated pattern, and corrected with ...
class A
{
this(int x) { }
}
void main()
{
auto a = std.typecons.scoped!A(1);
}
However, in DIP1000, the examples use the above deprecated
pattern extensively. So what's the story? Does the deprecations
page [1] need an update?
[1]
http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
Re: DIP1000: Scoped Pointers
On Monday, 15 August 2016 at 04:58:06 UTC, Walter Bright wrote: On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote: Does that actually work in D2? Yes. Can you please clarify the current implementation `scope`, and what DIP1000 proposes to change with respect to the current implementation? According to this [http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack] it was deprecated in favor of std.typecons.scoped. But your previous statement say's scoped variables is still a thing. What exactly is being deprecated with regard to `scope`, if anything? Does the deprecated features page need an update? Will DIP1000 render `std.typecons.scoped` obsolete? In other words, does DIP1000 deprecate the deprecation? Is `scope` being repurposed for DIP1000, or simply expanded? In other words does DIP1000 change the current implementation of scope in any way, or just add to it? Thanks, Mike
Re: Dreams come true: Compiling and running linux apps on windows :)
On Saturday, 6 August 2016 at 17:34:14 UTC, Andre Pany wrote: there is a new feature with the recent windows 10 update. You now can compile and run your linux apps (console only) on windows. For those who might not be aware of this and are looking for a little more info, it's called the "Windows Subsystem for Linux" (WSL) Wikipedia Entry: https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux Microsoft's overview: https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/ Microsoft blog post: https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/ On a related note, Microsoft has also created an open-source MI interface to GDB: https://github.com/Microsoft/MIEngine. You can install the Visual Studio 2015 plugin through Nuget - if I remember correctly it is this plugin: https://visualstudiogallery.msdn.microsoft.com/725025cf-7067-45c2-8d01-1e0fd359ae6e. There's a nice video about it here: https://www.youtube.com/watch?v=-3toI8L3Oug I currently use this to do ARM microcontroller development in Visual Studio 2015 with GCC and OpenOCD. Mike
Re: Dreams come true: Compiling and running linux apps on windows :)
On Sunday, 7 August 2016 at 03:06:27 UTC, Martin Nowak wrote: What OS does it detect and download? $lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04.4 LTS Release:14.04 Codename: trusty
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: We have made the switch from C++ DMD to D DMD! Very Cool! And thank you to all who worked towards it. There are still a number of .h files in the front end. What will happen with those? Do they need to be maintained?
Re: Build It And They Will Not Come
On Tuesday, 18 August 2015 at 19:35:02 UTC, Walter Bright wrote: I hate the movie Field of Dreams where they push the idiotic idea of Build it and they will come. No, they won't. There's a blizzard of stuff competing for their attention out there, why should they invest the time looking at your stuff? You need to tell them why! Here's the frustrating typical pattern I've seen here for years: 1. spend hundreds if not thousands of hours developing something really cool 2. spend 2 minutes posting a link to the repository on D.announce 3. someone posts it to reddit. Ignore it 4. get frustrated that nobody looks at it 5. get bitter and quit I have a number of projects I'd love to blog about, but I'm currently held back by https://issues.dlang.org/show_bug.cgi?id=14758. Perhaps now is not the right time with the transition DDMD on the horizon, but 14758 is currently holding me back, and recently kept me from soliciting D for my employer's most recent venture. I have defaulted back to C/C++, unfortunately. If I could get some support on that issue, I really think I could make a major contribution to D, and perhaps bring an industry with me. Please just bring me the baton, and I will run. Mike
Re: Build It And They Will Not Come
On Thursday, 20 August 2015 at 06:50:51 UTC, Rikki Cattermole wrote: Humm, I wonder if we could strip it out before the final link. I tried a number of things, all discussed on the D.gnu forum (http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org). The only hack that worked some of the time was to compile to assembly, use a sed script to modify the assembly, and then compile the modified assembly. That's pretty ridiculous. I can't go to my employer with that and I don't think anyone will take me seriously if my projects contain such things. A few compiler devs threw me a bone with an -fno-rtti implementation. I am very grateful to those who worked on that and I think it has great value, but it forces me to compromise on slicing, postblit, and a few others, and that severely diminished its appeal. This specific issue, TypeInfo bloat, is just a symptom of a more general problem in the D toolchain, namely, dead code elimination. This is not an opportunity to find clever hacks and workarounds, its an opportunity to improve the compiler and linker. Mike
Re: Voting for std.experimental.allocator
On Wednesday, 8 July 2015 at 11:33:03 UTC, Dicebot wrote: Please respond to this post with a comment starting with a single Yes/No and optional explanation after that. Yes
Re: Beta D 2.068.0-b1
On Thursday, 25 June 2015 at 07:48:24 UTC, Iain Buclaw wrote: More importantly, will all cross-platform regressions introduced in the development cycle of 2.068 be fixed? :-) And, for your convenience the current list of regressions is here: https://issues.dlang.org/buglist.cgi?bug_severity=regressionlist_id=201812resolution=---
Re: More Dconf 2015 videos
On Friday, 26 June 2015 at 18:43:50 UTC, Andrei Alexandrescu wrote: It is planned inasmuch people send pull requests for it. -- Andrei A pull request was submitted a couple of days ago. https://github.com/D-Programming-Language/dconf.org/pull/81 I added these new videos today. There's work getting done would only take a few seconds to review. They just need someone with authority or a subject-matter expert (yes, I know they are in short supply). Just need someone to hit the button: https://github.com/D-Programming-Language/dlang.org/pull/1000 Trivial (10 seconds max), but need a subject matter expert: https://github.com/D-Programming-Language/dlang.org/pull/1022 https://github.com/D-Programming-Language/dlang.org/pull/859 https://github.com/D-Programming-Language/dlang.org/pull/996 https://github.com/D-Programming-Language/druntime/pull/1303 https://github.com/D-Programming-Language/druntime/pull/1302 https://github.com/D-Programming-Language/dmd/pull/4753 Should probably be closed to remove the clutter: https://github.com/D-Programming-Language/dlang.org/pull/1009 Mike
Re: Beta D 2.068.0-b1
On Thursday, 25 June 2015 at 10:30:29 UTC, Martin Nowak wrote: On Wednesday, 24 June 2015 at 23:59:43 UTC, Mike wrote: * If you do wish to pursue it please polish it up and rebase it so it has a chance Which doesn't increase our review capacity, it would make more sense to only spent more effort on a pull on request. * If you see a pull request that can still make it in 2.068, please make a final attempt at a review/merge so it is not delayed for yet another release. No, let's not play that game. Last minute additions are never a good idea and the next release is already coming in 2 month. I hope that more regular releases will help people to get their stuff ready in time. Then please flag things accordingly (milestone 2.068, post-2.068)
Re: Beta D 2.068.0-b1
On Thursday, 25 June 2015 at 10:42:46 UTC, Mike wrote: No, let's not play that game. Last minute additions are never a good idea and the next release is already coming in 2 month. I hope that more regular releases will help people to get their stuff ready in time. Then please flag things accordingly (milestone 2.068, post-2.068) Martin, I see what you said here: ... if it wasn't in master when we merged master into stable it won't be part of the release. I understand now. Please disregard my last statement.
Re: Beta D 2.068.0-b1
On Wednesday, 24 June 2015 at 23:14:05 UTC, Martin Nowak wrote: First beta for the 2.068.0 release. Martin, I saw your post about a potentially using Trello (http://forum.dlang.org/post/55586d5b.8020...@dawg.eu), and I added a link to it on the Wiki (http://wiki.dlang.org/The_D_Programming_Language) under Core Development. At the moment, I don't see anything there (https://trello.com/dlang). Are the board public? If you still plan on making use of it, then, in addition to getting the core team organized, I think it would be a nice place for people to self-serve themselves with information so they can see where things are, and make some reasonable predictions about what's coming and when. Mike
Re: Beta D 2.068.0-b1
On Wednesday, 24 June 2015 at 23:14:05 UTC, Martin Nowak wrote: First beta for the 2.068.0 release. There are 107 open pull requests in DMD, 32 in DRuntime, 78 in phobos, 25 in dlang.org, and a few elsewhere. I've seen a couple that are about 3 years old. I kindly ask... Contributuors: * If you no longer wish to pursue your pull request, please close it * If you do wish to pursue it please polish it up and rebase it so it has a chance Reviwers Committers: * Please close any pull request that has a very low chance of getting merged (e.g. the PR has merge conflicts and the contributor is no longer active) * If you see a pull request that has potential, but not for this release, please flag it with a Post 2.068 tag, so we don't leave the contributor hanging. * If you see a pull request that can still make it in 2.068, please make a final attempt at a review/merge so it is not delayed for yet another release. Thanks, Mike
Re: forum.dlang.org, version 2 (BETA)
On Thursday, 4 June 2015 at 15:04:05 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ messages sent to DMD-Internals don't seem to be appearing in the beta site. Mike
Re: Reggae binary backend: build your project with a D compiled executable
On Saturday, 6 June 2015 at 20:07:22 UTC, Atila Neves wrote: Original discussion: http://forum.dlang.org/post/ranqlmrjornlvopsu...@forum.dlang.org Now, with the `-b binary` option, reggae creates an executable called build in the build directory (i.e. wherever the CWD was when calling the tool) that knows how to build the project. If needed, there is no longer a dependency on make or ninja. I haven't tested it extensively, but it does pass all the other tests I wrote for make and ninja, so it looks good. I like what you're doing with reggae, and I salute the work. I will reiterate my suggestion to consider making Reggae a simple package import so this build functionality can be used in anyone's D program, including the Reggae tool. We already have the ability to generate a binary with the compiler, so the binary backend seems a little redundant. You have all the great features one would need: Targets, dependencies, flags, build driver, etc... so it seems plausible to move some of your driver code to the payload/reggae package to make one's task of building a custom driver trivial. I don't suggest making a libreggae library as a separate repository from the Reggae tool, but rather simply do the refactoring to make payload/reggae folder importable from any D program, including the Reggae tool itself. Mike
Re: Arch Linux D package update
On Thursday, 4 June 2015 at 14:46:39 UTC, Dicebot wrote: gdc - now uses 5.1 gcc base and 2.066.1 frontend - patched to correctly use system zlib library (resulted in linker errors before) dtools - switched back to use dmd as default compiler dub - switched back to use dmd as default compiler dcd - new package, release 0.6.0 - only x86_64 for now (upstream bug) - provides systemd service : `sudo systemctl enable dcd.service` to start automatically upon system startup - provides default /etc/dcd.conf with stdlib paths for Arch Linux Just want to say Thanks! for maintaining these packages (LDC too). The DCD service is nice touch. I'm sure I take this work for granted, but without it, I know it would be a much less pleasant experience using D. Mike
Re: forum.dlang.org, version 2 (BETA)
On Friday, 5 June 2015 at 00:49:48 UTC, Vladimir Panteleev wrote: Consider the space bar's current functionality: it jumps to the next unread post. How would it work in this scheme? Would it go down within a thread and then jump up to the next thread? Or would it keep going down, going through older posts within a thread but newer threads? I think spacebar should just go down the list linearly however they are sorted. An option to reverse sorting direction could be added I suppose, but... why do you say that your proposal seems natural? Is it implemented that way elsewhere? The threaded view is implemented that way, only its split between two pages (page 1 lists threads latest first, page 2 sorts them hierarchically. That's natural to me. The horizontal-split mode (and its sorting direction) is not new, BTW. I know, but I prefer the other views given its current implementation (maybe others do too). But I would prefer the horizontal-split if it worked more like threaded.
Re: forum.dlang.org, version 2 (BETA)
On Thursday, 4 June 2015 at 15:04:05 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ This is really nice. It appears the horizontal split puts the latest thread at the bottom of the list instead of the top. I think that should be reversed. Mike
Re: forum.dlang.org, version 2 (BETA)
On Thursday, 4 June 2015 at 15:04:05 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ In threaded view, when viewing any post except the original post, and then clicking the leaf breadcrumb at the top, the following appears: Post #0 of thread mkpqgo$41n$1...@digitalmars.com not found
Re: forum.dlang.org, version 2 (BETA)
On Friday, 5 June 2015 at 00:37:20 UTC, Vladimir Panteleev wrote: It appears the horizontal split puts the latest thread at the bottom of the list instead of the top. I think that should be reversed. I think not, as that would mean that threads are sorted in one direction, but posts within a thread are sorted in another. That seems natural to me.
Re: Calypso milestone hit: D adaptation of Qt5 tutorial working
On Saturday, 9 May 2015 at 02:31:09 UTC, Elie Morisse wrote: Hi! Calypso just got a D translation of the first Qt5 Widgets tutorial building and running: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d Result: http://homo-nebulus.fr/dlang/oh%20my.webm Compilation log: https://paste.kde.org/pewbbsw45 Previously Calypso was merely able to work with STL types, this is the first time a large C++ library is successfully mapped and used by D code (Ogre3D is probably close as well, but after Kagamin's suggestion and for a change of scene I switched my focus from Ogre3D to Qt). Wow! Game changing work here, IMO! Question: You are using a modified version of LDC, but is that compiler required to consume link to a library created with that custom compiler? What I mean is: Can you use this modified version of LDC to create a library, and then use a generic D compiler to build an application that links to that library? Mike
Re: The hackathon week roundup
On Saturday, 2 May 2015 at 23:02:05 UTC, Andrei Alexandrescu wrote: I'm looking into ways to make this more interactive (google hangouts?) and more fun (contests? prizes? etc). Chime in! My idea: 1. Members of the D leadership/committers form a working group. 2. The working group creates of list of bugs they are willing to work on. 3. Hackathon is announced. To motivate participants, the working group agrees to fix a bug of the winner's choosing. 4. After the hackathon, the working group subjectively chooses a winner from the participants. 5. The winner discloses which bug they would like fixed, and the qualified members of the working group agrees to fix it for the next release. 7. Wash, rinse, repeat. Mike
[Hackathon] ARM Cortex-M LCD Demo
A simple demonstration using D to bare-metal program and ARM Cortex-M microcontroller. Full description with pictures and even a video can be found here: https://github.com/JinShil/stm32f42_discovery_demo/blob/master/README.md I know, random rectangles on a screen is not all that remarkable, but there's quite a bit of work that needs to be done before one can write their first pixel. * Minimal D runtime * Memory-mapped IO features * Clock and flash memory configuration * Software initialization (data and bss segments) * SPI driver to configure the external LCD controller * Internal parallel LCD controller configuration * Hardware random number generator EVERYTHING is in D. I've had this project on the back burner for a while, and the Hackathon gave me the excuse I needed to get it done. I didn't put a lot of effort into the code because I just wanted to get something working to prove some ideas I had, and show that D has some potential in this domain. I hope you find it interesting. Ask me anything. Mike
Re: Heady House Hunting with D
On Wednesday, 14 January 2015 at 03:46:39 UTC, Philpax wrote: Hey everyone, I recently wrote a blog post about how I used D/vibe.d to help find a new house. I haven't publicized it anywhere else yet, so I'm looking forward to what the D community has to say! You can check it out here: http://philpax.me/blog/heady-house-hunting-with-d I love this kind of creative programming to automate an individual and personal need. It's possibilities like this that makes programming so attractive to me. Nice work! and thanks for making it available for everyone to benefit from. Mike
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! Nice work, Adam! (as usual). I'm already looking forward to the next one :) Mike
Re: DConf 2015 Call for Submissions is now open
On Sunday, 11 January 2015 at 20:17:25 UTC, Iain Buclaw via Digitalmars-d-announce wrote: On 10 January 2015 at 20:15, Walter Bright via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 1/10/2015 9:50 AM, Andrei Alexandrescu wrote: On 1/10/15 9:49 AM, Andrei Alexandrescu wrote: On 1/10/15 8:15 AM, Iain Buclaw via Digitalmars-d-announce wrote: In any event, are you doing flash talks this year? I don't think I could find something to spend more than 15 minutes talking about this year. Yes. -- Andrei I should add that gdc is a topic of much interest so pretty much anything you say would be interesting. I compel you to prepare a full talk. -- Andrei I agree. There's no way you don't have interesting things to talk about! For example, what is your process for integrating dmd changes into gdc? What are the advantages/disadvantages of gdc? What are the biggest challenges you face working on gdc? What's the hardest problem you solved with gdc? How can others help out? Etc. Talking about that probably extends a possible talk to 30 minutes, covering two subjects. :o) I have a suggestion for any compiler implementers: How about a talk on how to get started hacking the compiler. Something that may lower the entry barrier and encourage participation. Some random thoughts: * General structure of the compiler * Walk through the data flow: Lexer - parser - AST - backend * How to add a new compiler switch (e.g. -fnotypeinfo) * How to add a new attribute (e.g. @notypeinfo) * What's your workflow for debugging the compiler? * Pick a bug, and fix it (Live demo) * Overview of CTFE and how it's implemented * (I'm sure you can think of more) I realize there's documentation on the wiki, and some of this was discussed briefly at DConf2013, but there's more that can be done to make it accessible and interesting. Mike
Re: forum.dlang.org is now using DCaptcha
On Wednesday, 3 December 2014 at 19:42:39 UTC, Ary Borenszweig
wrote:
On 12/2/14, 6:41 PM, Vladimir Panteleev wrote:
Enter DCaptcha
I think this could work with just two or three variants of a
question. Always ask what's the return value of the function.
1. int foo() { return 8 % 3; }
I don't think non-programmers know what that '%' symbol is, but
programmers of any language would recognize this.
2. int foo() { int x = 8; x++; x++; return x; }
I don't think non-programmers would guess ++ is increment, but
programmers most probably know it.
3. bool foo() { return 42 != 30 };
I don't think non-programmers know what != is.
I had to maintain a technical forum last year that was getting
spammed like crazy. I added the question how many bits are in a
byte?, and the spam vanished. Based on that experience, I think
the bar can be set very low.
I prefer something like the examples above. Honestly, I don't
know what the names of many syntax features are, but I usually
know how to use and interpret them. But, one positive side
effect of this is that if I ever do get challenged with a what
is the name of this feature? question, I will finally be
motivated to go look it up.
Mike
Re: core.stdcpp
On Friday, 29 August 2014 at 16:37:12 UTC, Sean Kelly wrote: On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote: On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Please understand that I'm not suggesting we start refactoring druntime for 2.067. All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come. The reason these are in Druntime at all is because code in Druntime depends on them. So if they were split into a separate library then it would be a required library. And even if we completely eliminate any dependency on standard C functions, I don't see any way to avoid depending on platform-specific calls. Now I would be fine with including just a subset of declarations in Druntime (which is really what we have right now anyway), but if the remainder were split into a standalone library then things start to get weird. Please let me know if you have a solution to this problem. I'm not suggesting we eliminate libc and platform-specific bindings, just encapsulate and isolate them. To make D work on any platform, druntime must be ported to that platform. To do the port, of course we have to make platform-specific calls. That's no problem. But they should be internally encapsulated in that port's logic, not publicly exposed. And if we implement 11666 we should isolate each port to its own folder so the abstraction between language and platform is clear. For example (what druntime may look like many years from now): If a port chooses to use libc, no problem. Just encapsulate the bindings in its own file/folder. Don't make it publicly available. If D programmers want bindings to libc in their programs, they should use std.c in phobos (or we could simply move core.stdc to phobos). This means that we may have duplicate bindings in druntime and std.c for the few features of libc that are required to implement the port. This isn't really a duplication of code as it should just be type declarations and function signatures - just information for the linker. Some time in the future, many years from now, it would be nice if gradually those C bindings were replaced with D implementations to throw out the middle-man and put the port directly on the platform. There's absolutely no hurry, and if it's never done, so be it. Now what about the stuff in core.sys.whateverOS? It's the same thing. Certainly these are needed to port druntime to a given platform, but they are an implementation detail of the port, not the language. Again they should be encapsulated and isolated. If users want to make calls to whateverOS libs, than we can either move core.sys.whateverOS to phobos, or create a new namespace std.whateverOS or whatever namespace name you want, and users can use that. Just get it out of the way of the language implementation. But NONE of this needs to be done right now, or even this year, or even next year. All I'm asking for with this thread is that instead of making it harder to move away from the current structure by adding core.stdcpp to druntime, we simply choose to put the C++ standard library bindings in std.cpp in phobos. Or you could choose to keep it as core.stdcpp, but just put it in phobos instead of druntime. The C++ standard library bindings don't exist yet. There's nothing to change. It's just a design decision. What do you want druntime to look like in 10 years? Let's make sure we're pointed in that direction with the C++ standard library bindings. Mike
Re: core.stdcpp
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote: On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote: On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: The irony is D1 has std.c, and for D2 it was migrated to core.stdc. ...and design takes the backseat to convenience. This was a necessary part of the separation of the runtime components of the standard library from the extraneous stuff. Consider Druntime to be roughly equivalent to the java.lang package. It contains code and interfaces that pertain to the language definition, plus certain related low-level functionality. I don't believe it was necessary. D is quite capable of implementing the same logic that libc has. However, if for convenience, expediency, time-tested-reliance, optimization, or some other reason, one wishes to use libc, they can encapsulate it in the platform-specific logic, because that's what it is. It will always be a judgement call for where to draw the line. For example, should Range be in Druntime since it's something the compiler is aware of? What about basic math routines that the compiler might replace with an intrinsic call? So far, we've actually erred on the side of having less in Druntime rather than more. It currently contains user-visible code that's actually required for every D application: the GC, threads, bit operations, and atomics, plus some additional code and declarations that are required to implement these features. And that's it. If D is defined as a garbage-collected language, then it makes sense for the GC to be in druntime. If D is defined as a language the intrinsically supports threads, then that belongs in druntime, etc... But D is not defined as a superset of libc, or a standard operating system API, so there is no reason to publicly expose these. My argument can be limited to core.stdc/stdcpp for now. * Only a very limited subset of libc is needed by druntime * These can be eliminated by implementing them in D, or by using what the platform provides (kernel libs, etc...). It may not be convenient/expedient to do so, and will take significant effort and testing, but I'm not saying it needs to be done right now, just that it should be a goal. * If it is decided to keep them for convenience/expediency or another reason, they can be encapsulated by the ports that need them rather than publicly exposed. D could be so much more than what it currently is. What I eventually would like to see is the following ports: Architecture (bare metal) ports: --- X86 X86_64 ARM9 ARM7M MIPS etc.. OS Ports Windows Posix Linux MacOS etc... I believe that list shows what a narrow focus D currently has. While a libc exists for all of these, and it might be convenient to use it, it is not necessary given D's capabilities. D could do it all, and I think that would set D apart from many other languages if it did. That being said, it certainly would be convenient to make use of libc for many of these ports, so let's use it. Just encapsulate it so if, in the future, someone like me wants to submit pull requests to gradually remove the dependency on libc, they can do so without breaking the API and causing controversy. You might argue that Druntime shouldn't exist as a separate library at all, and at times I've wondered this myself, but some of the reasons for this have really borne out in practice, such as the forced elimination of unnecessary dependencies. If you look at D1 you'll find that the better part of the standard library is linked with every D application because some stuff that's always included (the GC code and what's in dmain, for example) uses high-level code which in turn depends on everything else. And while it's possible to avoid this with proper discipline, this is much easier to accomplish if the code simply isn't available in the first place. I think it is good design to separate the implementation of the language spec and compiler intrinsics from library functions that implement domain-specific logic or commonly used utility functions even if they are considered low-level. If one thinks of druntime as a low-level library, there's no reason to separate it from phobos. But if it's thought of as the language implementation, as I do, then the reason to separate the two is quite apparent, and the boundary between the two is quite stark. When making these arguments, please try thinking about the library from the perspective of a library designer and not an end user. Does the standard C interface truly belong in Phobos? In Druntime? Elsewhere? Why? And what factors might influence your decision? Are any of these factors currently present? Some of the reasons for the current design are historic and unnecessary and others are not. And anything can be changed if someone comes up with a better idea and is willing to do the work to make it so. It
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: On 8/26/2014 5:32 PM, Mike wrote: We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead. The irony is D1 has std.c, and for D2 it was migrated to core.stdc. ...and design takes the backseat to convenience. Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums. But I'm not aware of a single user gained by these changes, and I suspect we've lost a few, not because they didn't like the newer names, but because they disliked the constant disruption of their code base. I completely understand and sympathize. This is most unfortunate.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 02:17:39 UTC, Dicebot wrote: On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote: What do you think about following compromise: 1) C bindings are defined in spec to be optional 2) They are still kept in druntime repo but declared an implementation detail 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own. It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation. By C bindings do you really mean C/C++ bindings given the context of this thread? Yeah, any external / OS bindings is probably more appropriate wording. It's a step in the right direction, but ultimately just a formality. Maybe that's the best I can hope for.
core.stdcpp
On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote: Mike wrote in message news:sdrjfagsayomsngme...@forum.dlang.org... What's the motivation for embedding these things in the d runtime? Make them available. Wouldn't it be better to have a libc_d instead of core.stdc, libcpp_d instead of core.stdcpp, liblinux_d instead of core.sys.linux, etc...? I don't see how. The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently available to users, and reduce the coupling between the language and the platform. I thought the D runtime was supposed to be simply an implementation of the language features, but it appears its scope is much more broad. Language features (gc, profiler, etc), OS bindings, C stdlib bindings. C++ bindings aren't a big leap from there. I think druntime started off including OS and stdlib bindings because it needed to use them internally, and it made more sense to expose them publically instead of adding dependencies or duplicating them. I think this is what makes issue 11666[1] so difficult and controversial. The features of the C std lib that are needed by the D runtime are not many, and could be re-implemented in D. The OS bindings needed to implement the D runtime could be internal and moved to a separate folder as proposed in the spirit of 11666. Public OS bindings could be put in std.linux, std.windows, etc... along with std.stdc and std.stdcpp. It might be expeditious to just wrap and link, but I argue that D would be more appealing as a language (rather than a framework) if this wasn't the case. This makes the language coupled to those platforms and less general purpose like C and C++. I disagree. D does not depend on C++ being available, but druntime should provide bindings if possible. Depending on the C runtime is not a problem, because realistically you will either have a C runtime available for your platform, or be on a restricted platform where you will need to define your own D runtime, and can choose which parts of the C runtime to include. I concede this is true for the vast majority of systems out there, but it makes D an applications programming framework, not a systems programming language. I politely ask those pursuing core.stdcpp to reconsider and look further in the future. Please think beyond desktop and server application programming. Consider what D could be used for, not just what it is currently used for, and darken the line between the language and the platform. Make it a more of a language, and less of a framework. Mike [1] https://issues.dlang.org/show_bug.cgi?id=11666
Re: core.stdcpp
On Tuesday, 26 August 2014 at 08:15:07 UTC, Marc Schütz wrote: On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote: The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently available to users, and reduce the coupling between the language and the platform. But stdc is its own subpackage in druntime, it's already very modular. It should be easy to remove if you want to create a minimal druntime. For stdcpp, this will be even more true. Up until now, Phobos consists of mostly high-level modules, while those closer to the OS, and the compiler-dependent parts, reside in druntime. I think this is a good division. My argument isn't about making my own hobby D Runtime. It's about THE D Runtime and more importantly D-the-language (not library routines and OS bindings). There's quite a bit in the D Runtime that's not relevant to the language. I'm guessing it's there because it was convenient at the time. Take a look at the controversy 11666 caused. It had nothing to do with the language or it's portability, and everything to do with how to expose the Linux kernel headers. Just as it is right to separate Phobos from druntime, it is right to separate the language from the platform. It will ensure D's longevity and our return on investment for learning and contributing to this language. (You will likely not be programming the platform you're currently programming in 5 years) I'm not interested in Go, Rust, and other application and server programming languages. I want an alternative to C/C++ (and I'm not talking about libc, libm, and libcpp, I'm talking about the language). D has a lot of potential beyond it's current use. Please take this opportunity to reflect on what's been done, take a look ahead, and see if we can set a better precedent for the future. Mike
Re: core.stdcpp
On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote: On 8/25/2014 11:12 PM, Mike wrote: The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently available to users, and reduce the coupling between the language and the platform. It's beginning to look more and more like an stdcpp is achievable. The implementation of it, however, is going to be ugly and very specific to each C++ compiler. The user shouldn't need to have to see that ugliness, though. It also means that implementing stdcpp is going to require someone who is very willing to go spelunking around the underbelly of C++ ::std:: and understand it, which is a tall order. You must have stopped reading after my first paragraph :) I seem to have that effect :(
Re: core.stdcpp
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote: Yeah, I think C's success is directly linked to having a clear use scenario and avoiding being a general purpose language What? C is THE quintessential general purpose programming language. It can be used to program anything.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: D has a lot of potential beyond it's current use. Please take this opportunity to reflect on what's been done, take a look ahead, and see if we can set a better precedent for the future. C++ interoperability is very important for D's future. -- Andrei I know it is and I fully support it. I'm not arguing against it. Please add all C++ interoperability support you want to the compiler and to druntime. I look forward to making use of it. But libstdc++ is not part of C++-the-language, and libc is not part of C-the-language. C and C++ can be used without them; I do every day. If core.stdcpp is intended to be the language bindings to libstdc++, I don't think it should belong it D's language implementation, druntime, any more the language bindings to Cairo or GTK should. The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. Mike
Re: core.stdcpp
On Tuesday, 26 August 2014 at 12:54:49 UTC, Daniel Murphy wrote: I really don't see a practical problem with having them in druntime, only a philosophical one. It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function. If I create a port without core.stdc, it can be argued that my port is incomplete. Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language. They should still be available when not using phobos, Then they can be put in their own library instead of phobos. That's even better as far as I'm concerned. GTKD isn't part of phobos or druntime. I don't see libc as being any different (in principle) than GTKD. and they are used in druntime internally. For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666. But you could take it a step further for the principled approach. Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights. Why create DDMD? We already have an implementation in C++, right. What a waste of time... (of course I'm being facetious. Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists. No offense intended) 11666 is contentious because everybody has a different opinion on the layout. This is about personal preferences, and has nothing to do with OS bindings being in druntime. The same exact discussion would happen if they were in phobos. That's exactly my point. The debate that ensued with 11666 had nothing to do with the spirit of 11666. If those OS bindings weren't in druntime, 11666 would already be implemented without controversy. And we'd likely already have a few more ports of D to other platforms. The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate. Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that. I get that you're saying this, but why? How will it make any difference to anything ever? libc is ubiquitous, and the parts that are used internally could trivially be reimplemented on a platform where it was missing. (or more likely, it could just be ported) Or those features in libc could be implemented in D, removing the artificial dependency on libc. ??? If you want to / need to, you can write a libc implementation in D. The fact that the major D platforms all choose to link against the system libc instead of rolling their own has no bearing on the language class of D. The fact that druntime includes a prototype for memcpy or fopen does not change anything either. It just makes D more convenient for porting C code. Only the *port* should have bindings to libc. The language implementation should not. Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language. It could be my failing, but I really don't see the point. What are the potential consequences of maintaining and extending the C, C++ and OS bindings in druntime? * It conflates the language with the platform. druntime should be solely the implementation of the language, not an OS API. * It conflates the implementation of the language with bindings for external libraries. Again, druntime is the language implementation, not an application programming framework. * It sets the wrong precedent for a systems programming language. IMO a true systems programming language should be self-reliant. That is, it should be a language that can be used to build the first layer of hardware abstraction. * It creates artificial dependencies when there's no real dependency. C++ being a superset of C is an example of a real dependency. That is not D. * It gets in the way of porting the language to more platforms and complicates maintenance of the runtime. Case in point: the 11666 debate. * It makes D unportable to some platforms without creating their own dialect of the language or their own D runtime implementation In summary, I believe libc, libstd++, and the OS bindings should be encapsulated and isolated by the ports that need them, not publicly exposed as part of the D language implementation. Having bindings to these these libraries is super important, and I'm glad they exists. I just don't think they belong in the D language implementation, except as encapsulated, isolated artifacts of ports that need them. Mike
Re: core.stdcpp
On Tuesday, 26 August 2014 at 15:44:31 UTC, eles wrote: On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote: On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. Am I correct to define the language as: begin file--- //no imports here //any code here - ? If you import, then is the library. That may be an oversimplification, but basically, Yes.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu wrote: I don't understand the objection. Are you arguing that we shouldn't make core.stdc and core.stdcpp available, and instead let anyone who wants to use libc and libc++ write their own declarations? No. We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead. Why? D is not subset of C. D is not defined in C. It is its own autonomous language (at least I though it was). Therefore, the dependencies on libc are artificial. Let's not add another artificial dependency with core.stdcpp. The OS bindings in core.sys are another artificial dependency, but let's not go there right now. But druntime relies on libc? Wrong! Some of the code needed to port druntime to certain platforms relies on libc (and actually doesn't need to). This code should be encapsulated and isolated from other ports, not publicly exposed and conflated with the rest of the language implementation. This is in the spirit of issue 11666. I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API. That's what phobos and DUB are for. I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Mike
Re: core.stdcpp
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. ... and start by creating std.cpp instead of core.stdcpp.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 01:05:19 UTC, Dicebot wrote: On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API. That's what phobos and DUB are for. I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. What do you think about following compromise: 1) C bindings are defined in spec to be optional 2) They are still kept in druntime repo but declared an implementation detail 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own. It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation. By C bindings do you really mean C/C++ bindings given the context of this thread?
Re: core.stdcpp
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Please understand that I'm not suggesting we start refactoring druntime for 2.067. All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come. Since C++ language bindings are a new addition, let's not exacerbate the problem by putting it in druntime as core.stdcpp, but set a new precedent by putting them in std.cpp (or core.stdcpp in phobos, or whatever else you have in mind). Mike
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 08:23:39 UTC, Daniel Murphy wrote: It works for ddmd's array.d/array.h at least, although it's not very maintenance friendly. I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation? What's the motivation for embedding these things in the d runtime? Wouldn't it be better to have a libc_d instead of core.stdc, libcpp_d instead of core.stdcpp, liblinux_d instead of core.sys.linux, etc...? I thought the D runtime was supposed to be simply an implementation of the language features, but it appears its scope is much more broad. This makes the language coupled to those platforms and less general purpose like C and C++. Mike
Re: D for the Win
On Sunday, 24 August 2014 at 09:24:55 UTC, Jacob Carlborg wrote: On 2014-08-24 10:53, bearophile wrote: Dicebot: In reddit thread one of commenters complained about D performance and linked this benchmark : That benchmark found a small performance bug in ldc2, that I reported, but I think it's not yet fixed. The numbers in the benchmark has just been updated. DMD is behind C. GDC is the fastest of all and LDC is ahead of Clang but behind GCC. Seems pretty good to me. I did some analysis to find out which changes made the difference. Here's my result. 1. Disabling the GC - insignificant 2. Liberal use of `immutable` - insignificant 3. Decorating functions with @trusted, @safe, nothrow, pure - insignificant 4. Using C's random number generator for both D and C - insignificant 5. Using C's floor instead of D's floor. - very significant (why?) 6. This change (https://github.com/nsf/pnoise/commit/baadfe20c7ae6aa900cb0e4188aa9d20bea95918) - very significant. Mike
Re: D for the Win
On Sunday, 24 August 2014 at 13:13:58 UTC, ketmar via Digitalmars-d-announce wrote: On Sun, 24 Aug 2014 12:51:10 + Mike via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: ps. 6. This change (https://github.com/nsf/pnoise/commit/baadfe20c7ae6aa900cb0e4188aa9d20bea95918) with GDC has no effect at all. If I undo all of Edmund Smith's changes from today, use C's floor, and remove all the excessive function attributes, I get this http://dpaste.dzfl.pl/1b564efb423e === gcc -O3: 0.141484117 seconds time === D (dmd): 0.446634464 seconds time === D (ldc2): 0.191059330 seconds time === D (gdc): 0.226455762 seconds time Then I add change only #6 above, and remove the excessive function attributes, I get this: http://dpaste.dzfl.pl/f525adab909c === gcc -O3: 0.137815809 seconds time === D (dmd): 0.480525196 seconds time === D (ldc2): 0.139659135 seconds time === D (gdc): 0.131637220 seconds time Approaching twice as fast for GDC. That's significant to me. Also, all those optimization flags should already be on with -O3. Here are the flags I'm using: gcc -std=c99 -O3 -o bin_test_c_gcc test.c -lm dmd -ofbin_test_d_dmd -O -noboundscheck -inline -release test.d ldc2 -O3 -ofbin_test_d_ldc test.d -release gdc -O3 -o bin_test_d_gdc test.d -frelease Maybe I'll make a pull request for it. I don't think users should have to decorate their code like a Christmas tree and use a bunch of special compiler flags to get a well-behaved binary. Mike
Re: D for the Win
On Sunday, 24 August 2014 at 14:04:22 UTC, ketmar via
Digitalmars-d-announce wrote:
On Sun, 24 Aug 2014 13:44:07 +
Mike via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com
wrote:
p.s. what i did is this:
auto tm = Timer();
tm.start;
foreach (; 0..100) {
auto n2d = Noise2DContext(0);
foreach (i; 0..100) {
foreach (y; 0..256) {
foreach (x; 0..256) {
auto v = n2d.get(x * 0.1f, y * 0.1f) *
0.5f + 0.5f;
pixels[y*256+x] = v;
}
}
}
}
tm.stop;
writeln(tm.toString);
Timer is my simple timer class which uses MonoTime to measure
intervals.
this shows ~22 seconds for both variants, with #6 and without
#6.
and 57 seconds for variants without sse3 flags. ;-)
I'm guessing the dependency is probably due to our
configure/build of GDC. I'm using Arch Linux 64's default GDC
from their repository. Perhaps it's configured in a way that has
these optimizations on by default. It probably should.
Mike
Re: D for the Win
On Sunday, 24 August 2014 at 14:09:03 UTC, Mike wrote: I'm guessing the dependency is probably due to our configure/build of GDC. I'm using Arch Linux 64's default GDC from their repository. Perhaps it's configured in a way that has these optimizations on by default. It probably should. dependency -- discrepancy
Re: D for the Win
On Sunday, 24 August 2014 at 02:19:18 UTC, Dicebot wrote: On Saturday, 23 August 2014 at 16:28:33 UTC, Adam D. Ruppe wrote: Author posted part 2 http://tomerfiliba.com/blog/dlang-part2/ In reddit thread one of commenters complained about D performance and linked this benchmark : https://github.com/nsf/pnoise I tried running it and don't see anything inherently wrong that may justify 3x-5x slowdowns compared to clang / gcc versions - however, it does plenty of floating point math I don't know performance implications of. Maybe someone else can have a look what can be a problem? I believe that was previously discussed here: http://forum.dlang.org/post/lo19l7$n2a$1...@digitalmars.com. Mike
Re: D 2.066 is out. Enjoy!
On Wednesday, 20 August 2014 at 22:00:58 UTC, eles wrote: On Wednesday, 20 August 2014 at 09:15:54 UTC, disapointed user wrote: the the syntax getting ever weirder, less mainstream and a While I agree with some of your remarks (particularily, the fact that it becomes too scripting language) ... where to go? I don't like Go (syntax, mainly). The sole contender in the C++-like family, for systems programming, would be Vala, but since they dropped the posix profile... :( D has set a new standard for me. No CTFE, no thanks.
Re: Programming in D book is 100% translated
On Thursday, 24 July 2014 at 08:11:01 UTC, Ali Çehreli wrote: I have completed the translation of the book. Phew... :) However, there is still more work, like adding a UDA chapter and working on many little TODO items. The following was the final chapter, which actually only scratches the surface of the very broad topic: * Memory Management As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali Your book is such a valuable resourcE. We are so lucky to have it. Many thanks! Mike
Re: Programming in D book is 100% translated
On Thursday, 24 July 2014 at 18:51:39 UTC, Andrei Alexandrescu wrote: On 7/24/14, 1:11 AM, Ali Çehreli wrote: Where's the dlang.org pull request featuring the book prominently in the documentation section? Andrei There's a pending pull request [1] to forward visitors to the list of D books on the wiki [2] giving equal weight to all D books, including Ali's. If this is not what you want, please say so so we know to do something different. [1] https://github.com/D-Programming-Language/dlang.org/pull/610 [2] http://wiki.dlang.org/Books Mike
Re: DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin
On Tuesday, 15 July 2014 at 18:47:28 UTC, bearophile wrote:
The talk was nice, and it's the chance I was waiting to ask a
question to the speaker.
I've read a very nice paper (+ slides) about using some
specialized but simple type system rules to make less bug-prone
the bit-twiddling kind of code, Bit-Level Types for High-Level
Reasoning by Ranjit Jhala, Rupak Majumdar:
http://goto.ucsd.edu/~rjhala/papers/bit_level_types_for_high_level_reasoning.html
I'd like to use those ideas in D, they are useful for low-level
or embedded programming.
The D type system (and D syntax) seem enough to implement most
of them without changes to the D language (or with small
changes, but you can't tell before you have tried implementing
them with the current language).
So are those things a good addition to Phobos for your kind of
programming? (additions to the language can be discussed later).
Bye,
bearophile
You may have to summarize it for me, because in my few minutes of
scanning the slides and the PDF, I don't see much difference
between what the authors are proposing and what's provided by
std.bitmanip. (But the paper is pretty researchy, and its hard to
see the forest through the trees).
I use absolute indexes in my code rather than bitwitdhs. I do
this because my datasheet uses absolute indexes, and it's
important for me to be able to cross-reference to my datasheet,
at a glance. This is why I didn't use std.bitmanip.
My other goal is to enforce mutability and access. I want to
make sure I, or my users, know, at compile time, when they are
trying to write to a read-only bitfield or otherwise access a
bitfield incorrectly.
And finally, I want to reduce code size and increase performance.
I don't want to do read-modify-write if I don't have to, not
just for threading concerns, but because that usually results in
more instructions which is detrimental to both code-size and
performance. And, for the same reason, I don't want
function-call overhead.
Anything that helps me achieve these goals is great. D's CTFE,
templates, and mixins really came through for me here.
My registers are modeled like this (enabled by my mmio.d -
https://github.com/JinShil/memory_mapped_io/blob/master/source/mmio.d):
final abstract class RCC : Peripheral!(0x3800)
{
final abstract class CR : Register!(0x00,
Access.Byte_HalfWord_Word)
{
alias PLLI2SRDY = Bit!(27, Mutability.r);
alias PLLI2SON = Bit!(26, Mutability.rw);
alias PLLRDY= Bit!(25, Mutability.r);
alias PLLON = Bit!(24, Mutability.rw);
alias CSSON = Bit!(19, Mutability.rw);
alias HSEBYP= Bit!(18, Mutability.rw);
alias HSERDY= Bit!(17, Mutability.r);
alias HSEON = Bit!(16, Mutability.rw);
alias HSICAL= BitField!(15, 8, Mutability.r);
alias HSITRIM = BitField!(7, 3, Mutability.rw);
alias HSIRDY= Bit!(1, Mutability.r);
alias HSION = Bit!(0, Mutability.rw);
}
}
... and are used like this:
if (RCC.CR.HSIRDY)
{
RCC.CR.HSION = true;
while(!RCC.CR.HSIRDY);
}
This provides me a high-level abstraction to my bit
manipulations, named fields, no overhead, and compile-time
enforcement of constraints.
What in the authors' proposal is different than what is offered
by std.bitmanip, and how could I leverage it to achieve the goals
stated here?
Mike
