Devisualization and DWC
Right, time for a new announcement from me. First off the library I have been talking about called DWC has been renamed. It is now Under the banner of Devisualization, window[0] project. Devisualization.window otherwise known as de_window is a window and context creation for Windows, Linux and Mac OSX. It does need a good bit of testing especially on Linux. In short, the goal of Devisualization Github organization is to promote game development and the libraries to facilitate it in D. Projects I want made: - Events/controls abstraction + GUI controls - Native GUI controls (such as the menu for OSX) - Virtual File System - OpenGL wrappers and tooling - Image loading/exporting (currently working on png) - 3d model loading/exporting (.3ds .obj at the minimum) - Scenegraph - Audio loading/exporting - Unity like interface - Scripting - Entity modeling Not in any particular order and can very easily be added to. I'm sure there is a lot of code already available that can do some of these things, but to make it all work together nicely would be a challenge. I did write up on my blog about all this [1], but you don't need to read it. It just goes into a bit more depth. About Cmsed and my web dev stuff, I haven't stopped working on it per-say. I'm waiting on e.g. [2]. [0] https://github.com/Devisualization/window [1] http://blog.alphaglosined.tk/2014/11/window-creation-d-initiative.html [2] https://github.com/D-Programming-Language/dmd/pull/3921
Re: Devisualization and DWC
Nice work, it's basically the SDL replacement I wished for! I like that its scope is well defined. I don't get why it depends on DerelictGL. AFAIK SDL, GLFW and friends do not depend on GL function loaders.
Re: Devisualization and DWC
On Friday, 7 November 2014 at 10:48:46 UTC, Rikki Cattermole wrote: - Native GUI controls (such as the menu for OSX) D native or OS native?
Re: Devisualization and DWC
On 8/11/2014 12:46 a.m., ponce wrote: Nice work, it's basically the SDL replacement I wished for! I like that its scope is well defined. I don't get why it depends on DerelictGL. AFAIK SDL, GLFW and friends do not depend on GL function loaders. It depends because of OpenGL context creation. And it requires a reload to work properly when activating. Might be better as an optional dependency.
Re: Devisualization and DWC
On 8/11/2014 12:48 a.m., Kagamin wrote: On Friday, 7 November 2014 at 10:48:46 UTC, Rikki Cattermole wrote: - Native GUI controls (such as the menu for OSX) D native or OS native? Short answer: Basically it should use the native implementation if possible otherwise it should use the non native version. Long answer: I'll use the example of OSX with the menu. OSX has a specialized menu as part of its UI which all applications are meant to use. On this case it should use this. But on a platform such as Windows, if there is no context it can freely use the native menu system. But if it has a context it should emulate it via e.g. OpenGL like it wasn't native. Then of course is X11 which case it would be OpenGL as their is no native version of it.
Re: D/Objective-C 64bit
Also when I tried to declare / use extern strings like from NSApplication.h: APPKIT_EXTERN NSString *NSApplicationDidHideNotification; I found no way to get this working. Is this a limitation of the current 64 bit port? I think that should work. How did you declare it? It should be declared like this: extern (C) extern NSString NSApplicationDidHideNotification; I tried with a standard D compiler and void* instead of NSString and that worked. extern (C) tells the compiler to use C linkage, the second extern tells the compiler this symbols is defined somewhere else, i.e. in some library. Jacob, thank you very much for your reply and explanations! I get EXC_BAD_ACCESS (SIGSEGV) for both NSString and void * if I use the declaration you suggested. In the case for notification string constants, when I log it in Objective-C, it just equals to NSApplicationDidHideNotification, so these could be simply redeclared for such strings, but that's not very stylish and against the basic idea, i guess.
Re: D/Objective-C 64bit
On 2014-11-07 13:12, Christian Schneider wrote: Jacob, thank you very much for your reply and explanations! I get EXC_BAD_ACCESS (SIGSEGV) for both NSString and void * if I use the declaration you suggested. What exactly are you doing with the string when you get the EXC_BAD_ACCESS? Also, can you reproduce the issue in an program just printing this variable with NSLog? In the case for notification string constants, when I log it in Objective-C, it just equals to NSApplicationDidHideNotification, so these could be simply redeclared for such strings, but that's not very stylish and against the basic idea, i guess. Yeah, that's not pretty, it should work like in Objective-C. -- /Jacob Carlborg
Re: D/Objective-C 64bit
I get EXC_BAD_ACCESS (SIGSEGV) for both NSString and void * if I use the declaration you suggested. What exactly are you doing with the string when you get the EXC_BAD_ACCESS? Also, can you reproduce the issue in an program just printing this variable with NSLog? I get the SIGSEGV when i try to NSLog this string constant. I was not looking any further, because if it fails to NSLog, i can't do anything with it ;)
Re: D/Objective-C 64bit
On 2014-11-07 15:23, Christian Schneider wrote: I get the SIGSEGV when i try to NSLog this string constant. I was not looking any further, because if it fails to NSLog, i can't do anything with it ;) Now I know what the problem is. In D, module variables are by default in TLS (thread local storage). To make it refer to a global C variable, use __gshared: extern (C) extern __gshared NSString NSApplicationDidHideNotification; Sorry, I completely forgot about that. -- /Jacob Carlborg
Re: D/Objective-C 64bit
Now I know what the problem is. In D, module variables are by default in TLS (thread local storage). To make it refer to a global C variable, use __gshared: extern (C) extern __gshared NSString NSApplicationDidHideNotification; Sorry, I completely forgot about that. Ha, awesome! It works! I'll add this to a wiki page in the DiveFramework github repos. Thanks again! Oh, and btw, I was briefly looking into the DMD source for trying to fix myself the issue with the protocol to class instance cast (trying to be useful), but I am seriously completely not hardcore enough of digging anything in there, lol. Anyhow, if you got a hint, let me know. It's not just in the example discussed in my other posts, I found it to be an issue in other places as well, as often framework classes return id / ObjcObject instead of a further typed instance. I don't remember where exactly I had a problem, but I remember I used NSObject instead of ObjcObject in these places, which of course is not the way to go. Have a nice weekend!
Re: D/Objective-C 64bit
On 2014-11-07 17:05, Christian Schneider wrote: Ha, awesome! It works! I'll add this to a wiki page in the DiveFramework github repos. Thanks again! No problem :). This isn't mention in the DIP since this has nothing to do with Objective-C, it's rather plain C. This is documented here [1]. Oh, and btw, I was briefly looking into the DMD source for trying to fix myself the issue with the protocol to class instance cast (trying to be useful), but I am seriously completely not hardcore enough of digging anything in there, lol. I had no idea what I was doing when I started with this :) Anyhow, if you got a hint, let me know. It's not just in the example discussed in my other posts, I found it to be an issue in other places as well, as often framework classes return id / ObjcObject instead of a further typed instance. I don't remember where exactly I had a problem, but I remember I used NSObject instead of ObjcObject in these places, which of course is not the way to go. I guess you have to live using NSObject for now, until I fixed that. But in practice NSObject is the only root class. So far I've seen one other class, NSProxy, that doesn't inherit from NSObject. Ok, I had a quick look at this issue. It is implemented but it's not working. There is a test but that's only casting from a class to an interface, not the other way around. Either there's an issue in the druntime function _dobjc_interface_cast or in the compiler (most likely in the compiler). It looks like the casting is implemented here [2], or at least parts of it. [1] http://dlang.org/interfaceToC.html [2] https://github.com/jacob-carlborg/dmd/blob/d-objc/src/e2ir.c#L3843-L3854 -- /Jacob Carlborg
FoundationDB D API
I've recently decided to open source FoundationDB D API from our internal project. It's released under MIT license since that's the simplest option I could think of. https://github.com/GeorgeSapkin/fdb-d It has been ripped out of a working project so it's missing unit testing and sample usage for now. It's based on FoundationDB Node.js API[1] and you have to be familiar with FoundationDB in general to use it. Certain features (parts of Tuple layer) that we don't use have not been implemented yet. This has only been used/tested on Fedora 20/21 x64 and Ubuntu 14.04 x64. For more information about FoundationDB check out it's official website: https://foundationdb.com/ Comments, suggestions, contributions are all welcome ;) [1] https://foundationdb.com/key-value-store/documentation/api-node.html
