FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Derelict on Mac OS X - another solution
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
doob



Joined: 06 Jan 2007
Posts: 367

PostPosted: Mon Sep 22, 2008 7:58 am    Post subject: Re: Objective-C in D? Reply with quote

hugues wrote:
Your code should be included in DerelictSDL.load(). To load the Cocoa framework and get function pointers, you should do something like this:
Code:
import derelict.util.loader;

SharedLib cocoa = Derelict_LoadSharedLib("Cocoa.framework/Cocoa");
char* function(char*) sel_registerName = cast(char* function(char*)) Derelict_GetProc(cocoa, "sel_registerName");

Hope this helps. If you need more info, don't hesitate to ask.

Hugues De Keyzer


If I understand the derelict code correctly then DerelictSDL.load is actually derelict.util.loader.GenericLoader.load and it doesn't seem right to place the code there. Isn't derelict.sdl.sdl.load a better place to have the code in?

Can I create a new module like: derelict.sdl.cocoa or derelict.sdl.internal.cocoa where all the bindings are?

I guess I can't use this code to load cocoa? It will then require minimal changes on my existing bindings:
Code:
pragma(link,"--framework,Cocoa");

It will require DSSS 0.78

Is there a code style that I should follow?
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Mon Sep 22, 2008 8:54 pm    Post subject: Re: Objective-C in D? Reply with quote

doob wrote:
hugues wrote:
Your code should be included in DerelictSDL.load(). To load the Cocoa framework and get function pointers, you should do something like this:
Code:
import derelict.util.loader;

SharedLib cocoa = Derelict_LoadSharedLib("Cocoa.framework/Cocoa");
char* function(char*) sel_registerName = cast(char* function(char*)) Derelict_GetProc(cocoa, "sel_registerName");

Hope this helps. If you need more info, don't hesitate to ask.

Hugues De Keyzer


If I understand the derelict code correctly then DerelictSDL.load is actually derelict.util.loader.GenericLoader.load and it doesn't seem right to place the code there. Isn't derelict.sdl.sdl.load a better place to have the code in?


Technically, DerelictSDL.load is a delegate that points to the load function in the SDL module. So yes, you are correct. That's the correct place to put it.

Quote:

Can I create a new module like: derelict.sdl.cocoa or derelict.sdl.internal.cocoa where all the bindings are?


derelict.sdl.cocoa is probably a good idea, though I'd rather call it sdl.macinit or some such so that people aren't tempted to import it thinking it gives them access to Cocoa.. I suggest that you only prototype and typedef the things you need, but keep them in a private block so that people who unwittingly import the module don't pollute the name space. The function that handles loading Cocoa and handling initialization should have package protection, then it can be called at the end of the sdl.load function (with version(Darwin)). Also, the entire cocoa module should be wrapped in a version(Darwin) block.

That's how I'd do it, anyway.

Quote:

I guess I can't use this code to load cocoa? It will then require minimal changes on my existing bindings:
Code:
pragma(link,"--framework,Cocoa");

It will require DSSS 0.78


I would avoid that, because it introduces an extra dependency on Mac. Just dynamically load the bits you need.

Quote:
Is there a code style that I should follow?


Just try to generally follow the form of what's already there. If you deviate a little, it doesn't really matter. Anything extreme I'll reformat, but it's not such a big deal.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Tue Sep 23, 2008 1:17 pm    Post subject: Re: Objective-C in D? Reply with quote

hugues wrote:
To load the Cocoa framework and get function pointers, you should do something like this:
Code:
import derelict.util.loader;

SharedLib cocoa = Derelict_LoadSharedLib("Cocoa.framework/Cocoa");
char* function(char*) sel_registerName = cast(char* function(char*)) Derelict_GetProc(cocoa, "sel_registerName");

Actually, as SDL is linked to Cocoa, we can directly use the SDL SharedLib handle to get the function pointers. I think it's cleaner and it avoids an unnecessary dynamic load and handle management.
Back to top
View user's profile Send private message
doob



Joined: 06 Jan 2007
Posts: 367

PostPosted: Wed Sep 24, 2008 3:49 am    Post subject: Re: Objective-C in D? Reply with quote

hugues wrote:
hugues wrote:
To load the Cocoa framework and get function pointers, you should do something like this:
Code:
import derelict.util.loader;

SharedLib cocoa = Derelict_LoadSharedLib("Cocoa.framework/Cocoa");
char* function(char*) sel_registerName = cast(char* function(char*)) Derelict_GetProc(cocoa, "sel_registerName");

Actually, as SDL is linked to Cocoa, we can directly use the SDL SharedLib handle to get the function pointers. I think it's cleaner and it avoids an unnecessary dynamic load and handle management.


If SDL is already linked to Cocoa can't I use regular function declarations like this:
Code:
extern (C) char* registerName(char*);

