www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Calypso progress report (+ updated MingW64 build)

reply Elie Morisse <syniurge gmail.com> writes:
It's been a while since the last update, so here's a quick one 
before making the jump to LDC 0.16.

Kelly added a more complex Qt5 demo, I recently added an Ogre3D 
one:

   https://www.youtube.com/watch?v=eryhDOa9MV0
   
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/ogre3d/demo.d

Ogre3D is a much more "sophisticated" creature than Qt5, relies 
on some Boost libraries, so Calypso had to reach quite another 
level to support it.

As a reminder Calypso (https://github.com/Syniurge/Calypso) is an 
experimental LDC fork which lets you use C/C++ libraries without 
having to write bindings. Its main additions:

  • Maps C++ functions, global variables, structs, classes, 
unions, enums, typedefs, templates
  • C++ class and function template instantiation (including 
global variables inside class templates with their proper 
initialization in the global ctor)
  • C++ class creation with the correct calls to ctors 
(destruction is still disabled)
  • Virtual function calls
  • Static casts between C++ base and derived classes (incl. 
multiple inheritance offsets)
  • D classes inheriting from C++ classes, including the correct 
vtable generation for the C++ part of the class (except for MSVC 
which has a different ABI)
  • Debug info generation for any C++ symbol instantiated by D code

The roadmap is:

  merge upstream LDC 0.16 into Calypso → C++ exception support → 
better C++11 support → MSVC support → extend magicport2 to 
convert Calypso to D (and Calypso could "bootstrap" itself to 
avoid writing bindings to Clang) → make Calypso an optional 
shared library

On Linux Calypso should be in a state usable enough to start a 
project assuming the lack of C++ exceptions or class destruction 
isn't a blocker to start it (but I'm looking into the latter 
right now), it has held up quite well while expanding the Ogre 
and Qt5 demos, and my own project based on Qt5 and OpenCV.

So far only Kelly Wilson has been testing Calypso with various 
libs and expanded the test cases (most of the libstdc++ samples 
are his), so more testing would be very helpful.


Updated MingW build: 
http://www.homo-nebulus.fr/dlang/Calypso-Mingw64-i686-4.9.3-posix-dwarf-rt_v4-rev1.tar.xz
Oct 21 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/21/2015 07:40 PM, Elie Morisse wrote:

 It's been a while since the last update, so here's a quick one before
 making the jump to LDC 0.16.


Great news! What's the story on exceptions? Does Calypso allow D code to 
catch exceptions thrown from C++ code? -- Andrei
Oct 21 2015
next sibling parent Elie Morisse <syniurge gmail.com> writes:
On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu 
wrote:

 On 10/21/2015 07:40 PM, Elie Morisse wrote:

 It's been a while since the last update, so here's a quick one 
 before
 making the jump to LDC 0.16.


 Great news! What's the story on exceptions? Does Calypso allow 
 D code to catch exceptions thrown from C++ code? -- Andrei


Hi Andrei,

Not yet but I've looked into it, the plan is to add:

   catch (C++) (...) { }

statements and make Clang translate them into C++ landing pads 
(as for imports the parser will query the language plugins when 
encountering two pairs of (), so the C++-specific statement will 
be part of Calypso, not DMD).

Then add a "C++ exception class" handler in LDC's personality 
function:

   
https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/eh/libunwind.d#L327

Easier said that done but Clang should make the std::type_info 
matching doable.

So it's on the roadmap just after the merge of LDC 0.16.
Oct 21 2015
prev sibling parent reply Elie Morisse <syniurge gmail.com> writes:
On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu 
wrote:

 Great news! What's the story on exceptions? Does Calypso allow 
 D code to catch exceptions thrown from C++ code? -- Andrei


Small update: the LDC 0.16.1 merge was done and it's now possible 
to catch about any C++ exception with catch (C++) (..) {..} 
statements.

   
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d

