Re: write a function template specialisation that tests if an argument is known at compile time
On Tuesday, 14 August 2018 at 02:53:01 UTC, Cecil Ward wrote:
On Sunday, 12 August 2018 at 12:27:59 UTC, Alex wrote:
On Saturday, 11 August 2018 at 05:17:51 UTC, Cecil Ward wrote:
T myfunc(T)( T x, uint mask )
if ( mask == 3 )
{
return fast_func( x, mask );
}
[...]
Is it the volcano pattern you are looking for?
https://p0nce.github.io/d-idioms/#Is-this-available-at-compile-time-or-runtime?
Wow, now that _is_ clever. I think that is definitely a big
part of it.
Now somehow after having used a static if to select the
known-at-compile-time case I then have to test the argument for
particular values.
So how to get the next step along the way?
Would it be ok to ask Walter maybe ? I am so far out of my depth
here tho.
Re: write a function template specialisation that tests if an argument is known at compile time
On Sunday, 12 August 2018 at 12:27:59 UTC, Alex wrote:
On Saturday, 11 August 2018 at 05:17:51 UTC, Cecil Ward wrote:
T myfunc(T)( T x, uint mask )
if ( mask == 3 )
{
return fast_func( x, mask );
}
[...]
Is it the volcano pattern you are looking for?
https://p0nce.github.io/d-idioms/#Is-this-available-at-compile-time-or-runtime?
Wow, now that _is_ clever. I think that is definitely a big part
of it.
Now somehow after having used a static if to select the
known-at-compile-time case I then have to test the argument for
particular values.
So how to get the next step along the way?
Re: Found on proggit: Nim receives funding from a company (D should be doing something like this)
On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote: Announced last week, the Nim team will be adding two full-time paid devs and setting up grants for needed projects with this new funding: :jealous: However, there are other ways to raise funds. Companies using D could use the existing bountysource page to put up bounties for features/fixes or projects they need, to which community members who need some particular feature/fix could also donate: https://www.bountysource.com/teams/d I think bountysource would work if the bounties were significantly higher, but there are also the funding options at https://opencollective.com/dlang Looking on the right column of the page there are several D enthusiasts contributing their hard-earned money to D. Maybe there's a better option for the masses, besides a T-shirt and a DConf discount, that might encourage more donors. For example, I might contribute somewhere between $100 or more if I could get some attention on some bugs/features that I care about (assuming I couldn't implement them myself). Maybe I'll post a bounty in the near future and see how it goes. Right now, I'm the only one I know of working on the #dbugfix stuff, but I'm finding the bugs submitted this round exceptionally difficult. I don't know if I'll succeed with a fix this round (Sorry!), but contact me directly, or post an announcement on the forum, if you have a bug that you're willing to motivate with a financial contribution to the D Foundation, and I'll personally take a look at it. I'm generally only capable of fixing some of the more simple bugs, as my skills and understanding of DMD are quite limited, but I promise I'll try. Mike
Re: How to declare static compile-time assoc array inside struct?
On Monday, August 13, 2018 6:14:56 AM MDT Andrey via Digitalmars-d-learn wrote: > On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole wrote: > > Unsupported. AA's don't go between CT and RT. You must use a > > module constructor to initialize it. > > Will be supported in future? Maybe, but don't plan on it. Stefan Koch is working on a major rewrite for CTFE (which he calls newCTFE), but it's going to be a while before that's done (as in, it won't be done this year and has no definitive timeframe for completion). I don't know if he has plans to improve AA support with newCTFE (I think that he's mostly focused on getting to the point that it supports everything that the current CTFE supports but way more efficiently), but either way, I very much doubt that anyone is going to rework the current CTFE implementation to support having AAs transfer from compile-time to runtime. So, while you might get that ability at some point in the future, for now (and possibly permanently), you will need to proceed without that ability. - Jonathan M Davis
Re: string to char conv
On Monday, August 13, 2018 6:42:02 PM MDT zeus via Digitalmars-d-learn wrote: > On Tuesday, 14 August 2018 at 00:24:53 UTC, Jonathan M Davis > > wrote: > > On Monday, August 13, 2018 6:06:22 PM MDT zeus via > > > > Digitalmars-d-learn wrote: > >> [...] > > > > Why are you casting the string to a char*? That's just going to > > make writeln print out the pointer value. If you want to print > > out the value of the string, then just pass the string to > > writeln. > > > > - Jonathan M Davis > > Needed char* for while (isspace(*testi)) --testi; etc Why would you be calling C functions for basic stuff like that? Just use std.ascii.isWhite (or std.uni.isWhite if you want Unicode whitespace) if you want to check whether a character is whitespace, and there's really no reason to use pointers with D strings. But if you just want to strip the whitespace off of the front of a string, then use std.string.stripLeft. e.g. auto result = str.stripLeft(); Or a more general solution would involve using std.algorithm.searching.find to find a specific character, or a character which matches a predicate. stripLeft is basically a more efficient version of auto result = str.find!(a => !isWhite(a))(); Very little D code is ever going to be doing anything with char* unless it's calling toStringz on a string to pass it to a C function, because there is no D equivalent. Using char* loses the length of the string and loses out on bounds-checking. And since D strings are not zero-terminated, it usually does not work well at all to operate on a char* as if it were a string. - Jonathan M Davis
Re: Signed DMD binaries
On Monday, 13 August 2018 at 18:48:21 UTC, Seb wrote: Feedback is welcome ;-) Thanks a lot for doing this. Honestly, I think this small change, if we can keep it maintained, will make a significant impact in users' perception of D. I don't think the issue is actually with the DMD executables, but with the DMD installer package. I'm speaking somewhat in ignorance here, but I think what's most important is to sign the installer package. I asked about what installer packaging software we are using (InstallShield, InnoSetup, etc...) at https://issues.dlang.org/show_bug.cgi?id=18786, but didn't get a response. When you try to run the installer on a recent Windows machine, you see this (https://cdn1.tekrevue.com/wp-content/uploads/2017/09/windows-protected-your-pc.jpg). That is what's scaring people. User's have to click the "More info" link, and then a "Run anyway" button appears (https://www.autoitscript.com/site/wp-content/uploads/2018/01/SmartScreen_Windows_Protected_Your_PC_Run_Anyway.png) So, I think the solution is to sign the installer package. I've never done that before, but a quick search on the Internet yielded: http://www.samlogic.net/visual-installer/tips/tips-pages/code-sign-setup-package/code-sign-setup-package.htm https://learn.adafruit.com/how-to-sign-windows-drivers-installer/making-an-installer#sign-the-installer-5-28 I don't think that will solve the virus problem, but it should at least remove the scary *Windows is protecting you* popup message. For the virus problem, it would be helpful to know what software we are using to create the installer package. Is it legit? Mike
Re: string to char conv
On Tuesday, 14 August 2018 at 00:24:53 UTC, Jonathan M Davis wrote: On Monday, August 13, 2018 6:06:22 PM MDT zeus via Digitalmars-d-learn wrote: [...] Why are you casting the string to a char*? That's just going to make writeln print out the pointer value. If you want to print out the value of the string, then just pass the string to writeln. - Jonathan M Davis Needed char* for while (isspace(*testi)) --testi; etc
Re: string to char conv
On Monday, August 13, 2018 6:24:53 PM MDT Jonathan M Davis via Digitalmars-
d-learn wrote:
> On Monday, August 13, 2018 6:06:22 PM MDT zeus via Digitalmars-d-learn
>
> wrote:
> > i have the following code in d and i get as result 4D77EB, also i
> > have the following code in c++ wich give me as results
> > 0xABCDEF123abcdef12345678909832190 how i can get in d
> > 0xABCDEF123abcdef12345678909832190 instead of 4D77EB
> >
> >
> > // D
> >
> > void test(string test){
> >
> > char* testi = cast(char*)(test);
> > writeln(testi);
> >
> > }
> >
> >
> > void main()
> > {
> >
> > test("0xABCDEF123abcdef12345678909832190");
> >
> > }
> >
> >
> > // C++
> >
> > void test(string str){
> >
> > const char* testi = str.c_str();
> > printf("%s\n", testi);
> >
> > }
> >
> > int main(int argc, char const *argv[]){
> >
> > test("0xABCDEF123abcdef12345678909832190");
> >
> > }
>
> Why are you casting the string to a char*? That's just going to make
> writeln print out the pointer value. If you want to print out the value
> of the string, then just pass the string to writeln.
I suppose that I should point out that you almost never want to use char* in
D unless interacting with C or C++. Strings in D are not zero-terminated.
They are dynamic arrays of characters. String literals do have a '\0' one
past their end so that you can pass string literals to C functions which
take const char*, and std.string.toStringz can be used to convert a string
to a zero-terminated immutable(char)*, but in general, you just don't use
zero-terminated strings in D, and writeln is far more flexible than printf,
since it will accept pretty much any type. I'd suggest that you read the
documentation for the writeln family of functions:
https://dlang.org/phobos/std_stdio.html#.writeln
https://dlang.org/phobos/std_stdio.html#.writefln
https://dlang.org/phobos/std_stdio.html#.write
https://dlang.org/phobos/std_stdio.html#.writef
and the documentation for formattedWrite explains the flags accepted by the
various functions that accept format strings (e.g. writefln or format):
https://dlang.org/phobos/std_format.html#.formattedWrite
- Jonathan M Davis
Re: string to char conv
On Monday, August 13, 2018 6:06:22 PM MDT zeus via Digitalmars-d-learn
wrote:
> i have the following code in d and i get as result 4D77EB, also i
> have the following code in c++ wich give me as results
> 0xABCDEF123abcdef12345678909832190 how i can get in d
> 0xABCDEF123abcdef12345678909832190 instead of 4D77EB
>
>
> // D
>
> void test(string test){
> char* testi = cast(char*)(test);
> writeln(testi);
>
> }
>
>
> void main()
> {
> test("0xABCDEF123abcdef12345678909832190");
> }
>
>
> // C++
>
> void test(string str){
> const char* testi = str.c_str();
> printf("%s\n", testi);
>
> }
>
> int main(int argc, char const *argv[]){
>
> test("0xABCDEF123abcdef12345678909832190");
> }
Why are you casting the string to a char*? That's just going to make writeln
print out the pointer value. If you want to print out the value of the
string, then just pass the string to writeln.
- Jonathan M Davis
string to char conv
i have the following code in d and i get as result 4D77EB, also i
have the following code in c++ wich give me as results
0xABCDEF123abcdef12345678909832190 how i can get in d
0xABCDEF123abcdef12345678909832190 instead of 4D77EB
// D
void test(string test){
char* testi = cast(char*)(test);
writeln(testi);
}
void main()
{
test("0xABCDEF123abcdef12345678909832190");
}
// C++
void test(string str){
const char* testi = str.c_str();
printf("%s\n", testi);
}
int main(int argc, char const *argv[]){
test("0xABCDEF123abcdef12345678909832190");
}
Re: Signed DMD binaries
On 8/13/2018 11:48 AM, Seb wrote: Feedback is welcome ;-) Thank you!
Re: Write for the D Blog!
On Monday, 13 August 2018 at 16:16:31 UTC, Dukc wrote: But I want to say, that the fairly recent post about SARC moving to D was great stuff to read! It had so many links and viewpoints rarely mentioned, I was not even aware about them. The naval architecht viewpoint is a refresher! That’s nice to hear, thanks a lot! Update on that project: I have moved out from the laboratory and today I successfully transpiled the second real-world Pascal module. The next one requires more thought, as it’s interface and implementation are in separate files. Morale of the story? I think that one should not be afraid to post there if he does not consider himself a "regular" programmer, because thats precisely what produces the best posts. I appreciate that morale. There's definitely no reason to be shy, and Mike is a very helpful editor!
Re: Reimplementing software building blocks like malloc and free in D
On Monday, 13 August 2018 at 01:49:35 UTC, Mike Franklin wrote: On Sunday, 12 August 2018 at 06:35:17 UTC, Eugene Wissner wrote: P.S. In the last weeks I had thoughts to split low-level stuff from tanya and put it into a separate library, kind of native, gc-free x86-64 (and maybe aarch64) Linux runtime for D. Probably I should go for it :) In recent months, I've been thinking about something like that as well. I think it's a very promising idea. Why not start with DasBetterC and build a Phobos like library from there?
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Saturday, 11 August 2018 at 10:04:14 UTC, Nicholas Wilson wrote: On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote: The benefit would be that null can be a regular pointer constant (enum null = typeof((false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex. I disagree. I have no doubt you know more about compiler internals than me so not arguing about that. Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer. Of what _practical use_ is that? Tried to come up with an example but it would be so far-fetched that it won't be a reason in itself to add a new feature. I have to start to think longer before I post.
Re: Signed DMD binaries
On 2018-08-13 20:48, Seb wrote: As a few of you might have noticed, we bought a Code Signing Certificate a few days ago and while we're still investigating on how to integrate the code signing best into the release process, I thought a share a first preview of signed DMD binaries with you. So I semi-officially repacked 2.081.2 and signed the released binaries and libraries: http://files.wilzba.ch/dlang/releases sha256sum dmd.2.081.2.windows.7z 598a477e3692fb43c2bf010d62620506e0d0169e5dbaaa909ab9fca84204f751 dmd.2.081.2.windows.7z In the future, the official releases will come with signed binaries, but as there are a few people running into troubles with their company software policy or virus scanner, I thought I share this semi-official release with you. Feedback is welcome ;-) Any plans for doing the same thing for the installer on macOS? It complains that it's from an unidentified developer and forces the user to go into System Preferences and reopen the installer. -- /Jacob Carlborg
Re: unimplemented abstract function compiles.
On 2018-08-12 19:29, Eric wrote: I thought it would work the same way as an interface (which must be implemented by the direct sub class, otherwise compile error). But apparently it's possible to implement an abstract function anywhere in the class hierarchy. That makes it, in this case, impossible to check during compile time. It will be checked during compile time if the class is referenced during compile time. In your example it's not. The thing is that a library can provide an abstract class which is then subclassed and completely implemented by the user of the library. In that case you don't want an compile error when you're compiling the library but now using the class. One can argue that an abstract class always should be marked with "abstract" but that's not currently how the language is working. -- /Jacob Carlborg
Signed DMD binaries
As a few of you might have noticed, we bought a Code Signing Certificate a few days ago and while we're still investigating on how to integrate the code signing best into the release process, I thought a share a first preview of signed DMD binaries with you. So I semi-officially repacked 2.081.2 and signed the released binaries and libraries: http://files.wilzba.ch/dlang/releases sha256sum dmd.2.081.2.windows.7z 598a477e3692fb43c2bf010d62620506e0d0169e5dbaaa909ab9fca84204f751 dmd.2.081.2.windows.7z In the future, the official releases will come with signed binaries, but as there are a few people running into troubles with their company software policy or virus scanner, I thought I share this semi-official release with you. Feedback is welcome ;-)
[Issue 19138] std.uuid.randomUUID should not depend on std.random.Random being Mt19937
https://issues.dlang.org/show_bug.cgi?id=19138 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19138] std.uuid.randomUUID should not depend on std.random.Random being Mt19937
https://issues.dlang.org/show_bug.cgi?id=19138 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/202a837b7d0afeee740342137aeeb3dd44e9c53d Fix Issue 19138 - std.uuid.randomUUID should not depend on std.random.Random being Mt19937 https://github.com/dlang/phobos/commit/4f47af9dd649728e54f850d264584e9db13af191 Merge pull request #6653 from n8sh/issue-19138 Fix Issue 19138 - std.uuid.randomUUID should not depend on std.random.Random being Mt19937 --
[Issue 19165] Update d-keying.gpg if it is out-of-date
https://issues.dlang.org/show_bug.cgi?id=19165 Seb changed: What|Removed |Added Summary|Update d-kerying.gpg if it |Update d-keying.gpg if it |is out-of-date |is out-of-date --
[Issue 19165] Update d-kerying.gpg if it is out-of-date
https://issues.dlang.org/show_bug.cgi?id=19165 Jonathan Marler changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #1 from Jonathan Marler --- *** Issue 19166 has been marked as a duplicate of this issue. *** --
[Issue 19166] Detect old keyrings by checking their hashsum
https://issues.dlang.org/show_bug.cgi?id=19166 Jonathan Marler changed: What|Removed |Added Status|NEW |RESOLVED CC||johnnymar...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Marler --- *** This issue has been marked as a duplicate of issue 19165 *** --
Re: ./install.sh dmd broken?
On Monday, 13 August 2018 at 17:10:13 UTC, Jonathan Marler wrote: Seb and I found the issue (TLDR: fix here: https://github.com/dlang/installer/pull/338) ... What made it more confusing is that if it doesn't download d-keyring.gpg, then it will create a default one...making you think it was downloaded but it actually wasn't...odd. In your case you'll want to manually remove "~/dlang/d-keyring.gpg" and use the new "install.sh" script after PR 338 is merged/deployed. The respective hotfix PR is merged and deployed now ;-)
[Issue 19166] New: Detect old keyrings by checking their hashsum
https://issues.dlang.org/show_bug.cgi?id=19166 Issue ID: 19166 Summary: Detect old keyrings by checking their hashsum Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com > If the keyring ever changes (i.e. if someone has an old keyring installed), > the install.sh script should probably detect this and remove/download the new > keyring. You could do this by checking the sha of the keyring to detect if it > is out-of-date. https://github.com/dlang/installer/pull/338#issuecomment-412604923 --
[Issue 19165] Update d-kerying.gpg if it is out-of-date
https://issues.dlang.org/show_bug.cgi?id=19165 Jonathan Marler changed: What|Removed |Added Priority|P1 |P2 Hardware|x86 |All OS|Windows |Linux --
[Issue 19165] New: Update d-kerying.gpg if it is out-of-date
https://issues.dlang.org/show_bug.cgi?id=19165 Issue ID: 19165 Summary: Update d-kerying.gpg if it is out-of-date Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: johnnymar...@gmail.com There are a few cases where a user could have either an invalid d-keyring.gpg or it could be out-of-date. The install.sh script should be updated to detect invalid keyrings and update them when this occurs. This can be done by checking the SHA of the d-keyring.gpg file and removing/downloaded the latest when it doesn't match. --
[Issue 19100] install.sh signature verification fails, no public key
https://issues.dlang.org/show_bug.cgi?id=19100 --- Comment #6 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/installer https://github.com/dlang/installer/commit/bae1b3480a51991a0d014d4232102ee990c8ba3a Fix Issue 19100 - install.sh signature verification fails, no public key --
[Issue 19100] install.sh signature verification fails, no public key
https://issues.dlang.org/show_bug.cgi?id=19100 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: silly is released - new test runner for the D programming language
On Monday, 13 August 2018 at 11:57:34 UTC, Atila Neves wrote: On Monday, 13 August 2018 at 04:13:46 UTC, Anton Fediushin wrote: On Sunday, 12 August 2018 at 21:33:21 UTC, Dechcaudron wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Problem with unit-threaded and similar tools is that they are too complicated for no particular reason. Yes, I often wake up and think to myself "what feature can I add that aren't going to be useful to anyone at all?" then write some code. Nobody adds complication "for no particular reason". Even people who shouldn't be doing it do it because they're trying to accomplish something else. Hacking into dub.json to add some scripting into it is not something everybody wants to waste their time on. Agreed. Other than manually listing modules however (which is what I do these days anyway due to a dub bug), I don't know of a better way. I wish there were a compile-time trait like __traits(allModules). I've thought of writing a DSI Sadly, there's no better way yet. Silly imports `dub_test_root` which contains all of the modules. That's why no `main()` should be defined and tests must be run with `dub test`. Another thing, these tools are trying to be everything people might need adding all kinds of features nobody really uses. For example, assertions in unit-threaded and a lot of different reporters in trial. This is a good point. I think I should split unit-threaded up into separate dub subpackages. Thanks for the idea! That'd be nice. These tools also advertise usage of built-in `unittest` blocks for integration testing. I think it's just wrong because `unittest`s are obviously meant for unit testing and slapping integration tests on with some duct tape and zip ties is not a good solution. Integration testing needs it's own tool and it's quite possible that I'll end up writing one soon or later. I'm curious as to why you think that's the case. Well, 'advertise' might not be the right word for that, but both unit-threaded and trial provide means to write integration tests. Even though there is support for some simple things like creating temporary files and defining steps, it goes beyond "unit testing" but is not enough for integration tests. This kind of testing can require things like setting up a database or running other services which cannot be done with existing tools. ...
Re: ./install.sh dmd broken?
On Friday, 10 August 2018 at 13:19:21 UTC, Jean-Louis Leroy wrote: jll@euclid:~/dlang$ ./install.sh dmd Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.081.1/dmd.2.081.1.linux.tar.xz # 100.0% Invalid signature http://downloads.dlang.org/releases/2.x/2.081.1/dmd.2.081.1.linux.tar.xz.sig Same problem with 'install update'. But not when installing ldc or gdc. Seb and I found the issue (TLDR: fix here: https://github.com/dlang/installer/pull/338) The problem is downloading "install.sh" directly to "~/dlang/install.sh". This causes the install script to think that it has already downloaded the "d-keyring.gpg" so it never downloads it, causing the "invalid signature" error. The fix is to download "install.sh" if the d-keyring is not downloaded, even if install.sh already is. What made it more confusing is that if it doesn't download d-keyring.gpg, then it will create a default one...making you think it was downloaded but it actually wasn't...odd. In your case you'll want to manually remove "~/dlang/d-keyring.gpg" and use the new "install.sh" script after PR 338 is merged/deployed.
[Issue 19100] install.sh signature verification fails, no public key
https://issues.dlang.org/show_bug.cgi?id=19100 Seb changed: What|Removed |Added Hardware|x86 |All OS|Windows |All Severity|enhancement |major --
[Issue 19100] install.sh signature verification fails, no public key
https://issues.dlang.org/show_bug.cgi?id=19100 --- Comment #5 from Seb --- After debugging this for a while with Jonathan, the problem seemed to be that the install.sh script was manually installed to ~/dlang/install.sh and the check for a keyring upgrade only checks for the existence of ~/dlang/install.sh and not ~/dlang/d-keyring.gpg Also, gpg seems to create a default keyring with 32B if no keyring exists (i.e. the passed file doesn't exist). A fix: https://github.com/dlang/installer/pull/338 --
[Issue 19100] install.sh signature verification fails, no public key
https://issues.dlang.org/show_bug.cgi?id=19100 --- Comment #4 from Jonathan Marler --- Seb has fix here: https://github.com/dlang/installer/pull/338 --
Re: Write for the D Blog!
On Mon, Aug 13, 2018 at 02:29:30PM +, Mike Parker via Digitalmars-d-announce wrote: [...] > If you've got something D-related you'd like to tell the world about, > please let me know. It doesn't have to be a guest post -- project > highlights, where you give me info about your project and I write the > post, are also welcome. I'm open to ideas for other formats, too. > Just drop me a line at aldac...@gmail.com and let me know what you'd > like to do. [...] I'm too busy to actually work on much right now, but if you're running short of material to post, what about this draft wiki article that I haven't been able to finish? https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time It's pretty much ready except for some details that need to be updated (that I'm sorry to say I haven't had time to get around to). You can freely copy/adapt/etc. whatever you need from this article to throw together a blog post. Just throwing it out there. T -- Живёшь только однажды.
Re: Write for the D Blog!
On Monday, 13 August 2018 at 14:29:30 UTC, Mike Parker wrote: You may have noticed the blog is relatively quiet right now. That's not from a lack of trying. Good to know, and thanks for trying. If you've got something D-related you'd like to tell the world about, please let me know. I'll keep in mind, but nothing right now. But I want to say, that the fairly recent post about SARC moving to D was great stuff to read! It had so many links and viewpoints rarely mentioned, I was not even aware about them. The naval architecht viewpoint is a refresher! Morale of the story? I think that one should not be afraid to post there if he does not consider himself a "regular" programmer, because thats precisely what produces the best posts.
Re: Dub support was added to Meson
On Mon, 2018-08-13 at 14:33 +, Matthias Klumpp via Digitalmars-d-announce
wrote:
[…]
> This is intentional, see this comment from Jussi:
> https://github.com/mesonbuild/meson/pull/3592#issuecomment-390421754
I am not entirely sure I agree with everything there, but he is BDFL of the
project so his view wins.
> Unfortunately, this makes the dub feature almost useless for
> Linux distro integration.
> However, I hope we might be able to implement reading dub.json
> files that are locally installed and incorporate D sources from
> the dependency into the regular Meson build process.
I am rapidly heading this route for SCons: instead of using Dub to create the
libraries just use it to get the sources and then compile the sources as a
sub-project. However I still prefer having a Meson build for the library and
building that way. If however there is a way of using dub.sdl or dub.json that
would be interesting.
> This would mean that Meson's dlang plugin would have to implement
> quite a bit of dub and dub.json parsing, which is some effort.
> The benefit would be the creation of a near-seamless bridge
> between the dub and Meson worlds (you'd only have to locally
> install a dub package), that is also useful for Linux
> distribution packaging.
Perhaps there is a route whereby there can be a separate Python package to do
this that both Meson and SCons can use? Otherwise it risks there being
implementation of the same code for Meson and SCons separately.
[…]
> Jup, deterministic source lists are useful for split-building
> stuff efficiently. And globbing sources is possible with Meson,
> but highly discouraged (and even looks ugly).
I am not entirely convinced explicit manual lists are better, nor are they
required for consistent builds. If the source files structure changes you have
to create a new build anyway.
What is the ugly globbing way you know – I'm wondering if it better than the
hack I have.
[…]
> At the moment, I think for a final project, adding Meson files to
> dependencies still is the better way. However, for quickly
> testing out things and for building something locally, the new
> dub support is quite valuable.
> Also, we can expand it in future, this is a first step :-)
I get the feeling Meson Rust/Cargo support is easier and better than D/Dub
support, even though D seems to get more publicity in the Meson documentation.
I think a really good way forward for Meson (and analogously SCons) would be
to have the Dub dub.{json,sdl} file usable to create (and deploy if using
shared objects) a Meson (Scons) build of the dependency and then building the
project based on the created dependencies.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: High-level vision for 2018 H2?
On Monday, 13 August 2018 at 14:06:24 UTC, walker wrote: I am curious about the plan of 2018/H2 version also, the H1 is very promising and may be hard to summarize its output. --walker + 1 Decillion D needs more vision talk and elaboration Long term goals increase motivation around the project
[Issue 19164] New: malloc may be considered pure when failure results in program exit (no need to reset errno)
https://issues.dlang.org/show_bug.cgi?id=19164 Issue ID: 19164 Summary: malloc may be considered pure when failure results in program exit (no need to reset errno) Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com A common pattern is to call `core.memory.pureMalloc` and either `assert(false)` or `onOutOfMemoryError()` if allocation fails. In those places instead using `malloc` directly (privately annotated as `pure`) would avoid a small amount of work: the `core.memory.pureMalloc` wrapper reads errno, calls malloc, then resets errno, which is unnecessary if allocation failure results in the program exiting at once. --
Re: How to declare static compile-time assoc array inside struct?
On Monday, 13 August 2018 at 13:21:45 UTC, Andrey wrote:
On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole
wrote:
You must use a module constructor to initialize it.
Tried this:
static this()
{
Test.DESCRIPTION = [Test.Type.One: "One!", Test.Type.Two:
"It's Two...", Test.Type.Three: "And... Three!"];
}
struct Test
{
// ...
}
I have an error: cannot modify immutable expression DESCRIPTION
I suppose something along these lines was meant:
immutable string[Test.Type] DESCRIPTION;
shared static this()
{
DESCRIPTION = [Test.Type.One: "One!", Test.Type.Two:
"It's Two...", Test.Type.Three: "And... Three!"];
}
struct Test
{
enum Type { One, Two, Three };
}
See also:
https://forum.dlang.org/post/p941qc$43q$1...@digitalmars.com
Re: How to declare static compile-time assoc array inside struct?
On Monday, 13 August 2018 at 13:21:45 UTC, Andrey wrote:
On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole
wrote:
You must use a module constructor to initialize it.
Tried this:
static this()
{
Test.DESCRIPTION = [Test.Type.One: "One!", Test.Type.Two:
"It's Two...", Test.Type.Three: "And... Three!"];
}
struct Test
{
// ...
}
I have an error: cannot modify immutable expression DESCRIPTION
What is your other code?
It can work, e.g.:
https://run.dlang.io/is/kAC4pl
Re: Importing struct
On Monday, 13 August 2018 at 14:16:47 UTC, Mike Parker wrote:
On Monday, 13 August 2018 at 13:09:24 UTC, Andrey wrote:
On Monday, 13 August 2018 at 13:05:28 UTC, evilrat wrote:
however the best option is simply avoid naming anything with
same name as module.
Hmm, I thought that name of class should match name of file...
And how to name a file that contains only one class/struct?
Like in my case. What usually true D coders do?)
The convention is to use lowercase for the module name:
module myclass;
struct MyClass {}
Using lowercase letters for module names (and their respective
file names!!) also prevents weird errors when different OSes
treat lower/capital case letters differently which can sometimes
lead to modules not being found.
So from my experience: always use lower-case letters for modules
and the file names.
Re: Dub support was added to Meson
On Friday, 10 August 2018 at 14:38:10 UTC, Russel Winder wrote: On Sat, 2018-08-04 at 16:07 +, Filipe Laíns via Digitalmars-d-announce wrote: Hello, Dub support was finally merged to the Meson's upstream. For the ones that don't know, Meson[1] is a fast build system that uses ninja[2] as a backend. Until now it was impossible to use dependencies via the Dub and many many packages only supported Dub. Now you can import dependencies that already exist in Dub's local repo. You still need to fetch and build them though. Sadly not in Meson 0.47.1 is a new release due soon? There is no fixed release schedule, but from experience, this might take a few months. First, you need to fetch and build the dependency. dub fetch vibe-d dub build vibe-d This feels a little unsatisfactory. Dub (and soon SCons I hope) builds handle getting the dependency as well as building it and thence linking the project to it. Meson both depends on the dub executable and yet isn't doing the getting, it is assuming already got. Of course Meson relies on all dependencies being present at build specification time, so nothing inconsistent, it just seems a wee bit incomplete. This is intentional, see this comment from Jussi: https://github.com/mesonbuild/meson/pull/3592#issuecomment-390421754 Unfortunately, this makes the dub feature almost useless for Linux distro integration. However, I hope we might be able to implement reading dub.json files that are locally installed and incorporate D sources from the dependency into the regular Meson build process. This would mean that Meson's dlang plugin would have to implement quite a bit of dub and dub.json parsing, which is some effort. The benefit would be the creation of a near-seamless bridge between the dub and Meson worlds (you'd only have to locally install a dub package), that is also useful for Linux distribution packaging. [...] I have been getting projects such as Unit-Threaded, DInotify, TinyEndian, and D_YAML to have Meson builds so as to create shared libraries prior to using pkg-config to handle D project being dependent on these libraries. It's working nicely (for me anyway) except Dub uses GitHub tags for versioning and Meson requires version numbers in the meson.build file. This duplication is getting quite annoying for all concerned. As is the Meson requirement to list all source files, rather than have a convention over configuration approach as Dub does – SCons has a different approach but still avoids explicit source lists. I can get round it with Meson, but I am informed it is naughty and should not be done. Jup, deterministic source lists are useful for split-building stuff efficiently. And globbing sources is possible with Meson, but highly discouraged (and even looks ugly). These builds create shared objects and allow for dynamic linking. Using Dub built archives means static linking. Unless Meson somehow manages to get shared objects out of the Dub build. Unless Dub can generate shared objects, having the dependencies build locally and creating pkg-config files actually seems a better way that accessing Dub builds. [...] At the moment, I think for a final project, adding Meson files to dependencies still is the better way. However, for quickly testing out things and for building something locally, the new dub support is quite valuable. Also, we can expand it in future, this is a first step :-)
Write for the D Blog!
You may have noticed the blog is relatively quiet right now. That's not from a lack of trying. I am in a dry spell with my own writing at the moment. I've got two posts in progress that shouldn't be difficult to write, but the words haven't been coming out the way I want them to nor as easily as they usually do. One is the next post in the GC series (I'm currently on my fifth revision) and the other is the first in a Sociomantic profile. I'll finish them eventually and my dry spell will pass, but until then, I need backup! My usual approach to drum up guest posts is to contact people directly as broad calls in the forums tend to come up empty. Thought I'd give it a go, though If you've got something D-related you'd like to tell the world about, please let me know. It doesn't have to be a guest post -- project highlights, where you give me info about your project and I write the post, are also welcome. I'm open to ideas for other formats, too. Just drop me a line at aldac...@gmail.com and let me know what you'd like to do. Thanks!
Re: dub is not able to install any package
On Monday, 13 August 2018 at 13:37:28 UTC, Adil wrote: On Monday, 13 August 2018 at 13:28:02 UTC, Joakim wrote: On Monday, 13 August 2018 at 13:02:43 UTC, Adil wrote: dub build Package gelfd not found in registry at https://code.dlang.org/ (fallback ["registry at http://code.dlang.org/;, "registry at https://code-mirror.dlang.io/;, "registry at https://code-mirror2.dlang.io/;, "registry at https://dub-registry.herokuapp.com/;]): Failed to load curl, tried "libcurl.so", "libcurl.so.4", "libcurl-gnutls.so.4", "libcurl-nss.so.4", "libcurl.so.3". Looks like you need to install a libcurl package also, in some place where dub can find it. Thanks. It seems the `snap` version is not packaged with a libcurl. It worked when i switched to a `dub` installed via `apt` I opened an issue for you: https://github.com/dlang-snaps/dmd.snap/issues/24
Re: Importing struct
On Monday, 13 August 2018 at 13:09:24 UTC, Andrey wrote:
On Monday, 13 August 2018 at 13:05:28 UTC, evilrat wrote:
however the best option is simply avoid naming anything with
same name as module.
Hmm, I thought that name of class should match name of file...
And how to name a file that contains only one class/struct?
Like in my case. What usually true D coders do?)
The convention is to use lowercase for the module name:
module myclass;
struct MyClass {}
Re: High-level vision for 2018 H2?
I am curious about the plan of 2018/H2 version also, the H1 is very promising and may be hard to summarize its output. --walker
Re: Found on proggit: Nim receives funding from a company (D should be doing something like this)
On Monday, 13 August 2018 at 12:06:25 UTC, I Lindström wrote: In that case things look decent enough for me to stop worrying about this too much. And yeah, if it's a common occurance that companies try to highjack things, then it's better to be careful. Enough things have been run to the ground by Big Bucks starting to meddle in things without knowhow or vision. Didn't know it was that common. I want to be careful not to give the impression that I have inside knowledge on these things. If you're getting outside funding, there is uniquely one thing that you focus on - making money. The two devs that are working on Nim full-time will not be working on things that are in the interest of anyone other than the company paying their salaries. That may or may not be good for the community.
Re: dub is not able to install any package
On Monday, 13 August 2018 at 13:28:02 UTC, Joakim wrote: On Monday, 13 August 2018 at 13:02:43 UTC, Adil wrote: dub build Package gelfd not found in registry at https://code.dlang.org/ (fallback ["registry at http://code.dlang.org/;, "registry at https://code-mirror.dlang.io/;, "registry at https://code-mirror2.dlang.io/;, "registry at https://dub-registry.herokuapp.com/;]): Failed to load curl, tried "libcurl.so", "libcurl.so.4", "libcurl-gnutls.so.4", "libcurl-nss.so.4", "libcurl.so.3". Looks like you need to install a libcurl package also, in some place where dub can find it. Thanks. It seems the `snap` version is not packaged with a libcurl. It worked when i switched to a `dub` installed via `apt`
Re: Importing struct
On Monday, 13 August 2018 at 13:09:24 UTC, Andrey wrote: On Monday, 13 August 2018 at 13:05:28 UTC, evilrat wrote: however the best option is simply avoid naming anything with same name as module. Hmm, I thought that name of class should match name of file... And how to name a file that contains only one class/struct? Like in my case. What usually true D coders do?) Modules usually named after their purpose. Like std.stdio for IO stuff, std.file for file utilities, and complex example is std.algorithm.search for various searching algorithms which is a part of more global std.algorithm package (importing it also brings in several other std.algorithm.* modules). Not sure about your use case, but seems like parser.d or args.d or argsparser.d (names best to keep lower case in case of OS or FS specific quirks, this is the convention) Also if you need ready to use arguments parser check this one https://dlang.org/phobos/std_getopt.html
Re: dub is not able to install any package
On Monday, 13 August 2018 at 13:02:43 UTC, Adil wrote: Dub details are: adil@adil-HP-ENVY-Notebook:~/workspace/screener-d$ whereis dub dub: /snap/bin/dub adil@adil-HP-ENVY-Notebook:~/workspace/screener-d$ dub --version DUB version 1.9.0, built on May 31 2018 How did you install D / dub? As Joakim mentioned curl is a dependency of std.net.curl which is used by dub.
Re: dub is not able to install any package
On Monday, 13 August 2018 at 13:02:43 UTC, Adil wrote: dub build Package gelfd not found in registry at https://code.dlang.org/ (fallback ["registry at http://code.dlang.org/;, "registry at https://code-mirror.dlang.io/;, "registry at https://code-mirror2.dlang.io/;, "registry at https://dub-registry.herokuapp.com/;]): Failed to load curl, tried "libcurl.so", "libcurl.so.4", "libcurl-gnutls.so.4", "libcurl-nss.so.4", "libcurl.so.3". Looks like you need to install a libcurl package also, in some place where dub can find it.
Re: How to declare static compile-time assoc array inside struct?
On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole wrote:
You must use a module constructor to initialize it.
Tried this:
static this()
{
Test.DESCRIPTION = [Test.Type.One: "One!", Test.Type.Two:
"It's Two...", Test.Type.Three: "And... Three!"];
}
struct Test
{
// ...
}
I have an error: cannot modify immutable expression DESCRIPTION
Re: InputRange help: (1) repeated dtor calls and (2) managing resources needing free()
On Monday, 13 August 2018 at 04:23:49 UTC, James Blachly wrote: On Thursday, 14 June 2018 at 00:42:25 UTC, James Blachly wrote: ... I assume the (apparent) lack of parity between ctor and dtor is because the "default postblit" (which I figured out for a struct means an empty `this(this)` ctor) is called when a copy is made. My understanding is that I cannot disable the default postblit and still act as a range, correct? Should I be overloading this? 2. Directly related to the above, I need, when the range is consumed, to free() the underlying library's iterator handle. Naively, I had the destructor do this, but obviously with multiple calls to ~this I end up with an error free()'ing a pointer that is no longer alloc'd. What is the correct way to handle this situation in D? Other Range and destructor advice generally (e.g., "You should totally change your design or approach to X instead") is always welcomed. James I think I have a handle on #1 (copy of the range is made for consumption which is why dtor is called more often than ctor), but would still be interested in advice regarding #2 (as well as general Range and dtor advice). Here: https://github.com/blachlylab/dhtslib/blob/master/source/dhtslib/tabix.d#L98 I need to free the library's iterator, but the Range's destructor is the wrong place to do this, otherwise memory is freed more than once. Is it a better approach to (a) somehow guard the call to tbx_itr_destroy or (b) create a postblit that creates a new iterator and pointer? (or (c), None of the above) I would "guard" the call to tbx_itr_destroy by means of reference counting (see below). As above, my understanding is that disabling the default posblit prohibits acting as a Range. That's not true. It just makes the range harder to be used. Last year, for example, it was proposed to make the ranges in std.random non-copyable because you don't want to accidentally copy your random state and it was only that bigger refactorings were planned for std.random which sadly never materialized that this didn't happen. BTW it's very uncommon for empty to do work, it's much more common to do such lazy initialization in `.front`. If I use the range, the destructor seems to be called many, many times. Then you probably make many copies. In some ways, this problem is generalizable to all InputRanges that represent a file or record stream. Yep, and that's why I recommend to have a look at e.g. std.stdio.File: - it does its initialization in the constructor [1] - it uses reference-counting for its allocated space and pointers [2, 3] (File is often shared by default, that's why atomic reference counting is necessary here) Have a look at this minimal example of reference-counting: https://run.dlang.io/is/GF5vbC The copies you see go away when the struct is passed by reference: https://run.dlang.io/is/Uhs5Bt [1] https://github.com/dlang/phobos/blob/565a51f8c6e8b703c0b625568a6f14473345f5d8/std/stdio.d#L394 [2] https://github.com/dlang/phobos/blob/565a51f8c6e8b703c0b625568a6f14473345f5d8/std/stdio.d#L474 [3] https://github.com/dlang/phobos/blob/565a51f8c6e8b703c0b625568a6f14473345f5d8/std/stdio.d#L835
Re: Importing struct
On Monday, 13 August 2018 at 13:05:28 UTC, evilrat wrote: however the best option is simply avoid naming anything with same name as module. Hmm, I thought that name of class should match name of file... And how to name a file that contains only one class/struct? Like in my case. What usually true D coders do?)
Re: Importing struct
On Monday, 13 August 2018 at 12:44:44 UTC, evilrat wrote: Another option to save up on typing is renamed imports import mc = MyClass; mc.MyClass.parse(...) this also should work import mc = MyClass; alias MyClass = mc.MyClass; // make synonym // now it is just MyClass MyClass.parse(...) however the best option is simply avoid naming anything with same name as module.
dub is not able to install any package
dub is unable to fetch any dependency from code.dlang.org
Here's the dub.json file
{
"name" : "screener-d",
"description" : "Screener Daemon",
"sourcePaths": ["source/screener"],
"dflags": ["-J."],
"arch":"x86_64",
"configurations" : [
{
"name" : "screener-d",
"targetType": "executable",
"targetName": "bin/screener-d",
"platforms": ["linux"],
"mainSourceFile" : "source/main.d",
"dependencies" : {
"gelfd": "~>1.3.0"
}
}
],
"buildTypes": {
"release": {
"buildOptions": ["debugInfoC", "optimize", "inline",
"releaseMode"],
},
}
}
dub build
Package gelfd not found in registry at https://code.dlang.org/
(fallback ["registry at http://code.dlang.org/;, "registry at
https://code-mirror.dlang.io/;, "registry at
https://code-mirror2.dlang.io/;, "registry at
https://dub-registry.herokuapp.com/;]): Failed to load curl,
tried "libcurl.so", "libcurl.so.4", "libcurl-gnutls.so.4",
"libcurl-nss.so.4", "libcurl.so.3".
Root package screener-d references unknown package gelfd
The package is https://code.dlang.org/packages/gelfd
Dub details are:
adil@adil-HP-ENVY-Notebook:~/workspace/screener-d$ whereis dub
dub: /snap/bin/dub
adil@adil-HP-ENVY-Notebook:~/workspace/screener-d$ dub --version
DUB version 1.9.0, built on May 31 2018
Re: Importing struct
On Monday, 13 August 2018 at 12:34:25 UTC, Andrey wrote:
Hello,
This is my test project:
source/app.d
source/MyClass.d
app.d:
import std.stdio;
import MyClass;
void main(string[] args)
{
MyClass.MyClass.parse(args); // I want just
MyClass.parse(args);
}
MyClass.d
import std.stdio;
struct MyClass
{
static void parse(string[] args)
{
}
}
In "main" function I need to write
"MyClass.MyClass.parse(args)" bit I want just
"MyClass.parse(args)". If I do so then I have an error:
Error: undefined identifier parse in module MyClass.
Of course function "parse" doesn't exist in this module. But it
exists inside struct "MyClass"!
What should I do to import my struct correctly?
That's just name collision, because module is a valid symbol you
need to be specific about what you are trying to access.
Try selective import instead
import MyClass : MyClass;
Of course if there is more symbols needed you have to specify
them as well after a comma.
Another option to save up on typing is renamed imports
import mc = MyClass;
mc.MyClass.parse(...)
Importing struct
Hello,
This is my test project:
source/app.d
source/MyClass.d
app.d:
import std.stdio;
import MyClass;
void main(string[] args)
{
MyClass.MyClass.parse(args); // I want just
MyClass.parse(args);
}
MyClass.d
import std.stdio;
struct MyClass
{
static void parse(string[] args)
{
}
}
In "main" function I need to write "MyClass.MyClass.parse(args)"
bit I want just "MyClass.parse(args)". If I do so then I have an
error:
Error: undefined identifier parse in module MyClass.
Of course function "parse" doesn't exist in this module. But it
exists inside struct "MyClass"!
What should I do to import my struct correctly?
Re: How to declare static compile-time assoc array inside struct?
On Monday, 13 August 2018 at 11:53:06 UTC, rikki cattermole wrote: Unsupported. AA's don't go between CT and RT. You must use a module constructor to initialize it. Will be supported in future?
Re: Found on proggit: Nim receives funding from a company (D should be doing something like this)
On Monday, 13 August 2018 at 11:42:57 UTC, bachmeier wrote: On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote: Announced last week, the Nim team will be adding two full-time paid devs and setting up grants for needed projects with this new funding: https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim/ https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html D should also be trying to raise resources like this, though it doesn't have to be corporate funding from one source. This company funding Nim raised $100 million in an ICO last year to build some kind of cryptocurrency-oriented mobile apps platform: We now have the D Language Foundation. They are doing what they can to raise this type of funding AFAICT. We may already have more than the equivalent of two full-time devs being funded. There are graduate students working on the compiler, Symmetry Autumn of Code (not an insignificant amount of money), and Symmetry has funded a lot of good work by Ilya that forms the foundation for scientific/data computing. Then there is the successful funding to improve the IDE situation. It's great for Nim that a company has decided they like the language and want to help get it into the state that they need to conduct their business. I'm not sure the risk of losing that kind of funding and being willing to change the language to suit one company's needs is a perfect solution. Rich Hickey actually stopped taking that kind of money, because everyone thought they could attach strings to it. Ah. This cleared things up a bit. Thank you. It seemed to be one way but apparently wasn't. I stand corrected. In that case things look decent enough for me to stop worrying about this too much. And yeah, if it's a common occurance that companies try to highjack things, then it's better to be careful. Enough things have been run to the ground by Big Bucks starting to meddle in things without knowhow or vision. Didn't know it was that common.
Re: silly is released - new test runner for the D programming language
On Monday, 13 August 2018 at 04:13:46 UTC, Anton Fediushin wrote: On Sunday, 12 August 2018 at 21:33:21 UTC, Dechcaudron wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Problem with unit-threaded and similar tools is that they are too complicated for no particular reason. Yes, I often wake up and think to myself "what feature can I add that aren't going to be useful to anyone at all?" then write some code. Nobody adds complication "for no particular reason". Even people who shouldn't be doing it do it because they're trying to accomplish something else. Hacking into dub.json to add some scripting into it is not something everybody wants to waste their time on. Agreed. Other than manually listing modules however (which is what I do these days anyway due to a dub bug), I don't know of a better way. I wish there were a compile-time trait like __traits(allModules). I've thought of writing a DSI Another thing, these tools are trying to be everything people might need adding all kinds of features nobody really uses. For example, assertions in unit-threaded and a lot of different reporters in trial. This is a good point. I think I should split unit-threaded up into separate dub subpackages. Thanks for the idea! These tools also advertise usage of built-in `unittest` blocks for integration testing. I think it's just wrong because `unittest`s are obviously meant for unit testing and slapping integration tests on with some duct tape and zip ties is not a good solution. Integration testing needs it's own tool and it's quite possible that I'll end up writing one soon or later. I'm curious as to why you think that's the case. Silly is just my attempt to improve current state of D's ecosystem where programmers don't use advanced test runners, well, because it doesn't worth it for small projects. The trouble with small projects is that they tend to not remain small if people find them useful. Also, even if they do, I'd still rather use a good test runner, the same way I don't think any project is too small for git.
Re: How to declare static compile-time assoc array inside struct?
On 13/08/2018 11:38 PM, Andrey wrote:
Hello,
I need to declare a static compile-time assoc array inside struct:
struct Test
{
enum Type : ubyte
{
One,
Two,
Three
}
static immutable string[Type] DESCRIPTION = [Type.One: "One!",
Type.Two: "It's Two...", Type.Three: "And... Three!"];
}
I have an error: "non-constant expression". What should I do?
I want to declare it and init at compile-time (to reduce run-time
overhead). After that it will be used in run-time expressions and in
compile-time expressions.
Regards, Andrey.
Unsupported. AA's don't go between CT and RT. You must use a module
constructor to initialize it.
Re: Found on proggit: Nim receives funding from a company (D should be doing something like this)
On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote: Announced last week, the Nim team will be adding two full-time paid devs and setting up grants for needed projects with this new funding: https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim/ https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html D should also be trying to raise resources like this, though it doesn't have to be corporate funding from one source. This company funding Nim raised $100 million in an ICO last year to build some kind of cryptocurrency-oriented mobile apps platform: We now have the D Language Foundation. They are doing what they can to raise this type of funding AFAICT. We may already have more than the equivalent of two full-time devs being funded. There are graduate students working on the compiler, Symmetry Autumn of Code (not an insignificant amount of money), and Symmetry has funded a lot of good work by Ilya that forms the foundation for scientific/data computing. Then there is the successful funding to improve the IDE situation. It's great for Nim that a company has decided they like the language and want to help get it into the state that they need to conduct their business. I'm not sure the risk of losing that kind of funding and being willing to change the language to suit one company's needs is a perfect solution. Rich Hickey actually stopped taking that kind of money, because everyone thought they could attach strings to it.
How to declare static compile-time assoc array inside struct?
Hello,
I need to declare a static compile-time assoc array inside struct:
struct Test
{
enum Type : ubyte
{
One,
Two,
Three
}
static immutable string[Type] DESCRIPTION = [Type.One:
"One!", Type.Two: "It's Two...", Type.Three: "And... Three!"];
}
I have an error: "non-constant expression". What should I do?
I want to declare it and init at compile-time (to reduce run-time
overhead). After that it will be used in run-time expressions and
in compile-time expressions.
Regards, Andrey.
Re: Found on proggit: Nim receives funding from a company (D should be doing something like this)
On Monday, 13 August 2018 at 09:50:29 UTC, Joakim wrote: Announced last week, the Nim team will be adding two full-time paid devs and setting up grants for needed projects with this new funding: https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim/ https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html D should also be trying to raise resources like this, though it doesn't have to be corporate funding from one source. This company funding Nim raised $100 million in an ICO last year to build some kind of cryptocurrency-oriented mobile apps platform: https://www.inc.com/brian-d-evans/status-ico-raised-over-100-million-for-ethereum-powered-dapps-on-ios-and-androi.html There are risks, of course. This company could flame out, like many of these new cryptocurrency companies do, leaving Nim without ongoing funding. Their priorities may not align with the Nim core team. However, there are other ways to raise funds. Companies using D could use the existing bountysource page to put up bounties for features/fixes or projects they need, to which community members who need some particular feature/fix could also donate: https://www.bountysource.com/teams/d There are two primary factors in the success of any project, design and resources. I'm reasonably happy with the design of D and how technical decisions are being made. I think this is a core strength of D. However, it appears the D core team has so far been doing a horrible job in gathering resources for the project. I'm not privy to any internal discussions or if this is being discussed at all. But it needs to be a priority for the ongoing growth of this project. I do agree on your points Joakim. The "orgs using D"-section has seen growth over the time I've been here so that's something, but it'd be good if the collaborations would rise above the news threshold. Also, has the bounty been suggested to the organizations using D? It could help develop aspects of D that are needed to break through into the wider world. As much fun as it is to do personal projects, D needs the features that are required by companies or other organizations to grow. D also needs the funding to operate the infrastructure, advertise and pay out something as an incentive for what to build to help those wishing to dev (more) full-time. The latest blog post about funding code-d was a step into the right direction IMO. It would be nice to hear from the core team if something is in the Works besides the code-d-project. If help is needed on where or how to try and get support, I can volunteer with what I know about the subject to throw around ideas or come up with plans. I have only a BBA so if someone knows more, it might be good if they volunteered instead/too.
Found on proggit: Nim receives funding from a company (D should be doing something like this)
Announced last week, the Nim team will be adding two full-time paid devs and setting up grants for needed projects with this new funding: https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim/ https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html D should also be trying to raise resources like this, though it doesn't have to be corporate funding from one source. This company funding Nim raised $100 million in an ICO last year to build some kind of cryptocurrency-oriented mobile apps platform: https://www.inc.com/brian-d-evans/status-ico-raised-over-100-million-for-ethereum-powered-dapps-on-ios-and-androi.html There are risks, of course. This company could flame out, like many of these new cryptocurrency companies do, leaving Nim without ongoing funding. Their priorities may not align with the Nim core team. However, there are other ways to raise funds. Companies using D could use the existing bountysource page to put up bounties for features/fixes or projects they need, to which community members who need some particular feature/fix could also donate: https://www.bountysource.com/teams/d There are two primary factors in the success of any project, design and resources. I'm reasonably happy with the design of D and how technical decisions are being made. I think this is a core strength of D. However, it appears the D core team has so far been doing a horrible job in gathering resources for the project. I'm not privy to any internal discussions or if this is being discussed at all. But it needs to be a priority for the ongoing growth of this project.
[Issue 19163] New: static/tuple foreach counted incorrectly in coverage analysis
https://issues.dlang.org/show_bug.cgi?id=19163
Issue ID: 19163
Summary: static/tuple foreach counted incorrectly in coverage
analysis
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
import std.meta : AliasSeq;
unittest {
foreach (n; 0..7)
sw: switch (n) {
static foreach (i, e; AliasSeq!(int, string, bool))
case i:
break sw;
foreach (i, e; AliasSeq!(int, string, bool))
case i+3:
break sw;
default:
break;
}
static foreach (i, e; AliasSeq!(int, string, bool)) {
}
foreach (i, e; AliasSeq!(int, string, bool)) {
}
}
The above code gives this coverage analysis:
|import std.meta : AliasSeq;
|
|unittest {
24|foreach (n; 0..7)
7|sw: switch (n) {
000|static foreach (i, e; AliasSeq!(int, string, bool))
3|case i:
3|break sw;
000|foreach (i, e; AliasSeq!(int, string, bool))
3|case i+3:
3|break sw;
1|default:
1|break;
|}
6|static foreach (i, e; AliasSeq!(int, string, bool)) {
|}
6|foreach (i, e; AliasSeq!(int, string, bool)) {
|}
|}
Four things stand out here - the static foreach and tuple foreach inside the
switch has a coverage count of 0, and the foreach outside are counted. I
contend that both are incorrect - the lines contain no run-time executable
code, and so shouldn't show up in the coverage report at all.
--
Re: High-level vision for 2018 H2?
On Saturday, 28 July 2018 at 08:37:25 UTC, Peter Alexander wrote: The wiki still links to high-level vision for 2018 H1. We're now nearly one month into H2. Is a H2 document in progress? Bump
