Re: D/Objective-C 64bit
On 11 Mar 2014 23:25, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-11 22:43:58 +, John Colvin john.loughran.col...@gmail.com said: To what extent will this be portable to ldc/gdc? The codegen elements in objc.c will need to be changed to bind to the LLVM/GCC backend. Shouldn't be too hard, I guess. [1]: https://github.com/jacob-carlborg/dmd/blob/d-objc/src/objc.c Oh no, not more work...
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 21:48:45 UTC, Asman01 wrote: It's really awesome. Congratulations! If this DIP is actually approved will dmd have native integration/support to Objective-C language just like we can do with C? I'm not a Obj-C programmer but I like the idea. Yes. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 23:20:23 UTC, Michel Fortin wrote: The codegen elements in objc.c will need to be changed to bind to the LLVM/GCC backend. Shouldn't be too hard, I guess. Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Wednesday, 12 March 2014 at 01:09:25 UTC, Walter Bright wrote: I'm glad to see this is building on the great groundwork you've already done. Yes, absolutely. Michel has done most of the work, forgot to mention that. I'm just polishing now. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 22:13:07 UTC, Paolo Invernizzi wrote: Thanks Jacob, great work! If someone is trying it like me, I don't know the proper way for doing that, but the compiler must be built with the DMD_OBJC define turned on. Yes, D_OBJC. You need the corresponding changes for druntime [1] as well. It seems I haven't pushed the changes for 64bit, I'll do that tonight. [1] https://github.com/jacob-carlborg/druntime/tree/d-objc -- /Jacob Carlborg
Re: D/Objective-C 64bit
On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. -- /Jacob Carlborg
Re: D/Objective-C 64bit
This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool. How do you plan to handle automatic reference counting? I imagine that's a hard part. When I was writing Objective C I remember having to write bridged casts so I could manually extend or limit object lifetime, but I never handled it from within a C library.
Re: D/Objective-C 64bit
On 3/11/14, Jacob Carlborg d...@me.com wrote: I just wanted to let everyone know that I have implemented D/Objective-C for 64bit. Excellent! One thing that's hard to implement right now in D is drag drop support on OSX, at least when I tried to do it. The problem is I need to call ObjC functions or provide ObjC callbacks, so I end up having to create a C layer, compile that, and then link that to D. Actual support for interfacing with Objective C would be great. Thanks for all the work to both you and Michel Fortin.
Re: D/Objective-C 64bit
On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote: On Tuesday, 11 March 2014 at 23:20:23 UTC, Michel Fortin wrote: The codegen elements in objc.c will need to be changed to bind to the LLVM/GCC backend. Shouldn't be too hard, I guess. Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI Each combination being incompatible with each other subtly different ways...
Re: D/Objective-C 64bit
On 2014-03-12 08:06:47 +, w0rp devw...@gmail.com said: This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool. How do you plan to handle automatic reference counting? I imagine that's a hard part. When I was writing Objective C I remember having to write bridged casts so I could manually extend or limit object lifetime, but I never handled it from within a C library. Well, there's three ways. (a) The first one is to implement ARC for Objective-C objects, and to automatically add/remove roots to member variables when constructing/destroying Objective-C objects that were defined in D so the GC can those pointers. (b) The second one is to not implement ARC and implement something in the GC so it can track Objective-C objects: retain them on first sight, release them once no longer connected to a root. (c) The third one is to implement ARC as an alternative memory management scheme for D and bolt Objective-C object support on top of it. I'd tend to go for (a) at first, as it's the simplest thing that can be done. But I fear always adding/removing roots will impact performance in a negative way. There's also the issue in (a) and (b) that if the last reference to an object is released from the GC thread the Objective-C object's destructor will be called in a different thread than what is expected which might cause some bugs. So we might want to implement (c) later on to have something more solid and deterministic. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said: On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one? Also, is there a list of differences between the two runtimes somewhere? Each combination being incompatible with each other subtly different ways... Which is why we have a test suite. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote: I just wanted to let everyone know that I have implemented D/Objective-C for 64bit. Everything that worked for 32bit should work, except for exceptions, which are not implemented yet. Objective-C on 64bit uses the modern runtime, which is also the same used on iOS. This means D/Objective-C should now be compatible with iOS as well, at least in theory. For those how don't know what D/Objective-C is. It is a language extension to D making it ABI compatible with Objective-C. This means it's possible to use Objective-C classes, methods, protocols (interfaces) and so on, directly just as it's currently possible to do with regular C functions. Here's a recap of what's implemented, both for 32 and 64bit unless otherwise noticed: * Classes * Subclasses * Instance and class methods * Protocols (interfaces) * Properties * Exceptions (only 32bit) * Selectors * Class references * String literals * Casts Some improvements that are really not part of Objective-C but are very convenient to have in D : * Constructors * Inheriting selectors * Automatically generated selectors On the other hand, here a list of what's not implemented yet: * Blocks (similar to delegates) * Categories (class extensions) * Any form of automatic memory management * Exceptions (64bit) * Vtable optimization (64bit) Objective-C exceptions on 64bit is implemented using the same mechanism as C++. I'm wondering if it would be possible for D (not just for this extension) to adapt this mechanism as well. This would make D compatible with both C++ and Objective-C exceptions on 64bit. A DIP is available here [1] and the latest implementation is available here [2]. [1] http://wiki.dlang.org/DIP43 [2] https://github.com/jacob-carlborg/dmd/tree/d-objc Wow, this is fantastic! This and recent progress on iOS/ARM/LDC porting make me so happy :)
Re: D/Objective-C 64bit
On Wednesday, 12 March 2014 at 12:14:23 UTC, Michel Fortin wrote: On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said: On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one? Also, is there a list of differences between the two runtimes somewhere? Each combination being incompatible with each other subtly different ways... Which is why we have a test suite. There is an outdated list here, http://wiki.gnustep.org/index.php/ObjC2_FAQ I wouldn't care for GNUStep support. Objective-C support in gcc is almost dead and GNUStep seems to have hardly changed since I used WindowMaker as my main window manager. Which was around 1999 - 2004! -- Paulo
Re: D/Objective-C 64bit
w0rp devw...@gmail.com writes: This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool. Just a plug that the LDC iOS work is coming along well. D iOS programming may not be too far in the future. -- Dan
Re: D/Objective-C 64bit
Szymon Gatner noem...@gmail.com writes: Wow, this is fantastic! This and recent progress on iOS/ARM/LDC porting make me so happy :) Yeah, it will be cool to combine this with the LDC iOS work. I haven't posted progress lately. I got Fibers working on an iPhone 4. I found that GDC's thread.d already had ARM Fiber support so used it until it gets pulled into dmd. It's really coming down to just a few fundumental things (cross compiling getting real real type, and supporting TLS). -- Dan
AntTweakBarD - D binding to the AntTweakBar OpenGL/DirectX GUI tweaking library
Many C/C++ game development demos and apps tend to use the popular AntTweakBar parameter tweaking library. AntTweakBar is used to manipulate user-defined parameters in real-time by providing a GUI-like interface in an OpenGL / DirectX environment. AntTweakBarD[1][2] is just a simple D binding to this library. Note: If you prefer to load the AntTweakBar shared library lazily (Derelict-style), you may perhaps have success using the Deimos Dynamic Loader[3] (not tested with this project). Have fun, and let me know if there are any bugs! [1] : https://github.com/AndrejMitrovic/AntTweakBarD [2] : http://code.dlang.org/packages/ant-tweak-bar-d [3] : https://github.com/jkm/ddl
Re: D/Objective-C 64bit
On 3/12/14, 12:15 AM, Jacob Carlborg wrote: On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. I'll defer to domain experts on this one. Please advise. Andrei
Re: D/Objective-C 64bit
On 12 March 2014 12:14, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said: On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote: Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files. In what ABI may I ask? Your choices are: - Traditional (32bit) ABI without properties and Obj-C 2.0 additions - Traditional (32bit) ABI with properties and Obj-C 2.0 additions - Modern (64bit) ABI I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. That can be mixed in with either: - GNU Runtime ABI - NeXT Runtime ABI It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one? gobjc supports both, there's two ABI's for the NeXT - which I take to mean the difference between the difference between 32bit and 64bit. It seems that (now I read up on it) the GNU runtime came about from decades back when NeXT was not open sourced by Apple. From what I can gather, a move towards the modern ABI is the direction, but not considered production ready. From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. Also, is there a list of differences between the two runtimes somewhere? That's hard to say at an initial glance. There's a handy hook system into each ABI to allow you to switch between versions easily. The common differences I do however see are: NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: .objc_class_name_%s .objc_category_name_%s_%s GNU: __objc_class_name_%s __objc_category_name_%s_%s Most others look the same? Maybe you'll be able to find out more with this information.
Re: D/Objective-C 64bit
On 2014-03-12 13:14, Michel Fortin wrote: I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support. There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI. It is now :). I added support for properties. But as you say, I don't really know what they add. -- /Jacob Carlborg
Re: D/Objective-C 64bit
Am Wed, 12 Mar 2014 10:53:35 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: On 3/12/14, 12:15 AM, Jacob Carlborg wrote: On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. I'll defer to domain experts on this one. Please advise. Andrei We could also start a (better: the first) feature branch. http://wiki.dlang.org/Release_Process#Branching%20model
Re: D/Objective-C 64bit
On 2014-03-12 20:02, Iain Buclaw wrote: gobjc supports both, there's two ABI's for the NeXT - which I take to mean the difference between the difference between 32bit and 64bit. You previously listed three ABI's. It's the modern runtime for 64bit and the traditional for 32bit with with properties that are interesting. I don't know how much difference these properties do. It seems that (now I read up on it) the GNU runtime came about from decades back when NeXT was not open sourced by Apple. From what I can gather, a move towards the modern ABI is the direction, but not considered production ready. From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. I'm not sure I understand. Do you want to support the NeXT or GNU runtime? Clang is at least compatible with the Apple GCC. I don't know about FSF GCC. That's hard to say at an initial glance. There's a handy hook system into each ABI to allow you to switch between versions easily. The common differences I do however see are: NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: .objc_class_name_%s .objc_category_name_%s_%s GNU: __objc_class_name_%s __objc_category_name_%s_%s Most others look the same? Maybe you'll be able to find out more with this information. One basically need to look at each single feature and see what differs. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-03-12 17:53:35 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: On 3/12/14, 12:15 AM, Jacob Carlborg wrote: On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. I'll defer to domain experts on this one. Please advise. If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. The first question should about the review process. This patch touches a lot of things, so I wonder if Walter will be confortable reviewing it. Should different people review different parts? Here's a comparison view: DMD: 94 changed files with 8,005 additions and 48 deletions. https://github.com/jacob-carlborg/dmd/compare/d-objc druntime: 10 changed files with 1,263 additions and 0 deletions. https://github.com/jacob-carlborg/druntime/compare/d-objc Most of the changes to the compiler are inside #if DMD_OBJC/#endif blocks. Changes outside of those blocks shouldn't affect the semantics or the binary output of existing code. So I think a review could be done in two steps: 1. Review changes outside of those #if DMD_OBJC blocks. Those are the most critical changes as they'll affect the next version of the compiler that'll ship (I'm assuming Objective-C features won't be turned on until they're more usable). This includes some changes in the lexer, but it shouldn't affect current D code. This review could exclude the two files objc.h/objc.c, since the makefile ignores them without the D_OBJC flag. 2. Maybe review things inside of those #if DMD_OBJC blocks. Those things won't affect the compiler unless compiled with the D_OBJC flag, so it's less critical to review them. Most of them are there to implement Objective-C semantics so you'll need to be somewhat familiar with Objective-C to judge whether they're correct or not. What should be checked is whether an error would make them affect non-Objective-C constructs when they're compiled in. We also need to know what to do about the test suite. I made a separate test suite for D/Objective-C since those tests can only run on OS X and only with the compiler compiled with Objective-C support enabled. It could easily be merged with the main test suite, but the tests should be made conditional to whether the compiler is compiled with Objective-C or not. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 12 March 2014 19:29, Jacob Carlborg d...@me.com wrote: On 2014-03-12 20:02, Iain Buclaw wrote: gobjc supports both, there's two ABI's for the NeXT - which I take to mean the difference between the difference between 32bit and 64bit. You previously listed three ABI's. It's the modern runtime for 64bit and the traditional for 32bit with with properties that are interesting. I don't know how much difference these properties do. Sorry, some context. The two 32bit ABIs are part of the same source, I'd take them to be identical, with the exception that the second option supports features that are on-by-default in the 64bit ABI. I'm not sure I understand. Do you want to support the NeXT or GNU runtime? As in, if I were to support NeXT. I'd support the same as implemented by GNU ObjC. I'd have to look up if there are incompatibilities between GCC 4.3 and Clang on the ObjC side...
Re: D/Objective-C 64bit
On 2014-03-12 19:02:10 +, Iain Buclaw ibuc...@gdcproject.org said: From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. It all comes to how you integrate the thing with GCC. My guess is that you have three choices: 1. ignore Objective-C support: don't define DMD_OBJC in the code and the compiler will complain whenever it sees extern(Objective-C) 2. translate the calls to the DMD backend creating the various sections and segments to equivalent calls for creating sections and segments in GCC 3. replace the codegen for Objective-C data structures by what's already implemented in GCC for Objective-C This last option will support whatever ABI GCC has support for. That's probably the way to go if you want to make sure ABIs are compatible. All the Objective-C ABI DMD knows about is implemented in objc.c, so what you have to do is to rewrite objc.c to call the GCC equivalent implementation, probably getting rid of most of the code in there. NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: .objc_class_name_%s .objc_category_name_%s_%s GNU: __objc_class_name_%s __objc_category_name_%s_%s Most others look the same? Maybe you'll be able to find out more with this information. My understanding is that the differences are pretty trivial. But regardless, we probably don't have to care about them if you can hook directly to the GCC Objective-C codegen. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 12 March 2014 19:36, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 19:02:10 +, Iain Buclaw ibuc...@gdcproject.org said: From my POV, I wouldn't want to support the ABI of a language that GCC itself doesn't support. So code compiled by GNU ObjC should be compatible with extern(ObjC) code generated by GDC - even if it isn't compatible with Clang ObjC. But then, I'd be surprised if it wasn't compatible. It all comes to how you integrate the thing with GCC. My guess is that you have three choices: 1. ignore Objective-C support: don't define DMD_OBJC in the code and the compiler will complain whenever it sees extern(Objective-C) 2. translate the calls to the DMD backend creating the various sections and segments to equivalent calls for creating sections and segments in GCC 3. replace the codegen for Objective-C data structures by what's already implemented in GCC for Objective-C This last option will support whatever ABI GCC has support for. That's probably the way to go if you want to make sure ABIs are compatible. All the Objective-C ABI DMD knows about is implemented in objc.c, so what you have to do is to rewrite objc.c to call the GCC equivalent implementation, probably getting rid of most of the code in there. NeXT: NSConstantString objc_getClass objc_getMetaClass objc_msgSend objc_msgSendSuper GNU: NXConstantString objc_get_class objc_get_meta_class objc_msg_lookup objc_msg_lookup_super Some which greps for s(n)printf also show: NeXT: .objc_class_name_%s .objc_category_name_%s_%s GNU: __objc_class_name_%s __objc_category_name_%s_%s Most others look the same? Maybe you'll be able to find out more with this information. My understanding is that the differences are pretty trivial. But regardless, we probably don't have to care about them if you can hook directly to the GCC Objective-C codegen. Hooking to ObjC could be done, but requires patching GCC proper so that ObjC mangling becomes common code, not front-end specific.
Re: D/Objective-C 64bit
On 12 March 2014 19:34, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 17:53:35 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: On 3/12/14, 12:15 AM, Jacob Carlborg wrote: On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote: Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler. In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support. One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled. I'll defer to domain experts on this one. Please advise. If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. Daniel's DDMD conversion tool is on github, you could run it through that to get most of the legwork converted over I guess?
Re: D/Objective-C 64bit
On 2014-03-12 20:34, Michel Fortin wrote: If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes. I think Daniel has said he as a working Linux compiler. He just need to create pull requests (and get them merged) for all changes his tool requires. -- /Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-03-12 20:37, Iain Buclaw wrote: Sorry, some context. The two 32bit ABIs are part of the same source, I'd take them to be identical, with the exception that the second option supports features that are on-by-default in the 64bit ABI. I see. As in, if I were to support NeXT. I'd support the same as implemented by GNU ObjC. I'd have to look up if there are incompatibilities between GCC 4.3 and Clang on the ObjC side... Sounds reasonable. -- /Jacob Carlborg
Re: DigitalMars' GSoC application has been rejected
On Thursday, 27 February 2014 at 02:34:53 UTC, Andrei Alexandrescu wrote: Unfortunately we won't participate in GSoC this year. The decision was not surprising - our application has been rejected. Sadly there are lots of things we could have done better. Our application has been a low-priority side job for Walter and myself and as such its quality has suffered greatly. GSoC applications are a great example of things where one or more community members can have a large impact on D's well being by offloading a parallelizable work from the two of us. Please consider taking a leadership role for GSoC 2015. Andrei In 2013 KolibriOS, an open-source Operation System written in Assembly, applied for GSoC and was rejected as well. They went to Kickstarter, and raised money for their own SoC: https://www.kickstarter.com/projects/kolibrios/kolibrios-help-us-hold-our-own-summer-of-code-2013/ Should we try doing the same for D?
Memcached client
Hi, I'm writing a memcached client library for d. It's dependent on vibe-d - but this can be fixed . https://github.com/TiberiuGal/memcached4d I'd appreciate some feedback. thanks
