On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic wrote:
Is the actual problem those `@trusted:` declarations at the top
of C headers?
There could be a simple solution to that:
Ban `@trusted:` and `@trusted { }` which apply to multiple
symbols. Only allow `@trusted` to apply to a
On Wednesday, 27 May 2020 at 10:51:54 UTC, Walter Bright wrote:
On 5/27/2020 3:01 AM, Timon Gehr wrote:
I've addressed exactly this a dozen times or more, to you and
others. Repeating myself has become pointless.
It's fine to disagree with me. Argue that point. But don't say
I didn't address
On Wednesday, 13 May 2020 at 14:39:13 UTC, Mike Parker wrote:
I've recently implemented some improvements centered on
bindbc-sdl.
As a user of BindBC (and former Derelict), I really enjoy using
those binding libraries. It's some great work, thanks.
On Wednesday, 5 February 2020 at 11:50:47 UTC, IGotD- wrote:
[...]
The language is used as an academic sandbox for testing
stuff by their creators. Theres no direction whatsoever.
Ignoring the lack of tools, documentation, etc
I must say that it is summarized very well. Especially
On Tuesday, 18 September 2018 at 17:20:26 UTC, Atila Neves wrote:
I was envious of std::sync::Mutex from Rust and thought: can I
use DIP1000 to make this work in D and be @safe? Turns out, yes.
Beautiful! The only current downside, is the fact the application
using that library has to be
On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer
wrote:
However, I am struggling to find a use case for this that
showcases why you would want to use it. While it does work, and
works beautifully, it doesn't show any measurable difference
vs. the array allocated buffer that
On Thursday, 28 September 2017 at 09:26:19 UTC, Claude wrote:
However, I did not find any SDL2-2.0.6 package for Ubuntu... :(
I built it, it works fine.
On Saturday, 23 September 2017 at 12:16:46 UTC, Mike Parker wrote:
SDL 2.0.6 was just released [1], so I've updated DerelictSDL2
[2] to support it. It's available in DerelictSDL2
3.1.0-alpha.1. I've tested that the loader works, but beyond
that I've done nothing with it.
I also fixed some
I think "betterC" can be a good tool to use D on embedded
systems, keep as few dependencies as possible, a low ROM
footprint and a good C interoperability.
I'll try to find some time to play with it.
On Friday, 17 March 2017 at 06:33:38 UTC, ketmar wrote:
* pure D audio code, no external decoder libraries required
(and no SDL);
* supports FLAC, Vorbis, Opus, MP3 playback;
* various hardware sampling rates with transparent resampling
of source audio;
* multiband equalizer (the code is
1. Why your company uses D?
My company does not use D. If I had the time, I really think I
could integrate D into our build system, probably forcing it a
bit: "Oh and by the way, that new library I wrote happens to be
written in D..." (We have Vala in our build system, how worse
could it
On Friday, 15 July 2016 at 15:05:53 UTC, Ilya Yaroshenko wrote:
On Friday, 15 July 2016 at 12:10:22 UTC, Claude wrote:
[...]
Yes! Finally we need the final code for LDC, it support ARM
assembler.
http://wiki.dlang.org/LDC_inline_assembly_expressions
[...]
No, I have not. Thank you for
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote:
ARM contributors are wanted!
What exactly do you need for ARM architecture?
I have an ARM target and I have tried to run a library[1] to get
some CPU info.
I hacked in the source files to just build and link the CPU info
code.
Intel Core i5:
https://gist.github.com/claudemr/aa99d03360dccc65d7967651011dc8ca
14 matches
Mail list logo
