Re: Dub generated a visuald project for me that includes pegged + dqt (Qt widgets). Basic linking error fix?
I see now. https://github.com/tim-dlang/dqt has examples of where these libs are found within Qt itself.
Dub generated a visuald project for me that includes pegged + dqt (Qt widgets). Basic linking error fix?
``` Build started at 7:16 PM... -- Build started: Project: d--, Configuration: debug x64 -- Building C:\Users\fruit\OneDrive\Desktop\Code\StateMachine\D--\d--.exe... LINK : fatal error LNK1181: cannot open input file 'Qt5Widgets.lib' Building C:\Users\fruit\OneDrive\Desktop\Code\StateMachine\D--\d--.exe failed (error code 1181)! Details saved as "file://C:\Users\fruit\OneDrive\Desktop\Code\StateMachine\D--\.dub\obj\debug\dummy\d--\d--.buildlog.html" == Build: 0 succeeded, 1 failed, 4 up-to-date, 0 skipped == == Build completed at 7:16 PM and took 00.841 seconds == ``` Just wondering where / what in settings to change and what folder to point it to. Thanks! I'm making a public project on GitHub called D--. https://github.com/enjoysmath/D-- It's not a language extension, but will include new tools for visualizing your code and even refactoring it. D is like a host language for it, and also the code it will generate naturally. It's most likely only going to support a subset of D, though I will strive for the full grammar. Hence D-- sounds about right! The name is a play on the C++ is to C analogy.
Re: Opinions on iterating a struct to absorb the decoding of a CSV?
On Monday, 1 April 2024 at 04:54:46 UTC, cc wrote:
I scoured [Traits](https://dlang.org/spec/traits.html) and
[std.traits](https://dlang.org/phobos/std_traits.html) looking
for a simple method to tell whether a member was declared as
enum but couldn't find one, so if anyone knows a proper way to
do it please let me know.
Turns out this can be done as part of the panacea that is `is()`
statements.
```d
static if (is(typeof({enum X = SYM;})))
```
Re: Opinions on iterating a struct to absorb the decoding of a CSV?
On Thursday, 28 March 2024 at 17:23:39 UTC, Andy Valencia wrote:
I wanted a lightweight and simpler CSV decoder. I won't post
the whole thing, but basically you instantiate one as:
That's pretty much the best way to do it. While `.tupleof` does
look kind of hacky, and you could instead iterate using
`___traits(allMembers, T)` and `__traits(getMember, T,
"symbolname")` which looks more self-documenting, this ends up
being more of a pain, because it's going to iterate through
everything in the type, including functions,
constructors/destructors, aliases, enums, static members,
inherited members in classes, etc etc, and it's a plate of
spaghetti to sort them all out, plus there are issues with
aliasing on top of that. Sometimes you might want to do that of
course, but for simple situations like this, `.tupleof` just
works.
```d
struct Foo {
int x = 1;
float f = 3.14;
string abc = "abc";
string[] xyz;
immutable int i;
const int c;
this(int x) { this.x = x; i = 7; c = 8; }
this(float f) { this.f = f; }
bool speak() { return false; }
bool speak(bool b) { return b; }
void toString(scope void delegate(const(char)[]) writer) {
/*...*/ }
alias X = int;
enum E = 3;
static enum F = 4;
static int y = 5;
}
void main() {
Foo foo;
dumpInfo(foo);
}
void dumpInfo(T)(T t) {
import std.traits;
static foreach (idx, field; T.tupleof) {{
alias TYPE = typeof(field);
enum NAME = field.stringof;
writefln("[%s] %s => %s", TYPE.stringof, NAME, t.tupleof[idx]);
}}
writeln;
static foreach (sym; __traits(allMembers, T)) {{
enum bool ISSTATIC = hasStaticMember!(T, sym);
static if (ISSTATIC)
alias SYM = __traits(getMember, T, sym);
else
alias SYM = __traits(getMember, t, sym);
enum NAME = sym;
static if (isType!SYM) { // aliases
writefln("(TYPE) %s : %s", NAME, SYM.stringof);
} else static if (isFunction!SYM) {
alias OVERLOADS = __traits(getOverloads, T, sym);
static foreach (idx, FUNC; OVERLOADS) {
writefln("(FUNC) %s<%s> : %s", NAME, idx,
typeof(FUNC).stringof);
writefln("\t%s %s %s", ReturnType!FUNC.stringof,
Parameters!FUNC.stringof,
ParameterIdentifierTuple!FUNC.stringof); // Useful
}
} else {
alias TYPE = typeof(SYM);
// where is isEnum or isManifestConstant?
enum bool ISASSIGNABLE = __traits(compiles,
{__traits(getMember, t, sym) = __traits(getMember, t, sym);});
enum bool ISASSIGNABLE_IN_CTOR = __traits(compiles,
{cast()__traits(getMember, t, sym) = cast()__traits(getMember, t,
sym);});
static if (!ISASSIGNABLE && !ISASSIGNABLE_IN_CTOR) {
// MAYBE it's an enum. Or something else
unassignable.
writefln("(ENUM) [%s] %s => %s", TYPE.stringof,
NAME, SYM);
} else static if (ISSTATIC) {
writefln("(STATIC) [%s] %s => %s",
TYPE.stringof, NAME, SYM);
} else {
writefln("[%s] %s => %s", TYPE.stringof, NAME,
__traits(getMember, t, sym)); // SYM doesn't work here
}
}
}}
}
```
```
[int] x => 1
[float] f => 3.14
[string] abc => abc
[string[]] xyz => []
[immutable(int)] i => 0
[const(int)] c => 0
[int] x => 1
[float] f => 3.14
[string] abc => abc
[string[]] xyz => []
[immutable(int)] i => 0
[const(int)] c => 0
(FUNC) __ctor<0> : ref Foo(int x)
Foo (int) AliasSeq!("x")
(FUNC) __ctor<1> : ref Foo(float f)
Foo (float) AliasSeq!("f")
(FUNC) speak<0> : bool()
bool () ()
(FUNC) speak<1> : bool(bool b)
bool (bool) AliasSeq!("b")
(FUNC) toString<0> : void(scope void delegate(const(char)[])
writer)
void (scope void delegate(const(char)[])) AliasSeq!("writer")
(TYPE) X : int
(ENUM) [int] E => 3
(ENUM) [int] F => 4
(STATIC) [int] y => 5
```
I scoured [Traits](https://dlang.org/spec/traits.html) and
[std.traits](https://dlang.org/phobos/std_traits.html) looking
for a simple method to tell whether a member was declared as enum
but couldn't find one, so if anyone knows a proper way to do it
please let me know.
Re: Best way to use large C library in D as of 2024
On Saturday, 30 March 2024 at 05:01:32 UTC, harakim wrote: On Tuesday, 26 March 2024 at 20:42:00 UTC, Chris Piker wrote: On Tuesday, 26 March 2024 at 20:19:27 UTC, bachmeier wrote: Should be able to just use it, as described here: https://forum.dlang.org/post/qxctappnigkwvaqak...@forum.dlang.org Create a .c file that includes the header files and then call the functions you need. Wow. **That just worked the first time!** Holy &^@$ that's easy! So why does the 2nd page returned from the google search ``` interfacing with C site:dlang.org ``` (which happens to be: https://dlang.org/spec/interfaceToC.html) still have this text: Since D can call C code directly, it can also call any C library functions, giving D access to the smorgasbord of existing C libraries. To do so, however, one needs to write a D interface (.di) file, which is a translation of the C .h header file for the C library into D. For popular C libraries, the first place to look for the corresponding D interface file is the Deimos Project. If it isn't there already, please write and contribute one to the Deimos Project. ? This lead me to believe that interfacing was a chore and I was considering going back to C for a small program I need. @D Language Foundation - This is a HUGE selling point. I had to use cups the other day and I just copied some code from a d file and linked the library. It was so easy I was suspicious but it worked. Using C from D is pretty much as easy as using C from C and I think you should advertise that better! It works well if you only need to work with a header. There are still a few rough edges that get in the way if you're compiling the full C sources (I filed bugs for all of them): - Can't handle va_arg - Can't cast to a pointer of a struct that's typedef'd - Can't use complex numbers with the ternary operator These problems should be cleaned up before heavily promoting what is an incredible feature. I don't think it's widely known that you can translate C source files into D. I think that's really cool, but in addition to the bugs listed above that ImportC can't handle, it outputs things like dpulicate aliases, function argument names that are D keywords, and declaring unions inside structs equal to void. All of these are easy to fix by hand, but it's time consuming. Once these final odds and ends are working, we have a killer language feature.
Re: std.traits.ParameterIdentifierTuple problem
On Sunday, 31 March 2024 at 11:35:39 UTC, Nick Treleaven wrote: If a function type does include identifiers, then would two function types with the same argument types but different identifiers compare equal using `is`? Yes. That is the idea. Define `is` to work this way. Yes, it's not possible to instantiate a function type. But with extern it seems the semantics is fine as a function is not being instantiated. It is merely associating a name with a type: in what sense is this instantiation in any reasonable way?
Re: Limits of implicit conversion of class arrays
On Thursday, 28 March 2024 at 01:53:52 UTC, Steven Schveighoffer
wrote:
```d
class Base {}
class Derived : Base {}
@safe pure nothrow unittest {
Base b;
Derived d;
b = d; // pass
Base[] bs;
Derived[] ds;
bs ~= ds; // pass
bs = ds; // fail [1], should pass
bs = cast(Base[])ds; // fail [2], should pass
}
```
Yes, it's unsafe, as you can replace an element of `ds` with
something that has no relation to `Derived`.
This is a suggested change that when _applied_ will make the code
unsafe yes. But the code in its current form is safe and the
compiler could be extended to prove it.
Re: LDC Internal Compiler Error (ICE) mentioning attribute 'nocapture'
On Saturday, 30 March 2024 at 09:35:24 UTC, Per Nordlöw wrote:
Does anybody recognize the error
```
Attribute 'nocapture' does not apply to function return values
%12 = call noalias nocapture align 8 ptr @_D3xxx(ptr nonnull
%10, { i64, ptr } %11) #2, !dbg !7978
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz1
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz2
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz3
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz4
Attribute 'nocapture' does not apply to function return values
%164 = call noalias nocapture align 8 ptr @_D3xyz5(ptr
nonnull %rS72) #0, !dbg !9872
Attribute 'nocapture' does not apply to function return values
%285 = call noalias nocapture align 8 ptr @_D3xyz6(ptr
nonnull %284) #0, !dbg !9949
LLVM ERROR: Broken module found, compilation aborted!
#0 0x5ee4d001e927
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(~/.local/ldc2-1.37.0-beta1-linux-x86_64/bin/ldc2+0x6ad4927)
Error ldc2 failed with exit code -6.
```
? It's outputted when building and running a test application
with ldc with the compiler flag `-fsanitize=address`.
You can try to add the flag `--disable-verify` (see
https://github.com/ldc-developers/ldc/issues/4284, that prevents
an internal verification).
The error message indicates that a "parameter-only" attribute is
used as a "call-site" one. Not sure if this is a bug in LDC or in
LLVM but if you're lucky the attribute will be a no-op and the
generated binary will just work.
Re: std.traits.ParameterIdentifierTuple problem
On Saturday, 30 March 2024 at 22:37:53 UTC, Carl Sturtivant wrote: I'm inclined to a view that keeps more "it just works" options open. Regard the parameter names as a part of the type (which I am very grateful for them being currently) and just regard part of the definition of "type equality" as being to ignore parameter names when comparing types. With this viewpoint, ParameterIdentifierTuple should be repaired to work with function types just as it works with functions, and the current behavior is a bug. Maybe, but one of its unittests specifically tests that a function pointer has no parameter identifiers: ```d // might be changed in the future? void function(int num, string name) fp; static assert([ParameterIdentifierTuple!fp] == ["", ""]); ``` And changing in the future got quite a bit of push back in that PR link. This is because `fp` is declared using a function pointer type, and the author of the test did not think function pointer types should include identifiers. So it seems logical that ParameterIdentifierTuple should not give identifiers for a function type either. If a function type does include identifiers, then would two function types with the same argument types but different identifiers compare equal using `is`? Incidentally, I tried ```D extern typeof(foo) func; ``` to say that func was an actual function (`extern` so defined elsewhere) whose type was the type of the function `int foo(int num, string name, int);` so I can then use `ParameterIdentifierTuple` on a function, not a type, Nice try! but the compiler said `bug1.d(5): Error: variable ``bug1.func`` cannot be declared to be a function`. Seems unreasonable given the implied semantics. Yes, it's not possible to instantiate a function type.
