Re: Simple BeamUI project won't link
On Wednesday, 16 December 2020 at 07:40:45 UTC, Ferhat Kurtulmuş wrote: On Wednesday, 16 December 2020 at 07:02:11 UTC, Daren Scot Wilson wrote: Trying out the beamui GUI package, obtained by git clone from github. The "basic" example builds and runs. I'm working on an Arch Linux machine with lots of RAM, but a user with not enough practice at D yet. I have a little experience with beamui but only on windows. It is under WIP. You'd better open an issue with an error report on GitHub as I did before https://github.com/dayllenger/beamui/issues/16. You may get some help from the maintainer. This may be not your issue, but I could manage it to work by adding this line: subPackage "examples/myproject" to the dub.sdl of the beamui. I simply put my project in examples/ folder. And compile and run using: dub run :myproject
Re: Simple BeamUI project won't link
On Wednesday, 16 December 2020 at 07:02:11 UTC, Daren Scot Wilson wrote: Trying out the beamui GUI package, obtained by git clone from github. The "basic" example builds and runs. I'm working on an Arch Linux machine with lots of RAM, but a user with not enough practice at D yet. I have a little experience with beamui but only on windows. It is under WIP. You'd better open an issue with an error report on GitHub as I did before https://github.com/dayllenger/beamui/issues/16. You may get some help from the maintainer.
Simple BeamUI project won't link
Trying out the beamui GUI package, obtained by git clone from
github. The "basic" example builds and runs.
So I create a new project from scratch, with "dub init beamy
beamui" (ircc) in a directory outside beamui's, sibling to it in
fact. This builds and runs, but does not make use of beamui at
all. So I copy a tiny bit from the basic example. It only
initializes a GuiApp:
import std.stdio;
import beamui;
int main()
{
GuiApp app;
if (!app.initialize()) {
writeln("App no init :(");
return 1;
}
return 0;
}
Here's the dub file:
name "beamy"
description "trying BeamUI"
license "none"
authors "darenw"
targetName "beamy"
targetType "executable"
dependency "beamui" path="../../beamui/"
dependency "beamui:platforms" path="../../beamui/platforms/"
Running "dub build" leads to compiling but no linking. undefined
reference to `initPlatformProxy'. Note that this build takes
place in a directory such that ../../beamui/ goes to the
top-level directory for beamui. Changing the path or replacing
'beamui' with 'beamuixxx' prevents the build from getting
anywhere at all, so the path is right.
I compared everything with the basic example, but am either
missing some obvious detail or have something screwed up, or
failed to add something, or need to say some secret magic
incantation.
I'm working on an Arch Linux machine with lots of RAM, but a user
with not enough practice at D yet.
Re: extern(C) and name mangling
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker wrote: So what you're asking for is a way to retain the D name mangling on an extern C function. The way to do that is with `pragma(mangle, "new_name")`. To match the original D function mangling, declare the function first without extern(C) and print `func.mangleof`. Use that as the parameter to pragma(mangle). I can't imagine any benefit you'd get from doing that, though. I actually had a use case for this. An initialization function that is called by the C runtime, i.e. `pragma(crt_constructor)`. That function needs to have C calling convention. But to avoid any conflicts with other `extern(C)` functions I wanted to keep the D mangling. https://github.com/dlang/druntime/blob/master/src/core/memory.d#L212-L232 -- /Jacob Carlborg
Re: extern(C) and name mangling
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker wrote: However, the D calling convention is defined to be identical to the C calling convention on the host system for everything except Windows x86. Also keep in mind that D supports other types than C does, like D arrays and delegates. In those cases the D calling convention needs to be extended since there's no way to just relay on the C calling convention. One could think it would be possible to passes D arrays and delegates as structs, but that's not how DMD passes them. On some platforms it matches how a struct is passed, on some it doesn't. -- /Jacob Carlborg
Re: extern(C) and name mangling
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker wrote:
However, the D calling convention is defined to be identical to
the C calling convention on the host system for everything
except Windows x86.
That's what's specified, but that's not how DMD actually behaves.
DMD passes the arguments in reverse order. That's easily
observable by calling a C function with D linkage:
$ cat foo.c
#include
void foo(int a, int b)
{
printf("a=%d b=%d\n", a, b);
}
$ cat main.d
module main;
import std;
pragma(mangle, "foo") // override D mangling to get the same name
as the C function
void foo(int a, int b); // D calling convention
void main()
{
foo(1, 2);
}
$ clang -o foo.o foo.c -c
$ dmd main.d foo.o
$ ./main
a=2 b=1
LDC behaves the same way as DMD and, IIRC, GDC follows how GCC
passes the arguments.
--
/Jacob Carlborg
Updating to newer files with different disk formats
I found using timeLastModified from macOS drive to ExFat, macOS
has higher precision than ExFat[0], so a different number. My
little program lists the files to update, but I get files to
update still, after updating them, because of the differences
with the disk formats.
[0] from time: 2020-Nov-06 13:29:30.5897005, to time: 2020-Nov-06
13:29:30.58
Potential
copy("/Users/joelchristensen/jpro/dpro2/AbcKids/LettersO/d.wav","/Volumes/PNY480/jpro/dpro2/AbcKids/LettersO/d.wav");
Re: extern(C) and name mangling
On Wednesday, 16 December 2020 at 04:45:34 UTC, Dave P. wrote: Oh interesting, so I only need extern(C) for declaring symbols I’m linking to and for symbols I want to export to C. I had sort of assumed that D might have different calling conventions for different things, but that makes things a lot easier. Not so fast! :-) extern(C) does affect the calling convention on Windows x86. There's also extern(Windows), which changes a function to the stdcall calling convention used by the Win32 API (and OpenGL implementations on Windows, and a handful of other libraries). And there's no guarantee that as D moves to new platforms that there won't be other exceptions joining x86 Windows. That's why I said I'm not sure I'd ever pass a templated function pointer to C. It isn't going to work on 32-bit Windows, or with any stdcall C function, right now, and possibly other platforms in the future. So as a default, you should always be explicit with your extern(x) linkage attributes on functions even when you aren't actually linking with C, and only break that rule when it's necessary.
Re: UFCS functions with both pointers and refs
On Wednesday, 16 December 2020 at 03:50:07 UTC, Mike Parker wrote: On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote: On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote: On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote: [...] Based on you requirement to use pointers, I assume you're doing this for a type you get from a C library. I did the same thing for the SDL_Rect type when working with SDL. All I did was implement a pointer version of my "extension" functions. When I had an instance and not a pointer, I took its address when I called the function. If that's inconvenient (lots of generic code, perhaps), you can always have the pointer version forward to the ref version, but it seems to me like just having the one version is the way to go most of the time. Yeah, in this case the C library is the rest of my program :). I am porting an application I had written in C to D in betterC mode piece by piece and there’s a good number of functions where it’d be convenient to call them via UFCs. Thanks for answering my questions!
Re: extern(C) and name mangling
On Wednesday, 16 December 2020 at 04:17:13 UTC, Mike Parker wrote: On Tuesday, 15 December 2020 at 22:04:12 UTC, Dave P. wrote: [...] Mangling does not play any role in passing and calling function pointers between D and C. It only plays a role in linking and loading. You can declare function pointers in D and C without any name whatsoever. What matters is that both sides agree on the number and type of parameters accepted by the function that's pointed to, and that they both agree on the calling convention. I don't believe extern(C) has any effect on templated functions. However, the D calling convention is defined to be identical to the C calling convention on the host system for everything except Windows x86. Oh interesting, so I only need extern(C) for declaring symbols I’m linking to and for symbols I want to export to C. I had sort of assumed that D might have different calling conventions for different things, but that makes things a lot easier. So theoretically, you should be able to pass a pointer to a templated free function to C as long as the types in the functions parameter list match those the C function expects. I don't know if I'd do that myself, though. [...] There's no such thing as C name mangling. C functions are *not* mangled (though some platforms do prepend an underscore to symbol names). What extern(C) does is to turn off D name mangling. Yeah, I was playing a bit loose with the terminology and referring to the leading underscore. So what you're asking for is a way to retain the D name mangling on an extern C function. The way to do that is with `pragma(mangle, "new_name")`. To match the original D function mangling, declare the function first without extern(C) and print `func.mangleof`. Use that as the parameter to pragma(mangle). I can't imagine any benefit you'd get from doing that, though. Agreed!
Re: extern(C) and name mangling
On 12/15/20 2:04 PM, Dave P. wrote:
> I want to pass
> some templated functions as function pointers to some C code
As Mike Parker said, it works:
// The same thing as a C function pointer:
alias Func = long function(int);
long bar(T)(int) {
return 0;
}
Func f0 = &(bar!float);
Func d1 = &(bar!double);
> (and that different versions would be mangled
> differently).
Yes:
auto foo(T)() {
}
void main() {
pragma(msg, foo!int.mangleof);
pragma(msg, foo!double.mangleof);
}
Output:
_D6deneme__T3fooTiZQhFNaNbNiNfZv
_D6deneme__T3fooTdZQhFNaNbNiNfZv
Ali
Re: extern(C) and name mangling
On Tuesday, 15 December 2020 at 22:04:12 UTC, Dave P. wrote: I can’t find this in the spec, but from experimentation it seems like extern(C) only affects name mangling of functions at the top level scope. Thus extern(C) function templates would be mangled differently, but still use the C calling convention. Is this right? I want to pass some templated functions as function pointers to some C code and wanted to confirm that would work (and that different versions would be mangled differently). Mangling does not play any role in passing and calling function pointers between D and C. It only plays a role in linking and loading. You can declare function pointers in D and C without any name whatsoever. What matters is that both sides agree on the number and type of parameters accepted by the function that's pointed to, and that they both agree on the calling convention. I don't believe extern(C) has any effect on templated functions. However, the D calling convention is defined to be identical to the C calling convention on the host system for everything except Windows x86. So theoretically, you should be able to pass a pointer to a templated free function to C as long as the types in the functions parameter list match those the C function expects. I don't know if I'd do that myself, though. Also, is there any way to say you want the C calling convention, but don’t want C name mangling for top level functions? There's no such thing as C name mangling. C functions are *not* mangled (though some platforms do prepend an underscore to symbol names). What extern(C) does is to turn off D name mangling. So what you're asking for is a way to retain the D name mangling on an extern C function. The way to do that is with `pragma(mangle, "new_name")`. To match the original D function mangling, declare the function first without extern(C) and print `func.mangleof`. Use that as the parameter to pragma(mangle). I can't imagine any benefit you'd get from doing that, though.
Re: UFCS functions with both pointers and refs
On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote: On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote: On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote: Do I have to write both and have one forward to the other for more complicated functions? For free functions, yes. Is there any way to write the function as a template that is generic over a parameter being a pointer or a reference, but does not allow passing a copy? Even with a templated function, you'd still need to declare the first parameter to the function either as a pointer or as a `ref` parameter. I'm unaware of any way to get around that. Free functions and member functions are just different beasts Based on you requirement to use pointers, I assume you're doing this for a type you get from a C library. I did the same thing for the SDL_Rect type when working with SDL. All I did was implement a pointer version of my "extension" functions. When I had an instance and not a pointer, I took its address when I called the function. If that's inconvenient (lots of generic code, perhaps), you can always have the pointer version forward to the ref version, but it seems to me like just having the one version is the way to go most of the time.
Re: closures + struct: Error: forward reference to inferred return type of function call
On Tuesday, 15 December 2020 at 19:53:33 UTC, Q. Schroll wrote:
On Monday, 14 December 2020 at 14:39:14 UTC, ddcovery wrote:
On Monday, 14 December 2020 at 12:22:26 UTC, ddcovery wrote:
int opCmp(Number other){
return _value - other.value;
};
Correction:
bool opEquals(Number other){
return _value == other.value;
};
You could just give the struct a variable and use that instead
of the enclosing function's parameter:
https://run.dlang.io/is/4Lqf15
Then, the struct can actually be static.
First of all, thanks for maintaining opCmp... reading
documentation I thought that == and != needed a opEquals
method... but opCmp is enough.
Your solution is really nice for the example, but at the cost of
eliminating the closure ( In fact, the function is not necessary
either: the structure itself is sufficient for the example).
As I understand, problem is that calling "number" function from
struct is not possible because "number" should return an struct
definition that doesn't exist (because it's definition is not
finished yet).
It is similar to the problem with recursive lambda call using an
"proxy" variable:
const factorial = (int n) => n==0 ? 1 : n * factorial(n-1);
*factorial* is not defined yet when compiler analyzes lambda
expression.
This is something to keep in mind for people coming from
python/javascript languajes. Sometimes I forget D is not an
scripting/dynamic one (note: crystal has the same limitation...
it says "Error: can't use variable name 'factorial' inside
assignment to variable 'factorial'").
extern(C) and name mangling
I can’t find this in the spec, but from experimentation it seems like extern(C) only affects name mangling of functions at the top level scope. Thus extern(C) function templates would be mangled differently, but still use the C calling convention. Is this right? I want to pass some templated functions as function pointers to some C code and wanted to confirm that would work (and that different versions would be mangled differently). Also, is there any way to say you want the C calling convention, but don’t want C name mangling for top level functions?
Re: UFCS functions with both pointers and refs
On Tuesday, 15 December 2020 at 19:45:50 UTC, Q. Schroll wrote:
On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote:
On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote:
On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
Do I have to write both and have one forward to the other
for more
complicated functions?
For free functions, yes.
Is there any way to write the function as a template that is
generic over a parameter being a pointer or a reference, but
does not allow passing a copy?
I'm not sure what you mean by a reference. D doesn't have
references in general, only class references that are just
glorified pointers. There are also `ref` parameters, but those
aren't generally referred to as "references" and are inside the
function almost indiscernible from non-ref parameters. So, I'll
ignore that.
Copying only takes place under one circumstance: When an lvalue
is passed to a function that does not take that argument by
`ref`. So one possibility is to just define that overload and
@disable it. You don't even need a template for this:
void f(X x); // matches lvalues and rvalues
void f(ref X x); // matches lvalues only
The latter is a better match than the former for lvalues.
@disable'ing it will do the job. On the other hand, not
@disable'ing it will make `f` work with any argument by moving
rvalues to the former overload and referencing lvalues using
the second one.
On templates, those can be unified by slapping `auto ref`
before the parameter. You can also use `auto ref` (which infers
`ref` from the passed argument) and check it with an `if`
template constraint:
void f(T)(auto ref T arg)
if (!__tratis(isRef, arg)) // only accepts non-ref args
{ /* your code here */ }
The constraint can easily be flipped.
The use case would be to define extension methods on a struct
outside of where the struct is defined. The extension method
mutates the state of the struct, so I want to ensure I am
modifying the original struct and not a copy. If it’s a method
and I call it on a pointer to the struct, the pointer will get
auto-dereferenced and everything is great. So my question is that
if I want an extension method as a free function, do I have to
write both the version whose first argument is a pointer to the
struct and the version whose first argument is a ref, or is there
some keyword or other technique so that the pointer gets
auto-dereferenced the same way as if it were a method. It sounds
like the answer is no and I have to write a version that just
dereferences the pointer and calls the ref version.
Thanks for the explanation though!
Re: closures + struct: Error: forward reference to inferred return type of function call
On Monday, 14 December 2020 at 14:39:14 UTC, ddcovery wrote:
On Monday, 14 December 2020 at 12:22:26 UTC, ddcovery wrote:
int opCmp(Number other){
return _value - other.value;
};
Correction:
bool opEquals(Number other){
return _value == other.value;
};
You could just give the struct a variable and use that instead of
the enclosing function's parameter:
https://run.dlang.io/is/4Lqf15
Then, the struct can actually be static.
Re: UFCS functions with both pointers and refs
On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote:
On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote:
On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
Do I have to write both and have one forward to the other for
more
complicated functions?
For free functions, yes.
Is there any way to write the function as a template that is
generic over a parameter being a pointer or a reference, but
does not allow passing a copy?
I'm not sure what you mean by a reference. D doesn't have
references in general, only class references that are just
glorified pointers. There are also `ref` parameters, but those
aren't generally referred to as "references" and are inside the
function almost indiscernible from non-ref parameters. So, I'll
ignore that.
Copying only takes place under one circumstance: When an lvalue
is passed to a function that does not take that argument by
`ref`. So one possibility is to just define that overload and
@disable it. You don't even need a template for this:
void f(X x); // matches lvalues and rvalues
void f(ref X x); // matches lvalues only
The latter is a better match than the former for lvalues.
@disable'ing it will do the job. On the other hand, not
@disable'ing it will make `f` work with any argument by moving
rvalues to the former overload and referencing lvalues using the
second one.
On templates, those can be unified by slapping `auto ref` before
the parameter. You can also use `auto ref` (which infers `ref`
from the passed argument) and check it with an `if` template
constraint:
void f(T)(auto ref T arg)
if (!__tratis(isRef, arg)) // only accepts non-ref args
{ /* your code here */ }
The constraint can easily be flipped.
Getting started with graphqld
Is there anyone willing to help me get started with GraphQLD. I have some experience with graphql in node. My D is intermediate at best but i can learn fast with guidance. I am able to build and deploy vibe-d apps locally and on heroku. Basically, I'm looking for someone to stand-in in lieu of the documentation (currently WIP) to help me connect a basic vibe-d app to a graphql backend. I am willing to contribute to documentation (and produce premium quality video tutorials) once i am proficient using the package. Thanks in advance.
Paper comparing languages with egs?
I _think_ I remember seeing somewhere on the D site a reference to a paper on a comparison of programming languages that used a few small programs written in each compared language. I can't recall if D was one of the languages in the paper or whether someone had done D versions separately. Can anyone give me the link to the paper (and D versions) -- assuming I haven't completely misremembered!
