Re: The final form of the keyboard = ShionKeys
On Saturday, 24 March 2018 at 12:03:15 UTC, Abdulhaq wrote: On Friday, 10 November 2017 at 15:06:20 UTC, Shion wrote: I want to make more people aware of my project of trying to change the world (ShionKeys), seek proliferation. More project content will be announced at sales time / crowdfunding time. Please administrator support this project do not delete, I have been many evil community management will be regarded as spam / advertising information and delete. github @ShionAt twitter @ShionKeys Sounds a bit https://www.urbandictionary.com/define.php?term=shonkey See, this is one of the idiots who suppress ShionKeys.
Re: LDC 1.8.0
On Tuesday, 13 March 2018 at 01:52:48 UTC, Matthias Klumpp wrote: [...] Aww, just a little bit too late to easily get into Ubuntu 18.04 LTS Well It still made it, yay! (Even without me explicitly requesting it) This means Ubuntu 18.04 will be pretty up-to-date when it comes to D stuff, only GDC 8 won't be the default (but still available). The thing that is facilitating an up-to-date D stack in Debian and Ubuntu is software in the archive using D. The Tilix terminal emulator is at the forefront there, followed by my appstream-generator and the Laniakea archive management suite and all the bits and pieces those projects depend on (like GtkD in Tilix' case).
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On 2018-03-23 21:43, H. S. Teoh wrote: Yep. As I mentioned elsewhere, recently I've had to resort to external testing for one of my projects, and I'm still working on that right now. And already, I'm seeing a liability: rather than quickly locating a unittest immediately following a particular function, now I have to remember "oh which subdirectory was it that the tests were put in? and which file was it that a particular test of this function was done?". Put the tests in a directory called "tests" and follow the same file and directory structure as the regular code. It's just a matter of configuring a command in an editor that will find the corresponding test file and navigate to it. Or dump your editor if it doesn't support custom commands 'cos it sux and you deserve better. :-D I mean, this is 2018, not 1995, we shouldn't have to be stuck with the handicap of clicking through files and directories to find the right test file anymore. :D -- /Jacob Carlborg
Re: The final form of the keyboard = ShionKeys
On Friday, 10 November 2017 at 15:06:20 UTC, Shion wrote: I want to make more people aware of my project of trying to change the world (ShionKeys), seek proliferation. More project content will be announced at sales time / crowdfunding time. Please administrator support this project do not delete, I have been many evil community management will be regarded as spam / advertising information and delete. github @ShionAt twitter @ShionKeys Sounds a bit https://www.urbandictionary.com/define.php?term=shonkey
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On 3/23/18 9:54 PM, Tony wrote: I said my "original reply", meaning the one where I first mentioned Test-Driven Development. That was to something that Steven Schveighoffer said (although I did not reply directly to his message, but replied to his comment that was still in H.S. Teoh's message): "I've worked on a project where the testing was separated from the code, and it was a liability IMO. Things would get missed and not tested properly." He doesn't explicitly specify development or maintenance, but I assume it was development. It was somewhat development and somewhat maintenance, but I was not using TDD. The code was already written, I was adding to it. I was also adding tests afterwards to make sure what I did worked properly. In my case, I had no choice but to use separate files, as I was writing firmware for an embedded device, and the tests were running on the host PC (i.e. testing that when I communicated with the device, it was doing what I expected). But even in my normal work where tests and the code run on the same system, my style of development just doesn't fit TDD, I often times don't know what the code or functionality is going to look like at the end when I'm done (I rewrote what eventually became iopipe 5 times because I wasn't sure of the best way to do it). I can see where if you use TDD, it would be OK to separate the tests from the program, but I still feel that the cost of having them separated from the code it's testing outweighs the benefits of less recompilations. I'm just not as picky as Atila when it comes to build time :) -Steve
New release v0.6 of the D bindings for SAP NetWeaver RFC SDK
Hi! I made a new release of sapnwrfc-d, the D bindings for the SAP NetWeaver RFC SDK. Included are the following changes: - Support for release 7.50 of the SDK - New package name sapnwrfc. The old package name std.sap is deprecated and will be removed in the future. - New application createini: This utility converts a saplogon.ini file into sapnwrfc.ini format. The release notes are here: https://github.com/redstar/sapnwrfc-d/releases/tag/v0.6 To use the library just add a dependency to your dub.json/dub.sdl file or clone the source at https://github.com/redstar/sapnwrfc-d. My plan for the next release is to make use of struct and table parameters easier. The first draft of new module sapnwrfc.data is already committed (but not included in the release). Regards, Kai