Output:

     Throwing an ooops exception
     Catching the ooops, e.what() == Ooops!

     Throwing another ooops exception
     Catching the std::exception, e.what() == Ooops!

     Now throwing a float
     Catching the float, f == 20.160000!


What's left to implement for full C++ EH support:
  - catching class/struct by value (it's already possible to catch 
thrown class values by reference though)
  - thrown object lifetime
  - rethrowing
Nov 15 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/15/2015 02:32 PM, Elie Morisse wrote:

 On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu wrote:

 Great news! What's the story on exceptions? Does Calypso allow D code
 to catch exceptions thrown from C++ code? -- Andrei


 Small update: the LDC 0.16.1 merge was done and it's now possible to
 catch about any C++ exception with catch (C++) (..) {..} statements.

 https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d


 Output:

      Throwing an ooops exception
      Catching the ooops, e.what() == Ooops!

      Throwing another ooops exception
      Catching the std::exception, e.what() == Ooops!

      Now throwing a float
      Catching the float, f == 20.160000!


 What's left to implement for full C++ EH support:
   - catching class/struct by value (it's already possible to catch
 thrown class values by reference though)
   - thrown object lifetime
   - rethrowing


That's great progress. Do you have documentation for how things work? 
For example, what's the lifetime of the pointer people will get from 
std::exception::what().

IMHO: don't worry about catching exceptions by value; it's almost always 
either incorrect, uninteresting, or both. The prize is catching 
(references to) classes rooted in std::exception. Nice-to-have is 
catching (references to) classes rooted in other C++ classes.

A blog post would be fantastic.


Andrei
Nov 16 2015
parent reply Elie Morisse <syniurge gmail.com> writes:
On Monday, 16 November 2015 at 19:35:58 UTC, Andrei Alexandrescu 
wrote:

 That's great progress. Do you have documentation for how things 
 work? For example, what's the lifetime of the pointer people 
 will get from std::exception::what().

 IMHO: don't worry about catching exceptions by value; it's 
 almost always either incorrect, uninteresting, or both. The 
 prize is catching (references to) classes rooted in 
 std::exception. Nice-to-have is catching (references to) 
 classes rooted in other C++ classes.

 A blog post would be fantastic.


 Andrei


Finally there: 
https://syniurgeblog.wordpress.com/2015/11/20/catching-cpp-exceptions-in-d/

Although a little late and probably less user-oriented than you 
wanted?


 For example, what's the lifetime of the pointer people will get 
 from std::exception::what().


The exception object gets destroyed on exiting the catch (C++) 
block if the exception isn't rethrown.
Nov 21 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 November 2015 at 17:28:12 UTC, Elie Morisse wrote:

 Finally there: 
 https://syniurgeblog.wordpress.com/2015/11/20/catching-cpp-exceptions-in-d/

 Although a little late and probably less user-oriented than you 
 wanted?


 For example, what's the lifetime of the pointer people will 
 get from std::exception::what().


 The exception object gets destroyed on exiting the catch (C++) 
 block if the exception isn't rethrown.


I'd be very interested by the LLVM IR that this spout out. Also, 
good work, pulling that one is hard.
Nov 22 2015
parent reply Elie Morisse <syniurge gmail.com> writes:
On Monday, 23 November 2015 at 00:04:44 UTC, deadalnix wrote:

 I'd be very interested by the LLVM IR that this spout out.


Here's the IR for 
https://github.com/Syniurge/Calypso/blob/master/tests/calyps
/eh/std_exception.d :

   https://paste.kde.org/pjxrqjjhp


 Also, good work, pulling that one is hard.


It wasn't that hard to be honest, I took many shortcuts thanks to 
Clang and Calypso.

