Djinn: a new templating language and code generator
I was using Jinja2 to generate some files and I wished I had D ranges. So I made a toy proof-of-concept of a D answer to Jinja2. Then a COVID-19 outbreak here triggered a lockdown, and I polished it up a bit more: https://theartofmachinery.com/2021/01/01/djinn.html Hope someone else finds it useful, too.
Re: My hobby game running on the web using Emscripten
On Friday, 11 December 2020 at 14:59:47 UTC, Ferhat Kurtulmuş wrote: I saw a post[1] about d running on the browser using emscripten a while ago. I decided to modify my SDL-OpenGL hobby game[2] to run with emscripten. It is still WIP. But, nice to see it running on the browser :-D https://aferust.github.io/drawee-wasm/ source: https://github.com/aferust/drawee-wasm Controls: arrow keys and SPACE. [1] https://theartofmachinery.com/2018/12/20/emscripten_d.html [2] https://github.com/aferust/drawee Cool, nice to see someone doing something with that post.
Re: sumtype 1.0.0
On Wednesday, 25 November 2020 at 00:20:54 UTC, Paul Backus wrote: The exact memory layout and ABI of SumType is deliberately left unspecified. It's an implementation detail that client code isn't supposed to rely on. If you want to pass a SumType's value to a C function, you will first have to extract it using pattern matching. Is that also true of the version being merged into Phobos? Specifically talking about the Phobos version and not the code.dlang.org version, what might change the ABI? An example of where someone would care would be D code with a plugin system, or even a shared library with functions that take SumType instances as parameters.
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 11:54:54 UTC, Cym13 wrote: On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote: It also illustrates what's the prolem with cryptography: it's like coding without ability to test. Who could even dream to get that right the first or even the second time? I think there a shortcoming in the "don't roll your own crypto" - advice: One could think it only applies to the algorithms, not the implementation. That's what I did when I first heard it. There's one more element missing here: the protocol. Cryptography isn't about encrypting stuff, it's about protecting secrets from start to finish and that includes the protocol used. To take an example, many people can think "Hey, I need encryption between my two servers, I'll use AES" and stop there. But use AES how? What mode (CBC,GCM,...)? Let's say CBC is used, what about message authentication? Can I just modify your stream? How is the key exchanged? How is the key generated? Etc. People tend to focus on encryption, be it algorithm or implementation, but once you've got bricks it's still a pain to put them together in a solid way. Things like TLS or SSH actually combine at least 3 completely different sets of bricks to establish the communication, authenticate it, secure it once established etc. So, in a way, "don't roll your own crypto" means "use TLS as much as possible" :) Some people don't want to hear all that because implementing crypto is exciting. So I like to recommend this problem set instead: https://cryptopals.com/ It scratches the "I wanna write crypto" itch, and it makes the "custom crypto is easier to break than you might think" point really well. (By the way, your article had really good depth. I'm subscribing to your RSS :)
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 17:23:51 UTC, Meta wrote: On Wednesday, 26 February 2020 at 17:11:18 UTC, bachmeier wrote: There needs to be a variant of "mansplaining" modified for Python users. Agreed, and there also needs to be a variant of prison, modified for people who post dumb comments on Hacker News. Whatever the language, I like the "show me the code/graphs/benchmarks/disassembly/data/something/anything" approach Atila used in his blog post. When I wrote a blog post about why C const is practically useless for optimisation, I lost count of how many people smugly pointed out that const "should" go on the other side of the *, as if that made all the difference. If they actually tried it they'd see it makes zero difference because "int * const x" is even less useful for optimisation.
Re: FeedSpot Recognizes the GtkDcoding Blog
On Friday, 7 February 2020 at 19:51:52 UTC, Andre Pany wrote: On Friday, 7 February 2020 at 18:16:37 UTC, Les De Ridder wrote: I'm not sure why LGPL is an issue. Does GtkD not allow dynamic linking? I am not an expert at all in the topic of licensing. This is my understanding: Gtk has the license lgpl. As long as you link dynamically to the shared object files, you can use it in commercial products. GtkD is a D wrapper for GTK. It is D source code which ease the access to the C api of Gtk. GtkD has also the license lgpl. To use GtkD in my application I have to statically link the D source code. Now it gets more complicated, GtkD has some additions to the lgpl rules. I cannot judge how high the risk is for companies to use this component, but as an employee I do anything to avoid any risk for the company I work for. Kind regards Andre I prefer MPLv2 for LGPL-style liberal copyleft in D code because it unambiguously draws the line based on files. No one has to speculate about whether, for example, LGPL's special exceptions for macro expansion also cover D's template system. https://www.mozilla.org/en-US/MPL/2.0/FAQ/
Re: wc in D: 712 Characters Without a Single Branch
On Tuesday, 28 January 2020 at 14:01:35 UTC, Mike Parker wrote: Robert Schadek was inspired by a post he saw on Hacker News a while back showing an implementation of wc in Haskell totaling 80 lines. I enjoyed the article overall, but I think this part lets it down a bit: Is the Haskell wc faster? For big files, absolutely, but then it is using threads. For small files, GNU’s coreutils still beats the competition. At this stage my version is very likely IO bound, and it’s fast enough anyway. Admit it, "my version is very likely IO bound" is hand-wavey. The top comment on HN right now is pointing out that it doesn't make sense. It would be a better tech article if it stuck to the facts by either cutting out the hand-wavey bit (and just saying "it's fast enough anyway") or doing a test. (Quick and dirty way: running the code on a large file and seeing if it maxes out a CPU using the "top" command. More elegant way: using tools like these https://github.com/sysstat/sysstat/) Remember: plenty of us on the forums are happy to help make a D article more interesting.
Re: code.dlang.org downtime
On Tuesday, 17 December 2019 at 17:34:07 UTC, H. S. Teoh wrote: On Tue, Dec 17, 2019 at 01:34:16AM +, bachmeier via Digitalmars-d-announce wrote: [...] Oh, I don't doubt that. My point was that it makes the D language project look like a small-scale open source project relying on volunteers (in this case Sonke) being generous with time and resources. What manager is going to trust a project like that with a major project? It seems unlikely that this would not be considered a major issue. This looks like something the D Foundation ought to fund. ... If a volunteer-driven opensource project like Debian can have worldwide multiple redundant FTP mirrors that almost guarantees 100% uptime, why can't we? I agree. I sent an email to the Foundation in October offering to help fund some proper infrastructure. Maybe the email got lost. The offer still stands.
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 12:20:04 UTC, Jacob Carlborg wrote: On Tuesday, 5 November 2019 at 11:49:20 UTC, Daniel Kozak wrote: Generally no, because Apline use musl libc instead of glibc, so there are some issues with that The correct way is to use static linking and putting only the binary in a Docker image, i.e. "from scratch" [1] ;). But using Alpine and musl will help with building the binary. [1] https://hub.docker.com/_/scratch And the neat way to do that is with a multi-stage build: one Dockerfile, with an Alpine container building the binary, then copying to a FROM scratch container: https://docs.docker.com/develop/develop-images/multistage-build/ The musl build is practically necessary because glibc has effectively given up standalone static binary support. So, thanks BPF Korea :)
Re: remake of remake of Konami's Knightmare
On Saturday, 28 September 2019 at 02:59:20 UTC, Murilo wrote: On Thursday, 23 November 2017 at 12:18:38 UTC, ketmar wrote: recently i worked on remake of DOS remake of Konami's Knightmare game[0]. the game is playable now, it has music from original MSX Knightmare, and sfx/gfx/levels from DOS remake. it is written in D, of course, and it is FOSS. you can find the sources here[1]. Hi, I would like to see your source code please because I am making a game myself and I need to learn how to do it, I figured I could read your code and learn from it. The post you quoted links to the git repo. You can clone it with "git clone http://repo.or.cz/knightmare.git;, or view the code online at https://repo.or.cz/knightmare.git/tree (includes a link to download the tarball).
Re: Snake game
On Wednesday, 24 July 2019 at 07:47:03 UTC, Alireza SN wrote: Hi, I'm new to D. Thought it would be fun to write a simple snake game for start. I hope it's not irrelevant to post it here. https://github.com/TheWeirdDev/SnakeD I posted it to the dlang subreddit: https://old.reddit.com/r/d_language/comments/ch63ht/simple_ncurses_terminal_snake_game/
Re: Vibe.d on Raspberry Pi
On Monday, 5 November 2018 at 16:06:38 UTC, Pander wrote: As reported in https://forum.dlang.org/thread/rgmbwuwfihauvngqm...@forum.dlang.org I've written a brief tutorial for the Pi board. I'm pretty new to D and the community so any suggestion is really highly appreciated. Bye, Andrea Nice! One suggestion: add the last step to the documentation that gets you a built and running server. It's a little thing, but it really helps people learning.
Re: "Advent of D" article on Reddit
On Friday, 9 March 2018 at 05:34:31 UTC, bauss wrote: Lmao I love Reddit. The D hate has moved onto a new level. Instead of hating on D, it's now geared towards the amount of upvotes a D post on reddit gets. What an amusement. To be fair, some things get posted to /r/programming that really should stay on /r/d_language. Spamming doesn't create a good image.
Re: London senior DevOps job and two London [D-ish] developer roles
On Monday, 23 October 2017 at 05:26:17 UTC, Adil wrote: That email server is blocked. Other way round: SORBS is blocking your GMail server. They do stupid stuff like that sometimes :/ It might work if you try again later.
Re: Hong Kong dlang Meetup
On Monday, 4 September 2017 at 19:25:59 UTC, Jonathan M Davis wrote: We haven't decided when exactly to meet up yet Any updates?
Re: Hong Kong dlang Meetup
On Monday, 4 September 2017 at 19:25:59 UTC, Jonathan M Davis wrote: Several of us from the D community will be in Hong Kong on a business trip next week (me, John Colvin, Atila Neves, and Ilya Yaroshenko), and our client, Symmetry Investments[1], has offered to sponsor a dlang meetup. We haven't decided when exactly to meet up yet, but we're looking to meet up sometime during the week of the 11th - 15th (probably on Thursday or Friday evening) and figured that we should see if anyone here was interested in showing up and would thus have some stake in when during the week it happened. The current plan is that the meetup will take place at Symmetry's main office in Chater House in Central Hong Kong. Sounds interesting. The 14th and 15th aren't good for me, otherwise the rest of the week is okay. Are you staying near the office?
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis wrote: I confess that I tend to think of betterC as a waste of time. The overwhelming majority of programmers don't need betterC. At all. But today we live in a world where practically everything just builds on top of C, and we keep seeing how that goes wrong. I think Rust and betterC D are the best candidates we've got for replacing C everywhere C is used.
Re: D as a Better C
On Wednesday, 23 August 2017 at 16:17:57 UTC, SrMordred wrote: No structs in -betterC ??? I haven't tried the latest iteration of betterC yet, but the longstanding problem is that the compiler generates TypeInfo instances for structs, and TypeInfos are classes, which inherit from Object, which are implemented in the D runtime. If you're using the current release of D, the workarounds are to include an implementation of Object so that classes work, or hack out the TypeInfo at link time.
Re: Linker-hacking out the D runtime
On Monday, 9 January 2017 at 13:42:01 UTC, Mike wrote: On Sunday, 8 January 2017 at 22:14:36 UTC, Iain Buclaw wrote: 1) -fno-rtti should be a flag that is honoured by the compiler. The more I think about it the more I dislike the whole idea of -fno-rtti. All I've ever wanted from the D compiler is to not put code in my binary that has not chance of ever being used. Or, to generate it in a way that can be garbage collected by the linker. I've actually come to the same conclusion. Different combinations of compiler flags for different codebases is just a recipe for pain. We already have things like nothrow, and I'm pretty sure we can solve at least most of the problem just by exploiting language features to do what you said.
Re: Beta D 2.072.2-b1
On Tuesday, 27 December 2016 at 04:36:54 UTC, Martin Nowak wrote: -fPIC became default for all linux 64-bit binaries and packages in order to support PIE (default on Ubuntu 16.10 and hardened Gentoo). AFAIK, the only way to disable PIC for a specific build is to use a local dmd.conf that doesn't have -fPIC. Just a heads up because this might trip up (a small minority of) users (with weird use cases).
Re: Linker-hacking out the D runtime
On Sunday, 18 December 2016 at 02:37:22 UTC, Mike wrote: I abandoned D sometime ago largely because of https://issues.dlang.org/show_bug.cgi?id=14758 (but there were other reasons), so your blog post is interesting to me. It is unfortunate that we have to resort to such hackery, but its nice to have such tools at our disposal regardless. Yeah, the TypeInfo spam is the biggest pain point. I proposed another idea for giving users more control over D Runtime by moving runtime hook definitions to .di header files. If you're interested, you can read about it here: http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org. I'd much rather have something like that over a -betterC; you can read more about some disadvantages to expanding on -betterC (e.g. removing RTTI) here: http://forum.dlang.org/post/nevipjrkdqxivoerf...@forum.dlang.org. I think D can still be very usable without TypeInfo (especially if the unnecessary language dependence on it improves). But I'm also wary of "solving" the problem with a hundred compiler flags and causing fragmentation. Anyway, thanks for the post; it's given me a few ideas. Thanks for letting me know. I wasn't totally sure anyone would be interested in that hack.
Linker-hacking out the D runtime
As it stands, the -betterC flag is still immature and only removes a bit of the D runtime. I've been playing around a bit to see what could be possible. To do that, I've had to do some linker hacking to make code that's completely free of D runtime dependencies. I thought I'd write something up to help other people experiment with this stuff: https://theartofmachinery.com/2016/12/18/d_without_runtime.html Let's make a better -betterC :)
Re: Button: A fast, correct, and elegantly simple build system.
On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote: On 6/12/2016 4:27 PM, Jason White wrote: I don't understand this dependency-phobia. It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the people who just want to try it out. ... The makefiles, especially posix.mak, have grown into horrific snarls of who-knows-what-is-happening. I had a minor rant about this at DConf. The makefiles are the major reason I haven't contributed to the core D projects. They'd be a hell of a lot simpler if everything that isn't building an executable (and isn't idempotent) got ripped out. No downloading compilers, no cloning/updating repos, etc, etc. Having a pushbutton process for installing/bootstrapping is cool, but that stuff is better off in scripts.
Re: D Conference - use twitter #dconf to keep up to date
On Tuesday, 3 May 2016 at 03:10:57 UTC, Walter Bright wrote: Jet lagged as I am, I'll be at breakfast at Hotel Ibis at 630am. Come and join me! Damn, I got there at 7:30. Anyone else still around? (I don't use Twitter.)
Re: Weak Purity Blog Post
Yeah, there's a lot more stuff I could have talked about, but I think I'll leave it for other posts. About testing, I think the way protection works in D (i.e., private members are accessible within the same file) is important, too. I was a bit suspicious of that feature when I first looked at D (coming from C++) but now I actually like the kind of project structure it leads to. I think better testability is just one of the advantages, but I'll write up a full blog post sometime.
Re: Weak Purity Blog Post
On Monday, 28 March 2016 at 09:59:12 UTC, ag0aep6g wrote: On 28.03.2016 03:44, sarn wrote: https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html From there: Well, you can get the usual (“strong”) purity guarantee just by making all pointer or reference type arguments const. Indirections in the return type also play into this. David Nadlinger explains this in his article on the matter: http://klickverbot.at/blog/2012/05/purity-in-d/#indirections-in-the-return-type Thanks. I updated the post.
Weak Purity Blog Post
D's implementation of functional purity supports "weak" purity - functions that can mutate arguments but are otherwise traditionally pure. I wrote a post about some of the practical benefits of this kind of purity: https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html
