On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
Here, the DIP Author clearly expresses two reasons why a
programmer may choose to declare a function to accept ref
arguments. The Language Maintainers see this
On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic
wrote:
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
wrote:
Here is a question (that I don't think has been asked) why not
@copy?
@copy this(ref Foo other) { }
It can be read as copy constructor, which would be
On Saturday, 20 February 2016 at 17:34:48 UTC, Nicolas F. wrote:
This is really cool and an interesting project, though I've got
one concern: How will this fit in with the rest of the C++
efforts done upstream? (...) or is the goal to upstream these
changes and make them an officially
On Thursday, 18 February 2016 at 03:07:22 UTC, Ali Çehreli wrote:
Congratulations! Any project that can get rid of moc is a big
achievement. :) Folks at CopperSpice had done the same in C++
with their Qt replacement:
http://www.copperspice.com/
Ali
Nice! I've never heard of them,
Hi all,
I now have a working D replacement for moc:
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/moc
For those unfamiliar with Qt, moc (the Meta-Object Compiler) is a
tool that generates additional code for Qt classes, code then
used by the signal/slot system,
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
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
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
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
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
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
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
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
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
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
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
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
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
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote:
Just to clarify then. If gdalwarper.h includes gdal.h and
GDALDatasetH is declared in gdal.h, then gdal.h gets imported
too?
Craig
On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote:
How do you understand which files
On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote:
Just to clarify then. If gdalwarper.h includes gdal.h and
GDALDatasetH is declared in gdal.h, then gdal.h gets imported
too?
Craig
So to give a more straight answer, modmap is an #include
directive so every header
On Tuesday, 19 May 2015 at 08:02:47 UTC, Suliman wrote:
Oh, I forgot to fix path at:
/etc/ldc.conf
Am I right understand that:
C:/Program Files (x86)/ldc/lib = C:\Program Files
(x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\lib
? Or I can't find more proper folder
The Unix path
On Monday, 18 May 2015 at 12:27:35 UTC, Kagamin wrote:
BTW how does it rely on having everything on the D side? Maybe
it's enough to have just instance size and method symbols?
I'm not sure what you mean.
But then there's problem with this inference: what if the type
is intended to be used
On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote:
Where set where Calypso should look header files?
It works the same as in C++, there are the standard header paths:
/usr/include, /usr/include/c++/4.9, /usr/local/include
And to add another header search path you can pass options to
On Wednesday, 13 May 2015 at 15:54:47 UTC, John Colvin wrote:
That's great! I'm looking forward to being able to easily make
direct use of some of the great C++ code out there.
Are there are performance pitfalls to watch out for that are
unique to the way calypso interfaces between D and C++?
On Thursday, 14 May 2015 at 20:23:47 UTC, Laeeth Isharc wrote:
Elie,
Congratulations on this very impressive work.
Out of curiosity, how far away do you think it is from being at
a beta stage that one can use to write non-critical work in ?
Thanks Laeeth,
It's not too far I think. When
On Saturday, 9 May 2015 at 19:16:33 UTC, Elie Morisse wrote:
On Saturday, 9 May 2015 at 02:58:58 UTC, Mike wrote:
Question: You are using a modified version of LDC, but is
that compiler required to consume link to a library created
with that custom compiler? What I mean is: Can you use this
On Saturday, 9 May 2015 at 02:58:58 UTC, Mike wrote:
Question: You are using a modified version of LDC, but is that
compiler required to consume link to a library created with
that custom compiler? What I mean is: Can you use this
modified version of LDC to create a library, and then use a
Hi!
Calypso just got a D translation of the first Qt5 Widgets
tutorial building and running:
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d
Result: http://homo-nebulus.fr/dlang/oh%20my.webm
Compilation log: https://paste.kde.org/pewbbsw45
Previously Calypso
On Wednesday, 22 April 2015 at 14:57:43 UTC, Kagamin wrote:
What about Qt? I don't remember it being heavily templated.
Thanks for the hint, it's definitely true for most of the code of
Qt although there are still a few areas like QtCore/qtypetraits.h
or Q_STATIC_ASSERT in non-C++11 mode
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote:
Could anybody wrote very simple tutorial, that show how to use
any popular C/C++ lib without binding? I mean step by step
manual.
Also it would be nice to get binary builds for Windows to test.
Sorry for the wait.
So Calypso still
I should have given the same warning, there's a chance that
Calypso may work with not too sophisticated C++ libraries but new
bugs are around the corner if you try anything too big.
Nevertheless Suliman, Laeeth and maybe others have been wanting
to try it out in its current state, and it was
On Thursday, 16 April 2015 at 06:43:25 UTC, Suliman wrote:
Could anybody wrote very simple tutorial, that show how to use
any popular C/C++ lib without binding? I mean step by step
manual.
Also it would be nice to get binary builds for Windows to test.
Suliman sorry for keeping you waiting
Sorry for the lack of updates, progress was a bit boring for the
past 2 months and consisted mostly in crawling my way up a
bottomless pit of errors generated by « import (C++) Ogre.Light;
».
And then this happens: https://paste.kde.org/pse8pqzch :D
The compilation speed could be improved,
On Tuesday, 24 February 2015 at 08:44:25 UTC, Kagamin wrote:
On Tuesday, 24 February 2015 at 08:39:39 UTC, Kelly wrote:
due to class value support being incomplete
What about using that trick: recognize C++ classes and
represent them internally as structs with altered mangling - at
least it
On Wednesday, 18 February 2015 at 08:52:33 UTC, Kelly wrote:
Hello Elie,
I just pushed a small pull request for
fromTypeTemplateSpecialization. I forgot to mention in the
request that the changes allow bitset.d to be compiled and run
again.
Thanks for looking into this, I'll check your PR.
Hi Kelly,
It's done, I've merged latest LDC upstream + your build fixes
into Calypso.
About Microsoft vtables they work much more differently from the
Itanium ones than I thought, it's going to a lot trickier than
just a few lines of code so I won't be able to make D classes
inheriting
On Sunday, 15 February 2015 at 11:48:50 UTC, Kelly wrote:
Alirighty, Calypso builds and runs on both Linux and Win64 with
that last change from today in my fork. Now when I say 'runs'
on Linux, I mean it runs properly and fully (compiling and
running all examples from Feb 8th)...but when I say
Anyway I'm probably fixing the last issue right now preventing
std::vector from instantiating so I'm going to push the commits
to master in the hour.
On Friday, 13 February 2015 at 09:49:51 UTC, Kelly wrote:
Hello Elie,
Ok, I have merged in the newest LDC with Calypso from github
today and built it with vs2013 on Win7 :)
There is a small diff involved in getting things to compile.
The resulting ldc2 runs and builds a simple hello world
On Monday, 9 February 2015 at 04:27:06 UTC, Kelly wrote:
Thanks, just got that tangled mess of templates that is
std::string working too:
Hey Elie, this is great stuff, as usual. I have written a test
file for bitset here also (including a couple failures I am
sure you are aware of, but
On Monday, 9 February 2015 at 07:10:56 UTC, Suliman wrote:
If somebody have working Windows build, could you please share
it?
It would be nice to know if someone even managed to build Calypso
on Windows yet :)
On Monday, 9 February 2015 at 20:17:33 UTC, Andrei Alexandrescu
wrote:
You may
Small update: std::vector is now working.
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d
I went back to simpler problems than getting Ogre to work and
will focus on the C++ standard lib until the common class
templates work.
On Sunday, 8 February 2015 at 20:56:31 UTC, Syro wrote:
That is really cool.
Thanks, just got that tangled mess of templates that is
std::string working too:
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/string.d
Hi Laeeth,
Could you post the errors and which compiler you are using? If
you managed to build both LDC and Clang you should be pretty
close to get Calypso working.
Would there be any chance you could fork a version of clang that
works with Calypso, and then link to it in the instructions?
On Friday, 23 January 2015 at 12:29:56 UTC, Kelly wrote:
Hello Elie,
This project looks great, thanks for the hard work. I
downloaded Calypso and ldc2 about 6 hours ago to try your
project out.
I can get Calypso to compile with a couple small changes to
assistbuilder.cpp (just adding a
On Friday, 23 January 2015 at 10:02:55 UTC, Jacob Carlborg wrote:
Could this work for Objective-C as well. I'm working on adding
support for Objective-C to DMD [1].
[1] https://github.com/D-Programming-Language/dmd/pull/4321
It's planned to add Objective-C to Calypso, although I never used
Nevermind it's just that CodeGen is ambiguous with clang::CodeGen
although my compiler doesn't complain. Fixed.
On Friday, 23 January 2015 at 23:06:16 UTC, Kelly wrote:
People might still need the small quick fixes for
gen/cpp/assistbuilder.cpp, but just adding clang:: in a
couple spots shouldn't be too arduous for anybody if they
really want to compile and play with Calypso.
Weird, assistbuilder.cpp
On Thursday, 22 January 2015 at 07:27:03 UTC, Suliman wrote:
First you need a LLVM + Clang 3.5 source tree, built libraries
and the Clang binaries. Installing binary packages from your
distribution isn't enough since the include/ files aren't
exposing many symbols, so the source packages are
On Thursday, 22 January 2015 at 00:08:13 UTC, Walter Bright wrote:
Just making STL work would be an achievement!
Is the output of Calypso a file that can be imported?
The only outputs specific to Calypso are ligthweight object files
per C++ module that contain symbols created by LDC for
On Wednesday, 21 January 2015 at 10:37:18 UTC, Suliman wrote:
Could you explain how to build it's on Windows. I read readme,
but do not fully understand what I should to to to get it's
work?
You should follow the guides for LDC only you need to build Clang
3.5 as well beforehand and add the
On Tuesday, 23 December 2014 at 11:53:38 UTC, Dicebot wrote:
By upstream I don't mean LDC upstream but D upstream - we don't
want it to become part of full language spec if implementation
is so reliable on specific toolchain. It has been already
discussed when Jacob proposed dstep
On Tuesday, 23 December 2014 at 15:20:18 UTC, Kagamin wrote:
On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote:
• Structs
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/showcase.d
testClass cls = new testInherit;
This should be written
testClass* cls = new
On Tuesday, 23 December 2014 at 15:20:18 UTC, Kagamin wrote:
On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote:
• Structs
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/showcase.d
testClass cls = new testInherit;
This should be written
testClass* cls = new
Hi everyone,
I have the pleasure to announce to you all the existence of a
modified LDC able to interface directly to C++ libraries, wiping
out the need to write bindings:
https://github.com/Syniurge/Calypso
It's at a prototype stage, but its C++ support is pretty wide
already:
•
On Tuesday, 23 December 2014 at 00:01:30 UTC, Rikki Cattermole
wrote:
Will you be upstreaming this? Or maintaining this completely
yourself?
The ultimate goal is upstream, but first I need to agree with the
main DMD and LDC contributors about how this should really be
done. I.e atm the
56 matches
Mail list logo
