Re: DIP1028 - Rationale for accepting as is
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 single symbol. For
IMO, it makes things worse. Because the careless programmer will
slap @trusted to every declaration (maybe with a script or
find/replace macro of his editor). So now, we don't know if the
annotation is greenwashing or careful examination of the
definition.
At least with "@trusted:" and "@trusted { }", the greenwashing is
obvious.
Re: Rationale for accepting DIP 1028 as is
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 it. I'm trying to understand the logic of "@safe by default for extern declaration". So I setup a simplified real-life example that I had in my mind... Let's say we have a project consisting of: - an ASM file containing several function definitions (assembly language scares people away, so it's a good example). - a .di file containing the extern(C) declarations of the former ASM functions. - and a .d file using those functions with @safe code. No function is annotated. Before DIP-1028, it compiles and link without annotations. If extern(C) decl are @system by default, it will not compile anymore, and a careless programmer will slap a "@trusted:" at the top of the ".di" file (greenwashing), and it'll stay there. On the other hand, a careful programmer will need to annotate @trusted ONLY on functions that he actually trusts AND make the project compile anyway (because he cannot afford to leave his project broken). So what does he do to make it compile ? Should he slap a "@trusted:" at the beginning of the file just like the careless programmer and maybe explicitly annotate individually declarations that are actually trusted ? It's weird... However, if extern(C) decl are @safe by default, he does not need to slap a "@trusted" at the top of the ".di" file, he just needs to annotate individual declarations with @trusted to advertise (to the QA, or his colleague or future self) that he reviewed successfully the function implementation, AND it will still compile. So that example would go in favor of Walter's point. So is it a good example? Does pinpoint the point? Because again, as the others said, it's still controversial, it's hard to sell, it's convoluted... I dunno...
Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers
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.
Re: D as a C Replacement
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 that it is focusing implementing the latest cool feature instead of stability. Yeah... Sure... and after all that constructive, accurate and subtle criticism, the guy says: "I love D, i really do [... but blablabla]". That's funny, in some sort of convoluted way. Anyway, I quite agree with the article. I'm currently playing with D and some Vulkan demos, and translating some C++ tutorial code to D is very easy and gives a much more readable syntax. ie.: simple stuff like: std::vector uniformBuffers; VS VkBuffer[] uniformBuffers;
Re: fearless v0.0.1 - shared made easy (and @safe)
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 compiled with -dip1000 if I'm not wrong?
Re: iopipe v0.0.4 - RingBuffers!
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 copies data when it needs to extend. I can think of a good use-case: - Audio streaming (on embedded environment)! If you have something like a bluetooth audio source, and alsa or any audio hardware API as an audio sink to speakers, you can use the ring-buffer as a fifo between the two. The bluetooth source has its own pace (and you cannot control it) and has a variable bit-rate, whereas the sink has a constant bit-rate, so you have to have a buffer between them. And you want to reduce the CPU cost has much as possible due to embedded system constraints (or even real-time constraint, especially for audio).
Re: DerelictSDL2 3.1.0-alpha.1
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.
Re: DerelictSDL2 3.1.0-alpha.1
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 minor issues in the 3.0 branch, the latest release of which is 3.0.0-beta.7. The 3.0 series supports SDL 2.0.0 - SDL 2.0.5, and the 3.1 series supports SDL 2.0.0 - 2.0.6. The latter is currently not in the master branch (it's in the 3.1 branch), nor is it in the documentation. I'll move 3.1 development to master and update the docs once I pull it out of alpha. [1] https://discourse.libsdl.org/t/sdl-2-0-6-released/23109 [2] https://github.com/DerelictOrg/DerelictSDL2 Great! I made it work on Windows 10, with derelict-gl3 2.0.0-beta.4. Rendering and mouse/keyboard input works with my little engine (https://github.com/claudemr/orb). However, I did not find any SDL2-2.0.6 package for Ubuntu... :(
Re: D as a Better C
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.
Re: Amper audio player for GNU/Linux and X11
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 there, but UI is not ready yet); So you ported the FLAC, OPUS and MP3 decoder to D ? That's huge. :)
Re: Questionnaire
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 be?). I use it for personal projects. 2. Does your company uses C/C++, Java, Scala, Go, Rust? We use C/C++/assembly for system stuff. And Java for Android applications. We run Linux or Android on ARM embedded systems. 3. If yes, what the reasons to do not use D instead? Nobody knows about D. Most system developers use C here, half of them don't like C++ and scorn Java. And most of them don't know about D apart from my close colleagues which probably must hate it without having even used it, just because I always bring it up in any unrelated conversation at lunch. 2. Have you use one of the following Mir projects in production: No, but it could be very useful for DSP routines. I hope Mir (and D) to have the success it deserves. 4. Have you use one of the following Tamedia projects in your production: No. 5. What D misses to be commercially successful languages? I don't know, I'm not a sales-person at all. I also like D because it's got that "made by developers for developers" thing. I'm an idealist, I'd prefer D to be successful because of its cheer intrinsic value as a programing language, rather than because we throw big money at it. 6. Why many topnotch system projects use C programming language nowadays? For history reasons. And because of its simplicity (and tooling etc), and its "system" trait. I don't buy the "C compiles bugs" argument. Every languages in the world produce bugs [1]. I noticed the hardest and most insiduous bugs could always be avoided if the software was more carefully designed upfront, especially for real-time or concurrent software. I use C a lot, it's my favorite language with D, though I'm not a proselyte. I use C++ only as "C with class". [1] http://jonathanwhiting.com/writing/blog/games_in_c/
Re: new cpuid is ready for comments
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 the link! I uploaded the code I used from Yeppp there: https://github.com/claudemr/cputest It's a bit of the mess as it is, but it works, and it looks like there is a thorough test of what features ARM hardware may provide.
Re: new cpuid is ready for comments
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. I used an arm-gcc toolchain (I don't know how to cross-compile using ldc... yet). And it's built on a native Linux OS. And it seems to work. Here's the output I have after running the code: https://gist.github.com/claudemr/98b5a4bb83e8d967b31a3044e4d81c0f Most of it is C code. There is some ARM assembly code, some of which is inlined, and some is in a ".S" file to test specific instructions. Is it what you're looking for? [1] It's called "Yeppp", and looks like what you want to do with MIR: http://www.yeppp.info/ Have you come across it?
Re: new cpuid is ready for comments
Intel Core i5: https://gist.github.com/claudemr/aa99d03360dccc65d7967651011dc8ca