Or do I still have to use "Derelict_GetProc", in that case where can I access the SDL SharedLib handle?
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Wed Sep 24, 2008 9:45 pm    Post subject: Re: Objective-C in D? Reply with quote

hugues wrote:
hugues wrote:
To load the Cocoa framework and get function pointers, you should do something like this:
Code:
import derelict.util.loader;

SharedLib cocoa = Derelict_LoadSharedLib("Cocoa.framework/Cocoa");
char* function(char*) sel_registerName = cast(char* function(char*)) Derelict_GetProc(cocoa, "sel_registerName");

Actually, as SDL is linked to Cocoa, we can directly use the SDL SharedLib handle to get the function pointers. I think it's cleaner and it avoids an unnecessary dynamic load and handle management.


This doesn't make sense to me. Even though SDL links to Cocoa, you still need to get your own handle to the Cocoa framework. It will actually be loaded only once, no matter how many times you call dlopen or whatever. AFIAK, it's not possible to access one library's symbols through another library's handle.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Wed Sep 24, 2008 9:48 pm    Post subject: Re: Objective-C in D? Reply with quote

doob wrote:
Or do I still have to use "Derelict_GetProc", in that case where can I access the SDL SharedLib handle?


This isn't going to work. You need a handle to the Cocoa framework.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Thu Sep 25, 2008 2:26 pm    Post subject: Re: Objective-C in D? Reply with quote

aldacron wrote:
hugues wrote:
Actually, as SDL is linked to Cocoa, we can directly use the SDL SharedLib handle to get the function pointers. I think it's cleaner and it avoids an unnecessary dynamic load and handle management.


This doesn't make sense to me. Even though SDL links to Cocoa, you still need to get your own handle to the Cocoa framework. It will actually be loaded only once, no matter how many times you call dlopen or whatever. AFIAK, it's not possible to access one library's symbols through another library's handle.

Conceptually, we don’t need Cocoa. We need it because we have to implement a “missing” part of SDL. When loading SDL, we already load Cocoa, why should we try to load it a second time? Using the SDL handle to get the Cocoa symbols works fine. Actually, when using Cocoa, this is the kind of thing that is already done: the Cocoa lib itself doesn’t contain any (useful) symbol, it it just a “wrapper” library around AppKit and CoreData, and AppKit is linked to all other core libraries like Foundation.
_________________
Hugues De Keyzer
Back to top
View user's profile Send private message
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Thu Sep 25, 2008 2:51 pm    Post subject: Re: Objective-C in D? Reply with quote

doob wrote:
If SDL is already linked to Cocoa can't I use regular function declarations like this:
Code:
extern (C) char* registerName(char*);

Or do I still have to use "Derelict_GetProc", in that case where can I access the SDL SharedLib handle?

Because all the libs Derelict uses are dynamically loaded, we have to get all the symbols from them after loading. Declaring a function like this would prevent your program to link, unless you (hard-)link it to the lib that defines the function (what you don’t want).

To follow Derelict’s way, you will need to first create typedefs of functions pointers to all the functions that you will use, then declare those function pointers, then create a function that gets all the symbols with bindFunc(). For example, for SDL_Init (in sdl/sdl.d):
Code:
extern (C)
{
    typedef int function(Uint32) pfSDL_Init;

    pfSDL_Init SDL_Init;
}

private void load(SharedLib lib)
{
    bindFunc(SDL_Init)("SDL_Init", lib);
}
You will of course also need to declare all the types you will need.

Good luck Wink.
_________________
Hugues De Keyzer
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Thu Sep 25, 2008 9:19 pm    Post subject: Re: Objective-C in D? Reply with quote

hugues wrote:
When loading SDL, we already load Cocoa, why should we try to load it a second time?


Well, my point was that you actually don't load it a second time. No matter how many calls you make to dlopen (or whatever the other option is for frameworks on Mac) the library is actually only loaded once.

Quote:
Using the SDL handle to get the Cocoa symbols works fine. Actually, when using Cocoa, this is the kind of thing that is already done: the Cocoa lib itself doesn’t contain any (useful) symbol, it it just a “wrapper” library around AppKit and CoreData, and AppKit is linked to all other core libraries like Foundation.


Interesting. Is this unique to Mac frameworks? I wouldn't expect this to work with shared objects across the different Unices via dlopen.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Sat Sep 27, 2008 11:17 am    Post subject: Re: Objective-C in D? Reply with quote

aldacron wrote:
hugues wrote:
When loading SDL, we already load Cocoa, why should we try to load it a second time?

Well, my point was that you actually don't load it a second time. No matter how many calls you make to dlopen (or whatever the other option is for frameworks on Mac) the library is actually only loaded once.

