Re: macOS Sonoma Linker Issue
On Thursday, 21 December 2023 at 23:25:55 UTC, Renato wrote: ld: symbol(s) not found for architecture x86_64 Make sure you're using the "osx-universal" package in order to have both arch. https://github.com/ldc-developers/ldc/releases/tag/v1.35.0 That said, for consumer software it may be a good idea to use eg: LDC 1.28 for x86_64 and LDC 1.35 for arm64 builds. You can stich the binaries together, which will give compatibility with all macOS from 10.12 up to Sonoma (well, if you also: codesign, notarize, make a DMG...).
Re: macOS Sonoma Linker Issue
On Thursday, 21 December 2023 at 18:06:51 UTC, Renato wrote: Unless silly is completely broken, it seems like this is a linker issue again. Hello, why not use ldc instead of dmd for macOS? sudo ln -f -s /path/to/ldc/compiler/bin/ldc2 /usr/local/bin/ldc2 sudo ln -f -s /path/to/ldc/compiler/bin/dub /usr/local/bin/dub You will get multiple targets (dub -a arm64-apple-macos and -a x86_64)
Re: What parser generator can let me run arbitrary code in its match rules?
On Monday, 20 November 2023 at 23:56:36 UTC, Dmitry Ponyatov wrote: Or maybe someone advice me some set of books deeply targets for learning of binary and symmetric parsing (such as binpac), DCG in C or using generators in D, etc to let me write my own lib. 'Crafting Interpreters' book explain recursive descent parser, including parsing binary operators with priorities.
Re: performance issues with SIMD function
On Friday, 3 November 2023 at 15:11:31 UTC, Bogdan wrote: Can anyone help me to understand what I am missing? Your loop is likely dominated by sin() calls, And the rest of the loop isn't complicated enough to outperform the compiler. What you could do is use the intrinsics to implement a _mm_sin_ps that makes 4x sines at once, then you'll see an improvement at scale.
Re: D DLL crashes if not run on the main thread
On Tuesday, 5 September 2023 at 22:45:28 UTC, raven09 wrote: I *assume* that this has something to do with D's GC? But I tried calling GC.disable() and nothing changed. Any help or insight would be appreciated. Thanks in advance If you want to have a D DLL called from elsewhere, and don't control which threads call your dynlib: - first thread that comes (or the DLL load itself) should initialize the runtime. You can use pragma(crt_destructor) to deinitialize the D runtime. - threads that come through a callback should in general register to the D runtime, and unregister on exit. They will not hold roots while they are back in C land, and you must unregister them on exit else the GC will try to pause possibly dead threads when it collects. You can leave some threads unregistered, but then I'm not sure for TLS and they certainly cannot hold GC roots. You can also leave the whole D runtime disabled, but that is annoying (no GC, amongst other things).
Cool pattern or tragic?
The idea is to deliberately mark @system functions that need
special scrutiny to use, regardless of their memory-safety.
Function that would typically be named `assumeXXX`.
```d
class MyEncodedThing
{
Encoding encoding;
/// Unsafe cast of encoding.
void assumeEncoding (Encoding encoding) /* here */ @system /*
here */
{
this.encoding = encoding;
}
}
char* assumeZeroTerminated(char[] str) @system
{
return str.ptr;
}
```
That way, @safe code will still need to manually @trust them.
Re: Spec for the ‘locality’ parameter to the LDC and GDC builtin magic functions for accessing special CPU prefetch instructions
On Saturday, 19 August 2023 at 19:23:38 UTC, Cecil Ward wrote: I’m trying to write a cross-platform function that gives access to the CPU’s prefetch instructions such as x86 prefetch0/1/2/prefetchnta and AAarch64 too. I’ve found that the GDC and LDC compilers provide builtin magic functions for this, and are what I need. I am trying to put together a plain-English detailed spec for the respective builtin magic functions. Have you found that? https://github.com/AuburnSounds/intel-intrinsics/blob/002da84215a58f098cee671c5ba4ab6052613865/source/inteli/xmmintrin.d#L1935C9-L1935C9
Re: std.experimental.allocator
On Sunday, 13 August 2023 at 16:10:32 UTC, ryuukk_ wrote: Core API should subscribe to the premise: give memory allocation control (and therefore dealocation) back to the user I'm not sure about why RAII is an issue, but I fully agree with your stance about a simpler allocator, and one we can actually build upon. Great many C libraries work with just 3 preprocessor macros for malloc, free, realloc, something like that. A standard struct with 3 pointers in druntime would be great! We just can't build upon std.experimental.allocator if it doesn't work in betterC and WebASM. And it should be clear by now that D programmers want dependencies with fewer files, fewer concepts, fewer new names, (and if I may less templatitis) else they won't build upon it.
Re: Is it possible to make an Linux Executable Binary using a Windows Operating System? [compiling and linking]
On Monday, 24 July 2023 at 11:57:11 UTC, 4 wrote:
Could someone share a step by step way to compile and link a
x86-64 Linux Binary using Windows 10? (Without virtual machine
or "Linux Subsystem for Windows")
I want to compile and link a Hello World program for both Linux
and Windows.
**example.d**
```
import std.stdio;
void main()
{
writeln("Hello, World!");
}
```
So I need `.exe` binary for windows
and a runnable linux binary for linux.
1. Download LDC for Linux x86-64 and LDC for Windows
2. In your LDC that you want to use as cross-compiler, edit
etc/ldc2.conf to add the triple entry from the other LDC, for
linux cross-compiler support
3. Copy the pre-compiles libraries from the Linux LDC so that
they are accessible from your cross-compiler.
4. Use DUB with the right triple eg.
$ dub -a x86_64-something-linux
If DUB finds your cross-compiler, it will pass the triple to
-mtriple.
Re: Which D compiler is the most maintained and future-proof? [DMD GDC and LDC]
On Monday, 24 July 2023 at 09:20:05 UTC, BoQsc wrote: There are three compilers present in the Dlang website: DMD GDC and LDC DMD can build much faster than LDC. In some cases it is quite extreme, for example the product I work on has a 3.6x faster debug build time with DMD (well, only with --combined -b debug). It may be a bit more crucial that it seems to work with DMD for fast iteration, if you need a lot of experiments. It seems the product is benefiting from using DMD for prototyping, even though it was an accident at first. I wanted to compare the run times, but the same project doesn't build with DMD and optimizations. Usually LDC is 2x the speed, and LLVM output accelerate a bit over time as the optimizer gets smarter. (Numbers with LDC 1.33.0 and DMD 2.104.0)
Re: SIMD c = a op b
On Sunday, 18 June 2023 at 05:01:16 UTC, Cecil Ward wrote:
On Sunday, 18 June 2023 at 04:54:08 UTC, Cecil Ward wrote:
Is it true that this doesn’t always work (in either branch)?
float4 a,b;
static if (__traits(compiles, a/b))
c = a / b;
else
c[] = a[] / b[];
It's because SIMD stuff doesn't always works that
intel-intrinsics was created. It insulates you from the compiler
underneath.
import inteli.emmintrin;
void main()
{
float4 a, b, c;
c = a / b;// _always_ works
c = _mm_div_ps(a, b); // _always_ works
}
Sure in some case it may emulate those vectors, but for vector of
float it's only in DMD -m32. It relies on excellent __vector work
made a long time ago, and supplements it.
For 32-byte vectors such as __vector(float[8]), you will have
trouble on GDC when -mavx isn't there, or with DMD.
Do you think the builtin __vector support the same operations
across the compilers? The answer is "it's getting there", in the
meanwhile using intel-intrinsics will lower your exposure to the
compiler woes.
If you want to use DMD and -O -inline, you should also expect
much more problems unless working extra in order to have SIMD.
Re: Running LDC on a recent MacOS
On Friday, 16 June 2023 at 15:56:30 UTC, Dmitry Olshansky wrote: So I've got my hands on one of 'em MacPros. Great machine, nice build quality. Next order of business is to run D on the box, so I've downloaded universal binaries off ldc's release page. When I try to run any of the binaries nasty message box comes out to tell me it doesn't recognise the author of the binary. Any attempt to bypass the message turns to failure for me. Any advice from MacOS users? --- Dmitry Olshansky Right click on the executable and select "open" then pass the popup, next time it is executed it will run from the cmdline.
Re: Best way to use C library
On Friday, 19 May 2023 at 18:31:45 UTC, Maximilian Naderer wrote: Hello guys, So what’s currently the best way to use a big C library? Let’s assume something like cglm assimp glfw - Some big libraries are translated, for example https://code.dlang.org/packages/glfw-d was created with both manual work and ctod (https://forum.dlang.org/thread/hfpirezenlabjqtwe...@forum.dlang.org) Even then it is pretty manual and AI barely help with D. - Some libraries can be loaded with BindBC (typically dynamically) so that you can use existing builds. https://code.dlang.org/search?q=bindbc Creating a new BindBC-style package is typically manual but normally low maintenance after the fact. Now, if using a complex C++ libraries involves inlined C++ types, it will be a lot harder to create a nice D port. A library like cglm almost must be ported, a bindings won't help here, since it's probably lots of inlined C++ types in headers. You can use the package inmath instead.
Re: A Programmer's Dilema: juggling with C, BetterC, D, Macros and Cross Compiling, etc.
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote: So what language do you recommend: * Keep everything in plain C * Use C patched with macros to gain some language features like Foreach * Use BetterC for everything * Use D for the games, and better C or C for the libraries(To keep some compatibilities) * Use D for everything, no C compatibility. If you have other suggestions or questions let me know. My recommendation would be to acclimate to D, use it with a C style, but do it in normal D (with bindbc bindings to C libraries like SDL or, considering where you are coming from, raylib). You could use BetterC for sure, but it's more practical in the long term to just learn to live with the GC: it is a one-time mental cost.
Re: Memory leak issue between extern (c) and D function
On Friday, 14 April 2023 at 17:31:02 UTC, backtrack wrote: however the memory is not releasing. With the D GC, your object can have three state: - reachable by GC. If D code can see the reference, then it's "alive", kept alive by GC scanning. The GC finds the reference and doesn't touch it. This is the invariant that you need to maintain when interacting with C. - unreachable by GC and thus at a risk of being reclaimable at next GC collect. This happens when all your references are null. If you want immediate destructor, call .destroy() before nulling your references so that the object can't be scanned. By calling destroy() on all your objects manually, you can reach destruction determinism. - non-existing, memory has been reclaimed. You don't necessarily need to do that with __delete, this should be very rare even. If the references to the object are null, then their destructor will eventually be called if it wasn't already with .destroy, the memory eventually reclaimed. Usually you don't need to care about that state.
Re: Memory leak issue between extern (c) and D function
On Friday, 14 April 2023 at 11:15:59 UTC, Guillaume Piolat wrote: OP could add another extern(C) D function to free the allocated object. Or another extern(C) D function to call GC.addRoot Or simpler, add that object to a list of object in D DLL __gshared list, then clear the list (or set individual reference to null) if you want to reclaim space.
Re: Memory leak issue between extern (c) and D function
On Friday, 14 April 2023 at 04:43:39 UTC, Paul Backus wrote:
If you want the GC to clean up your memory, use `new` to
allocate it instead of `malloc`. Like this:
```d
mystruct* getmystruct()
{
return new mystruct;
}
```
That won't work because the C++ programm calling the D dynlib
will not have its stack scanned, leading to that object being
reclaimed early.
OP could add another extern(C) D function to free the allocated
object.
Or another extern(C) D function to call GC.addRoot
Re: What do you think about using Chat GPT to create functions in D?
On Monday, 3 April 2023 at 23:38:52 UTC, Marcone wrote: What do you think about using Chat GPT to create functions in D? Well you can use GitHub Copilot in VSCode, and it is kind of interesting but at the current time seems like a distracting waste of time. It will probably get more useful in a few years. LLMs repeats commonly accepted lies as gospel, so do not expect a well adjusted human-like opinion on anything.
Re: Why are globals set to tls by default? and why is fast code ugly by default?
On Saturday, 1 April 2023 at 08:47:54 UTC, IGotD- wrote: TLS by default is mistake in my opinion and it doesn't really help. TLS should be discouraged as much as possible as it is complicated and slows down thread creation. It looks like a mistake if we consider none of the D-inspired languages have stolen TLS-by-default.
Re: Why are globals set to tls by default? and why is fast code ugly by default?
On Friday, 31 March 2023 at 19:43:42 UTC, bachmeier wrote: Those of us that have been scarred by reading FORTRAN 77 code would disagree. I use global mutables myself (and even the occasional goto), but if anything, it should be `__GLOBAL_MUTABLE_VARIABLE` to increase the pain of using them. But you kind of get into the same things with "accidental TLS". It doesn't race, but now the variable is different for every thread, which is a different kind of race. TLS could be explicit and we wouldn't need a -vtls flag. There is no flag to warn for every use of @trusted, so in the grand scheme of things TLS is more dangerous than @trusted.
Re: Why are globals set to tls by default? and why is fast code ugly by default?
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote: Even C does it better: https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html Honestly I find TLS-by-default to be a bad idea, it has become a trap to be avoided, and TLS does occasionally speed up things but it should be opt-in.
Re: better video rendering in d
On Friday, 24 March 2023 at 15:41:36 UTC, Guillaume Piolat wrote: Hi, The idea to pipe stdout to ffmpeg is sound. In the following dead repo: https://github.com/p0nce/y4m-tools you will find a tool that capture a shader, format it into Y4M and output on stdout. Y4M output is useful because it embeds the metadata unlike .yuv See: https://github.com/p0nce/y4m-tools/blob/master/shader-capture/example.sh Fixed the URLs. How to output .y4m => https://github.com/p0nce/y4m-d/blob/master/source/y4md/package.d
Re: better video rendering in d
On Tuesday, 21 March 2023 at 16:57:49 UTC, monkyyy wrote: My current method of making videos of using raylib to generate screenshots, throwing those screenshots into a folder and calling a magic ffmpeg command is ... slow. Does anyone have a demo or a project that does something smarter (or willing to do the busy work of finding the right combo of dependencies that just work) I require basic images, text, and transparent rectangles https://youtu.be/HxFSmDNvDUI ideally raylib or image magik for the frame generation Hi, The idea to pipe stdout to ffmpeg is sound. In the following dead repo: https://github.com/p0nce/y4m-tools you will find a tool that capture a shader, format it into Y4M and output on stdout. Y4M output is useful because it embeds the metadata unlike .yuv See: https://github.com/p0nce/y4m-tools/blob/master/shader-capture/example.sh
Re: Can nice D code get a bit slow?
On Wednesday, 8 March 2023 at 10:49:32 UTC, Markus wrote: Uh, hope you understand my vague question, sorry about that. I found D to be the right place because it's not missing any essential feature I know of. Well, bounds check often cost a few percent, and you can disable it or use .ptr @safe will push you to use slices instead of raw pointers, and those can occupy the stack a bit more, but it's not a huge effect. Lack of dangerous "fast math" "optimizations" is a real boon for correctness. We don't have integers overflows, those would also cost a few percent. Your D programs by being easy to modify will have very few performance bottlenecks that are problematic, often the CPU-bound or memory-bound stuff that would be slow in any language. For example I like to merge array allocations, this necessitates the same code in C, C++, or any native language. I think it's important not to go overboard with lazy chains and templates though. Honestly the increased productivity will leave you ample time to make things fast, and you can use the native profilers, for example Intel Vtune. This year I released a free VST compressor named Lens, it does more than the closest manybands competitor while being in the ballpark CPU-wise, and they are using ICC AVX2 which does dynamic instruction set dispatch, while we use SSSE3. Optimization is all about having the time to do it.
Re: compile x64 .dll and .so without dependencies
On Sunday, 5 March 2023 at 06:36:05 UTC, novice2 wrote: It there any recipe to compile x64 .dll without dependencies? I mean it shoud be used without installing things like msvcr120.dll. Dependencies on system dll (advapi32.dll, kerner32.dll) is ok. I don't experiment on linux yet. But interest too. What we do here in dub.json, for no deps on big 3 desktop OSes: "targetType": "dynamicLibrary", "dflags-linux-dmd": ["-defaultlib=libphobos2.a"], "dflags-osx-ldc": ["-static"], "dflags-linux-ldc": ["-link-defaultlib-shared=false"], "dflags-linux-x86_64-ldc": ["-fvisibility=hidden"], "dflags-windows-ldc": ["-mscrtlib=libcmt","-fvisibility=hidden", "-link-defaultlib-shared=false"], Additionally on (Windows + DUB + LDC), you will need to set an envvar: DFLAGS=-fvisibility=hidden -dllimport=none else you may still depend upon a dynamic phobos. It's unfortunate situation for such a common requirement...
Re: Big struct/class and T.init
On Sunday, 19 February 2023 at 18:29:05 UTC, Steven Schveighoffer
wrote:
On 2/19/23 1:26 PM, Steven Schveighoffer wrote:
Testing with run.dlang.io, switching between `char` and `int`
changes the ASM output to show whether it's stored or not.
And BTW, you can override this by assigning a zero default:
```d
struct S
{
char[16384] array = 0; // no .init storage
}
```
-Steve
TIL. Nice trick!
Big struct/class and T.init
If my understanding is correct, the mere fact of having a:
struct S
{
char[16384] array;
}
And then using it anywhere, will necessarily lead to a S.init
being created and linked, leading to a binary size inflation of
16kb.
This is not a super high concern, but can inform design decisions.
Is this correct?
Re: Debugging memory leaks
On Wednesday, 15 February 2023 at 18:21:34 UTC, Hipreme wrote: I want to know if there is some way to debug memory leaks in runtime. I have been dealing with that by using a profiler and checking D runtime function calls. Usually those which allocates has high cpu usage so it can be easy for those bigger ones. While for the smaller ones, this approach doesn't seem to work and looking into my task manager I can see it increasing the memory usage very slowly. I wanted to know if there is an option to do that on RUNTIME. --vgc is not a good option as I don't care about allocations that happens on initialization code. Hello, As of a few years, Intel Inspector is free: https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html#inspector
Re: ImportC "no include path set"
On Wednesday, 8 February 2023 at 14:08:47 UTC, bachmeier wrote: this looks like one of those "death by paper cut" things. It has the smell of a rough edge that needs fixing. It's the one reason I haven't even tried ImportC. I still wonder why I need to provide those headers while for linking MSVC is kinda autodetected now.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 8 February 2023 at 12:10:59 UTC, zjh wrote: On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote: they are always unwilling to add facilities useful to others, `D`'s community is small, this is the reason! yeah right let's implement everything that people propose
Re: Which TOML package, or SDLang?
On Monday, 30 January 2023 at 06:38:46 UTC, Daren Scot Wilson wrote: I just realized - it's been ages since I've dealt with config files, beyond editing them as an end user. I work on existing software where someone else made the choiced and wrote the code, or it's a small specialized project not needing config. I'm a config caveman! Why not XML? :) It has comments, you can use backslashes too.
Re: Idiomatic D using GC as a library writer
On Sunday, 4 December 2022 at 21:55:52 UTC, Siarhei Siamashka wrote: Is it possible to filter packages in this list by @nogc or @safe compatibility? You can list DUB packages for "@nogc usage" https://code.dlang.org/?sort=score=20=library.nogc
Re: Idiomatic D using GC as a library writer
There are legitimate uses cases when you can't afford the runtime machinery (attach/detach every incoming thread in a shared library), more than not being able to afford the GC from a performance point of view. GC gives you higher productivity and better performance with the time gained. Now, @nogc code is good for performance since (even in a GC program) you will have no hidden allocation anymore, if you also disable postBlut and copy ctor, unlike in C++ where hidden copies are rempant. On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: What are your thoughts about using GC as a library writer? I don't use it always, but wish I could do it. Meanwhile, I make plenty of nothrow @nogc code. On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote: If you wan't to include a library into your project aren't you more inclined to use a library which is gc free? Yes I am, but my needs are very specific and only the "betterC" subset fits it, and it's certainly not the nominal case in D, nor should it be. Some of the D target have strict requirements, for example Hipreme engine use audio-formats (nothrow @nogc), but audio-formats uses exceptions internally, maybe that will be an issue, depending on the flavour of D runtime it uses.
Re: Makefiles and dub
On Saturday, 5 November 2022 at 12:17:14 UTC, rikki cattermole wrote: But yes, it has two others (although idk how much they get used, or how complete). Using the first two all the time. IIRC VisualD projects respect --combined
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Friday, 4 November 2022 at 19:53:01 UTC, Adam D Ruppe wrote: This isn't that hard; in the old days you'd have `pkg.foo` then `import pkg.all` instead of `import pkg;`. It was worse, you would do import mylib.all; and now it's just: import mylib; Also the "all" concept is bad, it should really be "mylib.api", because why import the private symbols.
Re: parallel is slower than serial
On Tuesday, 18 October 2022 at 11:56:30 UTC, Yura wrote: What I am doing wrong? The size of your task are way too small. To win something with OS threads, you must think of tasks that takes on the order of milliseconds rather than less than 0.1ms. Else you will just pay extra in synchronization costs.
Re: How do I correctly install packages for use with Visual Studio?
On Sunday, 16 October 2022 at 11:09:31 UTC, Decabytes wrote: I'm trying to set up Visual Studio 2022 with Visual D, and I'm running into issues trying to get my project to build correctly. Some recommendation to use Visual Studio: - tutorial for installation here: https://p0nce.github.io/d-idioms/#Installing-Dlang-on-Windows - then generate a Visual Studio solution with: dub generate visuald# default dub generate -a x86 visuald --compiler dmd # for DMD, x86 arch dub generate -a x86_64 visuald -c conf # x86_64 arch, DUB configuration "conf" dub generate visuald --combined # single VisualD project with all deps - if you use libraries that work with DUB they should come with static libs, or have dynamic loaders instead. Building .lib files yourself is just more annoying, and you will have to do it for each system you want to support
Is it possible? branching on debug info
I'd like to have:
version (D_DebugInfo)
{}
else
{
version = enableFeatureThatIsAnnoyingWhenDebugging;
}
Is there a way to know if debug info is being emitted when
compiling?
"debug is not cutting it because sometimes you really need to
debug with or without -debug, and with or without -O. I want -g.
Re: how to install the new dmd on Mac M1?
On Thursday, 25 August 2022 at 14:19:47 UTC, MichaelBi wrote: I downloaded the new dmd 2.1 on Mac, but with fail message of "unsupported Arch arm64". how can I do? thanks. ## Step 1 Get LDC here: https://github.com/ldc-developers/ldc/releases - If you are running on Apple Silicon, be sure to use the Universal LDC package (for LDC version >= 1.30). - If the "Universal" build is not available, use the x86_64 LDC package instead. (for LDC version < 1.30). Those builds are cross-compilers, able to target both x86_64 and arm64, with flags -a x86_64-apple-macos and -a arm64-apple-macos respectively. ## Step 2 Make sure you are using the dub and ldc2 executable from those builds. Please install Xcode 12.2+ to. $ sudo ln -s /my/absolute/path/to/ldc-xxx/bin/ldc2 /usr/local/bin/ldc2 $ sudo ln -s /my/absolute/path/to/ldc-xxx/bin/dub /usr/local/bin/dub - build a x86_64 program with: `dub -a x86_64-apple-macos` - build an arm64 program with: `dub -a arm64-apple-macos`
Re: Fetching licensing info for all dependencies of a DUB project
On Monday, 27 June 2022 at 21:36:31 UTC, Christian Köstlin wrote: I played around with the idea and came up with a small dub package, that is not (yet) uploaded to the dub registry. Source is available at https://github.com/gizmomogwai/packageinfo, feedback very welcome. I've done something similar not for licences but for code amount, to extract from a DUB project: - DUB packages used by project - source files used by project - and their LOC count This is a D forums exclusive: https://pastebin.com/RFbFCgR2 Keep your debt in check!
Re: Consuming D libraries from other languages
On Wednesday, 15 June 2022 at 19:36:34 UTC, Guillaume Piolat wrote: BindBC bindings are multi-platform and can be both static and dynamic linking. My bad I understood the reverse, consuming C libraries from D. I think what you are seeking is described in the D blog.
Re: Consuming D libraries from other languages
On Wednesday, 15 June 2022 at 17:37:32 UTC, Templated Person wrote: It there any resources on how to build D static (`.lib` / `.a`) and dynamic libraries (`.dll` / `.so`), and then use them from C? Do I need to link and initialize phobos somehow? What if I don't want to use the D runtime? What happens with module level `this()` and `~this()`? Is there a comprehensive guide on how to do this stuff? What I would suggest is to look at a few of the BindBC libraries and mimic them. https://code.dlang.org/search?q=bindbc BindBC bindings are multi-platform and can be both static and dynamic linking. They can also work without a D runtime.
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On Monday, 6 June 2022 at 22:24:45 UTC, Guillaume Piolat wrote: My understanding is that while scanning, the GC will see the data.ptr pointer, but will not scan the area it points to since it's not in a GC range (the runtime can distinguish managed pointer and other pointers). After scanning, when obj is non-reachable, the GC will destroy it but that won't lead to a reclaim of data.ptr since it knows it doesn't own that. In D, the ownership of slice is purely determined by the memory area it points to. If it points into GC memory then it's a GC slice.
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On Monday, 6 June 2022 at 22:18:08 UTC, mw wrote: So when `obj` is cleanup by the GC, obj.data won't be freed by the GC: because the `data` is non-gc-allocated (and it's allocated on the non-gc heap), the GC scanner will just skip that field during a collection scan. Is this understanding correct? My understanding is that while scanning, the GC will see the data.ptr pointer, but will not scan the area it points to since it's not in a GC range (the runtime can distinguish managed pointer and other pointers). After scanning, when obj is non-reachable, the GC will destroy it but that won't lead to a reclaim of data.ptr since it knows it doesn't own that.
Re: How to map machine instctions in memory and execute them? (Aka, how to create a loader)
On Monday, 6 June 2022 at 15:13:45 UTC, rempas wrote: Any ideas? See: https://github.com/GhostRain0/xbyak https://github.com/MrSmith33/vox/blob/master/source/vox/utils/mem.d
Re: Why are structs and classes so different?
On Sunday, 15 May 2022 at 15:26:40 UTC, Kevin Bailey wrote: I'm trying to understand why it is this way. I assume that there's some benefit for designing it this way. I'm hoping that it's not simply accidental, historical or easier for the compiler writer. Perhaps someone more informed will chime in, but there is a reason to avoid object inheritance with value types, and force them to be reference types. https://stackoverflow.com/questions/274626/what-is-object-slicing If we want to avoid that problem, then object with inheritance and virtual functions have to be reference types. But you still need values types. So now you have both struct and class, like in C# (Hejlsberg, 2000). For an escape hatch, D has library ways to have structs with virtual functions (there is a DUB package for that), and classes on the stack (Scoped!T, RefCounted!T, a __traits).
Re: What are (were) the most difficult parts of D?
On Friday, 13 May 2022 at 19:16:59 UTC, Steven Schveighoffer
wrote:
But we also have this confusing dynamic:
|scope |no attribute| shared |static |
||||---|
|module |TLS |global |TLS (no-op)|
|function|local |local! |TLS|
|class |instance|global |TLS|
There is a typo in your array, a shared field is per-instance,
not global.
class A
{
shared int c; // Each A has its own c
}
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 17:34:30 UTC, H. S. Teoh wrote:
Why is TLS by default a problem?
It's not really for optimization, AIUI, it's more for thread
safety: module-global state is TLS by default, so you don't
accidentally introduce race conditions.
What you accidentally have instead is people expecting top-level
to be global
and instead you get TLS, so it's a surprise.
I mean, a lot of things works like C and C++, but not that.
It's a problem because it goes from solving "no accidental race
condition" and you get "people forget to add shared or __gshared
and their shared library silently fail" situation. You could have
none of that with explicit TLS.
- `shared static this()` vs `static this()` is another
trap.
One is per-process, one is per-thread. Why is this a trap?
Well because you can get that wrong.
You get to initialize "__gshared" variables in "shared static
this".
It's not hard, but it's something more to explain.
I wouldn't sweat it if I couldn't easily add `pure` to an
entire codebase -- it hardly makes any difference anyway.
If it doesn't make a difference to the bottom-line then why keep
it?
you're on your own and you take responsibility for any problems
that you may inadvertently introduce by using the escape hatch.
Well sizeable @afe code has heaps of @trusted code, so the escape
hatch is very routine.
it's none of the users' business.
I'm not disagreeing about @trusted in API.
But I was remarking in practice that @safe would mean different
invariants.
it's not a big issue, I was probably ranting.
IOW, public APIs should always be @safe or @system. @trusted
should only appear on internal APIs.
Good rule to follow, TIL.
So I'm curious, what exactly is it about UFCS chains that make
it less maintainable?
Probably personal preference, I mostly write the pedestrian way,
so that debugging/optimization goes faster (maybe wrong, dunno).
In the dlang.org example:
void main()
{
stdin
.byLineCopy
.array
.sort!((a, b) => a > b) // descending order
.each!writeln;
}
This code has a number of prerequisites to be able to read: why
is ".array" needed, why is it ".byLineCopy" vs ".byLine", is the
sort stable, etc. It's just requires more time spent with the
language.
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 16:24:26 UTC, Ali Çehreli wrote: Cool trick but "parent" confused me there. I think you mean "base". :) https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming mentions "base class" as much as "parent class"
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 11:05:08 UTC, Basile B. wrote: - Certain variant forms of the `is` Expression are not obvious (not intuitive), I'm pretty sure I still cant use them without a quick look to the specs. That one was a trouble to hear about => http://p0nce.github.io/d-idioms/#Get-parent-class-of-a-class-at-compile-time
Re: What are (were) the most difficult parts of D?
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote: What are you stuck at? What was the most difficult features to understand? etc. - How to do deterministic destruction with programs that use everything (struct / class / dynamic dispatch / GC / manual / etc). This requires to understand what the runtime does, what the gc does. Interesting nonetheless. - Some traps. Accidental TLS is a thing, top-level should probably not be silently TLS. People will loose hours on this completely preventable thing. What was the idea, optimize code without people knowing? - `shared static this()` vs `static this()` is another trap. Honestly would have preferred `__threadlocal`. It's not like being thread-local is something completely normal or without consequence for platform support. - Some features lack an escape hatch, notably `pure`. pure leaks into identifiers, like `pureMalloc`. Trying to add `pure` fails on a large codebase. - `@safe`/`@trusted`/`@system` is good but the definition of what `@trusted` means has to be remembered from the programmer. For example `Mutex.lock()` is `@trusted`, it could have been `@system` to let user review their usage of locks. You have to wonder "can a lock()/unlock() corrupt memory?". People can use that to mean "@reviewed" instead. Because it is up to us, the exact meaning will float in the D subcultures. A function which has been marked `@trusted` does not receive any review whan changed later. It will not mean the same as `@trusted` in another codebase. - Generic code typically has bad names (domain-less) and worse usability. It's often not pretty to look at. Mostly cultural, since D has powerful templates so they had to be everywhere. UFCS chains are not that convincing when you are worried about maintenance. Phobos take short names for itself, this leads to pretty complicated operations having a small screen estate. - `assert(false)` being different and not removed by `-release`. Keyword reuse seems entrenched but honestly a "crash here" keyword would be more readable. It is really 3 different things: assert, crash, and unreachable. Otherwise D is glorious and get syntax and usability right, which puts it ahead of almost every other language.
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 22:16:15 UTC, rikki cattermole wrote: Of course I still don't think that code is right and should have the casts. Absolutely. I'm a bit anxious about "accidental VRP" now, not sure if the checks fluctuate from version to version, or worse, depends upon the platform.
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 21:59:39 UTC, rikki cattermole wrote: Putting an int into a ubyte absolutely should error, that is a lossy conversion and should not be automatic. It's just VRP, here it works in 2.094 https://d.godbolt.org/z/vjq7xsMdn because the compiler wasn't complaining I wouldn't know it was reliant on VRP (which is certainly an issue to be fixed).
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 21:44:56 UTC, rikki cattermole wrote:
On 27/04/2022 9:39 AM, Guillaume Piolat wrote:
On Tuesday, 26 April 2022 at 21:13:38 UTC, Alexander Zhirov
wrote:
more build errors
If you "dub upgrade" it should work a bit better.
No success in reproducing the bug here.
It definitely on your end.
void main() {
int scale;
int* in_ = new int;
ubyte b = cast(int)scale * (cast(int)*in_ >> 7);
}
onlineapp.d(5): Error: cannot implicitly convert expression
`scale * (*in_ >> 7)` of type `int` to `ubyte`
No.
Obviously VRP works differently for me and for him, for an
unknown reason.
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 21:13:38 UTC, Alexander Zhirov wrote: more build errors If you "dub upgrade" it should work a bit better. No success in reproducing the bug here.
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 20:45:16 UTC, Alexander Zhirov wrote: On Tuesday, 26 April 2022 at 20:37:28 UTC, Guillaume Piolat wrote: Curious as to what DMD you are using on what OS? It builds with 2.095.1 to 2.100-b1 here. DMD64 D Compiler v2.098.0 OS Solus Linux Well I cannot reproduce your problem => https://imgur.com/a/HZvZWr2 Perhaps a DUB mismatch that would give different DIP flags. DUB version 1.27.0, built on Oct 19 2021 Good luck.
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 20:26:42 UTC, Alexander Zhirov wrote: build error Curious as to what DMD you are using on what OS? It builds with 2.095.1 to 2.100-b1 here.
Re: Library for image editing and text insertion
On Tuesday, 26 April 2022 at 17:22:54 UTC, Alexander Zhirov wrote: It is necessary to write a utility that will insert (x,y) text on the image. It is desirable that the utility does not depend on large libraries, since a minimum utility size is required. I'm looking for something similar in C/C++, I can't find anything. Maybe there is some simple library on D? You can eventually use dplug:graphics for that https://u.pcloud.link/publink/show?code=XZPwMFVZW9c6bTWtevRvNz7UdfOOqVYIE5uk
Re: How to use Vector Extensions in an opBinary
On Sunday, 17 April 2022 at 11:16:25 UTC, HuskyNator wrote: As a small disclaimer; I don't know to what extent the compiler already automates these kind of operations, and mostly want to use this as a learning experience. For your particular case, it is very likely LDC and GDC will be able to optimize your loops using SIMD.
Re: Looking for a workaround
On Thursday, 7 April 2022 at 12:56:05 UTC, MoonlightSentinel wrote: On Wednesday, 6 April 2022 at 18:10:32 UTC, Guillaume Piolat wrote: Any idea how to workaround that? I really need the same UDA in parent and child class. Use a frontend >= dmd 2.099, it works according to run.dlang.io. Good to know, thanks.
Re: Looking for a workaround
On Wednesday, 6 April 2022 at 18:21:11 UTC, Adam D Ruppe wrote:
On Wednesday, 6 April 2022 at 18:10:32 UTC, Guillaume Piolat
wrote:
Any idea how to workaround that?
Works fine if you just use the language instead of the buggy
phobos wrappers:
---
struct MyUDA
{
}
class A
{
@MyUDA int a;
}
class B : A
{
@MyUDA int b;
}
void main()
{
foreach(memberName; __traits(allMembers, B))
foreach(attr; __traits(getAttributes,
__traits(getMember, B, memberName)))
static if(is(attr == MyUDA))
pragma(msg, memberName); // a, b
}
---
So make a function that does that and applies whatever it is
you need to apply and you're in business.
Note that it is `is(typeof(attr) == MyUDA)` if defined
`@MyUDA(args)`.
Thanks, it will also create less templates.
Looking for a workaround
This program fails to build:
import std.traits: getSymbolsByUDA;
struct MyUDA
{
}
class A
{
@MyUDA int a;
}
class B : A
{
@MyUDA int b;
}
void main()
{
alias G = getSymbolsByUDA!(B, MyUDA);
}
Output:
c:\d\ldc2-1.28.0-windows-multilib\bin\..\import\std\traits.d(8933): Error: template
instance `AliasSeq!(b, a)` `AliasSeq!(b, a)` is nested in
both `B` and `A`
c:\d\ldc2-1.28.0-windows-multilib\bin\..\import\std\traits.d(8707): Error: template
instance `std.traits.getSymbolsByUDAImpl!(B, MyUDA, "b", "a",
"toString", "toHash",
"opCmp", "opEquals", "Monitor", "factory")` error
instantiating
main.d(19):instantiated from here:
`getSymbolsByUDA!(B, MyUDA)`
Failed:
["c:\\d\\ldc2-1.28.0-windows-multilib\\bin\\ldmd2.exe", "-v",
"-o-", "main.d", "-I."]
Any idea how to workaround that? I really need the same UDA in
parent and child class.
Re: I like dlang but i don't like dub
On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote: Dlang includes some good ideas. But dub pulls in so much stuff. Too much for me. I like things which are clean,lean,little,small. But when i use dub it links with so many libraries. Are they really needed ? And how do you compare to pythons pip. Feel free to elaborate. DUB changed my programming practice. To understand why DUB is needed I think it's helpful to see the full picture, at the level of your total work, in particular recurring costs. ### An example My small software shop operation (sorry) is built on DUB and if I analyze my own package usage, there are 4 broad categories: - Set A. Proprietary Code => **8 packages, 30.4** kloc - Set B. Open source, that I wrote, maintain, and evolve => **33 packages, 88.6** kloc - Set C. Open source, that I maintain minimally, write it in part only => **5 packages, 59.1** kloc - Set D. Foreign packages (not maintaining it, nor wrote it. Stuff like arsd) => **14 package, 45.9** kloc => Total = **224 kloc**, only counting non-whitespace lines here. This is only the code that needs to be kept alive and maintained. Obviously code that is more R and/or temporary bear no recurring cost. Visually: Set A: ooo 30.4 (proprietary) Set B: o 88.6 (open-source) Set C: oo 59.1 (open-source) Set D: 45.9 (open-source) -- Total: oo ### What is the cost of maintaining all that? At a very minimum, all code in A + B + C + D needs to build with the D compiler since the business use it, and build at all times. Maintaining the "it builds" invariant takes a fixed cost m(A) + m(B) + m(C) + m(D). Here m(D) is beared by someone else. As B and C are open-source and maintained by me, the cost of building B and C for someone else is zero, that's why ecosystem is so important for language, as a recurrent expense removal. And indeed, open-source ecosystem is probably the main driver of language adoption, as a pure capital gain. Now consider the cost of evolving and bug fixing instead of just building. => This is about the same reasoning, with perhaps bug costs being less transferrable. Reuse delivers handsomely, and is cited by the Economics of Software Quality as one of the best driver for increased quality [1]. Code you don't control, but trust, is a driver for increased quality (and as the book demonstrate: lowered cost/defect/litigations). ### Now let's pretend DUB doesn't exist For maintaining the invariant "it builds with latest compiler", you'd have to pay: m(A) + m(B) + m(C) but then do another important task: => Copy each new updated source in dependent projects. Unfortunately this isn't trivial at all, that code is now duplicated in several place. Realistically you will do this on an as-needed basis. And then other people can rely on none of your code (it doesn't build, statistically) and then much fewer ecosystem becomes possible (because nothing builds and older version of files are everywhere). Without using DUB, you can't have a large set of code that maintain this or that invariant, and will have to rely to an attentional model where only the last thing you worked on is up-to-date. DUB also make it easy to stuff your code into the B and C categories which provides value for everyone. With DUB you won't have say VisualD projects because the cost of maintaining the invariant "has a working VisualD project" would be too high, but with DUB because it's declarative it's almost free. [1] "The Economics of Software Quality" - Jones, Bonsignour, Subramanyam
Re: Colors in Raylib
On Monday, 28 February 2022 at 11:48:59 UTC, Salih Dincer wrote: Is there a namespace I should implement in Raylib? For example, I cannot compile without writing Colors at the beginning of the colors: ```Colors.GRAY``` When writing C bindings, you may refer to this: https://p0nce.github.io/d-idioms/#Porting-from-C-gotchas This keeps example code working.
Re: How to deploy single exe application (?)
On Wednesday, 1 December 2021 at 09:49:56 UTC, Guillaume Piolat wrote: Huh, I never intended for someone to actually use this :| Such a thing will never work on macOS for example. You can create an installer rather easily with InnoSetup instead.
Re: How to deploy single exe application (?)
On Wednesday, 1 December 2021 at 07:45:21 UTC, bauss wrote: On Monday, 29 November 2021 at 14:58:07 UTC, Willem wrote: Thanks again for all the responses. For now -- I am simply adding the DLL to the EXE and writing it out to the working directory. Not elegant - but it does work. If you intend to distribute it then becareful with this as it might trigger some (if not all) antiviruses under most configurations. Huh, I never intended for someone to actually use this :| Such a thing will never work on macOS for example.
Re: Is DMD still not inlining "inline asm"?
On Friday, 12 November 2021 at 00:46:05 UTC, Elronnd wrote: On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote: As for now, I know no compiler that can do that. GCC can do it. Somewhat notoriously, LTO can lead to bugs from underspecified asm constraints following cross-TU inlining. LDC can also do it with GCC asm constraints, however it is atrociously hard to get documentation and examples for this.
Re: Rather Bizarre slow downs using Complex!float with avx (ldc).
On Friday, 1 October 2021 at 08:32:14 UTC, james.p.leblanc wrote: Does anyone have insight to what is happening? Thanks, James Maybe something related to: https://gist.github.com/rygorous/32bc3ea8301dba09358fd2c64e02d774 ? AVX is not always a clear win in terms of performance. Processing 8x float at once may not do anything if you are memory-bound, etc.
Re: Loading assimp
On Tuesday, 28 September 2021 at 16:30:09 UTC, Eric_DD wrote: I am trying to use a newer version of Assimp. I have found a assimp-vc140-mt.dll (v3.3.1) which I renamed to assimp.dll When running my executable it throws a derelict.util.exception.SharedLibLoadException: "Failed to load one or more shared libraries: assimp.dll - %1 is not a valid Win32 application. Assimp64.dll - The specified module could not be found" Any idea what's going on? Are 64bit dlls not supported? If using dub you can build your D programs with dub -a x86 for a 32-bit executable dub -a x86_64 for a 64-bit executable (which is also the default thankfully). Your problem is very probably trying to load a 32-bit DLL into a 64 host program.
Re: Two major problems with dub
On Tuesday, 3 August 2021 at 00:54:56 UTC, Steven Schveighoffer wrote: Given the way D works, and often template-heavy coding styles, I think it's going to be hard to do this correctly, without careful attention and lots of `version(has_xxx)` conditionals. -Steve I don't think optional dependencies are truly the answer. There are ways to fix this otherwise is to break dependency chains when only a small part is used. In this case: - use a GC slice - use malloc - use std.experimental.allocator My pet peeve is the isfreedesktop package. https://github.com/FreeSlave/isfreedesktop/blob/master/source/isfreedesktop.d package :) Yes it is annoying, but with a bit of copy-paste you can break dependencies chain and avoid the npm situation where "640 packages were installed"
Re: Registering-unregistering threads
On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote: Info on it is quite scarce and a bit confusing. If I unregister from the RT, will that mean it'll be GC independent, or will have other consequences too? The consequence is that the stack memory of that thread isn't traced, so things that are only "owned" pointed to transitively by pointers on the thread stack might get collected under your feet. Your thread should use things that outlive its existence.
Re: LLVM asm with constraints, and 2 operands
On Monday, 19 July 2021 at 17:20:21 UTC, kinke wrote:
You know that asm is to be avoided whenever possible, but
unfortunately, AFAIK intel-intrinsics doesn't fit the usual
'don't worry, simply compile all your code with an appropriate
-mattr/-mcpu option' recommendation, as it employs runtime
detection of available CPU instructions.
intel-intrinsics employs compile-time detection of CPU
instructions.
If not available, it will work anyway(tm) with alternate slower
pathes (and indeed need the right -mattr, so this is the one
worry you do get).
So, not using @target("feature") right now, figured it would be
helpful for runtime dispatch, but that means literring the code
with __traits(targetHasFeature).
Re: LLVM asm with constraints, and 2 operands
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote: This workaround is actually missing the clobber constraint for `%2`, which might be problematic after inlining. An unrelated other issue with asm/__asm is that it doesn't follow consistent VEX encoding compared to normal compiler output. sometimes you might want: paddq x, y at other times: vpaddq x, y, z but rarely both in the same program. So this can easily nullify any gain obtained with VEX transition costs (if they are still a thing).
Re: LLVM asm with constraints, and 2 operands
On Monday, 19 July 2021 at 16:05:57 UTC, kinke wrote: Is LDC still compatible with GDC/GCC inline asm? I remember Johan saying they will break compatibilty in the near future... I'm not aware of any of that; who'd be 'they'? GCC breaking their syntax is IMO unimaginable. LDC supporting it (to some extent) is pretty recent, was introduced with v1.21. It went under my radar. Thanks for the tips in this thread.
Re: LLVM asm with constraints, and 2 operands
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote: What works reliably is a manual mov: OK that's what I feared. It's very easy to get that wrong. Thankfully I haven't used __asm a lot.
Re: LLVM asm with constraints, and 2 operands
On Sunday, 18 July 2021 at 18:48:47 UTC, Basile B. wrote: On Sunday, 18 July 2021 at 18:47:50 UTC, Basile B. wrote: On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat wrote: On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote: [...] Thanks. Indeed that seems to work even when inline and optimized. Registers are spilled to stack. A minor concern is what happens when the enclosing function is extern(C) => https://d.godbolt.org/z/s6dM3a3de I need to check that more... I think this should be rejected just like when you use D arrays in the interface of an `extern(C)` func, as C has no equivalent of __vector (afaik). but in any case there's a bug. I checked and thankfullyit works when the enclosed function is inlined in an extern(C) function, that respects extern(C) ABI.
Re: LLVM asm with constraints, and 2 operands
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
Yeah I can confirm it's aweful. Took me hours to understand how
to use it a bit (my PL has [an
interface](https://styx-lang.gitlab.io/styx/primary_expressions.html#asmexpression) for LLVM asm)
You need to add a "x" to the constraint string
return __asm!int4("paddd $1,$0","=x,x,x",a, b);
- **=x** says "returns in whatever is has to"
- **x** (1) is the constraint for input `a`, which is passed as
operand **$0**
- **x** (2) is the constraint for input `b`, which is passed as
operand **$1**
So the thing to get is that the output constraint does not
consume anything else, it is standalone.
Thanks.
Indeed that seems to work even when inline and optimized.
Registers are spilled to stack.
A minor concern is what happens when the enclosing function is
extern(C) => https://d.godbolt.org/z/s6dM3a3de
I need to check that more...
LLVM asm with constraints, and 2 operands
Is anyone versed in LLVM inline asm?
I know how to generate SIMD unary op with:
return __asm!int4("pmovsxwd $1,$0","=x,x",a);
but I struggle to generate 2-operands SIMD ops like:
return __asm!int4("paddd $1,$0","=x,x",a, b);
If you know how to do it => https://d.godbolt.org/z/ccM38bfMT it
would probably help build speed of SIMD heavy code, also -O0
performance
Also generating the right instruction is good but it must resist
optimization too, so proper LLVM constraints is needed. It would
be really helpful if someone has understood the cryptic rules of
LLVM assembly constraints.
Re: Trivial simple OpenGl working example
On Thursday, 8 July 2021 at 14:09:30 UTC, drug wrote: 08.07.2021 16:51, Виталий Фадеев пишет: Hi! I searching trivial simple D/OpenGL working in 2021 year example. It may be triangle. It may be based on any library: SDL, GLFW, Derelict, etc. Can you help me ? https://github.com/drug007/gfm7/tree/master/examples/simpleshader it's not trivial though but it works (tested in linux) just `dub fetch gfm7` then go to `path\to\gfm7\examples\simpleshader` and run `dub`. All kudos to Guillaume Piolat, original author of gfm library. If like me you hate OpenGL :) you can can also get software-rendered DPI-aware triangles with the "turtle" package: https://code.dlang.org/packages/turtle (Courtesy of Cerjones for the software renderer. )
Re: How does inheritance and vtables work wrt. C++ and interop with D? Fns w/ Multiple-inheritance args impossible to bind to?
On Monday, 24 May 2021 at 17:39:38 UTC, Gavin Ray wrote: On Sunday, 23 May 2021 at 21:08:06 UTC, Ola Fosheim Grostad wrote: On Sunday, 23 May 2021 at 21:02:31 UTC, Gavin Ray wrote: I don't really know anything at all about compilers or low-level code -- but is there any high-level notion of "inheritance" after it's been compiled? Yes, in the structure of the vtable, which is why the spec is so hard to read. If possible stick to single inheritance in C++... Yeah agreed, multiple inheritance is asking for trouble. But unfortunately when you're binding to existing libraries you don't have control over the API Hence why I was asking how to make D structs/classes that have compatible or identical vtables to multiply inherited objects to pass as arguments to `extern (C++)` functions. Also general explanation of what makes a compiled variable compatible in terms of vtable with what's expected as an argument I'd be grateful for solid information on this AFAIK multiple inheritance is described in this book https://www.amazon.com/Inside-Object-Model-Stanley-Lippman/dp/0201834545 Multiple inheritance is a rare topic here, I doubt too many people know how it works internally. Java and COM stuck on single-inheritance because it gives you 99% bang for the buck, also v-table dispatch in case of multiple inheritance is not as straightforward.
Re: DUB doesn't seem to respect my config, am I doing something wrong?
On Saturday, 22 May 2021 at 20:28:56 UTC, rempas wrote: I'm compiling using `dub --config=development` and I'm getting the following line: `Performing "debug" build using /usr/bin/dmd for x86_64`. The same exactly happens when I'm trying to do the release config. If I disable the `targetType` option, it seems that it's creating a library and I can also manually change the compiler and the build-type so I don't know what's going on Hello, DUB has two separate concepts: - buildTypes: default ones are debug, release, release-debug, release-nobounds They You can define custom buildTypes. Selected with -b https://dub.pm/package-format-json.html#build-types By default, "debug" build type. - configurations are more often used to define software options You can define custom configurations. Selected with -c By default the first one in your file is taken, else it's a default configuration. People use configurations to define example programs or platform builds (probably becase buildTypes are limited), but they are primarily intended for enabling or disabling features in software.
Re: running a d compiler on the Mac Mini with an M1 chip
On Friday, 26 March 2021 at 22:41:08 UTC, dan wrote: On Friday, 26 March 2021 at 21:54:20 UTC, rikki cattermole wrote: On 27/03/2021 10:51 AM, dan wrote: Are there any d compilers that run natively on the Mac Mini with an M1 chip? If so, does anybody here have any experience with them that can be shared? If not, and your machine is a mac mini, how would you go about programming in d on it? TIA for any info! Looks like latest ldc has an arm build. But both dmd and ldc should already work due to x86 emulation that takes place. https://github.com/ldc-developers/ldc/releases/tag/v1.25.1 Thanks Rikki! If anybody has any particular experience using d on a mac mini with M1 that they want to share, please do post, but this does look promising. dan (Not M1 but the DTK) Hello, Here are the instructions for setup and building both for arm64 and x86_64: https://forum.dlang.org/post/rtf2j3$2oh1$1...@digitalmars.com In addition to these instructions, you can also use the native LDC for faster build.
Re: How to delete dynamic array ?
On Wednesday, 17 March 2021 at 10:54:10 UTC, jmh530 wrote: This is one of those things that is not explained well enough. Yes. I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property "That a slice own or not its memory is purely derived from the pointed area." could perhaps better be said "A slice is managed by the GC when the memory it points to is in GC memory"?
Re: Is it possible to suppress standard lib and dlang symbols in dylib (macos)
On Sunday, 14 March 2021 at 11:33:00 UTC, David wrote: Anyone else done this? Pointers welcome. Sorry for delay. Just add "dflags-osx-ldc": ["-static"],
Re: Is it possible to suppress standard lib and dlang symbols in dylib (macos)
On Thursday, 11 March 2021 at 08:34:48 UTC, David wrote:
I thought it would be fun to convert some old C++/C quant utils
to D. I'm starting with a simple library that I call from vba
in Excel on macos:
module xlutils;
import core.stdc.string : strlen, strcpy;
//import std.conv : to;
//import std.string : toStringz;
import core.stdc.stdlib : malloc, free;
extern (C) double addDD_D(double a, double b) {return a + b;}
...
Is there a way of not exposing the symbols that aren't mine? -
I only need a simple C interface.
Thx
David
Create a exports.lst file with:
_addDD_D
as the only line there.
Build with:
"lflags-osx-ldc": [ "-exported_symbols_list", "exports.lst",
"-dead_strip" ],
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 20:28:58 UTC, Ali Çehreli wrote: To my surprise, even though 'c' is not null below, the destructor is not executed multiple times. Hence why https://p0nce.github.io/d-idioms/#GC-proof-resource-class works as a detector of undeterminism.
Re: Using YMM registers causes an undefined label error
On Saturday, 6 March 2021 at 16:09:03 UTC, Imperatorn wrote: On Saturday, 6 March 2021 at 15:40:56 UTC, Rumbu wrote: On Saturday, 6 March 2021 at 12:15:43 UTC, Mike Parker wrote: [...] Where exactly is documented the extern(D) x86-64 calling convention? Because currently seems like a mess according to the dissasembly. First X parameters on stack from left to right, last 4 in registers. But wait, if you have less than 4 parameters, they are passed in register. Again, WTF? Reading this, I'm experiencing true fear for the first time in my life. I'm also learning that extern(D) is different across compilers in some cases, but it isn't that bad. Preferred ABI boundaries across executables is extern(C). If you deal with static librariries, then they are likely built from the same compiler too. When LDC change the extern(D) ABI, it is rightfully a minor change as everything will get rebuilt. https://github.com/ldc-developers/ldc/releases/tag/v1.25.0 Besides, such changes are there for efficiency :)
Re: DMD support for Apples new silicon
On Tuesday, 2 March 2021 at 08:01:41 UTC, tastyminerals wrote: On Sunday, 10 January 2021 at 14:50:44 UTC, Guillaume Piolat wrote: On Sunday, 10 January 2021 at 14:22:25 UTC, Christian Köstlin wrote: [...] Hello Christian, [...] I see that there is a ldc2-1.25.1-osx-arm64.tar.xz already among https://github.com/ldc-developers/ldc/releases So, one could use this straight away, right? Yes, it will run faster and you get to avoid the flag to target arm64. On the minus side, you can't target x86_64 with that build IIRC, whereas the x86_64 one cross-compile to arm64.
Re: Optimizing for SIMD: best practices?(i.e. what features are allowed?)
On Thursday, 25 February 2021 at 14:28:40 UTC, Guillaume Piolat wrote: On Thursday, 25 February 2021 at 11:28:14 UTC, z wrote: How does one optimize code to make full use of the CPU's SIMD capabilities? Is there any way to guarantee that "packed" versions of SIMD instructions will be used?(e.g. vmulps, vsqrtps, etc...) https://code.dlang.org/packages/intel-intrinsics A bit of elaboration on why you might want to prefer intel-intrinsics: - it supports all D compilers, including DMD 32-bit target - targets arm32 and arm64 with same code (LDC only) - core.simd just give you the basic operators, but not say, pmaddwd or any of the complex instructions. Some instructions need very specific work to get them. - at least with LLVM, optimizers works reliably over subsequent versions of the compiler.
Re: Optimizing for SIMD: best practices?(i.e. what features are allowed?)
On Thursday, 25 February 2021 at 11:28:14 UTC, z wrote: How does one optimize code to make full use of the CPU's SIMD capabilities? Is there any way to guarantee that "packed" versions of SIMD instructions will be used?(e.g. vmulps, vsqrtps, etc...) https://code.dlang.org/packages/intel-intrinsics
Re: Profiling
On Wednesday, 10 February 2021 at 11:52:51 UTC, JG wrote: Thanks for the suggestions. However, I would prefer not to spend time trying to debug d-profile-viewer at the moment. As a follow up question I would like to know what tool people use to profile d programs? Here is what I use for sampling profiler: (On Windows) Build with LDC, x86_64, with dub -b release-debug in order to have debug info. Run your program into: - Intel Amplifier (free with System Studio) - AMD CodeXL (more lightweight, and very good) - Very Sleepy (On Mac) Build with dub -b release-debug Run your program with Instruments.app which you can find in your Xcode.app (On Linux) I don't know. Though most of the time to validate the optimization a comparison program that runs two siilar programs and computer the speed difference can be needed.
Re: D meets GPU: recommendations?
On Friday, 29 January 2021 at 16:34:25 UTC, Bruce Carneal wrote: The project I've been working on for the last few months has a compute backend that is currently written MT+SIMD. I would like to bring up a GPU variant. What you could do is ressurect DerelictCL, port it to BindBC, and write vanilla OpenCL 1.2 + OpenCL C. Not up to date on both, but CUDA is messier than OpenCL. I don't really know about the other possibilities, like OpenGL + compute shaders or Vulkan + compute shaders.
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 19:49:34 UTC, Ola Fosheim Grøstad wrote: Many open source projects (and also some commercial ones) work ok for small datasets, but tank when you increase the dataset. So "match and mix" basically means use it for prototyping, but do-not-rely-on-it-if-you-can-avoid-it. It's certainly true that in team dynamics, without any reward, efficiency can be victim to a tragedy of commons. Well, any software invariant is harder to hold if the shareholders don't care. (be it "being fast", or "being correct", or other invariants).
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 18:55:27 UTC, Ola Fosheim Grøstad wrote: On Friday, 15 January 2021 at 18:43:44 UTC, Guillaume Piolat wrote: Calling collect() isn't very good, it's way better to ensure the GC heap is relatively small, hence easy to traverse. You can use -gc=profile for this (noting that things that can't contain pointer, such as ubyte[], scan way faster than void[]) Ok, so what you basically say is that the number of pointers to trace was small, and perhaps also the render thread was not under GC control? A small GC heap is sufficient. There is this blog post where there was a quantitative measure of the sub-1ms D GC heap size. http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html 200 KB can be scanned/collected in 1 ms. Since then the D GC has improved in many ways (multicore, precise, faster...) that surprisingly have not been publicized that much ; but probably the suggested realtime heap size is in the same order of magnitude. In this 200kb number above, things that can't contain pointers don't count.
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 16:37:46 UTC, Ola Fosheim Grøstad wrote: But when do you call collect? Do you not create more and more long-lived objects? Calling collect() isn't very good, it's way better to ensure the GC heap is relatively small, hence easy to traverse. You can use -gc=profile for this (noting that things that can't contain pointer, such as ubyte[], scan way faster than void[]) How do you structure this? Limit GC to one main thread? But an audio plugin GUI is not used frequently, so... hickups are less noticable. For a 3D or animation editor hickups would be very annoying. Yes but when a hiccup happen you can often trace it back to gargage generation and target it. It's an optimization task. I think it is better with something simpler like saying one GC per thread But then ownership doesn't cross threads, so it can be tricky to keep object alive when they cross threads. I think that was a problem in Nim. It really is quite easy to do: build you app normally, evetually optimize later by using manual memory management. I understand what you are saying, but it isn't all that much more work to use explicit ownership if all the libraries have support for it. But sometimes that ownership is just not interesting. If you are writing a hello world program, no one cares who "hello world" string belongs to. So the GC is that global owner.
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 16:21:18 UTC, Ola Fosheim Grøstad wrote: What do you mean by "mix and match"? If it means shutting down the GC after initialization then it can easily backfire for more complicated software that accidentally calls code that relies on the GC. I mean: "using GC, unless where it creates problems". Examples below. Until someone can describe a strategy that works for a full application, e.g. an animation-editor or something like that, it is really difficult to understand what is meant by it. Personal examples: - The game Vibrant uses GC for some long-lived objects. Memory pools for most game entities. Audio thread has disabled GC. - Dplug plugins before runtime removal used GC in the UI, but no GC in whatever was called repeatedly, leading to no GC pause in practice. In case an error was made, it would be a GC pause, but not a leak. The pain point with the mixed approach is adding GC roots when needed. You need a mental model of traceability. It really is quite easy to do: build you app normally, evetually optimize later by using manual memory management.
Re: Why many programmers don't like GC?
On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote: That's the whole point of being able to mix and match. Anyone avoiding the GC completely is missing it (unless they really, really, must be GC-less). +1 mix and match is a different style versus only having a GC, or only having lifetimes for everything. And it's quite awesome as a style, since half of things don't need a well-identified owner.
Re: Why many programmers don't like GC?
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote: I've always heard programmers complain about Garbage Collector GC. But I never understood why they complain. What's bad about GC? Languages where the GC usage is unavoidable (Javascript and Java) have created a lot of situations where there is a GC pause in realtime program and the cause is this dynamically allocated memory. So a lot of people make their opinion of GC while using setup where you couldn't really avoid it. For example in Javascript from 10 years ago just using a closure or an array literals could make your web game stutter.
Re: writeln and write at CTFE
On Wednesday, 13 January 2021 at 08:35:09 UTC, Andrey wrote: Hello all, Tell me please how can I "writeln" and "write" in function that is used in CTFE? At the moment I get this: import\std\stdio.d(4952,5): Error: variable impl cannot be modified at compile time Or may be exist some other ways to do it? pragma(msg, );
Re: DMD support for Apples new silicon
On Sunday, 10 January 2021 at 16:03:53 UTC, Christian Köstlin wrote: Good news! I was hoping for support in ldc, but dmds super fast compile times would be very welcome. I guess it's more work to put an ARM backend there. Kind regards, Christian It is indeed more work and up to the DMD leadership what should happen. You can already switch between compilers with: dub --compiler dmd dub --compiler ldc2 so as to benefit from dmd fast build times, and then release with ldc. Apple Silicon and Rosetta 2 are really quite fast, so you should experience pretty quick build times there anyway.
