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
Re: Broken?
On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote: I'd like to point out that Walter and Andrei can't do it all themselves. It takes a team and part of pulling it off is well defined goals and job descriptions with devoted people. This is one of the motivations for my remark. They both have probably more tan enough to do without having to wade through the tremendous volume of responses. Steve
Re: Broken?
On Tuesday, 11 March 2014 at 22:24:15 UTC, Nick Sabalausky wrote: On 3/11/2014 2:42 PM, Steve Teale wrote: Well if we're going there, we should go the whole hog and have final, direct, and virtual. Pardon my ignorance: What's 'direct'? It's a system programming language, so you should be able to walk down the street naked as long as you are prepared to put up with the consequences. There has been much debate in the programming community over what exactly system programming language means. I think you, sir, have found the winner! Gets my vote, anyway! :) What I meant by final is simply the third leg of a tuffet. As I understand it, final means called directly, and you can't override, virtual means called through the vtable and you can override, direct means called directly, but you can override (hide) in a derived class, like if you define a method with the same signature in a derived class in C++ when the base class method is not marked as virtual. I tried that with G++ the other day, and it still seems to compile. There may be other possibilities, I have not attempted to draw the matrix table. Steve
Re: Remove link from github to phobos mailing list?
On 3/11/14, Brad Roberts bra...@puremagic.com wrote: They could be separated into two lists, but is that what any of the developers want? I'd want the dmd internals NG to be split up: http://forum.dlang.org/post/mailman.109.1392491086.6445.digitalmar...@puremagic.com
Re: Broken?
On Tuesday, 11 March 2014 at 20:43:07 UTC, Walter Bright wrote: On 3/11/2014 10:47 AM, Steve Teale wrote: What D needs at this point is a dictator. http://www.youtube.com/watch?v=poDaTeyqIm4 Ace Walter - how do you find the time? I believe that you are becoming truly benevolent as you grow older ;=)
Re: Need help creating banner ads for Dconf 2014
On 11 March 2014 22:14, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Tuesday, 11 March 2014 at 21:32:19 UTC, Walter Bright wrote: The ads will be run in rotation, meaning we can have a whole set of them. For example, Scott Meyers is a big draw, so there should be one that looks like the 3 headshots on the site, underneath is Alexandrescu * Meyers * Bright, Dconf 2014 May 21-23 Makes it sound like a three-way prize fight! I like it! :) http://i.imgur.com/9IJv2KN.png
Re: Proposal for fixing dchar ranges
On Tuesday, 11 March 2014 at 18:26:36 UTC, Johannes Pfau wrote: I think the problem here is that if ranges / algorithms have to work on the same data type as slicing/indexing. If .front returns code units, then indexing/slicing should be done with code units. If it returns code points then slicing has to happen on code points for consistency or it should be disallowed. (Slicing on code units is important - no doubt. But it is error prone and should be explicit in some way: string.sliceCP(a, b) or string.representation[a...b]) I think it is import to remember that in terms of ranges/algorithms, strings are not indexable, nor sliceable ranges. The only way to generically slice a string in generic code, is to explicitly test that a range is actually a string, and then knowingly call an internal primitive that is NOT a part of the range traits. So slicing/indexing *is* already disallowed, in terms of range/algorithms anyways.
Re: Remove link from github to phobos mailing list?
On 3/12/14, 12:51 AM, Andrej Mitrovic wrote: On 3/11/14, Brad Roberts bra...@puremagic.com wrote: They could be separated into two lists, but is that what any of the developers want? I'd want the dmd internals NG to be split up: http://forum.dlang.org/post/mailman.109.1392491086.6445.digitalmar...@puremagic.com If its what people want, then I'll make the changes (at least on the mailing list and github config side of things, I can't do anything with the news groups or the forum configs). That said, I figured a few stats might be interesting and might help inform the value of the split. Since December 4 (where the log I'm using happens to start), through today, for the Phobos list, here's a break down of the number of days having a given post count (note, 0 post days will be missing from this since there won't have been any log lines to process, someone do the math to fill that line in for us :) # days # posts 18 1 15 2 9 3 14 4 6 5 5 6 6 7 3 8 1 9 3 10 2 11 2 12 1 17 1 19 1 23 1 26 This doesn't split between github vs non-github traffic, it's the two combined. So, the vast majority of days have less than 10 messages. That's such a tiny amount that I'm amazed that anyone is remotely concerned. The dmd-internals list has the same pattern: # days # posts 6 1 9 2 13 3 17 4 8 5 4 6 6 7 5 8 6 9 1 10 5 11 1 12 1 13 1 14 1 15 2 17 1 41
Re: Processes and Channels, cf. goroutines.
Am 03.03.2014 16:55, schrieb Bienlein: On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote: Just out of curiosity, what did you miss in vibe.d regarding fiber based scheduling? Hi Söhnke, I'm thinking of developing a little actor library on top of D's spawn/receive model for creating threads, which is already actor-like but on a level of global functions. I want to mold some thin class layer on top of it to have actors on class level. Vibe.d would be a good solution for distributed actors. But for a first step I want to have local actors. Actors that are in the same memory space don't need to communicate through sockets as in case of vibe.d. Regards, Bienlein The vibe.core.concurrency module provides the same interface as std.concurrency (with some different details). Once Sean's fiber additions to std.concurrency will be ready, vibe.core.concurrency will be layered on top of (and finally replaced by) it. There is also vibe.stream.taskpipe, which offers a stream interface for passing data between tasks. This works for tasks in the same or in different threads.
Re: Remove link from github to phobos mailing list?
On 12 March 2014 08:40, Brad Roberts bra...@puremagic.com wrote: On 3/12/14, 12:51 AM, Andrej Mitrovic wrote: On 3/11/14, Brad Roberts bra...@puremagic.com wrote: They could be separated into two lists, but is that what any of the developers want? I'd want the dmd internals NG to be split up: http://forum.dlang.org/post/mailman.109.1392491086.6445.digitalmar...@puremagic.com If its what people want, then I'll make the changes (at least on the mailing list and github config side of things, I can't do anything with the news groups or the forum configs). That said, I figured a few stats might be interesting and might help inform the value of the split. Since December 4 (where the log I'm using happens to start), through today, for the Phobos list, here's a break down of the number of days having a given post count (note, 0 post days will be missing from this since there won't have been any log lines to process, someone do the math to fill that line in for us :) # days # posts 18 1 15 2 9 3 14 4 6 5 5 6 6 7 3 8 1 9 3 10 2 11 2 12 1 17 1 19 1 23 1 26 This doesn't split between github vs non-github traffic, it's the two combined. So, the vast majority of days have less than 10 messages. That's such a tiny amount that I'm amazed that anyone is remotely concerned. From a perspective of someone who interacts with the ML through his own mail client, I don't feel concerned either about the extraneous traffic. At least I get messages for things that I should be aware of. From the perspective of someone who sees the ML as a forum though
Re: Processes and Channels, cf. goroutines.
Am 03.03.2014 22:58, schrieb Bienlein: On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote: Just out of curiosity, what did you miss in vibe.d regarding fiber based scheduling? There is something else I forgot to mention. One scenario I'm thinking of is to have a large number of connections like more than 100.000 I want to listen on. This results in a situation with blocking I/O for all those connections. Fibers in D are more like continuations that are distributed over several kernel threads. The way Sean Kelly has implemented the FiberScheduler a fiber is invoked in case it receives an item like data through the connection it serves as in my scenario. At least this is the way I understood the implementation. So I can have like 100.000 connections simultanously as in Go without having to use Go (the Go language is too simple for my taste). In vibe.d, there are basically two modes of fiber scheduling. The usual mode is purely driven by the event loop: Once a task/fiber triggers a blocking operation, lets say a socket receive operation, it registers its handle for the corresponding event and calls an internal rawYield() function. Once the event fires, the fiber is then resumed. The other mode happens when yield() (in vibe.core.core) is explicitly called. In this case, tasks are inserted into a singly-linked list, which is processed in chunks alternated with a call to processEvents() and in FIFO order to ensure a fair scheduling and to avoid blocking event processing when tasks perform continuous computations with intermittent yield() calls. So the first mode AFAICS is working just like how Sean has made his fiber scheduler. And at least on 64-bit systems, there is nothing that speaks against handling huge numbers of connections simultaneously. 32-bit can also handle a lot of connections with small fiber stack sizes (setTaskStackSize), but using decently sized stacks will quickly eat up the available address space.
Re: Proposal for fixing dchar ranges
On Tuesday, 11 March 2014 at 18:02:26 UTC, Steven Schveighoffer wrote: No, where we are today is that in some cases, the language treats a char[] as an array of char, in other cases, it treats a char[] as a bi-directional dchar range. -Steve I want to mention something I've had trouble with recently, that I haven't seen mentioned yet, but is related: The ambiguity of the lone char. By that I mean: When a function accepts 'char' as an argument, it is (IMO) very hard to know if it is actually accepting a? 1. An ascii char in the 0 .. 128 range? 2. A code unit? 3. (heaven forbid) a codepoint in the 0 .. 256 range packed into a char? Currently (fortuantly? unfortunatly?) the current choice taken in our algorithms is 3, which is actually the 'safest' solution. So if you write: find(cassé, cast(char)'é'); It *will* correctly find the 'é', but it *won't* search for it in individual codeunits. Another more pernicious case is that of output ranges. put is supposed to know how to convert and string/char width, into any sting/char width. Again, things become funky if you tell put to place a string, into a sink that accepts a char. Is the sink actually telling you to feed it code units? or ascii?
Re: Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?
Am 07.03.2014 22:11, schrieb Bienlein: One question - doesn't Vibe.d already use green threads? What they are saying on their web site is that they are using fibers and at the same time they say they are using libevent. That is confusing for me. On http://vibed.org/features they write: Instead of using classic blocking I/O together with multi-threading for doing parallel network and file operations, all operations are using asynchronous operating system APIs. By default, libevent is used to access these APIs operating system independently. Further up on the same page they write: The approach of vibe.d is to use asynchronous I/O under the hood, but at the same time make it seem as if all operations were synchronous and blocking, just like ordinary I/O. What makes this possible is D's support for so called fibers. It does. Bienlein has a very vague knowledge of topics he comments about. I thought the vibe.d guys would shed some light at this at the occasion, but no luck. What I don't understand is how fibers can listen to input that comes in through connections they hold on to. AFAIKS, a fiber only becomes active when it's call method is called. So who calls the call method in case a connection becomes active? That is then again a kernel thread? How does the kernel thread know something arrived through a connection? It can't do a blocking wait as the system would run out of kernel threads very quickly. Sorry, I've been busy with some non-programming business over the past days and didn't have a chance to reply. Making a small article about the internal workings of the task/fiber system is planned for a long time now, but there are so many items with higher priority that it unfortunately hasn't happened so far. See my reply [1] in the other thread for a rough outline. I think what Go and Erlang do is to use green threads (or equivalent, goroutines in Go) for the applications side and a kernel thread pool within the runtime doing work stealing on the green threads. This is more or less (ish) what the Java Fork/Join framework of Doug Lea does as well. When in Go a channel runs empty the scheduler detaches the thread that served it and attaches it to a non-empty channel. In Go all this is in the language and the runtime where it can be done more efficiently than in a library. AFAIU, this is a main selling point in Go. I actually don't see a reason why it can't be just as efficient when done as a library. Taking the example of vibe.d, fibers are currently never moved between threads (although technically, they could), but they are still stored in a free list and reused for later tasks. There is not much more overhead than a few variable assignments and the fiber context switches. Vert.x is caliming to be able to handle millions of active connections. All right, as you can't have millions of threads on the JVM they must do that through some asynchronous approach (I guess Java NewIO). I read that an asynchronous solution is not as fast as one with many blocking threads as in Go or Erlang. I don't understand why. It was just claimed that this were the case. AFAIK they use a combination of callback based asynchronous I/O (mostly for server applications) combined with a thread pool for parallelizing synchronous I/O (mostly for client type applications/tasks). So it's basically a hybrid system that still makes a lot of trade-offs between performance and comfort. Disclaimer: this statement is based only on looking at a few examples and maybe a bog post, I don't have any first hand experience with vert.x.
Re: Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?
Am 07.03.2014 23:29, schrieb Sean Kelly:
On Friday, 7 March 2014 at 18:58:18 UTC, Russel Winder wrote:
On Fri, 2014-03-07 at 16:53 +, Sean Kelly wrote:
[…]
68K connections is nothing. I'll start getting interested when his
benchmarks are 200K+. Event-based systems in C can handle millions
of concurrent connections if implemented properly. I'd like to
believe vibe.d can approach this as well.
There used to be a 100k problem, i.e maintaining more than 100k active,
that means regularly causing traffic, not just being dormant for a few
centuries, but so many frameworks can now support that , that it has
become a non-metric. I don't know if Spring, JavaEE, can handle this but
on the JVM Vert.x certainly, I suspect Node.js can as well. Vert.x is
caliming to be able to handle millions of active connections.
I suspect it is now at the stage that the OS is the bottle neck not the
language of the framework.
I think the biggest issue at very large number of connections is memory
use. In fact, I don't expect even vibe.d to scale beyond a few hundred K
if it allocates a fiber per connection. It would have to use a free list
of fibers and make a top-level read effectively release the current
fiber into the free list. Scaling at this level in C generally meant
retaining little to no state per connection basically by necessity.
A free list is already used for fibers actually. Each fiber can be
reused for any number of tasks. This is also why `Fiber` as a type
doesn't occur in the public API, but rather the `Task` struct, which
internally points to a fiber + a task ID.
But since the memory pages of a fiber's stack are allocated lazily, at
least on a 64-bit OS, where address space is not an issue, you can
actually scale to very high numbers with a decent amount of RAM.
Certainly you don't need to have the amount of RAM that the typical
dedicated server for such tasks would have.
Having said that, it may be an interesting idea to offer a callback
based overload of waitForData(), so that you can do something like this:
listenTCP(port, onConnection);
void onConnection(TCPConnection conn)
{
conn.waitForData(onData);
// return (exits the task and puts the fiber
// into the free list)
}
void onData(TCPConnection conn)
{
// onData gets called as a new task, so that no fiber is
// occupied between the wait and the read calls
conn.read(...);
}
Re: Need help creating banner ads for Dconf 2014
http://99designs.com/
Re: Need help creating banner ads for Dconf 2014
On Tuesday, 11 March 2014 at 20:58:41 UTC, Walter Bright wrote: Dr. Dobb's will be running the advertisements. The formats are: Text Ad: Headline and text in a 300x125 png image file Banner Ads: 728x90 and 300x250, Formats: gif, jpg, html, Flash, Rich Media My photoshop skilz are universally derided - I need help! Let's make Dconf 2014 a success! http://dconf.org/2014/index.html I'll have a go today.
Re: Broken?
On Wednesday, 12 March 2014 at 03:05:00 UTC, Manu wrote: I'm really trying to keep my lid on here... I'll just remind that in regard to this particular point which sounds reasonable, it's easy to forgot that *all library code where the author didn't care* is now unusable by anybody who does. The converse would not be true if the situation was reversed. virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers. Also, as discussed at length, revoking virtual from a function is a breaking change, adding virtual is not. Which means that, instead of making a controlled breaking change with a clear migration path here and now, we are committing every single instance of any user's intent to 'optimise' their libraries (by finalising unnecessarily virtuals) to breaking changes in their ABI - which *will* occur, since virtual is the default. According to semantic versioning, this requires bumping the major version number... that's horrible! What's better; implementing a controlled deprecation path now, or leaving it up to any project that ever uses the 'class' keyword to eventually confront breaking changes in their API when they encounter a performance oriented customer? Case in point: https://github.com/D-Programming-Language/phobos/pull/1771 mark std.zip classes as final Long story short: MartinNowak decided to make the Zip classes final, since it made no sense to have any of the functions virtual, or to have anybody derive from them anyways. https://github.com/D-Programming-Language/phobos/pull/1771#issuecomment-36524041 Comment from Dav1dde: Just to let you know, it broke my code
Re: Need help creating banner ads for Dconf 2014
On Tuesday, 11 March 2014 at 21:32:19 UTC, Walter Bright wrote: There should be one that is just snipping out the top of the dconf.org page and running that as a banner. Etc. Be creative! What is the typeface used at the top there?
Restriction on interface function types
interface I
{
auto myType();
}
class A: I
{
auto myType() { return cast(A) null; }
}
void main()
{
I x = getSomeI();
typeof(x.myType()) y;
}
dlang.sexy
I came across this for EMACS. http://emacs.sexy/ Which got me thinking, now we have a new .sexy domain available for the public, who wants to go out and buy dlang.sexy (and talk about how sexy D is :) Andrei, I'm looking at you. Regards, Iain.
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 10:57:10 UTC, Steve Teale wrote:
interface I
{
auto myType();
}
class A: I
{
auto myType() { return cast(A) null; }
}
void main()
{
I x = getSomeI();
typeof(x.myType()) y;
}
Seems like you want covariance? I don't see how else having an
interface that returns auto could work.
That said, I'd expect this to work:
//
interface I
{
I myType();
}
class A: I
{
//auto myType() { return cast(A) null; } //Nope
A myType() { return cast(A) null; } //OK
}
//
But app
Re: Remove link from github to phobos mailing list?
On Tue, 11 Mar 2014 18:41:53 -0400, Brad Roberts bra...@puremagic.com wrote: Personally, I believe that it receiving pull request traffic is a good thing. The lack of _other_ conversations is mostly a sign of lack of activity from the phobos contributors. The amount of github generated traffic is pretty low too, so it's not like it's overwhelming at all. The same for the other lists. They could be separated into two lists, but is that what any of the developers want? The list only seems to capture github commits. I get a ton of emails from github regarding discussion on pull requests. I get probably 25-50 emails a day on github discussion. At the very least, the d forum page is quite useless. Every message is from github and there is no threading. It would be nice I think for the d forum to just ignore messages from github. -Steve
Re: Callout to DMD hackers
On Wed, 2014-03-12 at 02:14 +, Brad Anderson wrote: […] You can change the file encoding but the default is codepage 1252 for me (I assume it changes based on your locale but I don't know that for certain). It's definitely not UTF-16 encoded. I don't recall ever seeing Windows VS source code encoded with anything other than 1252/8859-1 or (rarely) UTF-8. I would have thought UTF-8 was the only sensible encoding of Unicode for general purposes. Windows is the reason for UTF-16LE and UTF-16BE because Microsoft implemented things differently to the rest of the planet, and what the standard said. So the standard got retrofitted. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Broken?
On 12 March 2014 20:40, monarch_dodra monarchdo...@gmail.com wrote: On Wednesday, 12 March 2014 at 03:05:00 UTC, Manu wrote: I'm really trying to keep my lid on here... I'll just remind that in regard to this particular point which sounds reasonable, it's easy to forgot that *all library code where the author didn't care* is now unusable by anybody who does. The converse would not be true if the situation was reversed. virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers. Also, as discussed at length, revoking virtual from a function is a breaking change, adding virtual is not. Which means that, instead of making a controlled breaking change with a clear migration path here and now, we are committing every single instance of any user's intent to 'optimise' their libraries (by finalising unnecessarily virtuals) to breaking changes in their ABI - which *will* occur, since virtual is the default. According to semantic versioning, this requires bumping the major version number... that's horrible! What's better; implementing a controlled deprecation path now, or leaving it up to any project that ever uses the 'class' keyword to eventually confront breaking changes in their API when they encounter a performance oriented customer? Case in point: https://github.com/D-Programming-Language/phobos/pull/1771 mark std.zip classes as final Long story short: MartinNowak decided to make the Zip classes final, since it made no sense to have any of the functions virtual, or to have anybody derive from them anyways. https://github.com/D-Programming-Language/phobos/pull/1771#issuecomment- 36524041 Comment from Dav1dde: Just to let you know, it broke my code Thank you. There you go, it's not even hypothetical.
Re: Broken?
On Tue, 2014-03-11 at 18:01 +, John Colvin wrote: […] Also, of course Walter can decide not to do something due to community pressure. He has the ultimate say, it's his language, but that doesn't mean he shouldn't listen. Python used to be Guido's language, but he and the community evolved out of that phase. It has not diminished Guido's status or standing. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Remove link from github to phobos mailing list?
On Wed, 12 Mar 2014 04:45:33 -0400, Iain Buclaw ibuc...@gdcproject.org wrote: On 12 March 2014 08:40, Brad Roberts bra...@puremagic.com wrote: On 3/12/14, 12:51 AM, Andrej Mitrovic wrote: On 3/11/14, Brad Roberts bra...@puremagic.com wrote: They could be separated into two lists, but is that what any of the developers want? I'd want the dmd internals NG to be split up: http://forum.dlang.org/post/mailman.109.1392491086.6445.digitalmar...@puremagic.com If its what people want, then I'll make the changes (at least on the mailing list and github config side of things, I can't do anything with the news groups or the forum configs). That said, I figured a few stats might be interesting and might help inform the value of the split. Since December 4 (where the log I'm using happens to start), through today, for the Phobos list, here's a break down of the number of days having a given post count (note, 0 post days will be missing from this since there won't have been any log lines to process, someone do the math to fill that line in for us :) # days # posts 18 1 15 2 9 3 14 4 6 5 5 6 6 7 3 8 1 9 3 10 2 11 2 12 1 17 1 19 1 23 1 26 This doesn't split between github vs non-github traffic, it's the two combined. So, the vast majority of days have less than 10 messages. That's such a tiny amount that I'm amazed that anyone is remotely concerned. There is a threshold for everyone, where messages just get mindlessly deleted. Basically, I don't have time to go through all these messages to see if they are important when most of them aren't, so whenever I see a github commit, I delete it. I realized recently that this is just a task I would like not to have to do. Since December 4th, there have been 12 threads that were not github commits: http://forum.dlang.org/post/531122fe.1020...@digitalmars.com http://forum.dlang.org/post/CACYV=-efsq4ujgqiohf6uotz7ak_q1yx6iql--aknzhjr5e...@mail.gmail.com http://forum.dlang.org/post/52eb6e6a.4000...@digitalmars.com http://forum.dlang.org/post/1391143889.8220.yahoomail...@web124902.mail.ne1.yahoo.com http://forum.dlang.org/post/52daca0e@erdani.com http://forum.dlang.org/post/CAP9J_HXN2MxKEdXmi5FbFNtrXC_msW33GC=10mx3cf8_rfr...@mail.gmail.com http://forum.dlang.org/post/52d6f12d.5030...@puremagic.com http://forum.dlang.org/post/52d70e41.7070...@puremagic.com http://forum.dlang.org/post/eb35fc5f-ab7d-458b-93ba-4179cf9ed...@me.com http://forum.dlang.org/post/52ae0576.5070...@puremagic.com http://forum.dlang.org/post/526c95ec.6060...@erdani.com http://forum.dlang.org/post/52d72f0a.4030...@puremagic.com In all, we have 33 posts that were not made by github. Out of 427 that you reported. That's about 94% noise. I'll note that some of these were posted by newbies that used the forum interface and assumed a post to the phobos forum would be the best place to ask a question about phobos. They should have been posted to the main group. Having extra groups that seem more focused is sometimes a bad thing. From a perspective of someone who interacts with the ML through his own mail client, I don't feel concerned either about the extraneous traffic. At least I get messages for things that I should be aware of. From the perspective of someone who sees the ML as a forum though My main question here was, doesn't github already allow you to subscribe to this? In the beginning, everyone who was interested was already subscribed to the ML, so it made sense to send messages there. When D was developed on dsource and subversion, it was a way to see all the commits. But there was also much more discussion occurring on these groups. Now, it seems most of the development discussion occurs on pull requests. I don't want to eliminate the possibility of seeing all commits, but I would like to not see all commits. Is there a way we can split the discussion from the commits? -Steve
Re: Broken?
On Wednesday, 12 March 2014 at 11:40:39 UTC, Manu wrote: On 12 March 2014 20:40, monarch_dodra monarchdo...@gmail.com wrote: On Wednesday, 12 March 2014 at 03:05:00 UTC, Manu wrote: I'm really trying to keep my lid on here... I'll just remind that in regard to this particular point which sounds reasonable, it's easy to forgot that *all library code where the author didn't care* is now unusable by anybody who does. The converse would not be true if the situation was reversed. virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers. Also, as discussed at length, revoking virtual from a function is a breaking change, adding virtual is not. Which means that, instead of making a controlled breaking change with a clear migration path here and now, we are committing every single instance of any user's intent to 'optimise' their libraries (by finalising unnecessarily virtuals) to breaking changes in their ABI - which *will* occur, since virtual is the default. According to semantic versioning, this requires bumping the major version number... that's horrible! What's better; implementing a controlled deprecation path now, or leaving it up to any project that ever uses the 'class' keyword to eventually confront breaking changes in their API when they encounter a performance oriented customer? Case in point: https://github.com/D-Programming-Language/phobos/pull/1771 mark std.zip classes as final Long story short: MartinNowak decided to make the Zip classes final, since it made no sense to have any of the functions virtual, or to have anybody derive from them anyways. https://github.com/D-Programming-Language/phobos/pull/1771#issuecomment- 36524041 Comment from Dav1dde: Just to let you know, it broke my code Thank you. There you go, it's not even hypothetical. It can also happen the other way if I mark a method virtual that used to be final, which was overloaded in a subclass, right? -- Paulo
Re: Restriction on interface function types
On Wed, 12 Mar 2014 06:57:08 -0400, Steve Teale
steve.te...@britseyeview.com wrote:
interface I
{
auto myType();
}
class A: I
{
auto myType() { return cast(A) null; }
}
void main()
{
I x = getSomeI();
typeof(x.myType()) y;
}
What you want simply isn't possible. An interface binds at runtime, and
you need to declare types at compile-time. You can't use an interface
method to define the type of y.
-Steve
Re: Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?
On Wednesday, 12 March 2014 at 09:26:28 UTC, Sönke Ludwig wrote: I actually don't see a reason why it can't be just as efficient when done as a library. Taking the example of vibe.d, fibers are currently never moved between threads (although technically, they could), but they are still stored in a free list and reused for later tasks. I believe several kernel threads are in the play to call fibers. Then the free list must be synchronized which can make a difference on a heavy loaded system at the end of the day. HawtDispatch (http://hawtdispatch.fusesource.org) applies some tricks to reduce synchronization on its free lists for that reason. But I honestly don't have a clue how that exactly works.
Re: Remove link from github to phobos mailing list?
On Wednesday, 12 March 2014 at 11:53:50 UTC, Steven Schveighoffer wrote: My main question here was, doesn't github already allow you to subscribe to this? Actually, I'm subscribed to that, and I don't receive any of the posts of in the dlang phobos list. I don't see the point of having a forum that simply stores email notifications.
Re: Broken?
Andrei Alexandrescu wrote in message news:531f70ed.3040...@erdani.org... On 3/11/14, 1:18 PM, Vladimir Panteleev wrote: A combination of both. The change would break a lot of code and it seems to me final vs. virtual by default is a judgment call more than an obvious decision in favor of final. That said, if I'd do things over again I'd advocate final by default. But we're not doing things over again. Andrei FWIW this is exactly where I was back before dconf13. I was convinced when I realized that: - It is impossible for the optimizer to achieve the same performance in all cases thanks to dynamic linking - Linking with C++ usually requires marking _almost_ every method with 'final' - Only the introducing virtual methods need to be changed, so the breakage is actually very small and trivially handled So after 5 minutes of adding 'virtual' where the compiler tells me to, I can delete a whole bunch of cruft from my code and keep the same performance. (Note that those 5 minutes can be done at your leisure over the years it takes for this to progress through the deprecation stages)
Re: Need help creating banner ads for Dconf 2014
On Tuesday, 11 March 2014 at 20:58:41 UTC, Walter Bright wrote: Dr. Dobb's will be running the advertisements. The formats are: Text Ad: Headline and text in a 300x125 png image file Banner Ads: 728x90 and 300x250, Formats: gif, jpg, html, Flash, Rich Media My photoshop skilz are universally derided - I need help! Let's make Dconf 2014 a success! http://dconf.org/2014/index.html Here's a couple basic ones for starters: https://github.com/JinShil/DConf_2014_Banner_Ads I'll try to make a few more creative ones if I can find some more time. Would you like a couple with simple animations? Mike
Re: Broken?
On 2014-03-12 03:04:38 +, Manu turkey...@gmail.com said: virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers. I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently. Or we could implement final by default. This option would instead force people to add 'virtual' here and there, but otherwise existing code is likely to run faster after that. We could always keep things as they currently are: private/package is not virtual, everything else is virtual unless marked final. Honestly I'd like to se that go. The protection attribute should have nothing to do with whether a function is virtual or not. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: dlang.sexy
This is a pretty amusing site too: http://vim.sexy/
Re: Broken?
On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 03:04:38 +, Manu turkey...@gmail.com said: virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers. I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently. Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code! Package, I'm less concerned about. You can make that virtual, I don't ever use package functions. -Steve
Re: dlang.sexy
On Wed, 12 Mar 2014 08:38:25 -0400, Adam D. Ruppe destructiona...@gmail.com wrote: This is a pretty amusing site too: http://vim.sexy/ Dudebro startups like yours get shit from angry feminists all the time. Using Vim will put a stop to that. Vim donates money to children living in Uganda. You'll look so accepting and humanitarian just by using Vim, that you won't even have to think about actual social issues. This leaves you free to go back to solving problems that really matter, like building apps that incentivize breaking up protests or apps that crowd-source date conversations. Don't get me wrong: I know you don't actually care about human rights and social issues. All that matters is that you look like you care. :) -Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 11:13:00 UTC, monarch_dodra wrote:
That said, I'd expect this to work:
//
interface I
{
I myType();
}
class A: I
{
//auto myType() { return cast(A) null; } //Nope
A myType() { return cast(A) null; } //OK
}
//
Yup, covariance desired, but
import std.stdio;
interface I
{
I myType();
}
class A: I
{
A myType() { return cast(A) null; }
void foo() { writeln(foo); }
}
void main()
{
I a = new A();
writeln(typeof(a.myType()).stringof);
}
returns I
Seems like a bug to me.
Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:05:07 UTC, Steve Teale wrote: I a = new A(); Seems like a bug to me. You are working through the interface, so the type will be what was written in the interface. If you made that A a = new A();, then you could see type A on the override. But the interface has no way of knowing which child class is there at compile time so it has to work through base types only.
Re: Broken?
On 3/12/14, Michel Fortin michel.for...@michelf.ca wrote: Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. The last word from Walter was that he agreed tying access specifiers to virtuality is wrong, but that it needs a proper DIP.
Re: Restriction on interface function types
On Wed, 12 Mar 2014 09:05:05 -0400, Steve Teale
steve.te...@britseyeview.com wrote:
On Wednesday, 12 March 2014 at 11:13:00 UTC, monarch_dodra wrote:
That said, I'd expect this to work:
//
interface I
{
I myType();
}
class A: I
{
//auto myType() { return cast(A) null; } //Nope
A myType() { return cast(A) null; } //OK
}
//
Yup, covariance desired, but
import std.stdio;
interface I
{
I myType();
}
class A: I
{
A myType() { return cast(A) null; }
void foo() { writeln(foo); }
}
void main()
{
I a = new A();
writeln(typeof(a.myType()).stringof);
}
returns I
Seems like a bug to me.
No, not a bug. What you want is actually not possible.
To demonstrate further:
void bad(I i)
{
typeof(i.myType()) x;
}
class A : I
{
A myType() { return cast(A)null;}
}
class B : I
{
B myType() {return cast(B) null;}
}
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) {bad(i);}
}
How is the compiler to build it's one copy of bad? Should x be typed as A
or B? Or something not even seen in this module that could derive from I?
-Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 11:56:43 UTC, Steven Schveighoffer wrote: On Wed, 12 Mar 2014 06:57:08 -0400, Steve Teale steve.te...@britseyeview.com wrote: What you want simply isn't possible. An interface binds at runtime, and you need to declare types at compile-time. You can't use an interface method to define the type of y. -Steve Steve OK, it was a bad illustrative example, but (cast(typeof(a.myType()) whatever).foo(); could be useful, when foo() is not in the interface. It was the failure of auto in an interface that I was remarking on - should at least be documented. Also the covariant return values as suggested by md don't work either. Steve
Re: Broken?
On 3/12/14, Steven Schveighoffer schvei...@yahoo.com wrote: Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. It can if it's in the same module. You may want to have the benefit of virtual functions, but also the benefit of those methods being accessible in some internal API, but not to the user. If you make them protected, they're accessible by user-derived classes. You could make them package, but currently package is forced non-virtual as well. Package, I'm less concerned about. You can make that virtual, I don't ever use package functions. There is definitely a need for this. DFeed is full of these style of comments: /+ package +/ /+ protected +/ override int _rtype() // package It's obviously supposed to be hidden from the user, but it can't be. So underscores are prepended instead.
Re: Broken?
On 2014-03-12 12:48:59 +, Steven Schveighoffer schvei...@yahoo.com said: On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin michel.for...@michelf.ca wrote: I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently. Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code! You're mixing C++ private with D private. Private just means the symbol is only accessible within the same module. You can have a whole class hierarchy in a module if you want, and thus could override private functions assuming they could be virtual. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: dlang.sexy
Reading this I wonder if those links are SFW or if you're joking and you're driving me to some unsafe website :) On Wednesday, 12 March 2014 at 12:53:41 UTC, Steven Schveighoffer wrote: On Wed, 12 Mar 2014 08:38:25 -0400, Adam D. Ruppe destructiona...@gmail.com wrote: This is a pretty amusing site too: http://vim.sexy/ Dudebro startups like yours get shit from angry feminists all the time. Using Vim will put a stop to that. Vim donates money to children living in Uganda. You'll look so accepting and humanitarian just by using Vim, that you won't even have to think about actual social issues. This leaves you free to go back to solving problems that really matter, like building apps that incentivize breaking up protests or apps that crowd-source date conversations. Don't get me wrong: I know you don't actually care about human rights and social issues. All that matters is that you look like you care. :) -Steve
Re: Restriction on interface function types
On Wed, 12 Mar 2014 09:13:08 -0400, Steve Teale steve.te...@britseyeview.com wrote: On Wednesday, 12 March 2014 at 11:56:43 UTC, Steven Schveighoffer wrote: On Wed, 12 Mar 2014 06:57:08 -0400, Steve Teale steve.te...@britseyeview.com wrote: What you want simply isn't possible. An interface binds at runtime, and you need to declare types at compile-time. You can't use an interface method to define the type of y. -Steve Steve OK, it was a bad illustrative example, but (cast(typeof(a.myType()) whatever).foo(); could be useful, when foo() is not in the interface. It was the failure of auto in an interface that I was remarking on - should at least be documented. Also the covariant return values as suggested by md don't work either. Auto doesn't work if you don't define what it returns. Auto is not a type in itself, it means infer the type. If there's nothing to infer with, it's an error. -Steve
Re: Need help creating banner ads for Dconf 2014
On Wednesday, 12 March 2014 at 10:44:23 UTC, Gary Willoughby wrote: I'll have a go today. Here are my efforts: http://nomad.so/misc/dconf-2014/
Re: Proposal for fixing dchar ranges
On 3/10/14, 3:30 PM, Walter Bright wrote: On 3/10/2014 6:35 AM, Steven Schveighoffer wrote: An idea to fix the whole problems I see with char[] being treated specially by phobos: introduce an actual string type, with char[] as backing, that is a dchar range, that actually dictates the rules we want. Then, make the compiler use this type for literals. Proposals to make a string class for D have come up many times. I have a kneejerk dislike for it. It's a really strong feature for D to have strings be an array type, and I'll go to great lengths to keep it that way. You can also look at Erlang, where strings are just lists of numbers. Eventually they realized it was a huge mistake and introduced another type, a binary string, which is much more efficient and works as expected. I think making strings behave like arrays is a design mistake.
Re: Broken?
On Wed, 12 Mar 2014 09:15:14 -0400, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 12:48:59 +, Steven Schveighoffer schvei...@yahoo.com said: On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin michel.for...@michelf.ca wrote: I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently. Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code! You're mixing C++ private with D private. Private just means the symbol is only accessible within the same module. You can have a whole class hierarchy in a module if you want, and thus could override private functions assuming they could be virtual. OK, I can see that being useful. You are right, I was thinking C++ private. So essentially, a virtual private function can only be overridden in classes defined in the same module. What happens when you do it in a separate module, an error? What if you want to define that function name, but it's taken by the base class, what happens? -Steve
Re: Need help creating banner ads for Dconf 2014
On Wednesday, 12 March 2014 at 13:19:29 UTC, Gary Willoughby wrote: On Wednesday, 12 March 2014 at 10:44:23 UTC, Gary Willoughby wrote: I'll have a go today. Here are my efforts: http://nomad.so/misc/dconf-2014/ and you'll probably need your ad-blocker off to see them!
Re: dlang.sexy
On Wed, 12 Mar 2014 09:17:28 -0400, Andrea Fontana nos...@example.com wrote: Reading this I wonder if those links are SFW or if you're joking and you're driving me to some unsafe website :) I think it's satire. Kind of a Ron Burgundy style of humor. That is a quote from the site, which is not an unsafe site as far as I can tell! It also boasts that vim can do 256 colors :) -Steve
Plan 9 support
Just out of curiosity.,. Is there any way to use D with it?
Re: Broken?
On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer wrote: OK, I can see that being useful. You are right, I was thinking C++ private. -Steve Even in C++, private virtual a key part of the non-virtual interface thing. EG: You define your base class as having only non-virtual public functions, and private virtual function. They are private, so the derived classes can't *call* them, but they can still override them. The idea is that the base class holds any non-modifyable behavior, and the virtual functions are only customizeable sub-part behavior. For example, C++ streams work that way: All the public functions are non-virtual. To create your own streams, you are supposed to only override a set of low level functions, and then the base class takes care of calling them correctly. In any case, that's how private virtual makes sense in C++. I'm less fluent with how it works D classes, but last time I read TDPL, I seem to remember it was built-in in some way.
Re: Restriction on interface function types
On Wed, 12 Mar 2014 09:34:32 -0400, Steve Teale
steve.te...@britseyeview.com wrote:
On Wednesday, 12 March 2014 at 13:12:20 UTC, Steven Schveighoffer wrote:
On Wed, 12 Mar 2014 09:05:05 -0400, Steve Teale
steve.te...@britseyeview.com wrote:
How is the compiler to build it's one copy of bad? Should x be typed as
A or B? Or something not even seen in this module that could derive
from I?
-Steve
Let's take bad() away, and instead:
class A : I
{
A myType() { return cast(A)null;}
final void foo();
}
class B : I
{
B myType() {return cast(B) null;}
final void bar();
}
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the interface type
should get the correct version right?, and then the cast should cause a
call to A or B.
The type cannot be determined at runtime, it's a static language.
foreach(i; arr) { typeof(i.myType()) x = cast(i.myType()) i; x.foo();}
What is typeof(x)? It needs to be decided at compile time.
-Steve
Re: Status of multidimensional slicing
2014-03-08 10:24 GMT+09:00 Andrei Alexandrescu seewebsiteforem...@erdani.org: I agree and sympathize. I finished to update my pull request #443. Now it is active. Kenji Hara
Re: Broken?
On Wed, 12 Mar 2014 09:45:22 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer wrote:
OK, I can see that being useful. You are right, I was thinking C++
private.
-Steve
Even in C++, private virtual a key part of the non-virtual interface
thing.
EG: You define your base class as having only non-virtual public
functions, and private virtual function. They are private, so the
derived classes can't *call* them, but they can still override them.
Nonsense. If I'm writing a function, I can call it. There is no way to
prevent it. e.g.:
class X
{
virtual void _foo() {/* default impl */}
public:
void foo() {_foo();}
}
class Y : public X
{
virtual void _foo() {_foo2();}
void _foo2() { /* do whatever I want here */}
}
OK, so your idea is that I can't call my copy of _foo, which if that's how
it works, is dumb in my opinion. But if that's the case, I'm in control of
its implementation, I can just forward to another function that I can call.
The idea is that the base class holds any non-modifyable behavior, and
the virtual functions are only customizeable sub-part behavior.
For example, C++ streams work that way: All the public functions are
non-virtual. To create your own streams, you are supposed to only
override a set of low level functions, and then the base class takes
care of calling them correctly.
The idea is fine, but protected serves this purpose just as well.
-Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:34:33 UTC, Steve Teale wrote:
On Wednesday, 12 March 2014 at 13:12:20 UTC, Steven
Schveighoffer wrote:
On Wed, 12 Mar 2014 09:05:05 -0400, Steve Teale
steve.te...@britseyeview.com wrote:
How is the compiler to build it's one copy of bad? Should x be
typed as A or B? Or something not even seen in this module
that could derive from I?
-Steve
Let's take bad() away, and instead:
class A : I
{
A myType() { return cast(A)null;}
final void foo();
}
class B : I
{
B myType() {return cast(B) null;}
final void bar();
}
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the
interface type should get the correct version right?, and then
the cast should cause a call to A or B.
It will *call* the correct version, but the signature used will
still statically be the interface's signature.
It can make a difference when you *statically* know you are in a
derived type:
I i = new A();
A a = new A();
I ii = i.myType();
A aa = a.myType();
Here, the call to myType, in both cases, will runtime resolve
to A.myType().
*However*, the static type used to return the value, will not be
the same.
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:45:30 UTC, Steven Schveighoffer wrote: What is typeof(x)? It needs to be decided at compile time. -Steve OK, squirm, squirm - I misunderstood the examples for typeof. Will you take a look at my last post on d.learn please. What I describe there is the motivation for my squirming. Can you suggest a compile-time way of telling ControlSet what class it is targeting at the point where an instance of it is declared? Sorry Steve
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:12:20 UTC, Steven Schveighoffer
wrote:
On Wed, 12 Mar 2014 09:05:05 -0400, Steve Teale
steve.te...@britseyeview.com wrote:
How is the compiler to build it's one copy of bad? Should x be
typed as A or B? Or something not even seen in this module that
could derive from I?
-Steve
Let's take bad() away, and instead:
class A : I
{
A myType() { return cast(A)null;}
final void foo();
}
class B : I
{
B myType() {return cast(B) null;}
final void bar();
}
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the
interface type should get the correct version right?, and then
the cast should cause a call to A or B.
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:34:33 UTC, Steve Teale wrote:
class A : I
{
A myType() { return cast(A)null;}
final void foo();
}
class B : I
{
B myType() {return cast(B) null;}
final void bar();
}
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the
interface type should get the correct version right?, and then
the cast should cause a call to A or B.
Aargh - not final void foo() and final void bar(), just void
foo() in each case - a virtual function not mentioned by the
interface.
Re: Restriction on interface function types
On Wed, 12 Mar 2014 09:51:32 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Wednesday, 12 March 2014 at 13:34:33 UTC, Steve Teale wrote:
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the interface
type should get the correct version right?, and then the cast should
cause a call to A or B.
It will *call* the correct version, but the signature used will still
statically be the interface's signature.
There is no foo in the interface definition. The code is invalid, as is
the idea you can declare variables based on a runtime type definition.
-Steve
Re: Plan 9 support
On Wednesday, 12 March 2014 at 13:42:49 UTC, Jonathan Dunlap wrote: Just out of curiosity.,. Is there any way to use D with it? I don't know if anyone has tried, but it would definitely be an interesting project.
Re: ddox-generated Phobos documentation is available for review
Am 11.03.2014 16:12, schrieb Andrei Alexandrescu: On 3/11/14, 6:55 AM, Ivan Kazmenko wrote: http://dlang.org/library Looks nice! I second the opinion that Disqus might have a better alternative. Its loading after the page was rendered looks clumsy, its style does not match that of dlang.org's... the whole thing is somehow out of place. Unless something better comes about, we'll go with disqus. Sönke, are there styling options available? Andrei AFAICT the only options are dark or bright background and serif or sans-serif font. I didn't find anything to control the area around the horizontal bar at the top of the comments section.
Re: Restriction on interface function types
On Wed, 12 Mar 2014 09:54:00 -0400, Steve Teale steve.te...@britseyeview.com wrote: On Wednesday, 12 March 2014 at 13:45:30 UTC, Steven Schveighoffer wrote: What is typeof(x)? It needs to be decided at compile time. -Steve OK, squirm, squirm - I misunderstood the examples for typeof. Will you take a look at my last post on d.learn please. What I describe there is the motivation for my squirming. Can you suggest a compile-time way of telling ControlSet what class it is targeting at the point where an instance of it is declared? I saw that, but I think what you encountered was a bug in the compiler or differently-generated vtables. I think you should focus on trying to identify and fix the bug rather than trying to exploit a workaround. One thing to try is re-compiling all your code. Any changes in vtables will mess up the linkage. If the compiler thinks your function to call is in index 2 in one compilation, but it's in index 3 in another, bad things will happen :) -Steve
Re: Broken?
On 3/12/14, Steven Schveighoffer schvei...@yahoo.com wrote: The idea is fine, but protected serves this purpose just as well. Protected still allows subclasses to *call* the methods. The idea is that the base class provides a public API which implements the calling, because only it knows in which order some private functions should be called.
Re: Broken?
On Wednesday, 12 March 2014 at 12:48:58 UTC, Steven Schveighoffer wrote: On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin michel.for...@michelf.ca wrote: On 2014-03-12 03:04:38 +, Manu turkey...@gmail.com said: virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers. I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently. Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code! Package, I'm less concerned about. You can make that virtual, I don't ever use package functions. -Steve Private virtual functions actually make a LOT of sense in C++. Ever heard of NVI? It is actually good design practice to make class virtuals private in many cases and relay on Template Method pattern. Even Andrei advices that in C++ Coding Standards.
Re: Broken?
On Wednesday, 12 March 2014 at 13:53:28 UTC, Steven Schveighoffer wrote: On Wed, 12 Mar 2014 09:45:22 -0400, monarch_dodra monarchdo...@gmail.com wrote: On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer wrote: OK, I can see that being useful. You are right, I was thinking C++ private. -Steve Even in C++, private virtual a key part of the non-virtual interface thing. EG: You define your base class as having only non-virtual public functions, and private virtual function. They are private, so the derived classes can't *call* them, but they can still override them. Nonsense. If I'm writing a function, I can call it. There is no way to prevent it. e.g.: The point is that you can't call parent's virtual (often abstract) method. Of course you can call method you define but that is not the point of NVI.
Re: Restriction on interface function types
On Wednesday, 12 March 2014 at 13:55:35 UTC, Steven Schveighoffer
wrote:
On Wed, 12 Mar 2014 09:51:32 -0400, monarch_dodra
monarchdo...@gmail.com wrote:
On Wednesday, 12 March 2014 at 13:34:33 UTC, Steve Teale wrote:
void main()
{
I[] arr = [new A, new B];
foreach(i; arr) { (cast(typeof(i.myType()) i).foo() }
}
myType() is a virtual function, so calling it through the
interface type should get the correct version right?, and
then the cast should cause a call to A or B.
It will *call* the correct version, but the signature used
will still statically be the interface's signature.
There is no foo in the interface definition.
I meant call relative to myType(). I can see how that was not
clear actually. Sorry.
The code is invalid, as is the idea you can declare variables
based on a runtime type definition.
Yup.
Re: Need help creating banner ads for Dconf 2014
On Wednesday, 12 March 2014 at 12:29:35 UTC, Mike wrote: On Tuesday, 11 March 2014 at 20:58:41 UTC, Walter Bright wrote: Dr. Dobb's will be running the advertisements. The formats are: Text Ad: Headline and text in a 300x125 png image file Banner Ads: 728x90 and 300x250, Formats: gif, jpg, html, Flash, Rich Media My photoshop skilz are universally derided - I need help! Let's make Dconf 2014 a success! http://dconf.org/2014/index.html Added a couple more: https://github.com/JinShil/DConf_2014_Banner_Ads Mike
Re: Remember that Go vs D MQTT thing and how we wondered about dmd vs gdc?
On Wednesday, 12 March 2014 at 12:10:04 UTC, Bienlein wrote: On Wednesday, 12 March 2014 at 09:26:28 UTC, Sönke Ludwig wrote: I actually don't see a reason why it can't be just as efficient when done as a library. Taking the example of vibe.d, fibers are currently never moved between threads (although technically, they could), but they are still stored in a free list and reused for later tasks. I believe several kernel threads are in the play to call fibers. Then the free list must be synchronized which can make a difference on a heavy loaded system at the end of the day. HawtDispatch (http://hawtdispatch.fusesource.org) applies some tricks to reduce synchronization on its free lists for that reason. But I honestly don't have a clue how that exactly works. Bypassing the kernel could be more efficient for fibers if it were possible, and using thread affinity it could remove some interruption by setting the maxcpus option in the kernel. The alternative to locking via kernel is queuing using the freeway overpass method described here: http://blog.erratasec.com/2013/02/multi-core-scaling-its-not-multi.html I think HawtDispatch may be using queues to fit into this synchronization method. Snort is also a good example of mostly lock-less multi-core by using memory mapped regions I'm also very interested in optimizing fibers further as it would give D excellence where it already does great
Re: Broken?
On Wednesday, 12 March 2014 at 13:53:28 UTC, Steven Schveighoffer wrote: Nonsense. If I'm writing a function, I can call it. There is no way to prevent it. Yes, you are right. You can always call the function directly if you so wish, since you *are* defining it. But the idea is that it should just be a piece of implementation that should only be used in a controlled environment, as defined by the base class. OK, so your idea is that I can't call my copy of _foo, which if that's how it works, is dumb in my opinion. But if that's the case, I'm in control of its implementation, I can just forward to another function that I can call. Absolutely. And in NVI, arguably, that's a good idea. By doing this, you are basically creating a second level NVI for a potential third level implementation. *if* your derived class made a direct call to the virtual (protected) function, then you'd be voiding the base classes' guarantees for any other derived class. The idea is fine, but protected serves this purpose just as well. The basic idea of NVI is encapsulation of behavior. The derived class, while they are the ones defining the implementation, are considered no different from any other client, and are not given call rights. If you make the functions protected, then you are granting them access to implementation internals, which means weaker encapsulation. For a 1-level hierarchy, it doesn't make much difference, but the deeper you go, and the less robust the design gets.
Re: Broken?
On 03/12/2014 02:22 PM, Steven Schveighoffer wrote: OK, I can see that being useful. You are right, I was thinking C++ private. So essentially, a virtual private function can only be overridden in classes defined in the same module. What happens when you do it in a separate module, an error? In a different module, attempting an override should behave as if the base class didn't define the member function. What if you want to define that function name, but it's taken by the base class, what happens? It's not taken. There are corner cases, when eg. the module with the private member function imports a module with a public member function hiding the private one (i.e., circular imports) and then uses this newly defined member function, possibly expecting to call its own private member. Then it should maybe be an error. :o) Anyway, I think the main issue with virtual private and virtual package is that they'd influence the class ABI.
