Re: The ABC's of Templates in D
On 7/31/2020 10:57 AM, H. S. Teoh wrote: Not sure how blog-worthy this is, It is. Please do it!
Re: The ABC's of Templates in D
On Friday, 31 July 2020 at 13:46:43 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ Minor detail: in "Even shorter syntax" the point is not that the template has only one parameter, but that the template argument is only one token long (for example, no `char[]`).
Caching dependencies on GitHub Actions CI
Hello everyone, I have made a GitHub action which caches the output of `dub upgrade` and build results, meaning it will cache and restore both ~/.dub and **/.dub across builds. Using dub's native caching mechanism which checks for outdatedness with compiler and compilation options makes this an excellent option to speed up CI build times. Additionally this action checks the output of the `dub upgrade` command to see if it failed due to a network failure or due to some other reason. In case of a network failure it will retry up to 3 times so the registry may randomly be unavailable in an upgrade. In serve-d this has made `dub upgrade` never fail in the commits since I introduced that 3x run with falloff. The action can be found here: https://github.com/WebFreak001/dub-upgrade https://github.com/marketplace/actions/dub-upgrade and can be added like so: (simple example without executable caching) steps: - uses: actions/checkout@v1 - uses: dlang-community/setup-dlang@v1 # install D compiler & Dub with: compiler: dmd-latest - uses: WebFreak001/dub-upgrade@v0.1 - name: Run tests # do whatever with upgraded & fetched dependencies run: dub test Executable caching means running another cache-only action at the end of your workflow which caches all the temporary output binaries. This will make dub skip compilation of the dependencies on the next run saying they are up-to-date. How to do this is described in the README. This action is currently beta software (I just made it from start to finish in the past 80 minutes and I noticed quite a few typos in the release changelogs so there might as well be quite a few typos in the code) but if it runs well I will release it as stable soon enough.
Re: The ABC's of Templates in D
On Friday, 31 July 2020 at 13:46:43 UTC, Mike Parker wrote: I'm planning to publish several articles and tutorials about D templates over the next few months. As a means of setting the stage, I've published this tutorial on the basics. The blog: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ Good writing for the not-quite-beginner-and-up audience Mike. Reading it reminded me of how much I had been taking for granted, of how much power D provides with minimal drag. Really hope I never have to go back to C++/CUDA. Also enjoying your book. Looking forward to additional blog posts.
Re: The ABC's of Templates in D
On Fri, Jul 31, 2020 at 01:46:43PM +, Mike Parker via
Digitalmars-d-announce wrote:
[...]
> If you've got a code base that uses templates in interesting ways,
> please get in touch! We do offer a bounty for guest posts, so you can
> help with a bit of PR and make a bit of cash at the same time.
Not sure how blog-worthy this is, but recently I was writing a utility
that used std.regex extensively, and I wanted to globally initialize all
regexes (for performance), but I didn't want to use ctRegex because of
onerous compile-time overhead. So my initial solution was to create a
global struct `Re`, that declared all regexes as static fields and used
a static ctor to initialize them upon startup. Something like this:
struct Re {
static Regex!char pattern1;
static Regex!char pattern2;
... // etc.
static this() {
pattern1 = regex(`foo(\w+)bar`);
pattern2 = regex(`...`);
... // etc.
}
}
auto myFunc(string input) {
...
auto result = input.replaceAll(Re.pattern1, `blah $1 bleh`);
...
}
This worked, but was ugly because (1) there's too much boilerplate to
declare each regex and individually initialize them in the static ctor;
(2) the definition of each regex was far removed from its usage context,
so things like capture indices were hard to read (you had to look at two
places in the file at the same time to see the correspondence, like the
$1 in the above snippet).
Eventually, I came up with this little trick:
Regex!char staticRe(string reStr)()
{
static struct Impl
{
static Regex!char re;
static this()
{
re = regex(reStr);
}
}
return Impl.re;
}
auto myFunc(string input) {
...
auto result = input.replaceAll(staticRe!"foo(\w+)bar", `blah $1
bleh`);
...
}
This allowed the regex definition to be right where it's used, making
things like capture indices immediately obvious in the surrounding code.
Points of interest:
1) staticRe is a template function that takes its argument as a
compile-time parameter, but at runtime, it simply returns a
globally-initialized regex (so runtime overhead is basically nil at
the caller's site, if the compiler inlines the call).
2) The regex is not initialized by ctRegex in order to avoid the
compile-time overhead; instead, it's initialized at program startup
time.
3) Basically, this is equivalent to a global variable initialized by a
module static ctor, but since we can't inject global variables into
module scope from a template function, we instead declare a wrapper
struct inside the template function (which ensures a unique
instantiation -- which also sidesteps the issue of generating unique
global variable names at compile-time), with a static field that
basically behaves like a global variable. To ensure startup
initialization, we use a struct static ctor, which essentially gets
concatenated to the list of module-static ctors that are run before
main() at runtime.
Well, OK, strictly speaking the regex is re-created per thread because
it's in TLS. But since this is a single-threaded utility, it's Good
Enough(tm). (I didn't want to deal with `shared` or __gshared issues
since I don't strictly need it. But in theory you could do that if you
needed to.)
//
Here's a related trick using the same principles that I posted a while
ago: a D equivalent of gettext that automatically extracts translatable
strings. Basically, something like this:
class Language { ... }
Language curLang = ...;
version(extractStrings) {
private int[string] translatableStrings;
string[] getTranslatableStrings() {
return translatableStrings.keys;
}
}
string gettext(string str)() {
version(extractStrings) {
static struct StrInjector {
static this() {
translatableStrings[str]++;
}
}
}
return curLang.translate(str);
}
...
auto myFunc() {
...
writeln(gettext!"Some translatable message");
...
}
The gettext function uses a static struct to inject a static ctor into
the program that inserts all translatable strings into a global AA.
Then, when compiled with -version=extractStrings, this will expose the
function getTranslatableStrings that returns a list of all translatable
strings. Voila! No need for a separate utility to parse
Re: The ABC's of Templates in D
On Friday, 31 July 2020 at 13:46:43 UTC, Mike Parker wrote: I'm planning to publish several articles and tutorials about D templates over the next few months. As a means of setting the stage, I've published this tutorial on the basics. The blog: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ Reddit: https://www.reddit.com/r/programming/comments/i17n5d/the_abcs_of_templates_in_d/ I've got a few more posts on the topic that I intend to write myself, one of which will incorporate Stefan Koch's dive into a template instantiation. But I'm also looking for guest posts demonstrating specific instantiations (heh) of templates in real-world D code. If you've got a code base that uses templates in interesting ways, please get in touch! We do offer a bounty for guest posts, so you can help with a bit of PR and make a bit of cash at the same time. Thanks for this excellent article. It is really needed. I can't wait for the rest part. I will also plead with you to let the articles cover the full capability of the D template while making it simple for a newbie to grab it
Re: The ABC's of Templates in D
On Friday, 31 July 2020 at 15:24:46 UTC, Ali Çehreli wrote: On 7/31/20 6:46 AM, Mike Parker wrote: The blog: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ An excellent article and the ideas are delivered expertly, in a very natural way. And there are almost no typos. ;) comfusing -> confusing a normal a function -> a normal function declare first declare -> first declare implemnted -> implemented Ali As usual, thanks! I should start sending all of my blog posts to you before I publish :-)
Re: The ABC's of Templates in D
On 7/31/20 6:46 AM, Mike Parker wrote: The blog: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ An excellent article and the ideas are delivered expertly, in a very natural way. And there are almost no typos. ;) comfusing -> confusing a normal a function -> a normal function declare first declare -> first declare implemnted -> implemented Ali
The ABC's of Templates in D
I'm planning to publish several articles and tutorials about D templates over the next few months. As a means of setting the stage, I've published this tutorial on the basics. The blog: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ Reddit: https://www.reddit.com/r/programming/comments/i17n5d/the_abcs_of_templates_in_d/ I've got a few more posts on the topic that I intend to write myself, one of which will incorporate Stefan Koch's dive into a template instantiation. But I'm also looking for guest posts demonstrating specific instantiations (heh) of templates in real-world D code. If you've got a code base that uses templates in interesting ways, please get in touch! We do offer a bounty for guest posts, so you can help with a bit of PR and make a bit of cash at the same time.
Re: Release of std.io v0.3.0
On 7/31/20 5:20 AM, WebFreak001 wrote: On Sunday, 26 July 2020 at 17:09:07 UTC, Steven Schveighoffer wrote: I have released a minor improvement to std.io [1], which adds support for opening the standard handles (stdin, stdout, stderr) [2]. In order to make this work, I also had to add a feature to IOs that allows you to temporarily use a file descriptor/handle [3]. As of now, it hasn't updated on code.dlang.org, but it should be soon. With this, I'm going to focus next on making an iopipe/io layer that can replace write[f]ln and friends. [1] https://code.dlang.org/packages/io [2] https://martinnowak.github.io/io/std/io/driver.html [3] https://martinnowak.github.io/io/std/io/file/File.this.html very cool, will this replace std.stdio? Will there be an API similar to the old one for upgrading? I should clarify that when I say "replace" I mean become a viable choice to replace usage in user code. I don't think Phobos will move away from its current design. The hope is that it's written well enough that it could be the basis for low-level i/o in D 3rd party projects. For example, I'd love to see projects like vibe.d and hunt fit together on the same i/o subsystem. Then you can pick whichever library you want, or use multiple libraries, and they all work together with the same i/o framework. std.stdio is a one-stop-shop for one specific i/o implementation (C's FILE * i/o). I don't know if there's a way to replace it. I have thought of it in the past, and the issues are hairy. I know on Windows low level Console output is very different from File output, is a console API in scope for std.io or would that rather be a new module? It could also handle code page setup and console mode and stuff there. Doing console programming might fit in this library, but there is nothing there yet. If you have ideas, please start a github issue on it. I still need to add pipes, and unix sockets. -Steve
Re: Release of std.io v0.3.0
On Sunday, 26 July 2020 at 17:09:07 UTC, Steven Schveighoffer wrote: I have released a minor improvement to std.io [1], which adds support for opening the standard handles (stdin, stdout, stderr) [2]. In order to make this work, I also had to add a feature to IOs that allows you to temporarily use a file descriptor/handle [3]. As of now, it hasn't updated on code.dlang.org, but it should be soon. With this, I'm going to focus next on making an iopipe/io layer that can replace write[f]ln and friends. -Steve [1] https://code.dlang.org/packages/io [2] https://martinnowak.github.io/io/std/io/driver.html [3] https://martinnowak.github.io/io/std/io/file/File.this.html very cool, will this replace std.stdio? Will there be an API similar to the old one for upgrading? I know on Windows low level Console output is very different from File output, is a console API in scope for std.io or would that rather be a new module? It could also handle code page setup and console mode and stuff there.
