Re: Calypso progress report (+ updated MingW64 build)

2015-11-25 Thread Elie Morisse via Digitalmars-d-announce

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


Re: Calypso progress report (+ updated MingW64 build)

2015-11-24 Thread deadalnix via Digitalmars-d-announce

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



Re: Calypso progress report (+ updated MingW64 build)

2015-11-24 Thread deadalnix via Digitalmars-d-announce

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 ?


Re: Calypso progress report (+ updated MingW64 build)

2015-11-24 Thread Elie Morisse via Digitalmars-d-announce

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


Re: Calypso progress report (+ updated MingW64 build)

2015-11-23 Thread deadalnix via Digitalmars-d-announce

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/calypso/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 :(


Re: Calypso progress report (+ updated MingW64 build)

2015-11-23 Thread Elie Morisse via Digitalmars-d-announce

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/calypso/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.


Re: Calypso progress report (+ updated MingW64 build)

2015-11-22 Thread deadalnix via Digitalmars-d-announce

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.




Re: Calypso progress report (+ updated MingW64 build)

2015-11-21 Thread Elie Morisse via Digitalmars-d-announce
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.


Re: Calypso progress report (+ updated MingW64 build)

2015-11-16 Thread Andrei Alexandrescu via Digitalmars-d-announce

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.16!


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



Re: Calypso progress report (+ updated MingW64 build)

2015-11-15 Thread Elie Morisse via Digitalmars-d-announce
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.16!


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


Re: Calypso progress report (+ updated MingW64 build)

2015-10-27 Thread jmh530 via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-27 Thread bachmeier via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-26 Thread Russel Winder via Digitalmars-d-announce
On Mon, 2015-10-26 at 02:54 +, 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.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: Calypso progress report (+ updated MingW64 build)

2015-10-26 Thread Laeeth Isharc via Digitalmars-d-announce
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




Re: Calypso progress report (+ updated MingW64 build)

2015-10-25 Thread Elie Morisse via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-25 Thread Stefan via Digitalmars-d-announce

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?


Re: Calypso progress report (+ updated MingW64 build)

2015-10-25 Thread Laeeth Isharc via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-25 Thread Elie Morisse via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-25 Thread Elie Morisse via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-25 Thread Elie Morisse via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-23 Thread Kagamin via Digitalmars-d-announce

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?
  }
}


Re: Calypso progress report (+ updated MingW64 build)

2015-10-22 Thread Kai Nacke via Digitalmars-d-announce

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


Re: Calypso progress report (+ updated MingW64 build)

2015-10-22 Thread Elie Morisse via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-22 Thread Elie Morisse via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-22 Thread jmh530 via Digitalmars-d-announce

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/


Re: Calypso progress report (+ updated MingW64 build)

2015-10-22 Thread jmh530 via Digitalmars-d-announce

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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-22 Thread Suliman via Digitalmars-d-announce

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?



Re: Calypso progress report (+ updated MingW64 build)

2015-10-21 Thread Elie Morisse via Digitalmars-d-announce
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.


Re: Calypso progress report (+ updated MingW64 build)

2015-10-21 Thread Andrei Alexandrescu via Digitalmars-d-announce

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




Re: Calypso progress report (+ updated MingW64 build)

2015-10-21 Thread Joakim via Digitalmars-d-announce

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.