Yes, that is right and I had understood it, it is like the OpenGL framework that is also loaded for the GLU symbols on the Mac.
Quote:
Quote:
Using the SDL handle to get the Cocoa symbols works fine. Actually, when using Cocoa, this is the kind of thing that is already done: the Cocoa lib itself doesn’t contain any (useful) symbol, it it just a “wrapper” library around AppKit and CoreData, and AppKit is linked to all other core libraries like Foundation.

Interesting. Is this unique to Mac frameworks? I wouldn't expect this to work with shared objects across the different Unices via dlopen.

I tried it on GNU/Linux and it also works. It think it is standard, but I don’t know if it is considered “good practice”. My idea was for simplicity, to avoid loading (not re-loading, but still calling dlopen() to get the handle) with the right filename, remember to call dlclose() on the handle, etc.
_________________
Hugues De Keyzer
Back to top
View user's profile Send private message
doob



Joined: 06 Jan 2007
Posts: 367

PostPosted: Thu Oct 02, 2008 9:11 am    Post subject: Reply with quote

In SDLmain.m there are these lines:
Code:
/* Use this flag to determine whether we use SDLMain.nib or not */
#define      SDL_USE_NIB_FILE   0

/* Use this flag to determine whether we use CPS (docking) or not */
#define      SDL_USE_CPS      1


Should those be ported to:
Code:
/* Use this flag to determine whether we use SDLMain.nib or not */
bool      SDL_USE_NIB_FILE = false

/* Use this flag to determine whether we use CPS (docking) or not */
bool      SDL_USE_CPS   =   true

and used with "static if" or should those be versions used with version statements?
Back to top
View user's profile Send private message
doob



Joined: 06 Jan 2007
Posts: 367

PostPosted: Thu Oct 02, 2008 4:19 pm    Post subject: Reply with quote

I have ported everything now but there are some functions missing like:
SDL_main, SDL_malloc, SDL_free and so on. I replaced SDL_malloc and others with the corresponding functions from std but I don't know what to do about SDL_main and I don't know what to do about "main" that is also present in SDLmain.m
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Fri Oct 03, 2008 5:31 am    Post subject: Reply with quote

doob wrote:
I have ported everything now but there are some functions missing like:
SDL_main, SDL_malloc, SDL_free and so on. I replaced SDL_malloc and others with the corresponding functions from std but I don't know what to do about SDL_main and I don't know what to do about "main" that is also present in SDLmain.m


The whole purpose of this port is to work around the dependency on SDL's hijacking of the main method -- so you do nothing with main or SDL_main. Just make sure that everything that is handled by the main method, with the exception of the call to SDL_main, is handled instead during the call to DerelictSDL.load.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Fri Oct 03, 2008 2:14 pm    Post subject: Reply with quote

doob wrote:
In SDLmain.m there are these lines:
Code:
/* Use this flag to determine whether we use SDLMain.nib or not */
#define      SDL_USE_NIB_FILE   0

/* Use this flag to determine whether we use CPS (docking) or not */
#define      SDL_USE_CPS      1


Should those be ported to:
Code:
/* Use this flag to determine whether we use SDLMain.nib or not */
bool      SDL_USE_NIB_FILE = false

/* Use this flag to determine whether we use CPS (docking) or not */
bool      SDL_USE_CPS   =   true

and used with "static if" or should those be versions used with version statements?
Probably versions should be better here, I think.
_________________
Hugues De Keyzer
Back to top
View user's profile Send private message
hugues



Joined: 09 Aug 2007
Posts: 20
Location: Brussels, Belgium

PostPosted: Fri Oct 03, 2008 2:31 pm    Post subject: Reply with quote

doob wrote:
I have ported everything now but there are some functions missing like:
SDL_main, SDL_malloc, SDL_free and so on. I replaced SDL_malloc and others with the corresponding functions from std but I don't know what to do about SDL_main and I don't know what to do about "main" that is also present in SDLmain.m
Already done? That's great! Did you have problems with the class inheritance?

You guessed it right, SDL_malloc() and SDL_free() are just defines to malloc() and free(), so you can easily replace them. About SDL_main(), see below.

aldacron wrote:
The whole purpose of this port is to work around the dependency on SDL's hijacking of the main method -- so you do nothing with main or SDL_main. Just make sure that everything that is handled by the main method, with the exception of the call to SDL_main, is handled instead during the call to DerelictSDL.load.
The way to do this is explained in this post. Normally, SDL redefines main() as SDL_main() (with a simple #define in SDL.h) and provides a new main() function. It then calls user's main() (then called SDL_main()) in applicationDidFinishLaunching. The workaround is to call [NSApp stop:nil] instead of SDL_main(), so the [NSApp run] call returns and the app is correctly initialized.

Great work, I'm looking forward to testing it!
_________________
Hugues De Keyzer
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict All times are GMT - 6 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 3 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group