On Mon, 2015-10-26 at 02:54 +0000, Elie Morisse via Digitalmars-d- announce wrote:
> 
[…]
> 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.

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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

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.

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

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.

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.

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.

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

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

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.

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.