DConf and DIPs
With DConf for all of us and a short vacation for me just around the corner, I'm not going to be initiating any DIP reviews until mid-May. It's looking like the DIP, "Hooking D's struct move semantics" [1], will become DIP 1014 and I currently intend to launch the Community Review on May 14th. There has been some light feedback in the Draft Review so far. The author, Shachar Shemesh, is hoping to flush out any obvious issues before DConf. He will be at the conference and welcomes face-to-face discussions of the DIP with anyone there wants to hash out the details with him. Also, the Community Review of DIP 1013, "The Deprecation Process" [2], is underway until April 26th. There has been very little feedback so far. If you haven't looked at it yet, please do! [1] https://github.com/dlang/DIPs/pull/109 [2] https://forum.dlang.org/thread/rxlbdijkbhanwvbks...@forum.dlang.org
Podcast episode about anemic domain models (OOP vs procedural)
In 2016 I gave an online presentation for the Silicon Valley D Meetup about anemic domain models and D, but this presentation wasn't recorded (as far as I know). I have now published a podcast episode discussing that topic, going over the most important parts of the presentation. http://www.coredump.xyz/1 Feedback is welcome. By the way, let me publicly express my gratitude to Mike Parker and Ali Çehreli for their help with this episode --- and for kicking ass in general! :o)
Re: PixelPerfectEngine v0.9.4-alpha.2
On Wednesday, 11 April 2018 at 21:44:57 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4-alpha.2 The editor is almost usable (still needs a way to import tiles from its own proprietary format), and now has a working, although still a bit slow and unstable transformable tile layer with mode7-esque capabilities. Also, feel free to visit us/swing by Allegro.cc. Allegro 4 was used in TONS of oldschool/DOS era projects. (Ever heard of Triplane Turmoil?) (Allegro 5 is the newer, C revamp of the API for supporting shaders/etc.) So there may be some helpful common knowledge to share. I'm personally working on a 2-D game engine for internal use, using Allegro as a backend, and D, to make my game projects more productive. I love D's templates, they've been instrumental. Have a great day.
Re: PixelPerfectEngine v0.9.4-alpha.2
On Wednesday, 11 April 2018 at 21:44:57 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4-alpha.2 The editor is almost usable (still needs a way to import tiles from its own proprietary format), and now has a working, although still a bit slow and unstable transformable tile layer with mode7-esque capabilities. Definitely add screen shots to the github. Screenshots = Downloads.
Re: #include C headers in D code
On Monday, 16 April 2018 at 12:26:12 UTC, Jacob Carlborg wrote: On Monday, 16 April 2018 at 11:20:51 UTC, Atila Neves wrote: You can use the C macros in the headers that you #include in your dpp file. dstep has a lot of code for translating macros. I don't want to translate macros at all, but it's deeply intertwined with translating everything else. There's a command line switch to disable that, `--translate-macros=false`. Or, alternatively, run the preprocessor first. I missed that. I can't remember the specifics, but dstep by default ignores declarations from other headers because the idea is to translate this one particular header. That's a simple change: replace these lines [1] with `return false;`. If that's something you need we can make it configurable. [1] https://github.com/jacob-carlborg/dstep/blob/97870ac5167f09e8acf17f8754c32636492b237f/dstep/translator/Translator.d#L326-L329 No need to make it configureable now - I did the translation work already and made a point of copying in dstep's tests to guarantee the same level of support. Given how small it ended up being, I'd trade ~500SLOC over a dependency nearly every time. I also like the end result better (unsurprising since I wrote it), even though I didn't quite achieve the level of testability I wanted.
Re: #include C headers in D code
On Monday, 16 April 2018 at 11:20:51 UTC, Atila Neves wrote: You can use the C macros in the headers that you #include in your dpp file. dstep has a lot of code for translating macros. I don't want to translate macros at all, but it's deeply intertwined with translating everything else. There's a command line switch to disable that, `--translate-macros=false`. Or, alternatively, run the preprocessor first. I can't remember the specifics, but dstep by default ignores declarations from other headers because the idea is to translate this one particular header. That's a simple change: replace these lines [1] with `return false;`. If that's something you need we can make it configurable. [1] https://github.com/jacob-carlborg/dstep/blob/97870ac5167f09e8acf17f8754c32636492b237f/dstep/translator/Translator.d#L326-L329 -- /Jacob Carlborg
Re: #include C headers in D code
On Saturday, 14 April 2018 at 04:07:12 UTC, Petar Kirov [ZombineDev] wrote: On Friday, 13 April 2018 at 10:31:43 UTC, Atila Neves wrote: On Wednesday, 11 April 2018 at 14:33:26 UTC, Jacob Carlborg wrote: On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* I don't know the exact details of your project but can't you just: 1. Copy the includes 2. Paste them into a C file 3. Run DStep on the C file 4. Replace the includes in the first file with the result from DStep This would require changing DStep to always return `false` here [1]. Or perhaps run the preprocessor to expand the includes and then run DStep. [1] https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L326 -- /Jacob Carlborg That wouldn't have the same semantics as I want. I tried using dstep as a library. It didn't work. You also mentioned this in the reddit thread, though I'm still curious to understand what's difference in the semantics between the approach you have taken and the approach Jacob proposed. You can use the C macros in the headers that you #include in your dpp file. dstep has a lot of code for translating macros. I don't want to translate macros at all, but it's deeply intertwined with translating everything else. This bug just can't happen with the dpp approach: https://github.com/jacob-carlborg/dstep/issues/166 In the idea above it assumes that all #include directives are together at the top of the file. They probably are, but they might not be for some reason. I can't remember the specifics, but dstep by default ignores declarations from other headers because the idea is to translate this one particular header. I don't want that either. I also don't want D code generated that has an `import` to a D file that's actually a translation of another C header. I want it to work like it does in C++. dstep doesn't set out to do that, which is fine, but contorting it to make it do what I wanted it to was more trouble than it was worth. Believe me, if I can avoid writing code, I do. Writing translations from scratch was not a decision I made lightly. In the end it turned out to be a lot less work than I thought though (just over 500 SLOC). Atila
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly
#including C headers in D*
https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/
The summary is that, modulo bugs, things like this work:
#include
void main() { printf("Hello world\n".ptr); }
So far it's successfully compiled whilst #including pthread,
libcurl, openssl and others. The blog and the github README
have more information, and feel free to reply to this with
questions.
dub: http://code.dlang.org/packages/dpp
reddit:
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/
hacker news: It's in there somewhere, search around.
Atila
* Technically, "D + #include directives + C macros"
This is really cool. This can be _very_ useful in situations
where you don't want to translate all the headers to D,
especially when experimenting with C libs. Really cool. Thanks.
The 10k Twitter Target
Lately, we've seen a steadily increasing trend of new followers on Twitter. We're closing in on the totally arbitrary yet emotionally significant number of 10,000. I was just thinking how cool it would be to hit that number before or during DConf. Now that my move is behind me and I'm settling in to my new house, I have more time to stay on top of things (note that "more" does not necessarily equate to "enough"). I'll try to keep the tweet stream more active than usual over the coming two+ weeks, even while I'm bopping around Germany in the week prior to the conference. If you have a Twitter handle, it would help us out to retweet anything interesting you see on @D_Programming. If you aren't following us, it would help us out even more for you to become a statistic! Let's see if we can turn that 9,781 (as I write this) into 10,000 before the Hackathon.
