Re: Frontend and backend communication

[Dainius (GreatEmerald)]

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: Importing D libraries

[Andrew Wiley]

On Wed, Jul 27, 2011 at 11:46 PM, Jacob Carlborg  wrote:

> On 2011-07-28 03:23, Andrew Wiley wrote:
>
>> On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg > > wrote:
>>
>>Cannot be implemented in GDC. The driver/compiler/assembler/__**
>> linker
>>structure doesn't allow it.
>>
>>
>>Why is that?
>>
>>
>> Well, the short version is that GDC (the executable) is not a compiler.
>> GDC is a driver that runs cc1d to compile your code, runs as (at least I
>> think that's the name offhand) to assemble it, then runs ld to link it.
>> As far as I know, there's no way for cc1d to communicate the contents of
>> pragmas like this back to the driver, which it would have to do if you
>> wanted the driver to include the library in the arguments to the linker.
>> It's possible that I just don't know the infrastructure well enough, but
>> I think this is one of the reasons the GCC guys refused to implement
>> #pragma in C/C++ as well.
>>
>
> I don't really get this. GDC is a D front end for the GCC back end. So the
> the front end should handle all language specific things, like the pragma.
> Then I assume the front end can pass options to the linker. Is this not the
> case?


In traditional terms, cc1d is a compiler, including both the frontend and
the backend. It takes parameters and spits out assembly. That's it.
The GDC executable is the driver responsible for running cc1d to compile the
source to assembly, as to assemble the object files, and ld to link it all
into a binary. cc1d cannot pass options to the linker because it does not
invoke the linker.

Re: Frontend and backend communication

[Pelle]

On Wed, 27 Jul 2011 19:41:37 +0200, Dainius (GreatEmerald)  
 wrote:



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?


You could use a struct of function pointers to define the interface, if
you need it to work both in C and D.

extern (C) struct FrontEndFunctions {
void function(sound) playSound;
...
}

backend does myFrontEndFunctions.playSound(SHUFFLE);

The front end:

void myPlaySound(...) { ... }

void main() {
FrontEndFunctions functions;
functions.playSound = &myPlaySound;
... etc for other functions ...;
backend.initialize(functions);
backend.run();
}

Re: How do I call super or object.opAssign for classes?

[Diego Canuhé]

thanks, I was looking at this the wrong way


On Tue, Jul 26, 2011 at 9:54 AM, Steven Schveighoffer
wrote:

> On Tue, 26 Jul 2011 07:54:54 -0400, Diego Canuhé 
> wrote:
>
>  Hi,
>> isn't that the way it's supposed to work? I mean
>>
>> void show(int a) { writeln(a); }
>>
>> void main() { show(null); }
>>
>> won't compile either.
>> Shouldn't bar be some kind of pointer?
>>
>
> null should be considered as the type of the class, not void *.  You should
> not be able to override the behavior of opAssign as it pertains to assigning
> to a class instance.  In other words, you should *never* be able to override
> x = null where x is a class instance.
>
>
>
>> btw, today I read "opAssign can no longer be overloaded for class objects"
>> here:
>>
>> http://www.d-programming-**language.org/features2.html
>>
>> is that no longer valid?
>>
>
> Here is the spec.  I would not trust that features2, it's probably out of
> date.
>
> http://www.d-programming-**language.org/**operatoroverloading.html#**
> Assignment
>
> -Steve
>

Re: Importing D libraries

[Jacob Carlborg]

On 2011-07-28 09:17, Andrew Wiley wrote:

In traditional terms, cc1d is a compiler, including both the frontend
and the backend. It takes parameters and spits out assembly. That's it.
The GDC executable is the driver responsible for running cc1d to compile
the source to assembly, as to assemble the object files, and ld to link
it all into a binary. cc1d cannot pass options to the linker because it
does not invoke the linker.


Ok, I see. But it doesn't sound that hard to have cc1d pass pragma 
values back to the gdc executable. Anyway, thanks for the explanation.


--
/Jacob Carlborg

Re: Frontend and backend communication

[novice2]

Pelle Wrote:

> On Wed, 27 Jul 2011 19:41:37 +0200, Dainius (GreatEmerald)  
> You could use a struct of function pointers to define the interface, if

This is known approach in app, using plugin. For example, then open source FAR 
(File Archive Manager) exe load pluging dll, it fill strcuct with exe functions 
pointers, so plugin dll can use it

Re: Frontend and backend communication

[Steven Schveighoffer]

On Wed, 27 Jul 2011 13:41:37 -0400, Dainius (GreatEmerald)  
 wrote:



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.


Actually, an event loop is a good way to do it.  If your front end is a  
GUI, it's already likely running an event loop.  All you need to do is  
stick an event in the event queue.


I'd examine how to create custom events for your front end's probably  
already existing event loop.


-Steve

Re: Importing D libraries

[Nick Sabalausky]

"Andrew Wiley"  wrote in message 
news:mailman.1941.1311837499.14074.digitalmars-d-le...@puremagic.com...
> On Wed, Jul 27, 2011 at 11:46 PM, Jacob Carlborg  wrote:
>
>> On 2011-07-28 03:23, Andrew Wiley wrote:
>>
>>> On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg >> > wrote:
>>>
>>>Cannot be implemented in GDC. The driver/compiler/assembler/__**
>>> linker
>>>structure doesn't allow it.
>>>
>>>
>>>Why is that?
>>>
>>>
>>> Well, the short version is that GDC (the executable) is not a compiler.
>>> GDC is a driver that runs cc1d to compile your code, runs as (at least I
>>> think that's the name offhand) to assemble it, then runs ld to link it.
>>> As far as I know, there's no way for cc1d to communicate the contents of
>>> pragmas like this back to the driver, which it would have to do if you
>>> wanted the driver to include the library in the arguments to the linker.
>>> It's possible that I just don't know the infrastructure well enough, but
>>> I think this is one of the reasons the GCC guys refused to implement
>>> #pragma in C/C++ as well.
>>>
>>
>> I don't really get this. GDC is a D front end for the GCC back end. So 
>> the
>> the front end should handle all language specific things, like the 
>> pragma.
>> Then I assume the front end can pass options to the linker. Is this not 
>> the
>> case?
>
>
> In traditional terms, cc1d is a compiler, including both the frontend and
> the backend. It takes parameters and spits out assembly. That's it.
> The GDC executable is the driver responsible for running cc1d to compile 
> the
> source to assembly, as to assemble the object files, and ld to link it all
> into a binary. cc1d cannot pass options to the linker because it does not
> invoke the linker.
>

cc1d can't just write a "hey_gdc_pass_these_options_to_the_linker.txt" file?

Re: Frontend and backend communication

[Kai Meyer]

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

Re: Frontend and backend communication

[Kai Meyer]

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

Re: Frontend and backend communication

[Dainius (GreatEmerald)]

On Thu, Jul 28, 2011 at 10:37 PM, Kai Meyer  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.

Re: Frontend and backend communication

[Jacob Carlborg]

On 2011-07-28 21:55, Dainius (GreatEmerald) wrote:

On Thu, Jul 28, 2011 at 10:37 PM, Kai Meyer  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