Re: Fastest JSON parser in the world is a D project
If this is the benchmark I'm remembering, the bulk of the time is spent parsing the floating point numbers. So it isn't a test of JSON parsing in general so much as the speed of scanf.
Re: Fastest JSON parser in the world is a D project
On Saturday, 17 October 2015 at 16:14:01 UTC, Andrei Alexandrescu wrote: On 10/17/15 6:43 PM, Sean Kelly wrote: If this is the benchmark I'm remembering, the bulk of the time is spent parsing the floating point numbers. So it isn't a test of JSON parsing in general so much as the speed of scanf. In many cases the use of scanf can be replaced with drastically faster methods, as I discuss in my talks on optimization (including Brasov recently). I hope they'll release the videos soon. -- Andrei Oh absolutely. My issue with the benchmark is just that it claims to be a JSON parser benchmark but the bulk of CPU time is actually spent parsing floats. I'm on my phone though so perhaps this is a different benchmark--I can't easily check. The one I recall came up a year or so ago and was discussed on D.general.
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 17:15:49 UTC, Kelly wrote: Hello Suliman, I have translated the GDAL example ( http://www.gdal.org/warptut.html ) and got it to run...woohoo!! I needed to apply the fix from Elie last night (and the pull request from me that hasn't been accepted yet), so this won't work for you yet, unfortunately...soon hopefully. For comparison I have posted the translation here ( http://pastebin.com/VwrVeBJ3 ), but it may be a day or two yet before Calypso can compile it out-of-the-box, even if my pull requrest is accepted today. There is still one outstanding error that I couldn't fix. I had to cheat and modify a system file (not a good thing to ask others to do, obviously)!! Ok, this example for GDAL should work out-of-the-box with Calypso now (new git HEAD from last night). This took a while to get running because of a major rewrite that Elie was working on the last couple weeks. Things work quite a bit better now, with the new changes, so hopefully we can get some more examples working soon. Elie may chime in with more specifics on the need for the rewrite. I still haven't built this GDAL example on Windows, but if you can let me know if you try this Suliman, that would be great. Let me know if something doesn't work for you and we'll try to help out. Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote: import (C++) GDALWarpOperation; import (C++) GDALAccess; import (C++) GDALWarpOptions; How do you understand which files should be imported? These aren't files being imported, they are classes/structs/templates being imported for use. Files are 'modmap'ed not imported in Calypso. It can be tricky to know which classes/structs/templates need to be imported if you aren't writing a program from scratch AND know the library fairly well. What you can do is run Calypso and if it complains that there is an 'undefined identifier', then check to see if that identifier is a class/struct/template and try to import it to see if the problem is fixed. Not an ideal programming philosophy, of course, but it can help at the beginning to let Calypso do some work for you. There are also clues in the source code...if you have to 'new' anything then it will need probably to be imported. GDALWarpOptions* psWarpOptions = GDALCreateWarpOptions(); GDALWarpOptions* is type? would: auto psWarpOptions = GDALCreateWarpOptions(); work? This actually ties in with the question above...and yes, 'auto' will work. 'Auto' is definitely your friend with Calypso, as sometimes it isn't clear what the C++ type would translate into. Now the big thing with 'auto', in this case, is that if you use 'auto' then you don't even need the 'import (C++) GDALWarpOptions' Calypso will figure it out and do it for you. This is a bit of a double edge sword though, because sometimes you will really want/need to know the type you are dealing with and what it translates into. Hopefully this doesn't happen too often. Windows I hope to be able to test it in nearest time. As I wrote before I have not enough knowlages to build it's by myself, so I will wait bin builds. If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too? +1 for question! Since everything in the headers on the C++ side is sort of mashed together into the PCH (pre-compiled header) file, and you import every global variable/typedef/function/namespace using the special _, then you can get access to all of these globals via the one modmap of gdalwarper.h. Some more well-behaved libraries that have multiple namespaces can be easier to deal with because you can be quite specific with what you want to import, instead of just importing 'EVERYTHING' and then only using a small portion of it. This is an As far as I understand it!!! type of answer designed to be a little less technical. Please see Elie's answers to these questions for a more technical and in depth explanation (and the CORRECT explanation, as I may be somewhat off in my interpretation here :) !! ) Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 16:33:00 UTC, CraigDillabaugh wrote:
On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
modmap (C++) gdalwarper;
import std.stdio;
void main()
{
GDALDatasetH hSrcDS, hDstDS;
GDALAllRegister();
writeln(hello);
}
error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister
Perhaps you also need to include the GDAL headers, as I suspect
gdalwarper doesn't define GDALDatasetH.
Hi Craig,
The method here is to actually 'import (C++) _;' since that '_'
will make Calypso import all the global
functions/variables/typedefs in gdalwarper.
This works for namespaces also, so if you have a namespace in a
different example called MySpace, then calling 'import (C++)
MySpace._;' will import all the functions/variables/typedefs in
the namespace and make them accessible in your D file.
If you just have a single class in the MySpace namespace called
'myclass', and you would like to use it in your D program, then
use 'import (C++) MySpace.myclass;' to import it. Then
instantiate the class in D and use it from there.
Thanks,
Kelly
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
modmap (C++) gdalwarper;
import std.stdio;
void main()
{
GDALDatasetH hSrcDS, hDstDS;
GDALAllRegister();
writeln(hello);
}
error:
app.d(7): Error: undefined identifier GDALDatasetH
app.d(7): Error: undefined identifier GDALDatasetH
app.d(8): Error: undefined identifier GDALAllRegister
Hello Suliman,
I have translated the GDAL example (
http://www.gdal.org/warptut.html ) and got it to run...woohoo!! I
needed to apply the fix from Elie last night (and the pull
request from me that hasn't been accepted yet), so this won't
work for you yet, unfortunately...soon hopefully.
For comparison I have posted the translation here (
http://pastebin.com/VwrVeBJ3 ), but it may be a day or two yet
before Calypso can compile it out-of-the-box, even if my pull
requrest is accepted today. There is still one outstanding error
that I couldn't fix. I had to cheat and modify a system file (not
a good thing to ask others to do, obviously)!!
As you can see the differences between the two examples are
pretty minimal. Things like using '.' instead of '-'. Having to
'new' the GDALWarpOperation, and another slightly subtle change
-- we need to use an ampersand for the function pointer
assignment of GDALTermProgress/GDALAGenImgProjTransform.
Also notice that we needed to explicitly modmap cpl_conv.h to get
access to CPLMalloc. In addition, we have to be explicit about
which structs/classes to 'import'.
I have not tested this on Windows! I haven't even built Calypso
on Windows yet...so I may not be able to help much with Windows
errors. Just so you know.
Thanks,
Kelly
Re: Calypso: Direct and full interfacing to C++
On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote: Where set where Calypso should look header files? Suliman, You can just use '-cpp-args -I/path/to/header/file' to pass along the include directory for C++ files. So for example: ldc2 -L-lstdc++ -cpp-args -I/usr/local/qt5/QtCore test.d -L-lQt5Core
Re: Calypso: Direct and full interfacing to C++
Well the first fully working example of a large library is finally working with Calypso. Elie has managed to get a Qt5 demo program to compile and run!! The demo is a D version of the Qt5 Widgets demo. This is a simple window with a pseudo address book app. The demo uses a D class inheriting from QWidget, calls 'super(parent)' from D code and uses the QStrings, QLabel, QLineEdit, QLayout, QGridLayout classes, among other things. You can see the code here: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d The demo is confirmed to work with Qt5.4 and Qt5.2.1. While this might not seem like a really big deal, please keep in mind that while compiling this demo, Calypso effectively parses and produces 692 object files, including large swathes of the C++ STL and most of the Qt library! The latest push last night also cut down on compile times quite a lot. Doing the initial compile of the example takes about 28 seconds on my mid-level Intel i5 machine, versus around 2 seconds for just the C++ version. After generating a cache file with last nights commits you can recompile the project in just 7.5 seconds...which I think is quite good for just getting things up and running :) Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
A small update may be appropriate. We have run into a couple snags this past week when Elie improved the modulemap'ing for C files. Calypso now autodetects modulemap files for libc and POSIX standard headers in the /usr/include directory and /usr/include/x86_64-linux-gnu/sys. This change took a few days and many libraries broke in the meantime, but now things are back to approximately where they were last week (although one improvement is that iterator now compiles). There was also a backport from D2.068 to allow MSVC library usage which should move things along on Win platforms. Upon further testing of the LEMON library, I discovered that many things worked, but there is still one or two errors that make it not quite work for everything, so rewriting a nice example in D didn't quite work out. Efforts continue and hopefully we can get at least one library completely working soon, so that a proper example of Calypso's use can be written. I think things are quite close now because I was able to use every class, struct, function, etc. (that I tried randomly) in scintilla with just a couple hand written fixes to two scintilla header files. I think scintilla, LEMON and libzmq are the closest to working at this point. Thanks for your patience, Kelly
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 29 April 2015 at 14:45:42 UTC, Kagamin wrote: On Thursday, 23 April 2015 at 08:04:46 UTC, Kelly wrote: I haven't tried Qt yet because it needs to be hand-compiled with a user supplied namespace Aren't there precompiled versions? Kagamin, Yes, the precompiled version was the problem. They didn't use the 'QT_NAMESPACE' option when compiling the precompiled versions of Qt, so there was no namespace to import with Calypso. This isn't a problem anymore because Calypso can import libraries without an explicit namespace now, as long as it has a modulemap (that was part of the updating effort over the last week). I think it might be possible to use parts of Qt now, but Elie is looking into that so I'll let him reveal how much works. Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 22 April 2015 at 14:57:43 UTC, Kagamin wrote: What about Qt? I don't remember it being heavily templated. Hello Kagamin, I haven't tried Qt yet because it needs to be hand-compiled with a user supplied namespace, otherwise there isn't a namespace to import with Calypso. I have also looked at it a bit and it uses some of the STL files that still don't compile with Calypso, like iterator, etc. so it is probably a no-go at this point. On a brighter note things are looking extremely close for some other libs (and one lib finally works...see below :) ). Here is a small sample of some I have tried: Libzmq should compile with one other change to Calypso. The change will need to allow multiple C header files to be modulemap'ed. The separate parts of this lib compile on their own so once we can use multiple PCH files, this should work. Fastflow actually DOES compile for all the C++ header files I have tried (YAY!!), but I just can't instantiate a worker thread (really the most basic need for this lib) because of one error I will discuss with Elie. Hopefully it will be pretty easy to fix, as the other minor parts of this lib that I have tried are working at this point. Irrlicht has some portions that compile and can be called like CWriteFile, CLogger, CImage and some os.h functionality. I ran into a couple errors so I stopped testing after that, but it is coming along. Now the best news...it looks like the LEMON C++ Library works!!! WooHoo!! (Library for Efficient Modeling and Optimization in Networks - http://lemon.cs.elte.hu/trac/lemon). I haven't tested everything, but I have imported all the headers and compiled them without errors (I think I got them all). I have also instantiated things like: dim2.Point, Tolerance, DHeaps, Graphs, Digraphs and Arg_Parsers. These all instantiate fine, and I have used a few function calls with the instances, so things are looking exceptionally good for LEMON. We can also cast between Digraphs and Graphs (the C++ classes) in D, so that is looking good :) I will try to do some more complete testing and get at least one decent example working to show off this library. I will also write up a tutorial on how to get Calypso up and running with this lib (Linux only at this point as I haven't even tried the Win build from Elie yet...and I don't believe OSX Calypso will work yet). Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
Amazing stuff Elie!! It has been a pleasure watching this come together. Looking forward to testing and using Calypso. A huge and impressive milestone :) Thanks, Kelly On Thursday, 16 April 2015 at 00:47:31 UTC, Elie Morisse wrote: 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, more bugs should get triggered by actual usage of Ogre, but close to everything gets mapped, semantic'd and codegen'd and this is the milestone I've been working towards for months. Last week also introduced was the Clang module map file support, which helps breaking namespaces into smaller pieces and thus makes probably most C libraries usable right now without having to maintain bindings, only a module map file which may also be generated by clang-modularize.
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 18 February 2015 at 16:18:10 UTC, Elie Morisse wrote: BTW I just pushed support for function template instantiation. So lately thanks to a bit of free time there has been quite a lot of new features implemented: overloaded operators, function templates, and groundwork for class value types (they were added to the AST as a new semi-hackish kind of type, they make mapping any C++ type possible but they can't be used directly from D code yet). Operators should make std::map usable, so I'm going to resume testing further STL types. Just so others know, coding of Calypso continues and more of the STL is working now. Currently these C++ files can be mapped and used from a D program with Calypso: bitset deque foreach list map set stack string vector vstring -- just a vector of strings, but at least using classes in combination is working. Not all functions in these files work, but a significant portion do in most cases above. Iterators are still not working due to class value support being incomplete, but hopefully it will be working soon. Thanks to Elie for moving forward with this. Coding continues :) Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
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. With those changes all the examples compile and run again. There are still two errors when compiling vector.d. Clang errors when making the pch file. LDC2 still runs and produces a working binary anyways. Not sure what you are working on, but I can look at those errors if you like. Do you have an email address I can get in touch with you at? Jump on to #ldc on IRC and pm me if you don't want to post here. I didn't look at the build errors on OS X again yet...got tired of build errors for a bit :) Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 17 February 2015 at 01:53:22 UTC, Elie Morisse wrote: Hi Kelly, It's done, I've merged latest LDC upstream + your build fixes into Calypso. Alright, cool. I pulled it here and things build fine on Linux. Showcase and string examples work nicely. 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 from C++ ones work on MSVC until I setup a dev environment on Windows. Ok, developing on Win is not the nicest right now. I use Qt and it seems like the best option (change to msvc when needed...like to change the Debug/Release build types because the command line and Qt don't seem persistent). It's just those « D-C++ classes » though, the rest has a better chance to work now. Ok, I might try to build again here and see how it goes. Thanks, Kelly P.S. I HATE THIS FORUM EDITORplease add a preview button, whoever takes care of this!?!? I take notes in a different editor and then paste here and it looks fine, only to end up mangled when actually submitted...ugh :)
Re: Calypso: Direct and full interfacing to C++
Hello Elie, Ok, I tried to build on OS X with the LLVM/Clang revisions from above and the Calypso/LDC code from my github fork, but it is a no go. Calypso compiles pretty easily, but there are issues with vector not being found, so then I install libc++ so that clang easily picks up the correct include directories. Then unistd.h isn't found...ok it turns out XCode Command Line Tools needs to be installed to get some gcc specific files, but the internal Calypso call to clang needs to be modified. Change Calypso to call 'xcrun --show-sdk-path`, because this seems to work from the command line. Needs to be run from a shell...ugh. Etc, etc. Run into problems with libc++ and libstdc++ colliding. Remove libc++. Ugh. I finally just compile things by hand and get through to Calypso running and producing a bunch of object files, but then gcc won't link in some allocator code from stdc++?? Sheesh, not sure what is going on...I have tried several different ways to fix this, to no avail. Anyways, I am tired so I will just have to mess with this some more tomorrow or the next day. Hopefully I can figure out what is going on as it seems close to working. There might be real issues with someone having libc++ and libstdc++ alongside XCode tools like I had. Thanks, Kelly P.S. I try out Calypso from your github repo most days and the vector/bitset/showcase examples weren't working with todays code -- Do not call _d_invariant on C++ class objects. Just to make sure you are aware of it.
Re: Calypso: Direct and full interfacing to C++
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 'runs' on Win64, I should say 'runs as far as it can' because there is an internal LLVM assert with getVTableContext Microsoft VTableContext not yet supported UGH! :( Well...that is a stopper on Win64, period. I imagine this will be addressed fairly quickly because LLVM is moving extremely fast on Win64...at least I hope that will be the case!! So that leaves us with Calypso up to the last commit on February 8th, LDC from yesterday (Feb 14th) and with LLVM-3.7/Clang using the revision hashes above. I will make sure all this builds and works on OS X now...wish me luck :) I will also try to pull in the latest Calypso commits from the last couple days, and merge it with LDC so that we are all up to date and synced with LDC from yesterday. Unfortunately we are stuck with bleeding edge on all this stuff, (even when LLVM-3.6 stable comes out next week) because most of the Win64 code in LLVM and LDC has been added in just the last few weeks. Anyways, hopefully you can just spend time on the internal Calypso stuff this way Elie, and not waste time poking around with the Win64 build right now. Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Sunday, 15 February 2015 at 14:03:22 UTC, Elie Morisse wrote: It's from Calypso actually, the assert is in gen/dcxxclasses.cpp and is only triggered by D classes inheriting from C++ classes with a vtable. Ah, sorry I see it now...there is the assert and then a backtrace that indicates that an llvm file had the assert, but the actual error does print from within dxxclasses.cpp before the assert code backtrace. If the rest works as usual on Linux you got the most important covered. I'll check your merge as soon as I'm done fixing a linking error with the std::string example the latest additions introduced, then I'll add the Microsoft VTableContext support so we could get those first working binaries for Windows users :) Ok, cool. Hopefully that is the only difficulty left. However LLVM and Clang 3.6 aren't even released yet (next week), IMHO it would be wiser to stick with 3.6 and get LDC/Calypso working with 3.6 until 3.7 is more stable. Did you mean that even LDC can't be built by MSVC with LLVM 3.6 atm? Actually, I am not totally sure whether the current LDC will build with 3.6 on Win64. I didn't want to try it until 3.6 is finalized because building takes forever on Windoze!!! Probably 10 times slower than Linux/OSX...and my Win7 machine is a dual quad-core i7 with 12GB RAM!! A much better machine than my Linux machines. Anyways, once 3.6 final comes out we'll have to see if it works, I guess. Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
Ok, I have pushed my changes to Calypso on github. I did this mostly for testing because I wanted to make sure things still compiled on linux. Unfortunately, we need specific versions of llvm and clang to get things compiled as ldc2 hasn't been updated to the bleeding edge as of today. The versions I used on Win64 and Linux (didn't test OS X, but I can if needed) are: llvm: 77b557430c1315ef50c3256cdc5e73ac54d0154e Clang: baa701f47b7856f848080b51bc4fbcf984d29faa So, it took me a while to figure out that some problems weren't ours, but rather with compiling calypso (or ldc) with llvm from git today. Things build and will compile D programs as is, but fail on Win64 and Linux today for calypso specific code. Elie, perhaps you can see what is wrong just looking at my revisions? I would suspect the problem is in astunit.cpp because ASTReader is where the error is coming from. Anyways, take a look if you like. I would like to get this problem figured out before importing the last couple days worth of Calypso changes. I'll work on it some more in a few hours since I have a usable linux install again...WIN64 is just painful to work on for me, so I'll get things working and merged on Linux first and then move back to WIN64 :) Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 22:38:51 UTC, Elie Morisse wrote: 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 :) 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 program, but it fails when trying to use calypso. I guess I've made a mistake with my patch since I am getting an assert in ASTReader with input for calypso to compile. I will look at it tomorrow and once I can get calypso to work I will push to my github fork. Hoping for better news tomorrow, Kelly
Re: Calypso: Direct and full interfacing to C++
On Friday, 13 February 2015 at 17:54:25 UTC, Elie Morisse wrote: 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. Hello Elie, You can push to master, if you like, because we'll just have to go through and update everything either way. Hopefully not too many collisions or changes for llvm-3.7. Most of the changes I made are just slight modifications without new code, so there really shouldn't be too many collisions. Just going to start working on this ASTReader assert. Once it works, I will push to my fork, or I might just pull in your changes and see what happens. Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 22:38:51 UTC, Elie Morisse wrote: 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 :) Hello Elie, I have tried to build and use a few versions of Calypso/ldc with vs2013 and only the newest combination of LLVM and ldc from git work. llvm-3.6 with the corresponding ldc doesn't compile cleanly and neither does llvm-3.5 with ldc or Calypso with vs2013. Lastly Calypso with llvm3.7git doesn't compile, which is to be expected because of the many win64 patches that have been pushed to ldc the last couple months. Anyways, I just thought I would let you, and any interested others, know that Calypso won't build and run properly (or at least I couldn't get it to build/run) on Win7 with vs2013 today. Maybe things would work with llvm-3.5 and mingw with clang? I don't think so, though. I'll take a look at merging together Calypso and ldc since the split, if you like...hopefully not many conflicts. Not sure what all changed in llvm between 3.5 and 3.7, though. Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 22:38:51 UTC, Elie Morisse wrote: 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 :) Hello Elie, I did manage to build Calypso on Win7, and the resulting binary works to produce an obj file, but linking of a full executable fails :( I am getting file contains invalid .pdata contributions when trying to link. Trass3r over on ldc's github page was getting this error at one point also, but I don't know what the solution was. It seems like this was back in Aug 2014 so I would have thought any changes needed were picked up by Calypso when you forked in Oct. I would post an issue with ldc but Calypso isn't up to date, so it might not be really fair as the fix may be in the newest ldc. I can't see anything standing out in the commits for an issue like this, but I might just be missing it. Thanks, Kelly P.S. There is a small patch needed to compile on windows with VS2013. Things should still build fine on Linux with the patch. Here it is: diff --git a/dmd2/cpp/cppimport.cpp b/dmd2/cpp/cppimport.cpp index 709f324..2dec2ae 100644 --- a/dmd2/cpp/cppimport.cpp +++ b/dmd2/cpp/cppimport.cpp @@ -6,7 +6,10 @@ #include cpp/calypso.h #include expression.h +#ifndef _MSC_VER #include unistd.h +#endif + #include stdlib.h #include stdio.h diff --git a/dmd2/cpp/cppmodule.cpp b/dmd2/cpp/cppmodule.cpp index 114f3f0..385cb79 100644 --- a/dmd2/cpp/cppmodule.cpp +++ b/dmd2/cpp/cppmodule.cpp @@ -21,7 +21,10 @@ #include cppexpression.h #include cpptemplate.h +#ifndef _MSC_VER #include unistd.h +#endif + #include stdio.h #include stdlib.h diff --git a/dmd2/mars.h b/dmd2/mars.h index b22dc5b..fc8f798 100644 --- a/dmd2/mars.h +++ b/dmd2/mars.h @@ -270,8 +270,8 @@ struct Compiler const char *vendor; // Compiler backend name }; -struct LangPlugin; -typedef Arraystruct LangPlugin * LangPlugins; +class LangPlugin; +typedef Arrayclass LangPlugin * LangPlugins; typedef unsigned structalign_t; #define STRUCTALIGN_DEFAULT ((structalign_t) ~0)
Re: Calypso: Direct and full interfacing to C++
On Monday, 9 February 2015 at 22:24:49 UTC, Elie Morisse wrote: Hi Kelly, Good to see bitset instantiating and basically working too! Can I add your code to the tests? So yes to clear things up a bit, operators are still missing and so are many other features. Off the top of my head: - Function templates = the groundwork is here, they're already mapped and it shouldn't be too difficult to get them instantiating from D - Operators = probably easy to add although there might be differences between C++ and D operators - Functions with class values parameters aren't even mapped yet, since I haven't made my mind on how to handle class values. Despite the POD or not issue it still feels more consistent to treat C++ classes like D classes, while adding C++ class value types to DMD's types like C++ reference types were with TypeReference (which makes C++ variables with reference types usable but which can't be assigned as the types of D variables) - C++ reference types are supported by DMD but not by LDC yet, they only work for function parameters and return types since Calypso replace them by ref Hello Elie, Yes, you can use the code above for bitsets (modify as you see fit, it is public domain as far as I am concerned), thanks for asking. I have set up test files for most other STL headers...some seem quite close to working. Hopefully soon :) Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Sunday, 8 February 2015 at 22:45:14 UTC, Elie Morisse wrote:
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:
On Sunday, 8 February 2015 at 22:45:14 UTC, Elie Morisse wrote:
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:
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 others might want to see what works and
what doesn't).
/**
* std::bitset example.
*
* Build with:
* $ ldc2 -L-lstdc++ bitset.d
*/
modmap (C++) bitset;
import std.stdio;
import (C++) std.bitset;
void main()
{
enum : ulong { A=0, B, C, D, E, F, G, H, numColors };
auto usedColors = new bitset!(numColors);
usedColors.set(A, true);
usedColors.set(C, true);
writeln(usedColors.len=\t, numColors); // '8' as it
should be
write(usedColors = \t);
if (usedColors.any()) // any() works
{
for(int i=0; iusedColors.size; i++) // size seems to
work
if (usedColors.test(i))// works
write('1');
else
write('0');
write('\n'); // prints 1010 for usedColors
} // seems backwards also see 'b'
below
// is this right?
writeln(C bit = \t, usedColors.test(C)); // true as it
should be
writeln(count = \t, usedColors.count()); // seems like
count is
//
working...returns 2
writeln(as ulong = \t, usedColors.to_ulong); // '5' is
correct
writeln(all = \t\t, usedColors.all);
writeln(none = \t\t, usedColors.none);// these work
writeln(any = \t\t, usedColors.any);
usedColors.flip(C);
writeln(C flipped = \t, usedColors.test(C)); // false as
appropriate
write(b = \t\t);
auto a = new bitset!(4u)(0b0110);
auto b = new bitset!(4u)(0b1101);
for(int i=0; ib.size; i++)// size seems to work
{
if (b.test(i))
write('1'); // prints out 1011 for 'b'
else
write('0');
}
write('\n');
writeln(b as ulong = \t, b.to_ulong); // '13' is correct
// FAILURE in phobos format.d
//writeln(b);
// FAILURE because the [] operator isn't recognised
//writeln(usedColors[C]);
// FAILURE on operators again
//auto d = ab;
}
Thanks,
Kelly
Re: Calypso: Direct and full interfacing to C++
Hello Elie, Just a little build script until cmake can be used properly: #!/bin/bash set -x clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o /bin/rm calypso_cache* ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d I remove the the calypso_cache otherwise there will be an error if a previous build failed and the C++ files get modified. It looks like the 'undefined identifier size_t;' error is just from testStruct. If I comment out all refs/uses to testStruct then things compile and run fine. Good stuff. Thanks, Kelly P.S. If I find a little time, I'll try to get up to speed on the code base :) On Friday, 23 January 2015 at 17:18:22 UTC, Elie Morisse wrote: Thanks for the feedback Kelly, you're probably the first person to give it a serious try, sorry for the bumpy ride :) Since I was focused on getting Ogre working and neither rebuilt druntime/phobos nor tested the showcase example against the latest commits they might have broken something. Also the README forgets to say how libshowcase.a should be built: clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d Adding this now. I'm going to fix the rest this afternoon (finally some free time), and also figure out why assistbuilder.cpp failed to compile against the latest Clang 3.5. Also going to setup a testing script to ensure not everything gets broken again by a commit.
Re: Calypso: Direct and full interfacing to C++
Hello Elie, The small patch for defining size_t works here. Thanks. I just wanted to let people know that showcase.d should build fine (one deprecation warning, but not a big deal). 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. Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
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 namespace qualifier for two class instantiations of CodeGen). That is with clang-3.5 from todays svn. Maybe a recent clang commit has changed things? Once I had a working Calypso ldc2 build, I unfortunately couldn't get the showcase example to build. I just use the build line from your git page to try to build, but I get an 'undefined identifier size_t' error. The pch file is produced properly but then this error comes up...it seems like while compiling druntime from the '-v' output?? Maybe something changed in the druntime submodule in the last few days...but I didn't really look into it yet. I hacked a couple things to just get around this error and then things fail because libshowcase.a isn't available. I assume that is a remnant from an earlier compilation technique, because it appears everything is self contained in the .o files being produced and then linked on the command line...so I just thought I would let you know this part doesn't work. If you could give me a hint on the 'undefined identifier size_t' error, I can look into it a bit further here...I am just getting tired and probably not seeing what is going on there. If you are on #ldc I will be on there later today. Not sure what your username is in #ldc. At least one other person has been by asking if you were there also :) Thanks, Kelly (wilsonk-laptop)
Re: D2 port of Sociomantic CDGC available for early experiments
On Friday, 24 October 2014 at 06:50:05 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 15:53:19 UTC, Sean Kelly wrote: We could experiment with separately linking the GC. It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies. Can't it work like any other user library? Well, on linux at least I think you might have to list it twice. Once before and once after libdruntime. I don't know if there's a portable linker flag that indicates that it should try and resolve dependencies in libraries listed later in the link line.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 14:02:33 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote: It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order. At best, they won't clash :) If the default GC is not pulled by the linker, why should they clash? We could experiment with separately linking the GC. It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies.
Re: D2 port of Sociomantic CDGC available for early experiments
On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote: Sure, but past/current env vars being used are used *privately* to a single program. What you're suggesting here are env vars which will affect *all* D programs that see them. If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to. I'm not advocating the approach, but you could create a run_d app that simply set the relevant environment args and then executed the specified app as a child process. The args would be picked up by the app without touching the system environment. This would work on Windows as well as on *nix.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 16 October 2014 at 10:56:49 UTC, ketmar via Digitalmars-d-announce wrote: On Thu, 16 Oct 2014 08:10:38 + Dylan Knutson via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I'm sure there's a cross platform way to retrieve them without bring passed them directly there isn't. Runtime.args?
Re: D2 port of Sociomantic CDGC available for early experiments
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote: On 10/8/2014 12:43 AM, Leandro Lucarella wrote: I think this is an unjustified fear, there are already many environment variables that can affect your program. That's why they are called... environment variables :) Being on the front lines of tech support for 30 years, it is not an unjustified fear nor a hypothetical problem. What you could do is propose a secret switch to all dmd generated programs that the druntime switch checks before main() gets control, such as: app --druntimeSet=usexxx ...the regular app args ... Back when Druntime was called Ares, it was possible to choose the GC at link time. Do we really need to defer the decision to run time? If so, switching GCs after the app has started should work in most cases, though I'm not sure offhand if memory allocated by the prior GC will be scanned through for references within the new GC.
Re: Digger 1.0
On Tuesday, 30 September 2014 at 09:35:20 UTC, Marco Leise wrote: So why would Apple be able to get away with 1GB on its just released iPhone 6? Maybe 1048576 kilobytes is enough for everyone? ARC is more memory efficient than mark sweep GC like Javascript uses. Though a lot of it is just that iOS developers are simply very careful about memory use. Writing a performant game in iOS is really quite hard because of the memory constraints.
Re: DVM - D Version Manager 0.4.3
On Wednesday, 3 September 2014 at 15:55:47 UTC, Chris wrote: Methinks DVM doesn't get it right. 2.065.zip is available here: ftp://ftp.digitalmars.com/dmd.2.065.0.zip (cf. http://forum.dlang.org/thread/ebvumaoniuukgjbow...@forum.dlang.org) But DVM tries to access it via http: Fetching: http://ftp.digitalmars.com/dmd.2.065.zip An unknown error occurred: tango.core.Exception.IOException@/home/doob/development/d/tango/tango/core/Exception.d(59): The resource with URL http://ftp.digitalmars.com/dmd.2.065.zip; could not be found. The link for 2.065 on http://dlang.org/changelog.html is broken as well. I don't think this particular issue can be blamed on DVM.
Re: DVM - D Version Manager 0.4.3
On Wednesday, 3 September 2014 at 19:34:26 UTC, Chris wrote: I know, but I thought maybe DVM tries different addresses, if one is not working. Anyway it should be on dlang.org/changelog.html. For what it's worth, if you do dvm install 2.065.0 it will find it. Not sure if DVM should try alternates or not though.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote: On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Please understand that I'm not suggesting we start refactoring druntime for 2.067. All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come. The reason these are in Druntime at all is because code in Druntime depends on them. So if they were split into a separate library then it would be a required library. And even if we completely eliminate any dependency on standard C functions, I don't see any way to avoid depending on platform-specific calls. Now I would be fine with including just a subset of declarations in Druntime (which is really what we have right now anyway), but if the remainder were split into a standalone library then things start to get weird. Please let me know if you have a solution to this problem.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote: The problem is that you don't always want to bring libc and libstdc++ with you with every single project you write. Thus it shouldn't be in the runtime (except the very bit you can't get rid of). It can still be core.stdc . To be fair, the only part you bring with you are the dependencies that Druntime itself has. And nearly all of core.stdc is declarations anyway, so the only code bloat is unused ModuleInfo objects (notice that in places where Druntime uses C structs it declares them as =void to avoid depending on default initialization). The remaining issue becomes one of maintenance. If Druntime only declares the functions it needs, then where does the other stuff live? If you want to use that other library to get everything, does it publicly import core.stdc for the basics? What if Druntime needs a new call for some reason that's in this separate library? Do we declare it in core.stdc and cause collisions? What if D is ported to a new platform? That may require a whole raft of new declarations, both in a common API like core.stdc and in something more targeted like core.sys.linux. Don't get me wrong, I hate having to maintain the modules in core.stdc and core.sys. It's the worst job ever. I'm just not aware of a better solution to this particular problem.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote: eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org... One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). An embedded system that can support all of D but doesn't have a cruntime? I don't believe it. If it has a cruntime then providing bindings is a non-issue, and if it can't support all of D then supporting only a subset (and then being free to exclude core.stdc) is inevitable. There was a D runtime years ago created as a separate project around the time that Druntime had its beginnings (as Ares) that had no dependencies on standard C. The creator went by Maide in IRC, and she was doing some really cool stuff with it that made D work kind of like ObjectiveC. I don't think it's in development any more, but it's probably possible to track it down with enough googling.
