digitalmars.D.announce - ATTN Derelict Users and Package Maintainers
- Mike Parker (28/28) Dec 30 2014 I've added a new feature to Derelict that I'd appreciate some feedback
- OlaOst (14/46) Dec 31 2014 Works fine for me on windows, after running 'dub upgrade'.
- Mike Parker (27/40) Dec 31 2014 Yes. I guess I wasn't clear about this in my blog post. This
- ponce (3/18) Dec 31 2014 I can see this being useful for DerelictENet since ENet can be
I've added a new feature to Derelict that I'd appreciate some feedback on. It works for me, but I want to verify that it works in the wild before I expand it to other packages and move forward with another feature I plan to add. You can read more about it in my blog post at [1]. If you are using DerelictSDL2 in a project, I'd appreciate it if you'd change your dependency to "derelict-sdl2": ">=1.9.0" and let me know if it breaks your build or not. And if you aren't using any of the functions added in SDL 2.0.2, then I'd also appreciate it if you'd test the new feature as described in the blog post: // If you require functions in 2.0.1 DerelictSDL2.load( SharedLibVersion( 2, 0, 1 )); // If you don't need any functions beyond 2.0.0 DerelictSDL2.load( SharedLibVersion( 2, 0, 0 )); The goal is to allow you to load any version of SDL that your app can support from one package. I've noticed that most people tend to use the highest version of DerelictSDL2 (1.2.x), which only loads SDL 2.0.2 and 2.0.3 and will fail with the lower versions, even though they aren't using any of the newer API additions. If you have a package you maintain that uses DerelictUtil for loading, you do not need to implement this yourself. It is entirely optional. Not all DerelictOrg packages will get this. However, if it makes sense in the context of the library you are loading, please consider implementing it and letting me know how it goes. Essentially, you'll need to change your dependency to "derelict-util":">=1.9.0" and override the new protected method configureMinimumVersion in your loader to install a library-specific MissingSymbolCallback. I've linked an example in the blog post. [1] http://dblog.aldacron.net/new-derelict-feature/
Dec 30 2014
Works fine for me on windows, after running 'dub upgrade'. I tested the SharedLibVersion with a 2.0.1 and a 2.0.3 SDL dll. With the 2.0.3 dll, I could call functions added in SDL 2.0.2 even when using SharedLibVersion(2, 0, 0) - is this intended behaviour? With the 2.0.1 DLL I got the expected 'Failed to load symbol' error without using the SharedLibVersion, or using SharedLibVersion(2, 0, 2). However, if I call one of the functions added in SDL 2.0.2 when loading the 2.0.1 context, I get an 'object.Error (0): Access violation' error. Would it be possible to get a more informative error message in this case? Highly appreciate your work on Derelict, BTW. On Wednesday, 31 December 2014 at 01:35:32 UTC, Mike Parker wrote:I've added a new feature to Derelict that I'd appreciate some feedback on. It works for me, but I want to verify that it works in the wild before I expand it to other packages and move forward with another feature I plan to add. You can read more about it in my blog post at [1]. If you are using DerelictSDL2 in a project, I'd appreciate it if you'd change your dependency to "derelict-sdl2": ">=1.9.0" and let me know if it breaks your build or not. And if you aren't using any of the functions added in SDL 2.0.2, then I'd also appreciate it if you'd test the new feature as described in the blog post: // If you require functions in 2.0.1 DerelictSDL2.load( SharedLibVersion( 2, 0, 1 )); // If you don't need any functions beyond 2.0.0 DerelictSDL2.load( SharedLibVersion( 2, 0, 0 )); The goal is to allow you to load any version of SDL that your app can support from one package. I've noticed that most people tend to use the highest version of DerelictSDL2 (1.2.x), which only loads SDL 2.0.2 and 2.0.3 and will fail with the lower versions, even though they aren't using any of the newer API additions. If you have a package you maintain that uses DerelictUtil for loading, you do not need to implement this yourself. It is entirely optional. Not all DerelictOrg packages will get this. However, if it makes sense in the context of the library you are loading, please consider implementing it and letting me know how it goes. Essentially, you'll need to change your dependency to "derelict-util":">=1.9.0" and override the new protected method configureMinimumVersion in your loader to install a library-specific MissingSymbolCallback. I've linked an example in the blog post. [1] http://dblog.aldacron.net/new-derelict-feature/
Dec 31 2014
On Wednesday, 31 December 2014 at 10:26:18 UTC, OlaOst wrote:Works fine for me on windows, after running 'dub upgrade'. I tested the SharedLibVersion with a 2.0.1 and a 2.0.3 SDL dll. With the 2.0.3 dll, I could call functions added in SDL 2.0.2 even when using SharedLibVersion(2, 0, 0) - is this intended behaviour?Yes. I guess I wasn't clear about this in my blog post. This isn't telling Derelict to "only load 2.0.0 functions and ignore the rest." It's instead saying, "Don't throw any exceptions if functions from 2.0.1 and 2.0.2 are missing." If you give it a 2.0.1 DLL, it will load 2.0.1 functions. Give it a 2.0.2 DLL and it will load 2.0.2 functions, regardless of what you pass in SharedLibVersion. But now you can happily load 2.0.0 and not worry about SymbolLoadExceptions. See below for the big caveat.With the 2.0.1 DLL I got the expected 'Failed to load symbol' error without using the SharedLibVersion, or using SharedLibVersion(2, 0, 2). However, if I call one of the functions added in SDL 2.0.2 when loading the 2.0.1 context, I get an 'object.Error (0): Access violation' error. Would it be possible to get a more informative error message in this case?That's not a Derelict error message. That's coming from the system. Keep in mind that Derelict binds to shared libraries via function pointers, so if any functions aren't loaded, the corresponding function pointers will be null and you'll get an Access Violation as a result. You should *only* use the SharedLibVersion to specify your minimum required version, not as a "give me whatever you've got" kind of thing like OpenGL. If you need 2.0.1 functions, but not 2.0.2, then you should be passing SharedLibVersion( 2,0,1 ), not 2,0,0. I also recommend that you get in the habit of always passing a SharedLibVersion to the load method so that you can future-proof your app. It will always load if you upgrade to take advantage of bug fixes, no matter which new API functions are added. If yo don't do this, then an update will cause it to stop loading older versions and only load the newest. In fact, I would love to remove the existing load methods completely, but I do need to maintain back compat.Highly appreciate your work on Derelict, BTW.Thanks! And thanks for trying out the new stuff.
Dec 31 2014
"ponce" <contact gam3sfrommars.fr> On Wednesday, 31 December 2014 at 11:20:09 UTC, Mike Parker wrote:On Wednesday, 31 December 2014 at 10:26:18 UTC, OlaOst wrote:I can see this being useful for DerelictENet since ENet can be often packaged with older versions in various distros.Works fine for me on windows, after running 'dub upgrade'. I tested the SharedLibVersion with a 2.0.1 and a 2.0.3 SDL dll. With the 2.0.3 dll, I could call functions added in SDL 2.0.2 even when using SharedLibVersion(2, 0, 0) - is this intended behaviour?Yes. I guess I wasn't clear about this in my blog post. This isn't telling Derelict to "only load 2.0.0 functions and ignore the rest." It's instead saying, "Don't throw any exceptions if functions from 2.0.1 and 2.0.2 are missing." If you give it a 2.0.1 DLL, it will load 2.0.1 functions. Give it a 2.0.2 DLL and it will load 2.0.2 functions, regardless of what you pass in SharedLibVersion. But now you can happily load 2.0.0 and not worry about SymbolLoadExceptions. See below for the big caveat.
Dec 31 2014