But even without them it's doable. About the issue you mentioned 
in the other thread, I don't think generating std::type_info 
values will be too big of a hindrance for Walter. Looking at 
cxxabi.h the classes derived from type_info all have simple 
layouts so generating values at least for classes singly 
inheriting from std::exception should be achievable without too 
much sweat.
Nov 23 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Monday, 23 November 2015 at 23:33:21 UTC, Elie Morisse wrote:

 On Monday, 23 November 2015 at 00:04:44 UTC, deadalnix wrote:

 I'd be very interested by the LLVM IR that this spout out.


 Here's the IR for 
 https://github.com/Syniurge/Calypso/blob/master/tests/calyps
/eh/std_exception.d :

   https://paste.kde.org/pjxrqjjhp


 Also, good work, pulling that one is hard.


 It wasn't that hard to be honest, I took many shortcuts thanks 
 to Clang and Calypso.

 But even without them it's doable. About the issue you 
 mentioned in the other thread, I don't think generating 
 std::type_info values will be too big of a hindrance for 
 Walter. Looking at cxxabi.h the classes derived from type_info 
 all have simple layouts so generating values at least for 
 classes singly inheriting from std::exception should be 
 achievable without too much sweat.


Yeah that's what I wanted to look int he IR. Where is 
_D_ZTISt9exception7__tiwrap defined ? Looks like you trimed the 
output :(
Nov 23 2015
parent reply Elie Morisse <syniurge gmail.com> writes:
On Tuesday, 24 November 2015 at 06:44:31 UTC, deadalnix wrote:

 Yeah that's what I wanted to look int he IR. Where is 
 _D_ZTISt9exception7__tiwrap defined ? Looks like you trimed the 
 output :(


Sorry I got a little heavy handed, here's the full IR: 
https://paste.kde.org/piivojs0s
Nov 24 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 24 November 2015 at 22:51:40 UTC, Elie Morisse wrote:

 On Tuesday, 24 November 2015 at 06:44:31 UTC, deadalnix wrote:

 Yeah that's what I wanted to look int he IR. Where is 
 _D_ZTISt9exception7__tiwrap defined ? Looks like you trimed 
 the output :(


 Sorry I got a little heavy handed, here's the full IR: 
 https://paste.kde.org/piivojs0s


<3 <3 <3 <3
Nov 24 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 25 November 2015 at 01:04:19 UTC, deadalnix wrote:

 On Tuesday, 24 November 2015 at 22:51:40 UTC, Elie Morisse 
 wrote:

 On Tuesday, 24 November 2015 at 06:44:31 UTC, deadalnix wrote:

 Yeah that's what I wanted to look int he IR. Where is 
 _D_ZTISt9exception7__tiwrap defined ? Looks like you trimed 
 the output :(


 Sorry I got a little heavy handed, here's the full IR: 
 https://paste.kde.org/piivojs0s


 <3 <3 <3 <3


I can't find the runtime that goes with this. My best guess was 
here: 
https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/common.d
But it doesn't check the source language.

Can I get some pointers ?
Nov 24 2015
parent Elie Morisse <syniurge gmail.com> writes:
On Wednesday, 25 November 2015 at 06:57:14 UTC, deadalnix wrote:

 I can't find the runtime that goes with this. My best guess was 
 here: 
 https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/common.d
But it doesn't check the source language.

 Can I get some pointers ?


In case you haven't found already, the rest of the changes lies 
next door in libunwind.d. Then if you're after the differences 
from vanilla LDC you could ctrl+f for // CALYPSO comments (I've 
made a habit of tagging all the departures from vanilla code with 
these), or you could browse the diff from the single commit:

https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1#diff-da783b0dc7ec2a5b78b6c4479a320d08
Nov 25 2015
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse wrote:

 It's been a while since the last update, so here's a quick one 
 before making the jump to LDC 0.16.


You should write a blog post explaining what you have done so far 
and what remains to be done, then submit it to the usual link 
sites.  I bet a lot of people would be interested in reading 
about this approach.
Oct 21 2015
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 22 October 2015 at 03:14:39 UTC, Joakim wrote:

 On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse 
 wrote:

 It's been a while since the last update, so here's a quick one 
 before making the jump to LDC 0.16.


 You should write a blog post explaining what you have done so 
 far and what remains to be done, then submit it to the usual 
 link sites.  I bet a lot of people would be interested in 
 reading about this approach.


Second.
Oct 22 2015
prev sibling next sibling parent Suliman <evermind live.ru> writes:
On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse wrote:

 make Calypso an optional shared library


Does it's mean, that Calypso can be work as plugin for Clang?
Oct 21 2015
prev sibling next sibling parent reply Szymon Gatner <noemail gmail.com> writes:
On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse wrote:

 It's been a while since the last update, so here's a quick one 
 before making the jump to LDC 0.16.

 Kelly added a more complex Qt5 demo, I recently added an Ogre3D 
 one:

   https://www.youtube.com/watch?v=eryhDOa9MV0
   
 https://github.com/Syniurge/Calypso/blob/master/tests/calypso/ogre3d/demo.d

 Ogre3D is a much more "sophisticated" creature than Qt5, relies 
 on some Boost libraries, so Calypso had to reach quite another 
 level to support it.


Wow, this is fantastic. What about Windows and iOS support?
Oct 22 2015
next sibling parent reply Szymon Gatner <noemail gmail.com> writes:
On Thursday, 22 October 2015 at 15:22:16 UTC, Szymon Gatner wrote:

 On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse 
 wrote:

 It's been a while since the last update, so here's a quick one 
 before making the jump to LDC 0.16.

 Kelly added a more complex Qt5 demo, I recently added an 
 Ogre3D one:

   https://www.youtube.com/watch?v=eryhDOa9MV0
   
 https://github.com/Syniurge/Calypso/blob/master/tests/calypso/ogre3d/demo.d

 Ogre3D is a much more "sophisticated" creature than Qt5, 
 relies on some Boost libraries, so Calypso had to reach quite 
 another level to support it.


 Wow, this is fantastic. What about Windows and iOS support?


By Windows I meant Win32/x86
Oct 22 2015
parent Kai Nacke <kai redstar.de> writes:
On Thursday, 22 October 2015 at 15:23:34 UTC, Szymon Gatner wrote:

 On Thursday, 22 October 2015 at 15:22:16 UTC, Szymon Gatner 
 wrote:

 On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse 
 wrote:

 It's been a while since the last update, so here's a quick 
 one before making the jump to LDC 0.16.

 Kelly added a more complex Qt5 demo, I recently added an 
 Ogre3D one:

   https://www.youtube.com/watch?v=eryhDOa9MV0
   
 https://github.com/Syniurge/Calypso/blob/master/tests/calypso/ogre3d/demo.d

 Ogre3D is a much more "sophisticated" creature than Qt5, 
 relies on some Boost libraries, so Calypso had to reach quite 
 another level to support it.


 Wow, this is fantastic. What about Windows and iOS support?


 By Windows I meant Win32/x86


Win32/x86 is on the todo-list for the LDC release. I assume that 
once merged Calypso will support Win32/x86, too. (There is still 
work to do on x86 exception support in LLVM.)

Regards,
Kai
Oct 22 2015
prev sibling parent reply Elie Morisse <syniurge gmail.com> writes:
On Thursday, 22 October 2015 at 06:28:06 UTC, Suliman wrote:

 Does it's mean, that Calypso can be work as plugin for Clang?


As a LDC plugin, so that LDC doesn't depend on Clang.

On Thursday, 22 October 2015 at 15:22:16 UTC, Szymon Gatner wrote:

 Wow, this is fantastic. What about Windows and iOS support?


MSVC hasn't been tested since 5 months ago. Calypso built by MSVC 
compiles basic examples but last time we tried none of the C++ 
standard lib test cases worked. Maybe it's better now that the 
template support is more robust but I've postponed work on MSVC 
until LDC 0.16 which includes the Win64 work by kinke.

The MingW x86 build works better and compiles most libstdc++ 
samples but hasn't been tested much either.

I'll come back to MSVC after improving the C++11 support, because 
one Achilles' heel of Calypso is currently whenever template 
argument deduction is involved and both MSVC's standard lib and 
C++11-enabled GNU libstdc++ makes heavy usage of template 
argument deduction. It's because Calypso relies on a hack that 
doesn't handle every case yet, although the situation has 
improved a lot and it works well enough to handle some Boost 
libraries.
Oct 22 2015
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 22 October 2015 at 23:23:50 UTC, Elie Morisse wrote:

 MSVC hasn't been tested since 5 months ago. Calypso built by 
 MSVC compiles basic examples but last time we tried none of the 
 C++ standard lib test cases worked. Maybe it's better now that 
 the template support is more robust but I've postponed work on 
 MSVC until LDC 0.16 which includes the Win64 work by kinke.


You might find this informative as well, if you were not aware:
http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/
Oct 22 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse wrote:

 On Linux Calypso should be in a state usable enough to start a 
 project assuming the lack of C++ exceptions or class 
 destruction isn't a blocker to start it (but I'm looking into 
 the latter right now), it has held up quite well while 
 expanding the Ogre and Qt5 demos, and my own project based on 
 Qt5 and OpenCV.


Cool, is that a value type QString? Really? Then functions in Qt5 
demo should accept QString by ref to better match C++.
Are copy constructors and assignment operator invoked?
As I see default constructors are not invoked yet?
Oct 22 2015
parent reply Elie Morisse <syniurge gmail.com> writes:
On Thursday, 22 October 2015 at 18:02:08 UTC, Kagamin wrote:

 Cool, is that a value type QString? Really? Then functions in 
 Qt5 demo should accept QString by ref to better match C++.


Not sure if I already announced it here but one major change a 
few months ago is that all C++ classes are now value types, it 
made things a lot saner.

I think the reason why Kelly didn't use ref was to be able to 
write loadFile(QString("myFilename")) instead of:

     auto s_myFilename = QString("myFilename");
     loadFile(s_myFilename); // only takes lvalues

Add me to the people who'd really love D to get through this once 
and for all btw :)


 Are copy constructors and assignment operator invoked?
 As I see default constructors are not invoked yet?


Default constructors are invoked, and I should have added another 
line to the list of main features:

  • Maps C++ overloaded operators to D operators when an 
equivalent exists (and others are mapped to normal functions 
named e.g __opUnaryArrow for operator->)

Since D doesn't support non-member overloaded operators those 
aren't usable as in C++, I need to work on a solution for this 
(there's already some groundwork actually, non-member operators 
that take for example a std::basic_string left operand are mapped 
as part of the std.basic_string module).

Currently copy constructors aren't invoked when calling functions 
with class/struct byval arguments, arguments are memcpy'd. This 
is another important missing feature I should implement asap.
Oct 22 2015
parent reply Kagamin <spam here.lot> writes:
On Thursday, 22 October 2015 at 23:24:57 UTC, Elie Morisse wrote:

 Default constructors are invoked


Including class fields?

class A
{
   QString s_myFilename;
   this()
   {
     //is s_myFilename constructed already?
   }
}
Oct 23 2015
parent reply Elie Morisse <syniurge gmail.com> writes:
On Friday, 23 October 2015 at 09:19:44 UTC, Kagamin wrote:

 On Thursday, 22 October 2015 at 23:24:57 UTC, Elie Morisse 
 wrote:

 Default constructors are invoked


 Including class fields?

 class A
 {
   QString s_myFilename;
   this()
   {
     //is s_myFilename constructed already?
   }
 }


That triggered my own assert, oops. It's fixed now, the field 
default ctor is called if the field has no initializer, just 
before A's ctor.
Oct 25 2015
parent reply Stefan <SHertenberger web.de> writes:
Hello,

// compile with: ldc2 -cpp-args -std=gnu++11 main.d

modmap (C++) "cmath";

import (C++) std._;

import std.stdio;

int main()
{
   writeln(sin(cast(float)0.8159));
	return 0;
}

gives a lot of "error: constexpr function never produces a 
constant expression" messages. Not sure this is supposed to work?
Oct 25 2015
next sibling parent Elie Morisse <syniurge gmail.com> writes:
On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:

 Hello,

 // compile with: ldc2 -cpp-args -std=gnu++11 main.d

 modmap (C++) "cmath";

 import (C++) std._;

 import std.stdio;

 int main()
 {
   writeln(sin(cast(float)0.8159));
 	return 0;
 }

 gives a lot of "error: constexpr function never produces a 
 constant expression" messages. Not sure this is supposed to 
 work?


Hi and thank you for testing!

The code compiles and runs with C++11 disabled, I don't know why 
these errors occur while generating the PCH with C++11 enabled, 
looking into it.
Oct 25 2015
prev sibling parent reply Elie Morisse <syniurge gmail.com> writes:
On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:

 Hello,

 // compile with: ldc2 -cpp-args -std=gnu++11 main.d

 modmap (C++) "cmath";

 import (C++) std._;

 import std.stdio;

 int main()
 {
   writeln(sin(cast(float)0.8159));
 	return 0;
 }

 gives a lot of "error: constexpr function never produces a 
 constant expression" messages. Not sure this is supposed to 
 work?


It's fixed with the latest commit.
Oct 25 2015
parent reply Laeeth Isharc <spamnolaeeth nospamlaeeth.com> writes:
On Monday, 26 October 2015 at 01:39:52 UTC, Elie Morisse wrote:

 On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:

 Hello,

 // compile with: ldc2 -cpp-args -std=gnu++11 main.d

 modmap (C++) "cmath";

 import (C++) std._;

 import std.stdio;

 int main()
 {
   writeln(sin(cast(float)0.8159));
 	return 0;
 }

 gives a lot of "error: constexpr function never produces a 
 constant expression" messages. Not sure this is supposed to 
 work?


 It's fixed with the latest commit.


any chance of some release builds on github when the time is 
right?  I've tried a few times, and somewhat embarrassingly each 
time I get a bit further, but still never made it to a usable 
version of ldc-calypso.  I didn't want to file bug report as 
figure you have better things to do at this stage and it's a 
moving target. ldc itself I can compile fine (without your mods).

I'd be interested in seeing if quantlib is usable.  it's a 
library that's quite popular in finance world, and might open up 
the set of people that are interested in exploring D.
Oct 25 2015
parent reply Elie Morisse <syniurge gmail.com> writes:
On Monday, 26 October 2015 at 01:52:37 UTC, Laeeth Isharc wrote:

 any chance of some release builds on github when the time is 
 right?  I've tried a few times, and somewhat embarrassingly 
 each time I get a bit further, but still never made it to a 
 usable version of ldc-calypso.  I didn't want to file bug 
 report as figure you have better things to do at this stage and 
 it's a moving target. ldc itself I can compile fine (without 
 your mods).

 I'd be interested in seeing if quantlib is usable.  it's a 
 library that's quite popular in finance world, and might open 
 up the set of people that are interested in exploring D.


