July 28, 2011
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
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
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
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
I see. Well, I guess I'll have to stick to static ones until this gets sorted out.
July 29, 2011
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
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
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
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
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:
    ...
}