| View previous topic :: View next topic |
| Author |
Message |
Lutger
Joined: 25 May 2006
Posts: 91
|
 Posted: Wed Jun 21, 2006 12:57 pm Post subject: some minor issues |
 |
|
Yay I am at 'hello arc', codeblocks + arc + d == finally going to produce something! 
Probably a lot of issues are already fixed or will be, I see some recent activity in svn. Here are some things I encountered during setting arc up:
- when warnings are enabled, implicit casts (int to short or int to ubyte) cause dmd to refuse a compilation (mostly in gfxutil.d). Also, when using warnings and asserts, this is not legal:
bool someFunction()
{
assert(0); // Clayasaurus says not yet implemented
return false; // statement not reachable, dmd not happy
}
- the destructor of a Texture object causes an error (program exits with 1), it is the SDL_FreeSurface function. I had the same problem in my old Sprite class. I don't know why it does this, the sdl surface data is not garbage collected anyway.  Deleting a Texture object is fine however, it is only at program exit.
- the display surface is deleted by window.close, but this should not be done as SDL_Quit already takes care of it.
- the sdl.dll distributed with arc is 1.2.8 i think (newest is 1.2.10) and misses SDL_GetKeyRepeat, or maybe this is my fault?
btw, I'm happy to see some xml functions in there. Any plans to supports GLFW through versioning? |
|
| Back to top |
|
 |
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed Jun 21, 2006 5:46 pm Post subject: Re: some minor issues |
|
|
First, don't use the SVN. Use the zip for the stable releases, because a lot of things are broken in the SVN as the SVN is the development branch.
| Lutger wrote: | Yay I am at 'hello arc', codeblocks + arc + d == finally going to produce something!
Probably a lot of issues are already fixed or will be, I see some recent activity in svn. Here are some things I encountered during setting arc up:
- when warnings are enabled, implicit casts (int to short or int to ubyte) cause dmd to refuse a compilation (mostly in gfxutil.d). Also, when using warnings and asserts, this is not legal:
bool someFunction()
{
assert(0); // Clayasaurus says not yet implemented
return false; // statement not reachable, dmd not happy
}
|
Arg, I don't like DMD's warnings because they force themselves as errors, so I just havn't been compiling Arc with them. The warnings catch some things, but they also turn 'non-issues' into issues.
Hrm.. I guess I should try to get rid of all the warnings, but I'm not promising anything.
| Quote: |
- the destructor of a Texture object causes an error (program exits with 1), it is the SDL_FreeSurface function. I had the same problem in my old Sprite class. I don't know why it does this, the sdl surface data is not garbage collected anyway. Deleting a Texture object is fine however, it is only at program exit.
|
I'll remove this then. The next version of Arc will use DevIL anyways and will do away with SDL_Surfaces. Someday I hope to use a D native version of GLFW.
| Quote: |
- the display surface is deleted by window.close, but this should not be done as SDL_Quit already takes care of it.
|
Alright, I'll remove this then in the stable version.
| Quote: |
- the sdl.dll distributed with arc is 1.2.8 i think (newest is 1.2.10) and misses SDL_GetKeyRepeat, or maybe this is my fault?
|
It's because you are using a new SDL.dll when the version of derelict is the old SDL.dll. I've recently updated to the new derelict and will make the new changes for the stable release soon.
| Quote: |
btw, I'm happy to see some xml functions in there. Any plans to supports GLFW through versioning? |
I actually havn't tested the XML functions, but JoeCoder allowed me to borrow what I want from his YAGE engine.
About GLFW, if there is ever a D native version of it I would use it instead of SDL, but I would never introduce versioning to use both unless it way in very heavy demand by Arc users. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Wed Jun 21, 2006 8:54 pm Post subject: |
|
|
| Hey, I fixed your problems (except for the warnings). Re-download the arcpkg1.zip and give it a try. |
|
| Back to top |
|
|
Lutger
Joined: 25 May 2006
Posts: 91
|
| Posted: Thu Jun 22, 2006 4:37 am Post subject: |
|
|
Ah great! I'll use the zip then. Just want to mention these are still in the zip:
in particle.d:
line 108 - gColorList should be argColors
line 115 - gFullPath should be argFileName
in xmlstream.d:
line 7 and 8 - import core.xmld.* should be import arc.tools.xml.*
Nothing big, I can fix this for myself, you may want to fix it.
What is your problem with the current GLFW binding in derelict?
I'll stop annoying you now and make something. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Thu Jun 22, 2006 10:27 am Post subject: |
|
|
Thanks, I've made those changes now.
I'll think about just changing to DerelictGLFW instead of waiting for a native D version. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Thu Jun 22, 2006 12:34 pm Post subject: Re: some minor issues |
|
|
| Lutger wrote: | | - the destructor of a Texture object causes an error (program exits with 1), it is the SDL_FreeSurface function. I had the same problem in my old Sprite class. I don't know why it does this, the sdl surface data is not garbage collected anyway. Deleting a Texture object is fine however, it is only at program exit. |
Until recently, Derelict unloaded shared libraries automatically in module destructors so that the user need not call an unload method manually. Destructors are called by D's garbage collector when the app exits. If you look in the DMD directory tree at the file src/phobos/internal/dmain2.d, you can see that the module destructors are called before the GC is terminated.
So what is happening in this case is that the SDL DLL is being unloaded by the derelict.sdl.sdl module destructor, then after that, as the GC is cleaning up, the destructors for the Texture objects are being called. Since the SDL DLL is no longer in memory, the function pointer for SDL_FreeSurface is no longer valid. Hence the error.
Even though Derelict uses static object destructors now rather than module destructors, you'll likely still get the same error. I'm fairly certain that static object ctors/dtors are called from the _moduleCtor(), _moduleDtor() functions (which are called during bootstrap). So that means they will still be called before the gc terminates and calls the destructors of live objects.
Really, though, I think object destructors are a bad place to release system resources like that. There is no guarantee that a destructor will ever be called during the lifetime of the application (unless the object is auto), even if you call delete on the object yourself. That means that you could have unused objects hanging around, holding on to system resources while they are waiting to be GCed. It might be a better idea for arc to provide some sort of clean up method that can be called manually on an object that is no longer needed so that system resources can be freed on demand. |
|
| Back to top |
|
|
Lutger
Joined: 25 May 2006
Posts: 91
|
| Posted: Thu Jun 22, 2006 5:19 pm Post subject: Re: some minor issues |
|
|
| aldacron wrote: | (...)
Really, though, I think object destructors are a bad place to release system resources like that. There is no guarantee that a destructor will ever be called during the lifetime of the application (unless the object is auto), even if you call delete on the object yourself. That means that you could have unused objects hanging around, holding on to system resources while they are waiting to be GCed. It might be a better idea for arc to provide some sort of clean up method that can be called manually on an object that is no longer needed so that system resources can be freed on demand. |
Ah I finally get it, this is where I still have problems with in D as I'm so used to C++. Then I wonder what the use of destructors is really, if not releasing resources owned by an object. Auto classes won't work either here i think. I hope this situation will improve, as this means you will have to resort to manually releasing resources, a situation worse than C++ where you at least can have proper RAII  |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Thu Jun 22, 2006 7:08 pm Post subject: Re: some minor issues |
|
|
| Lutger wrote: | | Ah I finally get it, this is where I still have problems with in D as I'm so used to C++. Then I wonder what the use of destructors is really, if not releasing resources owned by an object. Auto classes won't work either here i think. I hope this situation will improve, as this means you will have to resort to manually releasing resources, a situation worse than C++ where you at least can have proper RAII |
Notice that I said "system" resources. The problem is that there's no way to guarantee an object will be garbage collected on any given collection cycle. You can have RAII with auto objects, but those are only useful in a limited scope and aren't going to work globally.
There's nothing wrong with releasing most resources in a destructor, such as other objects, but you can run into trouble with system resources. By that I mean file handles, memory allocated outside the GC, anything that you bring in directly from the OS or a third party C library (or even a D DLL with its own GC). These are things which you generally need to control the order of release. You can't free an OpenGL texture if the OpenGL context has been destroyed. You can't call any DLL method through Derelict if the DLL has been unloaded.
Garbage collection is a great feature that eases the burden of memory management, but does not eliminate it completely. One of the tradeoffs is that you cannot have reliable destruction of objects. Java has no destructors specifically for this reason. I've always felt that D shouldn't have them either, as they are only reliable when auto is used. There would be much less confusion if they would just disappear.
What I do now is just provide init() and term() methods for nearly every class I write. I generally avoid the use of constructors and destructors. I'm so used to doing that in C++ and Java already that it's second nature to me. This way I have complete control of when external resources are released and the GC can still handle internal memory as it wants. |
|
| 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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
