Re: Running GtkD programs on macOS
On Saturday, 30 November 2019 at 00:17:51 UTC, Mike Wey wrote: On 29-11-2019 04:40, Joel wrote: Oh, I used 'brew install gtk+3', and the test program worked, but (see below) I don't know about all that installing - is that alright? They all look like GTK+ dependencies so that would be alright/ Update: Three years to the day (from when I posted on here about it), since upgrading to macOS Ventura I've found my GTK+ programs work again! Yay. It never stopped working on my Windows computer. The DLangui hasn't been working on Windows though.
Re: Windows specific: MS C++ versus D thread local variables
On Monday, 28 November 2022 at 18:51:37 UTC, NonNull wrote: I tested this with D threads and it works for my test program. I might guess that this is so in general, because such a library has to successfully work with arbitrary MS VC++ and that "interop" is defined by MS to work. I worked on products where native C++ threads were calling complex CLR code and we never had an issue with the CLR runtime in these scenarios. As far as I recall the .Net documentation, this is entirely supported. I believe that the shim code handling the transitions behind the scenes takes care of that. If you want to know how it works in detail, I guess you have to dig into the runtime sources. They are complex and hard to understand, though.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Tuesday, 29 November 2022 at 01:08:03 UTC, zjh wrote: ... ```d [Environment64] LIB=%@P%\..\lib;%lj%\dku; ```
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Monday, 28 November 2022 at 16:21:20 UTC, NonNull wrote: Any idea what may be going on with dmd? use `sc.ini` like this: ```d [Version] version=7.51 Build 020 [Environment] lj=E:\path DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" "-I%lj%\dimport" LIB="%@P%\..\lib" ```
Re: __traits isCopyable vs isPOD
On Monday, 28 November 2022 at 23:11:37 UTC, Per Nordlöw wrote: the real question I had is whether one should use `isPOD` instead of `isCopyable` in cases ```d static if (__traits(isCopyable, Element)) insertAt(element, index); else insertAt(move(element), index); ``` because that avoids any potential call to the copy-constructor and destructor of `Element`. Afaict, one should. If your goal is to avoid calling the copy constructor (and, I assume, to avoid unnecessary instantiations of `move`), then yeah, `isPOD` is the one you want.
Re: How to move from Unique(someClass) to Unique(someInterface)?
On Monday, 28 November 2022 at 02:40:28 UTC, Tejas wrote:
On Sunday, 27 November 2022 at 17:06:31 UTC, vushu wrote:
On Saturday, 16 May 2020 at 17:45:56 UTC, Konstantin wrote:
[...]
I'm actually also very curious about this issue, since I come
from c++ where this is possible, and it is a very common
functionality for example for dependency inversion and
dependency injection or mocking. It would be very nice to have
this working.
I _think_ it's not working here because `Unique` is a `struct`,
so there's no concept of inheritance here, meanwhile that it
possible in `C++`
It should be possible to make template structs
assignable/initializable from a compatible wrapped type with a
custom constructor and a custom opAssign. There is a bit of
fiddling with constraints involved to prohibit implicit casting
of the wrapped type in ways that shouldn't work. See this
incomplete proof of concept:
```d
interface IFoo { }
class Foo : IFoo { }
struct Unique(T) {
T value;
// This should check that T2 is another instantiation of
Unique instead of this compiles trait
this(T2)(T2 v) if(!__traits(compiles, this.value = v.value))
{
this.value = v;
}
this(T2)(Unique!T2 other) if(__traits(compiles, this.value =
other.value))
{
this.value = other.value;
}
void opAssign(T2)(Unique!T2 other) {
value = other.value;
}
}
void main()
{
IFoo foo = new Foo();
Unique!IFoo f = Unique!Foo();
//Unique!IFoo f2 = Unique!int(); // error: assignment from
incompaatible type
}
```
The reason why automem.Unique doesn't support this is probably
hidden within the intended behavior of Unique. Maybe Adam Ruppe
can shed some light on this.
Re: __traits isCopyable vs isPOD
On Monday, 28 November 2022 at 22:59:13 UTC, Paul Backus wrote: Lots of types. For example, types with copy constructors or destructors are not POD but may still be copyable. This should be obvious if you read the definition of POD linked from the language spec: https://dlang.org/glossary.html#pod I guess I knew that, sorry for the dumb question - the real question I had is whether one should use `isPOD` instead of `isCopyable` in cases ```d static if (__traits(isCopyable, Element)) insertAt(element, index); else insertAt(move(element), index); ``` because that avoids any potential call to the copy-constructor and destructor of `Element`. Afaict, one should.
Re: __traits isCopyable vs isPOD
On Monday, 28 November 2022 at 20:58:43 UTC, Per Nordlöw wrote: For which types `T` does ```d __traits(isCopyable, T) ``` differ from ```d __traits(isPOD, T) ``` ? Lots of types. For example, types with copy constructors or destructors are not POD but may still be copyable. This should be obvious if you read the definition of POD linked from the language spec: https://dlang.org/glossary.html#pod
Re: __traits isCopyable vs isPOD
On Monday, 28 November 2022 at 20:58:43 UTC, Per Nordlöw wrote: For which types `T` does ```d __traits(isCopyable, T) ``` differ from ```d __traits(isPOD, T) ``` ? I'm asking because I have code like ```d static if (__traits(isCopyable, Element)) insertAt(element, index); else insertAt(move(element), index); ``` and I wonder if one in those cases should be using `isCopyable` or `isPOD`.
Re: Windows specific: MS C++ versus D thread local variables
On Saturday, 26 November 2022 at 23:36:13 UTC, NonNull wrote: In the CLR module I have a static variable that can contain a reference to a .NET object. I need that variable to be thread local. I achieved this by prefixing its declaration with [System::ThreadStaticAttribute]. But this is thread local for .NET concurrency. How will this variable behave with a multi-threaded D program (that calls those exported library functions from more than one thread) and why? I tested this with D threads and it works for my test program. I might guess that this is so in general, because such a library has to successfully work with arbitrary MS VC++ and that "interop" is defined by MS to work.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Sunday, 27 November 2022 at 17:26:37 UTC, NonNull wrote: I worked around this by setting a LIB environment variable containing the extra path I needed, so I didn't need the pragma. But this only worked for ldc2; dmd still complained it cannot find the necessary, ignoring the LIB environment variable. Is this a bug? I set the LIB environment variable and now ```ldc2 main.d``` works. So I know LIB is set correctly. But ```dmd main.d``` still has linking fail to find libraries at the location LIB. I did both in a new console where ```echo %LIB%``` produced the expected path. Any idea what may be going on with dmd?
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Monday, 28 November 2022 at 14:41:01 UTC, Adam D Ruppe wrote: This is the Microsoft doc page for the feature the pragma uses: https://learn.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?source=recommendations=msvc-170#linker It looks like they actually removed some options in the recent update, I know /SUBSYSTEM used to work there too but it is no longer listed and there's people on the web saying it stopped working after updating to the 2022 visual studio. So yeah I think they removed support for that. But /LIBPATH has never been supported as far as I know. Aha! Thank you: the MS doc page is very informative. So https://dlang.org/spec/pragma.html#linkerDirective is not simply a mechanism that via the object file can get any directive eventually to the linker as if on the command line. I've been completely successful using pragma(lib,_) but looking carefully I see that https://dlang.org/spec/pragma.html#lib contains highly significant clues under "implementation defined" when compared to "implementation defined" under https://dlang.org/spec/pragma.html#linkerDirective --- pragma(lib,_) in effect guarantees to get the information through to the linker. It is not restricted to MS-COFF, and is not restricted to passing the information through the object file but may use "other means" left unspecified. --- pragma(linkerDirective,_) IS restricted in these ways as you made clear. So by comparison I should have realized, taking the hint "restricted to MS-COFF" that the documentation for the MS linker about what directives can be embedded in object files was pertinent, because who knows what MS may permit?! The clues were all there. But I didn't catch on. Sorry about the kerfuffle. I have now successfully used pragma(lib,_) with a full path to link what's needed without resorting to external build stuff. I just need one pragma(lib,_) per library.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Monday, 28 November 2022 at 14:19:46 UTC, NonNull wrote: double quotes whatsoever into the linker command line via pragma(linkerDirective,_). linkerDirective doesn't add things to the linker command line at all. https://dlang.org/spec/pragma.html#linkerDirective "Implementation Defined: The string literal specifies a linker directive to be embedded in the generated object file. Linker directives are only supported for MS-COFF output. " "embedded in the generated object file" is not "added to linker command line". Only some switches are supported for embedding and the syntax might be different. This is why the error message also says "invalid directive". This is the Microsoft doc page for the feature the pragma uses: https://learn.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?source=recommendations=msvc-170#linker It looks like they actually removed some options in the recent update, I know /SUBSYSTEM used to work there too but it is no longer listed and there's people on the web saying it stopped working after updating to the 2022 visual studio. So yeah I think they removed support for that. But /LIBPATH has never been supported as far as I know. You'll want to use a build script/makefile/dub config/whatever to set linker command line options.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Sunday, 27 November 2022 at 17:37:50 UTC, kinke wrote: For LDC, you shouldn't need any double quotes, the compiler quotes the linker flag if it contains spaces. In fact I cannot find any way (multiple double quotes, escaped double quotes, different combinations of these) to get any double quotes whatsoever into the linker command line via pragma(linkerDirective,_). The linker always complains and the quoted error always contains no double quotes. The behavior of ldc2 is identical to that of dmd with all attempts. pragma(linkerDirective,_) is broken apparently. Please confirm or show how to use.