Hi Laeeth,

Were you trying to build it on Linux? I uploaded a Linux build: 
http://www.homo-nebulus.fr/dlang/Calypso-x86_64-Ubuntu15_04-2015_10_25.tar.xz

The build process got much simpler 2 weeks ago though, now that 
it doesn't depend on an LLVM source tree and an external Clang 
executable anymore it's almost identical to building LDC.

Let me know how Calypso fares with quantlib.
Oct 25 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2015-10-26 at 02:54 +0000, Elie Morisse via Digitalmars-d-
announce wrote:

=20


[=E2=80=A6]

 The build process got much simpler 2 weeks ago though, now that=20
 it doesn't depend on an LLVM source tree and an external Clang=20
 executable anymore it's almost identical to building LDC.


In which case I will start trying to build it and use it. If D code can
access C++ as well as C libraries without masses of adapter building,
the case for D get very much stronger.

An obviously interesting case is whether:

a. GtkD can make use of the features.

b. Whether we can create a Qt system more easily than any of the
current methods.

The backdrop to this follows on from the point Laeeth made about
quantlib. Being able to do the calculations is one thing, but
visualizing the data and results is where the real hook is. Hence it is
Matplotlib that is the real USP of the
Python/NumPy/SciPy/Pandas/IPython/Jupyter stack. Also the plotting in
R, Matlab, Mathematica.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 26 2015
parent reply bachmeier <no spam.net> writes:
On Monday, 26 October 2015 at 07:49:02 UTC, Russel Winder wrote:

 The backdrop to this follows on from the point Laeeth made 
 about quantlib. Being able to do the calculations is one thing, 
 but visualizing the data and results is where the real hook is. 
 Hence it is Matplotlib that is the real USP of the 
 Python/NumPy/SciPy/Pandas/IPython/Jupyter stack. Also the 
 plotting in R, Matlab, Mathematica.


