Re: Exporting template function instances to C
On Thursday, 23 March 2017 at 19:46:43 UTC, data pulverizer wrote:
On Thursday, 23 March 2017 at 17:58:21 UTC, H. S. Teoh wrote:
On Thu, Mar 23, 2017 at 05:29:22PM +, data pulverizer via
Thanks. Is there a less ham-handed way of exporting them
other than wrapping them in functions as I have?
Wrapping them in functions is probably the simplest way to
call them from C. You *could*, I suppose, use their mangled
names directly, then you wouldn't need a wrapper, but that
would be rather difficult to use on the C end. On the D side,
there's .mangleof that will tell you what mangled names to
use, but if you're calling from C you don't have that luxury.
T
Thanks. Mangling sounds painful and scary, I think I'll stick
to wrapping which sounds much less dangerous.
There's nothing scary or dangerous about it. It happens
automatically to allow overloads and templates so that you get a
unique symbol foreach version (unless you use extern(C),
extern(C++) or pragma mangle). C++,Java and any other compiled
language that has overloads does mangling. Heck, you can even do
it in C with __attribute__((overloadable)) (at least with clang),
it just transparently mangles (just as in D)the name as whatever
C++ would mangle it as.
So instead of doing
T mult(T)(T x, T y)
{
return x*y;
}
doing something like
template mult(T)
{
extern(C++) T mult(T x, T y)
{
return x*y;
}
}
in D, and then in C (noting that you have to declare the name and
signature anyway)
__attribute__((overloadable)) float mult(float,float);
__attribute__((overloadable)) double mult(double, double);
which I think is the least painful way of doing it. I seem to
remember somewhere in phobos
template Instantiate(alias a)
{
alias Instantiate = a;
}
to instantiate template, because you reference them from another
symbol it somehow magically works. Used like
Instantiate!(mult!float); // at module scope
Re: Undefined Reference calling D from C using static linking
On 2017-03-23 13:26, Nicholas Wilson wrote: Getting dmd to do the linking should work. You may wish to see what mir (github.com/libmir) does to build in it's "Better C" mode, so i'm sure it is possible, I just don't know the incantations, sorry. Perhaps someone else can help. As an ugly workaround, you can defined the "_d_dso_registry" symbol yourself. To be sure, it should match the signature in the runtime. -- /Jacob Carlborg
Re: Exporting template function instances to C
On Thursday, 23 March 2017 at 17:58:21 UTC, H. S. Teoh wrote: On Thu, Mar 23, 2017 at 05:29:22PM +, data pulverizer via Thanks. Is there a less ham-handed way of exporting them other than wrapping them in functions as I have? Wrapping them in functions is probably the simplest way to call them from C. You *could*, I suppose, use their mangled names directly, then you wouldn't need a wrapper, but that would be rather difficult to use on the C end. On the D side, there's .mangleof that will tell you what mangled names to use, but if you're calling from C you don't have that luxury. T Thanks. Mangling sounds painful and scary, I think I'll stick to wrapping which sounds much less dangerous.
Re: high performance client server solution in D?
@Laeeth Isharc and rikki cattermole: Thank you for your inputs. Msgpack is definitely something I will consider. I tried search some show cases and open-source projects of this kind for Dlang but still haven't found one. Those applications will give clearer ideas.
Re: high performance client server solution in D?
On Thursday, 23 March 2017 at 13:07:54 UTC, biocyberman wrote: I am considering to use D and its library to build a high performance client-server application. The client will be a cross platform (Windows, Mac, Linux) GUI program that can synchronize analysis results with the remote central server, and analyze data locally. It will also visualize big data files (about 10GB of binary data each). The term 'high performance' means it can serve several hundreds users with desktop application speed. Further more, heavy computation tasks will be done locally on the client side. This description is still vague, I know. But that's the best I can give for now. I would choose 'dlangui' and check 'vibe.d' for a start. However, I do not need to access the central server via web browsers. Hope that you can give some thoughts about this design, what GUI library to use, and what back-end library to use. cerealed, orange, and msgpack for serialisation/deserialisation (see code.dlang.org). Depends how complicated your D structures are. I found of those three msgpack handles more (for what I am doing), but vibed json serialiseToPrettyJSON (sp?) etc covers some that msgpack chokes on (trouble with Algebraic and TaggedAlgebraic from what I remember). However for speed asdf has better performance. But I guess for binary data you may as well use msgpack. I use nanomsg over 0MQ as I was burned a couple of years back by a problem I encountered using Salt Stack (which was then based on 0MQ) where I think if the server hangs up mid-connection than it's not completely straightforward to get the clients talking to it again. 0MQ is certainly more stable. I find nanomsg easier to use, and I haven't found too many problems with it (IPC on Windows not implemented/didn't work). If you use either, you might want to protect sockets if it isn't on internal network. stunnel worked fine for me. Dlangui was fine for GUI and very happy with it on linux and Windows. Much quicker to develop for that than in browser, was our experience.
Re: How to use C code in D
On Thursday, 23 March 2017 at 18:10:20 UTC, Dillen Meijboom wrote:
Hi there,
I'm learning D for a while because it's really easy to use
C-code in D.
The problem is that I don't really get how to deal with the
data structures defined in C in D.
At one time for instance I've tried to get all environment
variables on a POSIX system. I succeeded but I think it can be
done way easier.
So my question basically is:
1. How can I learn to use C code in D? Is there any good
tutorial or other packages that deal with this a lot?
2. Is the way I'm currently doing it okay or is it wrong and do
I need to do something else?
As a reference, I'm currently using the following D code to get
all environment variables:
```
import std.array;
import std.conv: to;
import std.string: fromStringz;
extern (C) extern const char** environ;
string[string] getenv() {
string[string] env;
char* line;
for (auto data = cast(char**)environ; (line = *data) != null;
++data) {
auto keyval = to!string(fromStringz(line)).split('=');
env[keyval[0]] = keyval[1];
}
return env;
}
```
https://dlang.org/phobos/std_process.html#.environment means it's
already done for you.
C global variables are __gshared.
Reading other people's source code - starting with standard
library and maybe look at some of the bindings and wrappers on
code.dlang.org.
IRC chat to get a quick answer most of the time.
How to use C code in D
Hi there,
I'm learning D for a while because it's really easy to use C-code
in D.
The problem is that I don't really get how to deal with the data
structures defined in C in D.
At one time for instance I've tried to get all environment
variables on a POSIX system. I succeeded but I think it can be
done way easier.
So my question basically is:
1. How can I learn to use C code in D? Is there any good tutorial
or other packages that deal with this a lot?
2. Is the way I'm currently doing it okay or is it wrong and do I
need to do something else?
As a reference, I'm currently using the following D code to get
all environment variables:
```
import std.array;
import std.conv: to;
import std.string: fromStringz;
extern (C) extern const char** environ;
string[string] getenv() {
string[string] env;
char* line;
for (auto data = cast(char**)environ; (line = *data) != null;
++data) {
auto keyval = to!string(fromStringz(line)).split('=');
env[keyval[0]] = keyval[1];
}
return env;
}
```
Re: Exporting template function instances to C
On Thu, Mar 23, 2017 at 05:29:22PM +, data pulverizer via Digitalmars-d-learn wrote: > On Thursday, 23 March 2017 at 16:38:02 UTC, Adam D. Ruppe wrote: > > On Thursday, 23 March 2017 at 16:28:18 UTC, data pulverizer wrote: > > > alias mult!double dmult; > > > alias mult!float fmult; > > > > Those are just aliases in the D compiler, they don't actually exist > > in the object file for C to use like regular functions. > > > > Templates need to actually be *used* to be instantiated for export, > > and aliases make them easier to use, but don't actually use them > > yet. [...] > > Thanks. Is there a less ham-handed way of exporting them other than > wrapping them in functions as I have? Wrapping them in functions is probably the simplest way to call them from C. You *could*, I suppose, use their mangled names directly, then you wouldn't need a wrapper, but that would be rather difficult to use on the C end. On the D side, there's .mangleof that will tell you what mangled names to use, but if you're calling from C you don't have that luxury. T -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth
Re: Exporting template function instances to C
On Thursday, 23 March 2017 at 16:38:02 UTC, Adam D. Ruppe wrote: On Thursday, 23 March 2017 at 16:28:18 UTC, data pulverizer wrote: alias mult!double dmult; alias mult!float fmult; Those are just aliases in the D compiler, they don't actually exist in the object file for C to use like regular functions. Templates need to actually be *used* to be instantiated for export, and aliases make them easier to use, but don't actually use them yet. Why is that? Thanks. Is there a less ham-handed way of exporting them other than wrapping them in functions as I have?
Re: bug in foreach continue
On Thursday, 23 March 2017 at 00:39:56 UTC, H. S. Teoh wrote: I'm still working on that. :-) Hey, can you at least put scare quotes around "static foreach" each time it is used? There's no such thing as static foreach and while we might call foreach over a typetuple "static", it isn't a precise term and invites additional confusion.
Re: Exporting template function instances to C
On Thursday, 23 March 2017 at 16:28:18 UTC, data pulverizer wrote: alias mult!double dmult; alias mult!float fmult; Those are just aliases in the D compiler, they don't actually exist in the object file for C to use like regular functions. Templates need to actually be *used* to be instantiated for export, and aliases make them easier to use, but don't actually use them yet. Why is that?
Exporting template function instances to C
I have noticed that the following will not successfully export
`dmult` and `fmult` to C:
```
extern (C) nothrow @nogc @system:
pragma(LDC_no_moduleinfo);
T mult(T)(T x, T y)
{
return x*y;
}
alias mult!double dmult;
alias mult!float fmult;
```
but this will
```
extern (C) nothrow @nogc @system:
pragma(LDC_no_moduleinfo);
T mult(T)(T x, T y)
{
return x*y;
}
double dmult(double x, double y)
{
return mult(x, y);
}
float fmult(float x, float y)
{
return mult(x, y);
}
```
Why is that?
Re: high performance client server solution in D?
On Thursday, 23 March 2017 at 13:07:54 UTC, biocyberman wrote: I would choose 'dlangui' and check 'vibe.d' for a start. However, I do not need to access the central server via web browsers. Hope that you can give some thoughts about this design, what GUI library to use, and what back-end library to use. Maybe you can give a try to zeromq library binding/wrapper for D.
Re: high performance client server solution in D?
On 24/03/2017 2:07 AM, biocyberman wrote: I am considering to use D and its library to build a high performance client-server application. The client will be a cross platform (Windows, Mac, Linux) GUI program that can synchronize analysis results with the remote central server, and analyze data locally. It will also visualize big data files (about 10GB of binary data each). The term 'high performance' means it can serve several hundreds users with desktop application speed. Further more, heavy computation tasks will be done locally on the client side. This description is still vague, I know. But that's the best I can give for now. I would choose 'dlangui' and check 'vibe.d' for a start. However, I do not need to access the central server via web browsers. Hope that you can give some thoughts about this design, what GUI library to use, and what back-end library to use. Yeah go with vibe.d as a starting point for communication. Add a serializer on top to handle the messagers and you'd be good to go. It shouldn't matter what GUI toolkit you use, you will end up writing custom drawing code for that large of data. Otherwise you will hit performance problems.
high performance client server solution in D?
I am considering to use D and its library to build a high performance client-server application. The client will be a cross platform (Windows, Mac, Linux) GUI program that can synchronize analysis results with the remote central server, and analyze data locally. It will also visualize big data files (about 10GB of binary data each). The term 'high performance' means it can serve several hundreds users with desktop application speed. Further more, heavy computation tasks will be done locally on the client side. This description is still vague, I know. But that's the best I can give for now. I would choose 'dlangui' and check 'vibe.d' for a start. However, I do not need to access the central server via web browsers. Hope that you can give some thoughts about this design, what GUI library to use, and what back-end library to use.
Re: Undefined Reference calling D from C using static linking
On Thursday, 23 March 2017 at 12:06:14 UTC, data pulverizer wrote: On Thursday, 23 March 2017 at 11:32:25 UTC, Nicholas Wilson wrote: On Thursday, 23 March 2017 at 10:49:37 UTC, data pulverizer wrote: [...] Those functions are the bounds checking function, the non unittest assert function, the unittest function an module initialisation function respectively. dmd -boundscheck=off -release should get rid of the first two, you didn't compile with -unittest so I'm not sure why the thord one is there at all. For _d_dso_registry all i can suggest is see what -betterC gets you. I just compiled `dmd -c dcode.d -betterC -boundscheck=off` (-betterC probably makes -boundscheck=off irrelevant but I threw it in as a prayer) I am still getting: ``` dcode.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry' collect2: error: ld returned 1 exit status ``` Getting dmd to do the linking should work. You may wish to see what mir (github.com/libmir) does to build in it's "Better C" mode, so i'm sure it is possible, I just don't know the incantations, sorry. Perhaps someone else can help.
Re: Undefined Reference calling D from C using static linking
On Thursday, 23 March 2017 at 11:32:25 UTC, Nicholas Wilson wrote: On Thursday, 23 March 2017 at 10:49:37 UTC, data pulverizer wrote: On Thursday, 23 March 2017 at 10:16:22 UTC, Nicholas Wilson wrote: It has to do with module references to druntime stuff. You can either try adding a pragma(LDC_no_module_info); //I think it is spelled correctly. or you can use ldc to link and it will link druntime gcc ccode.c -c ldc2 dcode.d code.o I don't know how well that will work. Many thanks, I tried: ``` pragma(LDC_no_moduleinfo) // https://wiki.dlang.org/LDC-specific_language_changes#LDC_no_moduleinfo ``` which worked, your method of doing the final compilation using ldc2 (or dmd) also works :-) Is there a dmd equivalent for `pragma(LDC_no_module_info);`? Attempting the final compilation `gcc -o output ccode.o dcode.o` after the second stage compilation `dmd -c dcode.d` gives an error: ``` dcode.o: In function `_D5dcode7__arrayZ': dcode.d:(.text._D5dcode7__arrayZ+0x23): undefined reference to `_d_arraybounds' dcode.o: In function `_D5dcode8__assertFiZv': dcode.d:(.text._D5dcode8__assertFiZv+0x23): undefined reference to `_d_assert' dcode.o: In function `_D5dcode15__unittest_failFiZv': dcode.d:(.text._D5dcode15__unittest_failFiZv+0x23): undefined reference to `_d_unittest' dcode.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry' collect2: error: ld returned 1 exit status ``` ``` dmd --version DMD64 D Compiler v2.073.2 Copyright (c) 1999-2016 by Digital Mars written by Walter Bright ``` Those functions are the bounds checking function, the non unittest assert function, the unittest function an module initialisation function respectively. dmd -boundscheck=off -release should get rid of the first two, you didn't compile with -unittest so I'm not sure why the thord one is there at all. For _d_dso_registry all i can suggest is see what -betterC gets you. I just compiled `dmd -c dcode.d -betterC -boundscheck=off` (-betterC probably makes -boundscheck=off irrelevant but I threw it in as a prayer) I am still getting: ``` dcode.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry' collect2: error: ld returned 1 exit status ```
Re: Undefined Reference calling D from C using static linking
On Thursday, 23 March 2017 at 10:49:37 UTC, data pulverizer wrote: On Thursday, 23 March 2017 at 10:16:22 UTC, Nicholas Wilson wrote: It has to do with module references to druntime stuff. You can either try adding a pragma(LDC_no_module_info); //I think it is spelled correctly. or you can use ldc to link and it will link druntime gcc ccode.c -c ldc2 dcode.d code.o I don't know how well that will work. Many thanks, I tried: ``` pragma(LDC_no_moduleinfo) // https://wiki.dlang.org/LDC-specific_language_changes#LDC_no_moduleinfo ``` which worked, your method of doing the final compilation using ldc2 (or dmd) also works :-) Is there a dmd equivalent for `pragma(LDC_no_module_info);`? Attempting the final compilation `gcc -o output ccode.o dcode.o` after the second stage compilation `dmd -c dcode.d` gives an error: ``` dcode.o: In function `_D5dcode7__arrayZ': dcode.d:(.text._D5dcode7__arrayZ+0x23): undefined reference to `_d_arraybounds' dcode.o: In function `_D5dcode8__assertFiZv': dcode.d:(.text._D5dcode8__assertFiZv+0x23): undefined reference to `_d_assert' dcode.o: In function `_D5dcode15__unittest_failFiZv': dcode.d:(.text._D5dcode15__unittest_failFiZv+0x23): undefined reference to `_d_unittest' dcode.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry' collect2: error: ld returned 1 exit status ``` ``` dmd --version DMD64 D Compiler v2.073.2 Copyright (c) 1999-2016 by Digital Mars written by Walter Bright ``` Those functions are the bounds checking function, the non unittest assert function, the unittest function an module initialisation function respectively. dmd -boundscheck=off -release should get rid of the first two, you didn't compile with -unittest so I'm not sure why the thord one is there at all. For _d_dso_registry all i can suggest is see what -betterC gets you.
Re: Undefined Reference calling D from C using static linking
On Thursday, 23 March 2017 at 10:16:22 UTC, Nicholas Wilson wrote: It has to do with module references to druntime stuff. You can either try adding a pragma(LDC_no_module_info); //I think it is spelled correctly. or you can use ldc to link and it will link druntime gcc ccode.c -c ldc2 dcode.d code.o I don't know how well that will work. Many thanks, I tried: ``` pragma(LDC_no_moduleinfo) // https://wiki.dlang.org/LDC-specific_language_changes#LDC_no_moduleinfo ``` which worked, your method of doing the final compilation using ldc2 (or dmd) also works :-) Is there a dmd equivalent for `pragma(LDC_no_module_info);`? Attempting the final compilation `gcc -o output ccode.o dcode.o` after the second stage compilation `dmd -c dcode.d` gives an error: ``` dcode.o: In function `_D5dcode7__arrayZ': dcode.d:(.text._D5dcode7__arrayZ+0x23): undefined reference to `_d_arraybounds' dcode.o: In function `_D5dcode8__assertFiZv': dcode.d:(.text._D5dcode8__assertFiZv+0x23): undefined reference to `_d_assert' dcode.o: In function `_D5dcode15__unittest_failFiZv': dcode.d:(.text._D5dcode15__unittest_failFiZv+0x23): undefined reference to `_d_unittest' dcode.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry' collect2: error: ld returned 1 exit status ``` ``` dmd --version DMD64 D Compiler v2.073.2 Copyright (c) 1999-2016 by Digital Mars written by Walter Bright ```
Re: Undefined Reference calling D from C using static linking
On Thursday, 23 March 2017 at 09:11:28 UTC, data pulverizer wrote:
I am trying to call a D function from C. Here is the D code:
```
/* dcode.d */
extern (C) nothrow @nogc @system {
double multNum(double x, double y)
{
return x*y;
}
}
```
[...]
It has to do with module references to druntime stuff. You can
either try adding a
pragma(LDC_no_module_info); //I think it is spelled correctly.
or you can use ldc to link and it will link druntime
gcc ccode.c -c
ldc2 dcode.d code.o
I don't know how well that will work.
Undefined Reference calling D from C using static linking
I am trying to call a D function from C. Here is the D code:
```
/* dcode.d */
extern (C) nothrow @nogc @system {
double multNum(double x, double y)
{
return x*y;
}
}
```
Then the C code:
```
/* ccode.c */
#include
#include
#include
extern double multNum(double x, double y);
int main()
{
printf("output: %f", multNum(3.0, 4.0));
return 0;
}
```
Then I compile with:
```
ldc2 -c dcode.d
gcc -c ccode.c
gcc -o output ccode.o dcode.o
```
I get the error:
```
dcode.o: In function `ldc.register_dso':
dcode.d:(.text.ldc.register_dso+0x6e): undefined reference to
`_d_dso_registry'
collect2: error: ld returned 1 exit status
```
Compiler versions:
```
$ ldc2 --version
LDC - the LLVM D compiler (1.1.0):
based on DMD v2.071.2 and LLVM 3.9.1
built with LDC - the LLVM D compiler (1.1.0)
Default target: x86_64-unknown-linux-gnu
Host CPU: ivybridge
http://dlang.org - http://wiki.dlang.org/LDC
Registered Targets:
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
```
```
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
```
I would appreciate it if someone could point out my mistake.
Thank you in advance
