View previous topic :: View next topic |
Author |
Message |
doob
Joined: 06 Jan 2007 Posts: 367
|
Posted: Mon Sep 22, 2008 7:58 am Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Mon Sep 22, 2008 8:54 pm Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
hugues
Joined: 09 Aug 2007 Posts: 20 Location: Brussels, Belgium
|
Posted: Tue Sep 23, 2008 1:17 pm Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
doob
Joined: 06 Jan 2007 Posts: 367
|
Posted: Wed Sep 24, 2008 3:49 am Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Wed Sep 24, 2008 9:45 pm Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Wed Sep 24, 2008 9:48 pm Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
hugues
Joined: 09 Aug 2007 Posts: 20 Location: Brussels, Belgium
|
Posted: Thu Sep 25, 2008 2:26 pm Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
hugues
Joined: 09 Aug 2007 Posts: 20 Location: Brussels, Belgium
|
Posted: Thu Sep 25, 2008 2:51 pm Post subject: Re: Objective-C in D? |
|
|
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 . _________________ Hugues De Keyzer |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Sep 25, 2008 9:19 pm Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
hugues
Joined: 09 Aug 2007 Posts: 20 Location: Brussels, Belgium
|
Posted: Sat Sep 27, 2008 11:17 am Post subject: Re: Objective-C in D? |
|
|
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 |
|
|
doob
Joined: 06 Jan 2007 Posts: 367
|
Posted: Thu Oct 02, 2008 9:11 am Post subject: |
|
|
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 |
|
|
doob
Joined: 06 Jan 2007 Posts: 367
|
Posted: Thu Oct 02, 2008 4:19 pm Post subject: |
|
|
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 |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Fri Oct 03, 2008 5:31 am Post subject: |
|
|
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 |
|
|
hugues
Joined: 09 Aug 2007 Posts: 20 Location: Brussels, Belgium
|
Posted: Fri Oct 03, 2008 2:14 pm Post subject: |
|
|
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 |
|
|
hugues
Joined: 09 Aug 2007 Posts: 20 Location: Brussels, Belgium
|
Posted: Fri Oct 03, 2008 2:31 pm Post subject: |
|
|
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 |
|
|
|
|
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
|