It's not difficult to embed R inside D. I will finish a 
forecasting project in early November, and will be able to finish 
it up after that. That will bring R's full plotting capabilities 
to D.
Oct 26 2015
next sibling parent Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
Elie - thanks for posting the build.  Have been working on 
something else past day, but this is on my list to look at next.  
Having quantlib work would be very nice for many financial users. 
  Lots of people use it, even just as a check on their own stuff.

Russell, I agree about the plotting, although the stuff I do for 
now is very simple as regards generating the image.  (I just need 
a bit of interactivity).  Speaking about charting today, someone 
mentioned that there are two cultures - science esp physics where 
purity is valued and pretty stuff is seen as not serious, and 
rest of world where people are only human and quite like the 
pretty stuff.

Bachmeier - great to hear about R.  looking forward to it.


Laeeth
Oct 26 2015
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 26 October 2015 at 23:39:19 UTC, bachmeier wrote:

 It's not difficult to embed R inside D. I will finish a 
 forecasting project in early November, and will be able to 
 finish it up after that. That will bring R's full plotting 
 capabilities to D.



This sounds cool. I look forward to it.
Oct 27 2015
parent reply bachmeier <no spam.com> writes:
On Tuesday, 27 October 2015 at 15:23:34 UTC, jmh530 wrote:

 On Monday, 26 October 2015 at 23:39:19 UTC, bachmeier wrote:

 It's not difficult to embed R inside D. I will finish a 
 forecasting project in early November, and will be able to 
 finish it up after that. That will bring R's full plotting 
 capabilities to D.



 This sounds cool. I look forward to it.


I've already written dmdinline to go in the other direction. I 
can reuse the underlying code I wrote for that for the 
interoperability, so all I have to do is create a C interface to 
RInside. Actually, that's what I did when I started using D, but 
I'll have to dig up my old code and polish it to the point that 
I'd be willing to share it.
Oct 27 2015
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 27 October 2015 at 15:33:04 UTC, bachmeier wrote:

 I've already written dmdinline to go in the other direction. I 
 can reuse the underlying code I wrote for that for the 
 interoperability, so all I have to do is create a C interface 
 to RInside. Actually, that's what I did when I started using D, 
 but I'll have to dig up my old code and polish it to the point 
 that I'd be willing to share it.


Hmm, I wasn't familiar with RInside (and it's several years old 
at this point). Dirk Eddelbuettel does some cool stuff. In 
general, I don't really have any sense of how people even get 
started on projects like this. I appreciate it though.
Oct 27 2015