Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept
On Friday, 21 July 2017 at 00:27:09 UTC, Mike wrote: 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 Thanks for your work
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
Re: Work on ARM backend for DMD started
On 7/20/2017 9:22 AM, solidstate1991 wrote: A few things you should be aware before you trash the reference compiler for D: I wouldn't be discouraged by the nay-sayers. If you want to build an ARM back end for it, do it! About every project I've ever embarked on, including D, started with everyone nay-saying it.
Re: static foreach is now in github master
On Thursday, 20 July 2017 at 20:33:47 UTC, Steven Schveighoffer wrote: On 7/20/17 4:08 PM, Seb wrote: On Thursday, 20 July 2017 at 19:53:46 UTC, Jack Stouffer wrote: On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote: https://is.gd/1TCQOh Hmmm, that code is printing 0 1 2 3 0 1 2 3 for me. Shouldn't it just be printing once? I bet you are using `rdmd`? It runs dmd twice on your main file ;-) See also: https://issues.dlang.org/process_bug.cgi https://github.com/dlang/tools/pull/191 https://github.com/dlang/tools/pull/194 (sadly this was reverted) I'm just clicking on the run button on the web page you linked to. How do I not run rdmd there? -Steve Oh because I thought run.dlang.io wasn't using `rdmd`. However, there was a minor glitch today when I added support for flags and stdin to the docker images [2]. The good news is that it has been fixed [2] & everything should behave as usual. Sorry for the inconvenience and continued happy hacking! [1] https://github.com/dlang-tour/core-exec/pull/2 [2] https://github.com/dlang-tour/core-exec/pull/4
Re: static foreach is now in github master
On 7/20/17 4:08 PM, Seb wrote: On Thursday, 20 July 2017 at 19:53:46 UTC, Jack Stouffer wrote: On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote: https://is.gd/1TCQOh Hmmm, that code is printing 0 1 2 3 0 1 2 3 for me. Shouldn't it just be printing once? I bet you are using `rdmd`? It runs dmd twice on your main file ;-) See also: https://issues.dlang.org/process_bug.cgi https://github.com/dlang/tools/pull/191 https://github.com/dlang/tools/pull/194 (sadly this was reverted) I'm just clicking on the run button on the web page you linked to. How do I not run rdmd there? -Steve
Re: static foreach is now in github master
On Thursday, 20 July 2017 at 19:53:46 UTC, Jack Stouffer wrote: On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote: https://is.gd/1TCQOh Hmmm, that code is printing 0 1 2 3 0 1 2 3 for me. Shouldn't it just be printing once? I bet you are using `rdmd`? It runs dmd twice on your main file ;-) See also: https://issues.dlang.org/process_bug.cgi https://github.com/dlang/tools/pull/191 https://github.com/dlang/tools/pull/194 (sadly this was reverted)
Re: static foreach is now in github master
On 7/20/17 3:53 PM, Jack Stouffer wrote: On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote: https://is.gd/1TCQOh Hmmm, that code is printing 0 1 2 3 0 1 2 3 for me. Shouldn't it just be printing once? I think it's because it's using rdmd, and that runs dmd once to generate dependencies, and one more time to compile. It's not specific to static foreach or the new compiler: https://is.gd/g6WPyv -Steve
Re: static foreach is now in github master
On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote: https://is.gd/1TCQOh Hmmm, that code is printing 0 1 2 3 0 1 2 3 for me. Shouldn't it just be printing once?
Re: Release D 2.075.0
On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [...] Could you please create a post on reddit? Kind regards André
Re: Release D 2.075.0
On Thursday, 20 July 2017 at 12:10:14 UTC, Adrian Matoga wrote: On Thursday, 20 July 2017 at 07:19:03 UTC, Patrick Schluter wrote: version 2.067 that still had the C++ frontend took more than 100 seconds. I can hardly believe it. I remember versions 2.05x building in about 11 seconds. 1 cpu on 2.4 GHz Westmere, gcc 6.2 version 2.067
Re: Release D 2.075.0 does not install on Windows 10 with VS2017
On Thursday, 20 July 2017 at 17:44:29 UTC, Jolly James wrote: On Thursday, 20 July 2017 at 16:28:54 UTC, jan wrote: seems like i am not the first one to have that problem. please fix. everything working fine from here :) Maybe you should state what exactly is not working for you and paste some error messages... +1 As a gentle reminder, the announce NG is __not__ meant for reporting issues. Please use the bugtracker - otherwise your issue might not be seen by the concerning volunteers: http://dlang.org/bugstats.html
Re: Release D 2.075.0 does not install on Windows 10 with VS2017
On Thursday, 20 July 2017 at 16:28:54 UTC, jan wrote: seems like i am not the first one to have that problem. please fix. everything working fine from here :) Maybe you should state what exactly is not working for you and paste some error messages...
Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept
Thanks for your work with bare metal MCUs! I am dreaming that someday I can program smart house IoT automation on D.
Release D 2.075.0 does not install on Windows 10 with VS2017
seems like i am not the first one to have that problem. please fix.
Re: Work on ARM backend for DMD started
On Friday, 7 July 2017 at 11:09:27 UTC, Temtaime wrote: DMD is a piece of shit, and adding another one ARM backend with all those bugs and low performance instead of improving ldc is wasting efforts. The only use of dmd is development because of compilation speed. But some persons have "cerveau lent" and just cannot realise it. A few things you should be aware before you trash the reference compiler for D: - Most of DMD's frontend and the part of the backend is in D. This means better productivity in the long run, especially once the whole of the backend is ported to D. - Well, it's the reference compiler. I understand that you would like to see many of the devs on DMD to move towards LDC instead. I myself like some healthy competition. - The performance issues can be fixed in the long run. I myself thinking on fixing some of the issues of DMD, like the SIMD support (might end up in issuing a DIP for better support the hardware functions). I think first I might learn how the current codegen works, issue some improvements, as learning how the arm architecture works is a hard work, I don't even know what to do with condition codes (ignore them completely, or use them in certain situations to save a few conditional jump?), thumb (yet another attribute to force the compiler to use thumb for the part of the code?), etc. I'll recycle some of the preexisting code which was made by another user.
WebConfig - a vibe.d HTML form generator & validator from D structs
I just released a vibe.d library that allows you to turn any D struct into an editable HTML5 compatible form with live JS updates but also normal no-JS updates with nearly the same experience. It basically feels like you don't need to write any boilerplate HTML code anymore but instead write D and show your D code with a fancy mask automatically to the user. Additionally it handles all the validation for you so you can be sure that anything the user couldn't type in into the HTML frontend won't be stored inside the backend struct (validation & some corrections for all HTML5 input types). It supports numerous data types as input types: * string - type="text" (there are UDAs to also change the type of a string to email, url, time, week, month, datetime-local, date, color or textarea) * bool - type="checkbox" * enum - a dropdown list (select) or with an UDA a list of radio elements * BitFlags!enum - a list of checkbox elements * DateTime (not SysTime) which is a timezone-less Date & Time combination, can be done with a string too * Date - type="date", can be done with a string too * TimeOfDay - type="time", can be done with a string too * URL (vibe.d) - type="url", can be done with a string too * integer & floating point types - type="number" or with an UDA type="slider" the input names are automatically generated by the variable name (myInputName or my_input_name -> My Input Name) but can also be renamed and with v1.1.0 also translated (i18n) using the upcoming "language" property in vibe.d WebInterfaces, you can depend on vibe.d ~master to use it already now, otherwise everything will default to one language for now. You can also translate or rename enum values with these UDAs (sadly you need to attach them on the member variable because enums can't have UDAs attached to them) which is great for having a large variety of supported languages on your website. A use case for the package is for example a user setting: A user accesses GET /settings and your app looks up the user account and the settings struct saved with it, then just passes the struct without any other obstacles into renderSettings() and it will output prefilled HTML + JS for the user to edit. You just need to accept POST /settings and POST /api/setting and pass both of them into req.processSettings(ref config) which does everything for you. Then it will return a bitfield of changed values (up to 64 fields) that you can check if you actually need to save the updated config. On the no-js version you will also pass that bitfield into the renderer and it will show error strings with it. Another use case would be a small game server front end configuration without a lot of thought or changes needing to go into it. Just send the struct through the render and process functions and don't care about validation and HTML. By default there is no CSS but the layout is very simple (check the GitHub README), but I have a simple material design CSS template you can use if you want a quick and simplistic UI for your form. I haven't covered everything the UDAs allow you to do yet or how you can customize the HTML generation, etc. but you can check out the Documentation[1] and the GitHub repository[2] to find out more. Install the package: dub.json "web-config": "~>1.1.0" dub.sdl dependency "web-config" version="~>1.1.0" DUB Page: http://web-config.dub.pm [1] https://webfreak001.github.io/WebConfig/package.html [2] https://github.com/WebFreak001/WebConfig
Re: Release D 2.075.0
wow, how nice - but it is not installed correctly with VS2017. While installing, i am told that 64bit will not work. what a SH.T you guys should get your act together - just once. it's always a real experience to install software and have problems. Nice experience!!
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: Release D 2.075.0
On Thursday, 20 July 2017 at 07:19:03 UTC, Patrick Schluter wrote: version 2.067 that still had the C++ frontend took more than 100 seconds. I can hardly believe it. I remember versions 2.05x building in about 11 seconds.
Re: Release D 2.075.0
On Thursday, 20 July 2017 at 07:19:03 UTC, Patrick Schluter wrote: version 2.067 that still had the C++ frontend took more than 100 seconds. I think if the backend is translated to D, building the compiler will take not more than 2 seconds. To put it in perspective, building gcc with only C and C++ support takes around 15 minutes on my machine and clang+llvm is ridiculously slow to compile with not far from 1 hour compilation. Ok, these projects are much, much bigger but that doesn't change the fact that C++ is slow to compile. One day, a colleague and I were working on migrating a large MSVC project to LLVM. Due to various reasons (using git master / bisecting regressions), this involved building LLVM from source code, which took an exorbitant amount of time (about 40 minutes IIRC). Later that day, I mentioned in passing that we might make building D part of the build process (of a project using D code), since building the compiler took only 3 seconds on my machine. To quote my colleague: "Whaaat? How can a compiler compile in 3 seconds?!"
Re: Release D 2.075.0
On 7/20/2017 12:19 AM, Patrick Schluter wrote: version 2.067 that still had the C++ frontend took more than 100 seconds. I think if the backend is translated to D, building the compiler will take not more than 2 seconds. To put it in perspective, building gcc with only C and C++ support takes around 15 minutes on my machine and clang+llvm is ridiculously slow to compile with not far from 1 hour compilation. Ok, these projects are much, much bigger but that doesn't change the fact that C++ is slow to compile. DMC++ takes about 15 seconds to do an optimized build of itself on my old Windows XP machine. (Of course, it doesn't use STL, or any templates for that matter. The code predates templates.)
Re: Release D 2.075.0
On Wednesday, 19 July 2017 at 19:34:44 UTC, Joakim wrote: On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [...] Wow, dmd builds in 12 seconds on a single linux/x64 core, can't wait to see what that time is when the backend is in D too, especially since it's taking most of the compile time now. Thanks to those involved for all the work on the release. version 2.067 that still had the C++ frontend took more than 100 seconds. I think if the backend is translated to D, building the compiler will take not more than 2 seconds. To put it in perspective, building gcc with only C and C++ support takes around 15 minutes on my machine and clang+llvm is ridiculously slow to compile with not far from 1 hour compilation. Ok, these projects are much, much bigger but that doesn't change the fact that C++ is slow to compile.
