Re: Is D so powerfull ??
On 9/11/2015 5:54 PM, Jeremy DeHaan wrote:
Didn't you say constructors and destructors are missing? What should
one do in those cases?
Constructors and destructors do not match the C++ ABI, but they are
still generated, so they can only be called from the language they were
written in. So if you write your classes in D you must new and delete
(or GC) them from D. You can still create them from C++ (or create
C++-written classes from D) if you use a forwarding function:
X makeX() { return new X(); }
Additionally, should we use new in this case? Wouldn't new create a
pointer to a C++ class? Or does it work differently for extern(c++)
classes?
New in D will allocate a class instance on the GC heap and return a
reference to it, just like when it's used with D classes.
These two functions have the same ABI:
// D
extern(C++) class X {}
extern(C++) void func(X x);
// C++
class X {}
void func(X *x);
You can find several examples of C++ interop in dmd's test\runnable\cppa.d
Re: Is D so powerfull ??
On Monday, 9 November 2015 at 06:51:03 UTC, Jeremy DeHaan wrote:
On Monday, 9 November 2015 at 06:27:22 UTC, Daniel Murphy wrote:
On 9/11/2015 4:26 PM, Jeremy DeHaan wrote:
What is the correct way to use C++ class instances in D? Can
you by
chance give an example?
extern (C++) class X
{
...
}
extern (C++) void func(X x);
void main(string[] args)
{
func(new X());
}
etc
Didn't you say constructors and destructors are missing? What
should one do in those cases?
Additionally, should we use new in this case? Wouldn't new create
a pointer to a C++ class? Or does it work differently for
extern(c++) classes?
Re: Is D so powerfull ??
On Monday, 9 November 2015 at 06:27:22 UTC, Daniel Murphy wrote:
On 9/11/2015 4:26 PM, Jeremy DeHaan wrote:
What is the correct way to use C++ class instances in D? Can
you by
chance give an example?
extern (C++) class X
{
...
}
extern (C++) void func(X x);
void main(string[] args)
{
func(new X());
}
etc
Didn't you say constructors and destructors are missing? What
should one do in those cases?
Re: Is D so powerfull ??
On 9/11/2015 4:26 PM, Jeremy DeHaan wrote:
What is the correct way to use C++ class instances in D? Can you by
chance give an example?
extern (C++) class X
{
...
}
extern (C++) void func(X x);
void main(string[] args)
{
func(new X());
}
etc
Re: Is D so powerfull ??
On Monday, 9 November 2015 at 05:16:50 UTC, Daniel Murphy wrote: On 9/11/2015 4:05 PM, Jeremy DeHaan wrote: Because that's what this page says: http://dlang.org/cpp_interface.html That page is out of date. Virtual and non-virtual member functions, static member functions, and free functions all work since ~2.066. The biggest missing thing is special member functions, ie ctor/dtor/operators. > Declaring it as a struct in D code is freaking genius. I wonder if > that works across the board with other compilers and OS's though. Mixing struct/class will only work properly with ABIs that mangle them the same way, so it's not portable. We should really update that page then. What is the correct way to use C++ class instances in D? Can you by chance give an example?
Re: Is D so powerfull ??
On 9/11/2015 4:05 PM, Jeremy DeHaan wrote: Because that's what this page says: http://dlang.org/cpp_interface.html That page is out of date. Virtual and non-virtual member functions, static member functions, and free functions all work since ~2.066. The biggest missing thing is special member functions, ie ctor/dtor/operators. > Declaring it as a struct in D code is freaking genius. I wonder if > that works across the board with other compilers and OS's though. Mixing struct/class will only work properly with ABIs that mangle them the same way, so it's not portable.
Re: Is D so powerfull ??
On Sunday, 8 November 2015 at 23:43:42 UTC, ZombineDev wrote: On Saturday, 7 November 2015 at 21:02:26 UTC, Jeremy DeHaan wrote: On Saturday, 7 November 2015 at 14:49:05 UTC, ZombineDev wrote: On Saturday, 7 November 2015 at 14:25:01 UTC, ZombineDev wrote: What standard C does not provide and D does: calling C++ free functions nested in namespaces, creating objects of C++ classes (with single inheritance), ... ... calling virtual and non-virtual methods on C++ classes from D Actually, you can only call virtual methods on classes. Using non-virtual methods isn't supported. Why do you think so? See: https://gist.github.com/ZombineDev/19f966273b4a82a5c2f1 Output: $ g++ --version g++ (Ubuntu 4.9.2-10ubuntu13) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ dmd --version DMD64 D Compiler v2.069.0-b2 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright $ ./build.sh $ ./d_class cpp.add(40, 2): 42 cpp.mul(1.5, 2f, 'B') 198 $ ./cpp_main d.add(7, 8): 15 d.mul(3.0, 2.0f, 'A'): 390 Because that's what this page says: http://dlang.org/cpp_interface.html It's about halfway down, but here's the section I am referring to says: Note: non-virtual functions, and static member functions, cannot be accessed. That's awesome if I am wrong, but that is what the C++ interfacing page says. Declaring it as a struct in D code is freaking genius. I wonder if that works across the board with other compilers and OS's though.
Re: Why does opCall disable struct-literal syntax?
On Monday, 9 November 2015 at 02:43:06 UTC, rcorre wrote: On Sunday, 8 November 2015 at 23:54:52 UTC, Adam D. Ruppe wrote: On Sunday, 8 November 2015 at 23:26:44 UTC, rcorre wrote: Is this just a technical limitation, or is there some other reasoning? Old bug/misdesign inherited from old D before there were struct constructors. It really should be the rest of the way fixed, but non-static and static methods, including opCall, are still not properly distinguished by the D language. Type.staticFunction(); // compiles, used to be done to kinda mimic constructors before they were there obj.staticFunction(); // also compiles, which means a change at this point would be a breaking change That seems like the opposite of what's happening here. It's not a static member being invoked on an instance, but an instance member being invoked on the type. Type.memberFunction() should never be possible, right? Oh, I think I see the confusion. If you _were_ to define static opCall, it could also be used on an instance. Which makes distinguishing the two ... problematic. Weird.
Re: Why does opCall disable struct-literal syntax?
On Sunday, 8 November 2015 at 23:54:52 UTC, Adam D. Ruppe wrote: On Sunday, 8 November 2015 at 23:26:44 UTC, rcorre wrote: Is this just a technical limitation, or is there some other reasoning? Old bug/misdesign inherited from old D before there were struct constructors. It really should be the rest of the way fixed, but non-static and static methods, including opCall, are still not properly distinguished by the D language. Type.staticFunction(); // compiles, used to be done to kinda mimic constructors before they were there obj.staticFunction(); // also compiles, which means a change at this point would be a breaking change That seems like the opposite of what's happening here. It's not a static member being invoked on an instance, but an instance member being invoked on the type. Type.memberFunction() should never be possible, right?
Re: ACCU 2016 conference
On 11/8/15 6:37 PM, Ali Çehreli wrote: On 11/08/2015 11:00 AM, Russel Winder via Digitalmars-d wrote: Only 1 week left to send in submissions proposing sessions for ACCU 2016: http://accu.org/index.php/conferences/accu_conference_2016/accu2016_cal l_for_sessions Given people are preparing proposals for DConf, preparing proposals for ACCU 2016 will be easy. Regarding publicity, it will be beneficial if we could get D books featured among ACCU book reviews. Astrid Byro posted Programming in D for review but I don't think there were any takers (the following link is for ACCU members only): http://lists.accu.org/mailman/private/accu-general/2015-August/047567.html Perhaps you can influence some people at ACCU to review that and other D books. :) Ali Great idea. Russel, do you think you could help with reviewing the three D books available? -- Andrei
Re: Why does opCall disable struct-literal syntax?
On Sunday, 8 November 2015 at 23:26:44 UTC, rcorre wrote: Is this just a technical limitation, or is there some other reasoning? Old bug/misdesign inherited from old D before there were struct constructors. It really should be the rest of the way fixed, but non-static and static methods, including opCall, are still not properly distinguished by the D language. Type.staticFunction(); // compiles, used to be done to kinda mimic constructors before they were there obj.staticFunction(); // also compiles, which means a change at this point would be a breaking change
Re: Is D so powerfull ??
On Saturday, 7 November 2015 at 21:02:26 UTC, Jeremy DeHaan wrote: On Saturday, 7 November 2015 at 14:49:05 UTC, ZombineDev wrote: On Saturday, 7 November 2015 at 14:25:01 UTC, ZombineDev wrote: What standard C does not provide and D does: calling C++ free functions nested in namespaces, creating objects of C++ classes (with single inheritance), ... ... calling virtual and non-virtual methods on C++ classes from D Actually, you can only call virtual methods on classes. Using non-virtual methods isn't supported. Why do you think so? See: https://gist.github.com/ZombineDev/19f966273b4a82a5c2f1 Output: $ g++ --version g++ (Ubuntu 4.9.2-10ubuntu13) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ dmd --version DMD64 D Compiler v2.069.0-b2 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright $ ./build.sh $ ./d_class cpp.add(40, 2): 42 cpp.mul(1.5, 2f, 'B') 198 $ ./cpp_main d.add(7, 8): 15 d.mul(3.0, 2.0f, 'A'): 390
Re: ACCU 2016 conference
On 11/08/2015 11:00 AM, Russel Winder via Digitalmars-d wrote: Only 1 week left to send in submissions proposing sessions for ACCU 2016: http://accu.org/index.php/conferences/accu_conference_2016/accu2016_cal l_for_sessions Given people are preparing proposals for DConf, preparing proposals for ACCU 2016 will be easy. Regarding publicity, it will be beneficial if we could get D books featured among ACCU book reviews. Astrid Byro posted Programming in D for review but I don't think there were any takers (the following link is for ACCU members only): http://lists.accu.org/mailman/private/accu-general/2015-August/047567.html Perhaps you can influence some people at ACCU to review that and other D books. :) Ali
Why does opCall disable struct-literal syntax?
I understand why _static_ opCall would disable it, as a static
call and struct construction are syntactically similar. But it
seems like instance opCall and struct literal construction should
be unambiguous:
struct S { int i; void opCall(int i) { } }
S s = S(3); // clearly a constructor
s(3); // clearly opCall
Is this just a technical limitation, or is there some other
reasoning?
See (http://dlang.org/operatoroverloading.html#function-call).
Re: ACCU 2016 conference
On 11/8/15 2:00 PM, Russel Winder via Digitalmars-d wrote: Only 1 week left to send in submissions proposing sessions for ACCU 2016: http://accu.org/index.php/conferences/accu_conference_2016/accu2016_cal l_for_sessions Given people are preparing proposals for DConf, preparing proposals for ACCU 2016 will be easy. Don't forget that I'll deliver a keynote and a D tutorial. OCCUPY ACCU! Andrei
Re: Metaprogramming in D - From a beginner's perspective
On Sunday, 8 November 2015 at 21:03:44 UTC, maik klein wrote: Here is the blog post https://maikklein.github.io/2015/08/11/Metaprogramming-D/ And the discussion on reddit: https://www.reddit.com/r/programming/comments/3s1qrt/metaprogramming_in_d_from_a_beginners_perspective/ Interesting read! The Engine class reminds me of a similar thing I did a while back when I was creating a simple entity system.
Metaprogramming in D - From a beginner's perspective
Here is the blog post https://maikklein.github.io/2015/08/11/Metaprogramming-D/ And the discussion on reddit: https://www.reddit.com/r/programming/comments/3s1qrt/metaprogramming_in_d_from_a_beginners_perspective/
Re: OS X libphobos2.so
On Sunday, 8 November 2015 at 18:12:04 UTC, bitwise wrote: On Saturday, 7 November 2015 at 08:37:40 UTC, Jacob Carlborg wrote: [...] Well, I'm speaking in relative terms when I say easy... ;) [...] Hi Bit, I'm very excited by your posts with your insights and progress into this issue. I'm afraid I am not able to help much (lacking in skills not enthusiasm). But Please keep going :) and keep us updated - if there is anything I can do to help - please don't hesitate to ask :) Thanks for the links you posted - I have started watching Martin's presentation with interest. --K
Re: Implement the "unum" representation in D ?
On Friday, 18 September 2015 at 03:19:26 UTC, Nick B wrote: On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di Franco wrote: I read the whole book and did not regret it at all, but I was already looking for good interval arithmetic implementations. I found that the techniques are not too different (though improved in important ways) from what is mainstream in verified computing. Hi, I haven't finished the book but have read over half of it and browsed the rest. I wanted to add that an implementation of unums would have advantages beyond verifiable computing. Some examples that spring to mind are: Using low precision (8-bit) unums to determine if an answer exists before using a higher precision representation to do the calculation (example briefly discussed in the book is ray tracing). More generally, unums can self-tune their precision which may be generally useful in getting high precision answers efficiently. It is possible for the programmer to specify the level of accuracy so that unums don't waste time calculating bits that have no meaning. Parallelisation - floating point ops are not associative but unum ops are. Tighter bounds on results than interval arithmetic or significance arithmetic. These are just a few areas where a software implementation could be useful. If you've ever had any issues with floating point, I'd recommend reading the book, not just because of the approach it proposes to solve these but also because it's very clearly written and quite entertaining (given the subject matter). Richard
ACCU 2016 conference
Only 1 week left to send in submissions proposing sessions for ACCU 2016: http://accu.org/index.php/conferences/accu_conference_2016/accu2016_cal l_for_sessions Given people are preparing proposals for DConf, preparing proposals for ACCU 2016 will be easy. -- 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: D for TensorFlow-like library
On 11/08/2015 01:36 PM, Muktabh wrote: It is a huge task and I am not going to achieve it all alone myself. I will start it alone but if my startup (which works on Deep Learning) scales up, we might work on it as a team. If you have an edge regarding design ideas for such an engine, that would be a task well worth tackling, and D is a great language for rapid development of efficient numeric code. I recommend securing the help of D experts here to get you started - e.g. share your code here early and often for feedback. Good luck! -- Andrei
Re: D for TensorFlow-like library
On Sunday, 8 November 2015 at 18:06:00 UTC, TheFlyingFiddle wrote: On Sunday, 8 November 2015 at 17:47:33 UTC, Muktabh wrote: We cannot make D bindings to it because it is a closed source project by Google and only a spec like mapreduce will be released, so I thought maybe I might try and come up with an open source implementation. I was just curious if D would be a good choice language for a library like this instead of C++ which is used by Google. Well, if you are going to write it yourself i see no reason why D would be any worse a language the C++. You can get the same speed, interface with the GPU in pretty much the same way etc. You could probably do a lot in compile time to simplify writing kernels in D. From my point of view D is simpler than C++ as-well so that should help implementation. (no headers, sane meta programming etc.) It does seem to be a huge undertaking however since tensorflow seems to be a very complex library. But if you feel confident in this domain then I would say go for it. It would be very cool to have something like this in D. Thanks for your answer. It is a huge task and I am not going to achieve it all alone myself. I will start it alone but if my startup (which works on Deep Learning) scales up, we might work on it as a team.
Re: OS X libphobos2.so
On Saturday, 7 November 2015 at 08:37:40 UTC, Jacob Carlborg wrote: On 2015-11-06 19:46, bitwise wrote: Currently, the compiler just calls ___tls_get_addr(void *p) to get the thread local copy of a global. If that function signature is altered to take a pointer to the image as well, the problem is solved. Hehe, you make it sound so easy. Perhaps I missed something and you know more than I do. But as far as I know you have two options: 1. Implement native TLS. This will require modifications to the compiler and minor tweaks in the runtime 2. Continue to use the custom TLS implementation but add support for dynamic libraries. This will require modifications to the compiler (as you said above) and major changes to the runtime The native TLS implementation works as you described above (roughly). I can hardly believe that the code Apple added to the dynamic linker to implement TLS is not necessary. I don't see how you can get around not implementing the same code as the dynamic linker does. I also think that this is a good opportunity to change to native TLS. I don't like this situation we have now: "Yeah, D is compatible with C, except TLS on OS X.". Well, I'm speaking in relative terms when I say easy... ;) Right now, TLS has a fairly simple implementation. DMD puts any global TLS vars into their own section in the binary. Then, at the point here those vars are accessed in code, DMD inserts a call to ___tls_get_addr(void*) to map the address of the var to some thread specific block of memory. When ___tls_get_addr() is called, it lazily instantiates a block of memory for the calling thread, memcpy's the TLS vars from the TLS section in the binary, and stores that thread local copy using pthread_set_specific(). Any subsequent calls to ___tls_get_addr() will simply use pthread_get_specific() to retrieve that block of memory, and map the received address to one pointing in that block. So, since binaries will not be mapped to overlapping address spaces, I can loop over all the binary images and find the range to which the argument of ___tls_get_addr() belongs, and map the pointer to the appropriate block of memory. I am concerned that looping over all binary images for each TLS access will have performance implications, but for now, this solution is good enough. Later, ___tls_get_addr() can be amended to pass a pointer to the image from which the TLS originated, allowing constant time lookup. I believe Martin has already done this for linux/fbsd, but I had time to look at this specific issue. So.. I've got a basic implementation working at this point. The global ctors are now used instead of that infernal dyld callback to initialize sections. I've tried loading(dynamically) a shared library, and everything seems to work. Next on the list is to work on how all this interacts with threads. Martin seems to have already solved this too, so it should be fairly straight forward. Currently, linking a dylib statically throws "thread.d(2916): Unable to suspend thread", but other wise, seems to work as expected. Anyways, I am open to any help on the TLS stuff if you've got time. Bit
Re: D for TensorFlow-like library
On Sunday, 8 November 2015 at 17:47:33 UTC, Muktabh wrote: We cannot make D bindings to it because it is a closed source project by Google and only a spec like mapreduce will be released, so I thought maybe I might try and come up with an open source implementation. I was just curious if D would be a good choice language for a library like this instead of C++ which is used by Google. Well, if you are going to write it yourself i see no reason why D would be any worse a language the C++. You can get the same speed, interface with the GPU in pretty much the same way etc. You could probably do a lot in compile time to simplify writing kernels in D. From my point of view D is simpler than C++ as-well so that should help implementation. (no headers, sane meta programming etc.) It does seem to be a huge undertaking however since tensorflow seems to be a very complex library. But if you feel confident in this domain then I would say go for it. It would be very cool to have something like this in D.
Re: Is D so powerfull ??
On Sunday, 8 November 2015 at 17:51:34 UTC, TheFlyingFiddle wrote: Pretty sure gc merging is done via the gc proxy in dlls/shared libraries. In the case of Linux/FreeBSD shared libraries, there is no merging to be done, as only one copy of the GC exists in the first place (we only support shared libraries when druntime is built as a shared library itself). — David
Re: Is D so powerfull ??
On Sunday, 8 November 2015 at 10:22:44 UTC, FreeSlave wrote: On Saturday, 7 November 2015 at 14:49:05 UTC, ZombineDev wrote: basically you don't have technical reasons not to use D :D What about the lack of proper support for dynamic libraries on Windows and OSX? I mean, GC merging is still not implemented, right? Pretty sure gc merging is done via the gc proxy in dlls/shared libraries. But there are lot's of other problems. Mainly that Phobos cannot be dynamically loaded (or is this fixed?) Last time i tried throwing exceptions did not work either. Also the export problems on windows have not really been fixed (see http://wiki.dlang.org/DIP45). Still I have used DLL's sucessfully for reloading plugins, it can be done but it's really a pain to use as it stands now.
Re: D for TensorFlow-like library
On Sunday, 8 November 2015 at 16:31:44 UTC, Jack Stouffer wrote: On Sunday, 8 November 2015 at 13:48:30 UTC, Muktabh wrote: Will it be a good idea to develop an opensource implementation in D than C++, if I try to write it? I mean, you can if you want to, but it would make more sense to just make bindings to library for D. Rewriting everything for a language in that language doesn't scale. Also, in the future, please post questions like this to the "Learn" page. Thanks. Sorry for posting it in the wrong group, I was not aware about the learn group. We cannot make D bindings to it because it is a closed source project by Google and only a spec like mapreduce will be released, so I thought maybe I might try and come up with an open source implementation. I was just curious if D would be a good choice language for a library like this instead of C++ which is used by Google.
Re: D for TensorFlow-like library
On Sunday, 8 November 2015 at 13:48:30 UTC, Muktabh wrote: Will it be a good idea to develop an opensource implementation in D than C++, if I try to write it? I mean, you can if you want to, but it would make more sense to just make bindings to library for D. Rewriting everything for a language in that language doesn't scale. Also, in the future, please post questions like this to the "Learn" page. Thanks.
D for TensorFlow-like library
Google recently announced a distributed computational graph engine called tensorflow (https://www.youtube.com/watch?v=90-S1M7Ny_o). They have written the backend in C++ and have a Python/C++ frontend. I am a D newbie and am reading through Ali's book, but still dont know enough about it, hence the question. Will it be a good idea to develop an opensource implementation in D than C++, if I try to write it ? Since I am reading about D, I would love if I can apply what I learn here. Sorry if the question sounds stupid, I am not a systems programmer and mostly work with Python-Numpy stack.
Re: Is D so powerfull ??
On Saturday, 7 November 2015 at 14:49:05 UTC, ZombineDev wrote: basically you don't have technical reasons not to use D :D What about the lack of proper support for dynamic libraries on Windows and OSX? I mean, GC merging is still not implemented, right?
Re: assert(0)
On Saturday, 7 November 2015 at 21:24:02 UTC, Fyodor Ustinov wrote: Colleagues, IMHO: If "assert" catch "fundamental programmers errors" - it should hang programm immediately with and without "-release". If "assert" catch not "too fundamental" errors - assert(0) should emit "Error" in both cases. Third option - assert(0) - it's a "special case" and halt program in both cases. But there should't be so that in one case the "fundamental error" and the other "not fundamental". It's my opinion. WBR, Fyodor. I strongly disagree. Without `-release`, the job of "fundamental programmers errors" is not to stop the program and prevent farther corruption(which is pointless - how do you know executing the `scope(exit)` and `scope(failure)` blocks will increase the corruption? Maybe they'll reduce it?), because when you are developing you shouldn't work with the only copies of important data files. Without `-release`, the role of `assert`s(and `Error`s in general) is the help the programmer fix these bugs. When I have a "fundamental programmer error" in my code, I prefer to get a stack trace from the exception mechanism than to find a core dump(that was hopefully generated) and rely on GDB's excellent support for D to analyze it. Besides, there are some very specific cases where it's acceptable to catch `Error`s - one of them is when you have a logging mechanism that can log these errors in a way/place that's easier for you to read - and then of course re-throws them. Halting the program on errors prevents this logging mechanism from doing it's thing.
Re: assert(0)
On Sunday, 8 November 2015 at 02:51:33 UTC, rsw0x wrote: Dumb question, does nothrow affect codegen? I'd be very surprised if it didn't. But even if it doesn't currently affect codegen, it likely will at some point in the future. - Jonathan M Davis
