View mode: basic / threaded / horizontal-split · Log in · Help
July 28, 2011
Re: Frontend and backend communication
On 07/27/2011 04:40 PM, Dainius (GreatEmerald) wrote:
> 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).


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".

Frontend->library->Shuffle()
Backend->executable->PlaySound()

Then in this email, you say:

"Shuffle() is in the library (backend)", and "PlaySound() is in the 
executable (frontend)"

Backend->library->Shuffle()
Frontend->executable->PlaySound()

I'm assuming that this is the more correct version.

Depending on what PlaySound needs, you can pass the function as a 
parameter to Shuffle().
July 28, 2011
Re: Frontend and backend communication
On 07/28/2011 01:18 AM, Dainius (GreatEmerald) wrote:
> 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.

Yes, you could create a "function table" and keep a list of all the 
functions that need to be called. You can then alter the behavior of one 
method at runtime with out having to pass a function as a parameter. Of 
course, global variables are tricky things, especially whe you're 
threaded. It's probably simplest to just pass the function pointer as a 
parameter to Shuffle(). If Shuffle() indeed has multiple entry points, 
and they all fight to have their version of PlaySound() run at the end 
of Shuffle(), then you may run into problems.

-Kai Meyer
July 28, 2011
Re: Frontend and backend communication
On Thu, Jul 28, 2011 at 10:37 PM, Kai Meyer <kai@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.
July 29, 2011
Re: Frontend and backend communication
On 2011-07-28 21:55, Dainius (GreatEmerald) wrote:
> On Thu, Jul 28, 2011 at 10:37 PM, Kai Meyer<kai@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.

Yeah, phobos/druntime doesn't work as a dynamic library yet on Linux or 
Windows.

-- 
/Jacob Carlborg
July 29, 2011
Re: Frontend and backend communication
I see. Well, I guess I'll have to stick to static ones until this gets
sorted out.
July 29, 2011
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.
July 29, 2011
Re: Frontend and backend communication
Dainius (GreatEmerald) Wrote:

> 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.

I didn't follow this discussion, but it is telling you there is no main function. Are you compiling a library? Maybe you should try giving your program a main?
July 29, 2011
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...
August 10, 2011
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?
August 10, 2011
Re: Frontend and backend communication
On Wed, 10 Aug 2011 10:35:46 +0200, Dainius (GreatEmerald)  
<pastas4@gmail.com> wrote:

> 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?

FrontendFunctions frontendFunctions;

use frontendFunctions everywhere.

OR (this makes them global):

struct FrontendFunctions {
static:
    ...
}
1 2 3
Top | Discussion index | About this forum | D home