Re: Frontend and backend communication
I seem to have another problem with the function pointer approach. I
am trying to set up a function that would pass the function pointers
from C to D, and DMD refuses to compile it:
If I have the function pointer struct with D calling convention
pointers, like this:
struct S_FrontendFunctions {
void function(int) SoundPlay;
void function() RedrawScreen;
}
S_FrontendFunctions FrontendFunctions;
And I try to set it in D like this:
FrontendFunctions.SoundPlay = function(int){};
FrontendFunctions.RedrawScreen = function(){};
And have a function for transferring the pointer from C like this:
extern (C):
void SetRedrawScreen(void function() RedrawScreen)
{
FrontendFunctions.RedrawScreen = RedrawScreen;
}
DMD throws an error in the last function:
Error: cannot implicitly convert expression (RedrawScreen) of type
extern (C) void function() to void function()
Now if I define the two function pointers as extern(C) like this:
struct S_FrontendFunctions {
extern (C) void function(int) SoundPlay;
extern (C) void function() RedrawScreen;
}
DMD still complains, but this time about when I set the pointers from
D directly:
Error: cannot implicitly convert expression (__funcliteral3) of
type void function() pure nothrow @safe to extern (C) void function()
Any ideas about how to make it work from both D and C sides?
Re: Frontend and backend communication
Ah, I see, that makes sense. And it now compiles correctly, thanks.
Re: Frontend and backend communication
I'm trying to implement the function pointer system right now, and it
seems to work on the C side, but not D. I assume I'm missing some kind
of syntax here. I have these global variables:
struct S_FrontendFunctions {
void function() RedrawScreen;
void function(const char*, int) PrecacheCard;
}
shared S_FrontendFunctions FrontendFunctions;
And if I try to set the pointers D style, like this:
FrontendFunctions.RedrawScreen = function(){};
FrontendFunctions.PrecacheCard = function(const char*, int){};
I get errors:
Error: cannot implicitly convert expression (__funcliteral3)
of type _error_ function() to shared(void function())
Error: cannot implicitly convert expression (__funcliteral4)
of type _error_ function(const const(char*), int) to shared(void
function(const const(char*), int))
So how do I define those functions as shared?
Transferring global variables from D to C
I'm testing how I could use globals in C, when using D as a library
and C as a frontend. So far it seems to be working well with some data
types, but not so much with a few others.
First of all, one obvious problem is strings, since they are a lot
different in D. I can transfer them with a wrapper function like this
(D code):
immutable(char)* getString()
{
return toStringz(MyString);
}
However, this gets quite inefficient with a lot of different strings,
and, if I understand how they work correctly, you also have to make
sure the pointer points to the string you want if it changes in D by
rerunning the function. That means that using a function instead of a
variable breaks the flow of the code in C. It would be a pretty good
solution if I could use a variable that automatically executes the
function, something like this (D code):
string MyString=a;
shared immutable(char)* a = () {return toStringz(MyString);};
But, of course, the compiler cannot compile it because it does not
evaluate at compile time. So are there any more solutions to this?
Struct packing can also be problematic, since if some members are not
of the same length, then any members below those will always return 0.
I have noticed that booleans, for example, translate to chars and not
ints, and while they do work as ints, any struct members below the
boolean will stop working. This is not mentioned in the documentation
at all.
I'm also not sure about how it would handle strings inside structs.
Are they actually just pointers in D, which means that they only take
the same amount of space in a struct as a regular char pointer?
Re: Transferring global variables from D to C
However, this gets quite inefficient with a lot of different strings,
I just had an idea, perhaps it's possible to work around this
particular point by creating a wrapper function that converts the
passed variable into the C string type? The problem with this idea is
that I can't find a way to pass the variable to begin with. Whenever I
try to do that, D receives an empty string. My C code is this:
extern char* str;
printf(string is %s\n, getString(str));
While the D code is this:
shared string str=a;
extern(C) immutable(char)* getString(string MyString)
{
writeln(Attempting to convert , MyString);
return toStringz(MyString);
}
This results in Attempting to convert , and not Attempting to
convert a, so obviously D is not getting the right data. But it
doesn't segfault, either.
CLI library?
Is there any library that would allow me to use the extended terminal features (like coloured backgrounds and custom/multiple resolution support) that works with D and is not platform-dependent? Something similar to ncurses? I know that there was a dcurses project, but it seems that it only works with D1 and the Linux implementation was never finished to begin with.
Re: Importing D libraries
Yeap, it's definitely a bug, and the temp file is in fact the library that I need. Anyway I'm trying to compile it on Windows now. However, there are two problems. First of all, the Windows Command Prompt does not expand wildcards, and DMD does not take it as an argument. Thus importing LuaD as a source library is quite a hassle, because it has a whole lot of files, and they don't even fit into one notepad line. The second issue is that even if I do compile it and get an executable, it doesn't run correctly. It says that the application failed to initialise, and the system log says that it failed to initialise lua51.dll, even though I used it with C just fine. Any ideas about what could be wrong here? This is the batch file that I use to compile my executable: https://github.com/GreatEmerald/Arcomage-GreatEmerald/blob/libarcomage-dev/clarcomage/src/compile.cmd
Re: Frontend and backend communication
I seem to have run into a problem with the function pointer method
here. I have this code:
arco.d:
struct FrontendFunctions {
void function(SoundTypes) Sound_Play;
void function() RedrawScreenFull;
void function(const char*, int) PrecacheCard;
void function(CardInfo, int) PlayCardAnimation;
}
cards.d:
void InitLuaFunctions()
{
lua[Damage] = (int Who, int Amount)
{
FrontendFunctions.Sound_Play(SoundTypes.Damage);
};
}
Essentially I am trying to get Lua (via LuaD) to call a function in D
that calls a frontend function. But when I compile the code, I get
this: cards.d(5): Error: 'this' is only defined in non-static member
functions, not __dgliteral14. Why is this and what can I do about it?
Re: Frontend and backend communication
Oh, so structs themselves are only definitions and not global variables, I see. Thanks.
Re: Importing D libraries
A question about RDMD - can it compile libraries as well? Since right now it compiles my library code fine, yet I get an .a file that is mere 72 bytes of size, so I'm pretty sure that it's not what I am supposed to be getting. The command I use to compile it is: rdmd --build-only -lib -L-llua -I../include/LuaD arco.d cards.d And while we're at it, how do you tell DMD what to name your library? I know you can change the output directory with -od and the output executable name with -of, but at least with RDMD, those don't seem to do anything, I always get an .a file in the directory of the arco.d file and the name is always 'arco.a'.
Re: Frontend and backend communication
I see. Well, I guess I'll have to stick to static ones until this gets sorted out.
Re: Frontend and backend communication
So, now my (static) library nearly links in Win32. There is only one link error, and apparently it's generated by phobos: ..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined __end Any clues about what is happening? Admittedly, that phobos.lib is from March 20, 2011, so it's rather old by now.
Re: Frontend and backend communication
Yes, this is a library, so a main() there would be rather pointless. However, it seems that on many occasions compilers will simply not acknowledge anything without one, so I guess at least a declaration is in order... I'll have to try that out once I get back on Windows. Meanwhile, on Linux, I am getting these linker errors instead: /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libphobos2.a(datetime_3a6_1ec.o): In function `_D3std8datetime5Clock11currStdTimeFNdNeZl': std/datetime.d:(.text._D3std8datetime5Clock11currStdTimeFNdNeZl+0x1d): undefined reference to `clock_gettime' /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libphobos2.a(time_c6_4d1.o): In function `_D4core4time12TickDuration12_staticCtor7OFNeZv': src/core/time.d:(.text._D4core4time12TickDuration12_staticCtor7OFNeZv+0x1f): undefined reference to `clock_getres' /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/libphobos2.a(time_c6_4d1.o): In function `_D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration': src/core/time.d:(.text._D4core4time12TickDuration14currSystemTickFNdNeZS4core4time12TickDuration+0x1f): undefined reference to `clock_gettime' Is it related, or is it a different issue altogether? Also, apparently SDL and Lua don't like being statically linked. Good thing the backend doesn't use SDL any more, then! And Lua does link, although reluctantly and with linker warnings. Reportedly they are nothing to worry about too much, but still...
Re: Frontend and backend communication
Hmm, there are still a whole lot of functions that call Shuffle(), so it might not be ideal. However, this gives me an idea - if a pointer to a function can be a parameter, can it be a global variable? In that case, the frontend would indeed be able to overwrite the function that the backend calls by simply altering that pointer.
Re: Frontend and backend communication
On Thu, Jul 28, 2011 at 10:37 PM, Kai Meyer k...@unixlords.com wrote: On 07/27/2011 04:40 PM, Dainius (GreatEmerald) wrote: One reason for the confusing responses is that in your original post you said: a frontend (a library), a backend (an executable), Shuffle() is a backend function, and PlaySound() is a frontend one. D'oh I missed! I did indeed mean the other way round. But yea, I have already implemented a function table. It seems to be working relatively fine for now - it compiled, but doesn't want to link just yet. On Windows, it says that there are undefined symbols, even though they are quite clearly defined, and then also quite a few more mangled linker errors; On Linux, my main development platform, however, I have hit a pretty obvious issue - there is no libphobos2.so, and I can't link against libphobos2.a because of this: ld: /lib64/libphobos2.a(object_.o): relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC And then there's another problem in that right now the backend is still written in C and it uses D as a static library, and linking against that provides a similar error. Of course, since I will have to rewrite the backend in D to begin with, this might not be such a big of an issue as the first one.
Frontend and backend communication
I have one program design problem and I wonder if anyone here could give any suggestions about it. The situation is like this: I am splitting a game into a frontend (a library) and a backend (an executable). The backend is going to handle all the game mechanics, while the frontend is going to handle I/O. But there are certain problems. For example, now I have a function Shuffle() that calls PlaySound(SHUFFLE). Shuffle() is a backend function, while PlaySound() is a frontend one, so obviously it won't work that way after the split. It would be ideal if there was a way to create hooks - say an empty PlaySound() function that the frontend could receive calls to. But I can't see a way to do that. Another way to do that that was suggested to me was to use an event loop - set a global variable, then have the frontend monitor it for changes and then respond as necessary, but that just isn't a very clean way to do it. And then there is the fact that the backend is going to be written in D (right now it's a mix of C and D), while the frontend will be in C (one of the frontends, anyway - the second one will also be in D). Any suggestions about this?
Re: Frontend and backend communication
Hm, well, at least I don't know how it's possible for a binary to overwrite/capture a library's function. Would you care to give an example?
Re: Frontend and backend communication
No no. It's the other way round. Shuffle() is in the library (backend). PlaySound() is in the executable (frontend). Since I don't want the library to be dependent on any sound libraries, I can't have PlaySound() in it. And there is no other way that I can think of to execute PlaySound() just at the end of Shuffle() without capturing events (since Shuffle() itself is called by a whole lot of different functions across the library, and not from the executable itself).
Importing D libraries
I must be missing something incredibly obvious here, but I can't find
out what it is... I'm trying to build a very simple test program for
LuaD, right now it simply imports the library. But it throws a linker
error for some reason. Here's the program I'm trying to compile:
import std.stdio;
import luad.all;
int main()
{
readln();
return 0;
}
This is what I use to compile it:
dmd -ILuaD LuaTest.d
This is the error it gives me:
LuaTest.o:(.data+0x18): undefined reference to `_D4luad3all12__ModuleInfoZ'
collect2: ld returned 1 exit status
--- errorlevel 1
I got LuaD by simply performing a git clone from here:
https://github.com/JakobOvrum/LuaD
Using Linux, DMD64 v2.053.
Re: Importing D libraries
Hmm, apparently it requires a strict compilation order. If I just add all .d files in no particular order, I get lots of linker errors, for example: LuaTest.o: In function `_D4luad4base9LuaObject9checkTypeFPT4luad1c3lua9lua_StateiiPxaZv': LuaD/luad/c/lua.d:(.text._D4luad4base9LuaObject9checkTypeFPT4luad1c3lua9lua_StateiiPxaZv+0x1a): undefined reference to `lua_type' LuaD/luad/c/lua.d:(.text._D4luad4base9LuaObject9checkTypeFPT4luad1c3lua9lua_StateiiPxaZv+0x2b): undefined reference to `lua_typename' LuaD/luad/c/lua.d:(.text._D4luad4base9LuaObject9checkTypeFPT4luad1c3lua9lua_StateiiPxaZv+0x47): undefined reference to `luaL_error' LuaTest.o: In function `_D4luad4base9LuaObject4typeMFNdZE4luad4base7LuaType': LuaD/luad/c/lua.d:(.text._D4luad4base9LuaObject4typeMFNdZE4luad4base7LuaType+0x45): undefined reference to `lua_type' LuaTest.o: In function `_D4luad4base9LuaObject8opEqualsMFC6ObjectZb': LuaD/luad/c/lua.d:(.text._D4luad4base9LuaObject8opEqualsMFC6ObjectZb+0xa1): undefined reference to `lua_equal' LuaTest.o: In function `_D4luad5table8LuaTable12setMetaTableMFC4luad5table8LuaTableZv': LuaD/luad/c/lua.d:(.text._D4luad5table8LuaTable12setMetaTableMFC4luad5table8LuaTableZv+0x5e): undefined reference to `lua_setmetatable' LuaTest.o: In function `_D4luad5table8LuaTable12getMetaTableMFZC4luad5table8LuaTable': LuaD/luad/c/lua.d:(.text._D4luad5table8LuaTable12getMetaTableMFZC4luad5table8LuaTable+0x45): undefined reference to `lua_getmetatable' How do I work around that? I know that things like lua_type are in luad/c/lua.d. How do I tell that to the compiler? How do I determine the correct order of files?
Re: Importing D libraries
I updated the DMD and tried RDMD, but still no luck. Linker errors galore. You can see all of them here: http://pastebin.com/C6cRVGKt
Re: Importing D libraries
Ah, that did the trick, thanks!
Re: SDL with D
According to the Derelict page, there already are unofficial bindings. But I guess they wouldn't work with Derelict2 anyway.
SDL with D
Can D interface with SDL directly? Right now the program I'm writing uses C as a sort of a wrapper for D and SDL to communicate, and I guess it would be simpler, cleaner and more reliable if D could call SDL functions directly. If it works, is there anything I should keep in mind about it?
Re: readf with strings
I have a related enhancement request since lot of time: http://d.puremagic.com/issues/show_bug.cgi?id=4716 Bye, bearophile That's exactly what I'd like to see. Voted. After all, D is created with practicality in mind, and doing all that parsing is the opposite of what it's trying to achieve.
Re: readf with strings
I see. Using %s does indeed work with ints, and chomp(readln()) works with strings. It's rather counter-intuitive, though. I wonder why there isn't a simpler way to do this, something like writeln() - you could input the variables as parameters and it would automatically read them...
Re: Using D libs in C
They both return 4, and both short and int16_t return 2. Also, I've noticed that if I use a struct (of four ints) instead, the same thing happens, the parameters are not correct. And yes, of course they are extern already.
Re: Using D libs in C
OK, now I have a question about passing variables. In D, I have a dynamic array of strings and I want C to get that array. Yet C supports neither dynamic arrays nor strings. So is there a way to accomplish this?
Re: Using D libs in C
Well, the situation is like this: D creates a list of names of files that should be loaded by C. C then takes the list, uses it to load the files, then stores both the pointers to the loaded files and the names of the files in an array of structs. Then when C wants to access the files, it asks D about which file to access, which then sends the file name, and C compares the known file names and on finding a match, accesses the file. So that means that the array should be pretty much read-only there, but C needs to know how big the newly created array of structs has to be. As for how long the list of file names will be - it's determined by the configuration, so it will be anywhere from 1 to around 300 or even more.
Re: Using D libs in C
Hmm, if I was to do it from C, I would have to deal with all the allocation, since I don't know how large the array is going to be when it's complete, while D doesn't need to know since it uses dynamic arrays.
Re: Using D libs in C
Ah, including pthread indeed works, but now I've run into another problem related to Linux and architecture. I want to use D for my program that also uses things like SDL and Lua. Earlier when I compiled it, I always did so with 64-bit libraries. But D is so far only in 32-bits, thus when compiling it doesn't accept phobos2. And it also seems that Debian x64 (which I'm using to compile this at the moment) doesn't have 32-bit libs of SDL as well. Plus compiling SDL from source doesn't work either. So how should I proceed with this? Try to get the beta D x64 libraries?
Re: Using D libs in C
Hmm... Spent a few hours trying to figure out how to update GCC and all to conform to the requirements for 2.0.52, and at seems that it compiles my small test program just fine, but it fails on compiling the main project for some reason. And the linker outputs half-scrambled things. Anyway, here's all the output that shows how I'm trying to build the thing: http://pastebin.com/j7bE76bn It seems that it for some odd reason doesn't want to link the imports, and I don't see why is that, since my small test program works, and it uses basically the same thing...
Re: Using D libs in C
I've tried compiling the same on Linux and the program still crashes (with segmentation fault there). No error message or anything. And it doesn't matter if I compile the thing from .obj or from .lib files, I still get the same crashes. So it's a real showtopper for me, since what's the use of having static libraries that compile successfully yet crash every time you attempt to use them?.. Anyone have any ideas about what's happening? Or should I just go ahead and submit this to the bug tracker?
Re: Using D libs in C
Now I'm trying to do something more complicated, and it seems that while
importing works (it compiles and links fine), actually using the imported
things or pretty much anything that D offers makes the program crash. For
instance, in the D part:
---
module dpart;
import std.stdio;
version(linux)
{
int main()
{
return 0;
}
}
extern(C):
shared int ResultD;
int Process(int Value)
{
writeln(hai); //- Hangs here
printf(You have sent the value %d to the D library.\n, Value);
ResultD = (Value % 5);
string a; //Doesn't hang
a = 10;//Doesn't hang
printf(String %s, a); //- Hangs here
return ResultD;
}
---
There is no readable error, just your ordinary program crash report this to
Microsoft... Any idea why it's like that?
