Re: HDF5 bindings for D
On Monday, 22 December 2014 at 05:04:10 UTC, Rikki Cattermole wrote: You seem to be missing your dub file. Would be rather hard to get it onto dub repository without it ;) Oh and keep the bindings separate from wrappers in terms of subpackages. Thanks - added now. Will work on separating out bindings when have a bit more time, but it should be easy enough.
Swiss Ephemeris / Nelder-Mead simplex
Last one for a while, I think. I wish you all a very peaceful Christmas and New Year, and let's hope 2015 brings some more positive energy to the world. Links here: https://github.com/Laeeth/d_simplex https://github.com/Laeeth/d_swisseph 1. D bindings/wrappers for the swiss ephemeris http://www.astro.com/swisseph/swephinfo_e.htm The SWISS EPHEMERIS is the high precision ephemeris developed by Astrodienst, largely based upon the DExxx ephemerides from NASA's JPL . The original release in 1997 was based on the DE405/406 ephemeris. Since release 2.00 in February 2014, it is based on the DE431 ephemeris released by JPL in September 2013. NB - Swiss Ephemeris is not free for commercial use. 2. D port of simple Nelder-Mead simplex minimisation (written by Michael F. Hutt in original C version) here. With constraints. From Wiki: https://en.wikipedia.org/wiki/Nelder-Mead_method The Nelder–Mead method or downhill simplex method or amoeba method is a commonly used nonlinear optimization technique, which is a well-defined numerical method for problems for which derivatives may not be known. However, the Nelder–Mead technique is a heuristic search method that can converge to non-stationary points[1] on problems that can be solved by alternative methods. Links here: https://github.com/Laeeth/d_simplex https://github.com/Laeeth/d_swisseph
dfl2 can work for 64 bit,and base on D2.067b1
Now,you can use dfl2 to get the 64 bit winForm. Frank.
dco can work for 64 bit,and base on D2.067b1:code.dlang.org
dco is a build tool,and very easy to use,it can build dfl64.lib ,dgui.lib or other your projects,it can auto copy dfl.lib to the dmd2\windows\lib or lib64. After you work on the dfl2,use the build.bat,you will feel it's very easy to use. dco: https://github.com/FrankLIKE/dco/ dfl2: https://github.com/FrankLIKE/dfl2/ Frank
Re: dfl2 can work for 64 bit,and base on D2.067b1
On Monday, 22 December 2014 at 11:33:14 UTC, FrankLike wrote: Now,you can use dfl2 to get the 64 bit winForm. Frank. dfl2: https://github.com/FrankLIKE/dfl2/
Re: Facebook is using D in production starting today
On Thursday, 18 December 2014 at 09:18:06 UTC, Rune Christensen wrote: On Monday, 18 November 2013 at 17:23:25 UTC, Andrei Alexandrescu wrote: On 11/18/13 6:03 AM, Gary Willoughby wrote: On Friday, 11 October 2013 at 00:36:12 UTC, Andrei Alexandrescu wrote: In all likelihood we'll follow up with a blog post describing the process. Any more news on this Andrei? Not yet. I'm the bottleneck here - must find the time to work on that. Andrei Are you still using D in production? Are you using it more than before? Regards, Rune D is useful ,now I use the dfl2(https://github.com/FrankLIKE/dfl2/)and the build tool dco (https://github.com/FrankLIKE/dco/),very good. Frank
Re: Facebook is using D in production starting today
On Monday, 22 December 2014 at 12:12:19 UTC, FrankLike wrote: D is useful ,now I use the dfl2(https://github.com/FrankLIKE/dfl2/)and the build tool dco (https://github.com/FrankLIKE/dco/),very good. Frank Do you work for Facebook ?
Re: dco can work for 64 bit,and base on D2.067b1:code.dlang.org
On Monday, 22 December 2014 at 11:41:16 UTC, FrankLike wrote: dco is a build tool,and very easy to use,it can build dfl64.lib ,dgui.lib or other your projects,it can auto copy dfl.lib to the dmd2\windows\lib or lib64. After you work on the dfl2,use the build.bat,you will feel it's very easy to use. dco: https://github.com/FrankLIKE/dco/ dfl2: https://github.com/FrankLIKE/dfl2/ Frank Thanks, I'm in the process of looking at CMake/SCons alternatives right at the moment and will have a look at dco. I'm trying dub at the moment and it's working perfectly fine so far as a build tool. The alternatives, such as CMake and SCons, are proven technologies with D support that have also worked for me in the past. Can I ask what the existing tools were missing and why did you felt it necessary to reinvented your own build tool? Thanks, uri
Re: dco can work for 64 bit,and base on D2.067b1:code.dlang.org
On Monday, 22 December 2014 at 12:57:01 UTC, uri wrote: On Monday, 22 December 2014 at 11:41:16 UTC, FrankLike wrote: dco is a build tool,and very easy to use,it can build dfl64.lib ,dgui.lib or other your projects,it can auto copy dfl.lib to the dmd2\windows\lib or lib64. After you work on the dfl2,use the build.bat,you will feel it's very easy to use. dco: https://github.com/FrankLIKE/dco/ dfl2: https://github.com/FrankLIKE/dfl2/ Frank Thanks, I'm in the process of looking at CMake/SCons alternatives right at the moment and will have a look at dco. I'm trying dub at the moment and it's working perfectly fine so far as a build tool. The alternatives, such as CMake and SCons, are proven technologies with D support that have also worked for me in the past. Can I ask what the existing tools were missing and why did you felt it necessary to reinvented your own build tool? Thanks, uri Then try waf as well. :) https://code.google.com/p/waf/
Re: HDF5 bindings for D
On Monday, 22 December 2014 at 04:51:44 UTC, Laeeth Isharc wrote: https://github.com/Laeeth/d_hdf5 HDF5 is a very valuable tool for those working with large data sets. From HDF5group.org HDF5 is a unique technology suite that makes possible the management of extremely large and complex data collections. The HDF5 technology suite includes: * A versatile data model that can represent very complex data objects and a wide variety of metadata. * A completely portable file format with no limit on the number or size of data objects in the collection. * A software library that runs on a range of computational platforms, from laptops to massively parallel systems, and implements a high-level API with C, C++, Fortran 90, and Java interfaces. * A rich set of integrated performance features that allow for access time and storage space optimizations. * Tools and applications for managing, manipulating, viewing, and analyzing the data in the collection. * The HDF5 data model, file format, API, library, and tools are open and distributed without charge. From h5py.org: [HDF5] lets you store huge amounts of numerical data, and easily manipulate that data from NumPy. For example, you can slice into multi-terabyte datasets stored on disk, as if they were real NumPy arrays. Thousands of datasets can be stored in a single file, categorized and tagged however you want. H5py uses straightforward NumPy and Python metaphors, like dictionary and NumPy array syntax. For example, you can iterate over datasets in a file, or check out the .shape or .dtype attributes of datasets. You don't need to know anything special about HDF5 to get started. In addition to the easy-to-use high level interface, h5py rests on a object-oriented Cython wrapping of the HDF5 C API. Almost anything you can do from C in HDF5, you can do from h5py. Best of all, the files you create are in a widely-used standard binary format, which you can exchange with other people, including those who use programs like IDL and MATLAB. === As far as I know there has not really been a complete set of HDF5 bindings for D yet. Bindings should have three levels: 1. pure C API declaration 2. 'nice' D wrapper around C API (eg that knows about strings, not just char*) 3. idiomatic D interface that uses CTFE/templates I borrowed Stefan Frijter's work on (1) above to get started. I cannot keep track of things when split over too many source files, so I put everything in one file - hdf5.d. Have implemented a basic version of 2. Includes throwOnError rather than forcing checking status C style, but the exception code is not very good/complete (time + lack of experience with D exceptions). (3) will have to come later. It's more or less complete, and the examples I have translated so far mostly work. But still a work in progress. Any help/suggestions appreciated. [I am doing this for myself, so project is not as pretty as I would like in an ideal world]. https://github.com/Laeeth/d_hdf5 Also relevant to some: http://code.dlang.org/packages/netcdf
Re: dco can work for 64 bit,and base on D2.067b1:code.dlang.org
On Mon, 2014-12-22 at 12:57 +, uri via Digitalmars-d-announce wrote: […] Thanks, I'm in the process of looking at CMake/SCons alternatives right at the moment and will have a look at dco. May I ask why SCons is insufficient for you? I'm trying dub at the moment and it's working perfectly fine so far as a build tool. The alternatives, such as CMake and SCons, are proven technologies with D support that have also worked for me in the past. Can I ask what the existing tools were missing and why did you felt it necessary to reinvented your own build tool? The makers of Dub chose to invent a new build tool despite Make, CMake and SCons. Although it is clear Dub is the current de facto standard build tool for pure D codes, there is nothing wrong with alternate experiments. I hope we can have an open technical discussion of these points, it can only help all the build systems with D support. -- 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
GCCJIT Bindings for D
Hi, Apparently I've never announced this here, so here we go. I have written, and started maintaining D bindings for the GCCJIT library, available on github at this location: https://github.com/ibuclaw/gccjitd What is GCCJIT? --- GCCJIT is a new front-end for gcc that aims to provide an embeddable shared library with an API for adding compilation to existing programs using GCC as the backend. This shared library can then be dynamically-linked into bytecode interpreters and other such programs that want to generate machine code on the fly at run-time. The library is of alpha quality and the API is subject to change. It is however in development for the next GCC release (5.0). How can I use it? --- See the following link for a hello world program. https://github.com/ibuclaw/gccjitd/blob/master/tests/dapi.d I am currently in the process of Ddoc-ifying the documentation that comes with the C API binding and moving that across to the D API. Improvements shall come over the next months - though any assistance in making the Ddocs prettier are welcome contributions. Regards Iain.
Re: Swiss Ephemeris / Nelder-Mead simplex
On Monday, 22 December 2014 at 08:43:56 UTC, Laeeth Isharc wrote: Last one for a while, I think. I wish you all a very peaceful Christmas and New Year, and let's hope 2015 brings some more positive energy to the world. Links here: https://github.com/Laeeth/d_simplex https://github.com/Laeeth/d_swisseph 1. D bindings/wrappers for the swiss ephemeris http://www.astro.com/swisseph/swephinfo_e.htm The SWISS EPHEMERIS is the high precision ephemeris developed by Astrodienst, largely based upon the DExxx ephemerides from NASA's JPL . The original release in 1997 was based on the DE405/406 ephemeris. Since release 2.00 in February 2014, it is based on the DE431 ephemeris released by JPL in September 2013. NB - Swiss Ephemeris is not free for commercial use. 2. D port of simple Nelder-Mead simplex minimisation (written by Michael F. Hutt in original C version) here. With constraints. From Wiki: https://en.wikipedia.org/wiki/Nelder-Mead_method The Nelder–Mead method or downhill simplex method or amoeba method is a commonly used nonlinear optimization technique, which is a well-defined numerical method for problems for which derivatives may not be known. However, the Nelder–Mead technique is a heuristic search method that can converge to non-stationary points[1] on problems that can be solved by alternative methods. Links here: https://github.com/Laeeth/d_simplex https://github.com/Laeeth/d_swisseph It's been ages since I read the paper, but there is a parallel version of Nelder-Mead that is supposed to give very large performance improvements, even when used on a single processor: http://www.cs.ucsb.edu/~kyleklein/publications/neldermead.pdf It is not difficult to implement. I may look into modifying your code to implement it when I get some time.
Re: Swiss Ephemeris / Nelder-Mead simplex
On Monday, 22 December 2014 at 20:46:23 UTC, bachmeier wrote: It's been ages since I read the paper, but there is a parallel version of Nelder-Mead that is supposed to give very large performance improvements, even when used on a single processor: http://www.cs.ucsb.edu/~kyleklein/publications/neldermead.pdf It is not difficult to implement. I may look into modifying your code to implement it when I get some time. It will certainly also be advantageous to pass the functions as aliases, so that they can get inlined.
Re: Swiss Ephemeris / Nelder-Mead simplex
On Monday, 22 December 2014 at 21:39:08 UTC, Marc Schütz wrote: On Monday, 22 December 2014 at 20:46:23 UTC, bachmeier wrote: It's been ages since I read the paper, but there is a parallel version of Nelder-Mead that is supposed to give very large performance improvements, even when used on a single processor: http://www.cs.ucsb.edu/~kyleklein/publications/neldermead.pdf It is not difficult to implement. I may look into modifying your code to implement it when I get some time. It will certainly also be advantageous to pass the functions as aliases, so that they can get inlined. Thanks, Marc. I appreciate the pointer, and if you do have time to look at the code. I confess that it can't really be called my own implementation as I simply ported it to D. There is some more clever stuff within quantlib (c++ project), but I quite liked the idea of starting with this one as it is simple, and speed is not yet vital at this stage. Laeeth.
Calypso: Direct and full interfacing to C++
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: • Global variables • Functions • Structs • Unions (symbol only) • Enums • Typedefs • C++ class creation with the correct calls to ctors (destruction is disabled for now) • Virtual function calls • Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • Mapping template implicit and explicit specializations already in the PCH to DMD ones, no new specialization on the D side yet • D classes inheriting from C++ ones, including the correct vtable generation for the C++ part of the class So what is this sorcery? Let's remind ourselves that this isn't supposed to be feasible: Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. http://dlang.org/cpp_interface.html Well.. it is :D Calypso introduces the modmap keyword, as in: modmap (C++) cppheader.h; to generate with the help of Clang libraries a virtual tree of C++ modules. Then after making Clang generate a PCH for all the headers, the PCH is loaded and classes, structs, enums are placed inside modules named after them, while global variables and functions are in a special module named _. For example: import (C++) Namespace.SomeClass; // imports Namespace::SomeClass import (C++) Namespace._; // imports all the global variables and functions in Namespace import (C++) _ : myCfunc, myGlobalVar; // importing the global namespace = bad idea, but selective imports work Being a prototype, I didn't really pay attention to code conventions or elegance and instead focused on getting things working. And being tied to LDC and Clang (I have no idea how feasible a GCC version would be), it's going to stay like this for some time until I get feedback from the contributors on how this all should really be implemented,. For example Calypso introduces language plugins, to minimize the amount of code specific to C++ and to make support of foreign languages cleaner and less intrusive, although it of course needs numerous hooks here and there in DMD and LDC. Calypso is still WIP, but it's in pretty good shape and already works in a lot of test cases (see tests/calypso/), and is almost ready to use for C++ libraries at least. Since C libraries are in the global namespace, it's not a convenient replacement yet for bindings until I implement the Clang module map format. More info this blog post detailing some of the history behind Calypso: http://syniurge.blogspot.com/2013/08/calypso-to-mars-first-contact.html So.. Merry Christmas dear D community? :) My take on the current talks of feature freezing D: the strength of D is its sophistication. The core reason why D fails to attract more users isn't the frequent compiler bugs or regressions, but the huge amount of time needed to get something done because neither equivalent nor bindings exist for most big and widespread C++ libraries like Qt. All these talks about making D a more minimalist language won't solve much and will only result in holding back D, which has the potential to become a superset of all the good in other system languages, as well as bringing its own powerful unique features such as metaprogramming done right. By removing the main reason why D wasn't a practical choice, this will hopefully unlock the situation and make D gain momentum as well as attract more contributors to the compilers to fix bugs and regressions before releases.
Re: dco can work for 64 bit,and base on D2.067b1:code.dlang.org
On Monday, 22 December 2014 at 18:33:42 UTC, Russel Winder via Digitalmars-d-announce wrote: On Mon, 2014-12-22 at 12:57 +, uri via Digitalmars-d-announce wrote: […] Thanks, I'm in the process of looking at CMake/SCons alternatives right at the moment and will have a look at dco. May I ask why SCons is insufficient for you? It isn't. We review our build system every 12 months over Xmas quite period and tidy it all up. Part of the process is trying alternatives. We use Python +SCons to drive our builds and CMake to generate native makefiles. We find this approach scales better in terms of speed and system load. It is a pity CMake invented it's own noisy script though. I also find with CMake it can be extremely difficult to establish context when looking at the code. This is why we're slowly migrating to SCons. I'm trying dub at the moment and it's working perfectly fine so far as a build tool. The alternatives, such as CMake and SCons, are proven technologies with D support that have also worked for me in the past. Can I ask what the existing tools were missing and why did you felt it necessary to reinvented your own build tool? The makers of Dub chose to invent a new build tool despite Make, CMake and SCons. Although it is clear Dub is the current de facto standard build tool for pure D codes, there is nothing wrong with alternate experiments. I hope we can have an open technical discussion of these points, it can only help all the build systems with D support. I really like DUB for quick development, but in it's current form I don't see it scaling to larger builds. IMO the use of JSON puts it on par with the Java build tool Ant. JSON and XML (Ant) are data formats, not scripting languages and In my experience a large build system requires logic and flow control. I've had to do this before in Ant XML and it isn't pretty, nor is it flexible. I use SCons for personal D projects that I think will be long lived and DUB for quick experiments. I was using CMake for personal work but that script is too ugly :) Cheers, uri
Re: Calypso: Direct and full interfacing to C++
On 23/12/2014 12:14 p.m., Elie Morisse wrote: 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: • Global variables • Functions • Structs • Unions (symbol only) • Enums • Typedefs • C++ class creation with the correct calls to ctors (destruction is disabled for now) • Virtual function calls • Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • Mapping template implicit and explicit specializations already in the PCH to DMD ones, no new specialization on the D side yet • D classes inheriting from C++ ones, including the correct vtable generation for the C++ part of the class So what is this sorcery? Let's remind ourselves that this isn't supposed to be feasible: Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. http://dlang.org/cpp_interface.html Well.. it is :D Calypso introduces the modmap keyword, as in: modmap (C++) cppheader.h; That really should be a pragma. pragma(modmap, C++, cppheader.h); Since pragma's are the way to instruct the compiler to do something. to generate with the help of Clang libraries a virtual tree of C++ modules. Then after making Clang generate a PCH for all the headers, the PCH is loaded and classes, structs, enums are placed inside modules named after them, while global variables and functions are in a special module named _. For example: import (C++) Namespace.SomeClass; // imports Namespace::SomeClass import (C++) Namespace._; // imports all the global variables and functions in Namespace import (C++) _ : myCfunc, myGlobalVar; // importing the global namespace = bad idea, but selective imports work Being a prototype, I didn't really pay attention to code conventions or elegance and instead focused on getting things working. And being tied to LDC and Clang (I have no idea how feasible a GCC version would be), it's going to stay like this for some time until I get feedback from the contributors on how this all should really be implemented,. For example Calypso introduces language plugins, to minimize the amount of code specific to C++ and to make support of foreign languages cleaner and less intrusive, although it of course needs numerous hooks here and there in DMD and LDC. Calypso is still WIP, but it's in pretty good shape and already works in a lot of test cases (see tests/calypso/), and is almost ready to use for C++ libraries at least. Since C libraries are in the global namespace, it's not a convenient replacement yet for bindings until I implement the Clang module map format. More info this blog post detailing some of the history behind Calypso: http://syniurge.blogspot.com/2013/08/calypso-to-mars-first-contact.html So.. Merry Christmas dear D community? :) My take on the current talks of feature freezing D: the strength of D is its sophistication. The core reason why D fails to attract more users isn't the frequent compiler bugs or regressions, but the huge amount of time needed to get something done because neither equivalent nor bindings exist for most big and widespread C++ libraries like Qt. All these talks about making D a more minimalist language won't solve much and will only result in holding back D, which has the potential to become a superset of all the good in other system languages, as well as bringing its own powerful unique features such as metaprogramming done right. By removing the main reason why D wasn't a practical choice, this will hopefully unlock the situation and make D gain momentum as well as attract more contributors to the compilers to fix bugs and regressions before releases. Will you be upstreaming this? Or maintaining this completely yourself?
Re: dco can work for 64 bit,and base on D2.067b1:code.dlang.org
On Monday, 22 December 2014 at 12:57:01 UTC, uri wrote: On Monday, 22 December 2014 at 11:41:16 UTC, FrankLike wrote: dco is a build tool,and very easy to use,it can build dfl64.lib ,dgui.lib or other your projects,it can auto copy dfl.lib to the dmd2\windows\lib or lib64. After you work on the dfl2,use the build.bat,you will feel it's very easy to use. dco: https://github.com/FrankLIKE/dco/ dfl2: https://github.com/FrankLIKE/dfl2/ Frank Thanks, I'm in the process of looking at CMake/SCons alternatives right at the moment and will have a look at dco. I'm trying dub at the moment and it's working perfectly fine so far as a build tool. The alternatives, such as CMake and SCons, are proven technologies with D support that have also worked for me in the past. Can I ask what the existing tools were missing and why did you felt it necessary to reinvented your own build tool? Thanks, uri dco lets building project is easy, auto add itself to bin folder, may auto add d files,auto ignore some d files in ignoreFiles folder,auto -L libs in dco.ini ,and in next version ,you can set your offen used libs in dco.ini.
Re: Calypso: Direct and full interfacing to C++
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 Calypso code coexists with the vanilla C++ support which has a different coding philosophy and is more intertwined with the rest of the code. So I expect that I'll have to maintain it myself quite some time before this happens. And of course I'll make Calypso catch up with upstream LDC frequently.
Re: Calypso: Direct and full interfacing to C++
On Monday, 22 December 2014 at 23:14:44 UTC, Elie Morisse wrote: Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. http://dlang.org/cpp_interface.html Well.. it is :D Well, technically speaking you DO include fully functional C++ compiler front end with much more than 10 man-years of time invested - it just happens that it is already available and called clang :) Project itself is very cool but I am in doubts about possibility of merging this upstream. Doing so would make full D implementation effectively impossible without some C++ compiler already available as a library on same platform - quite a restriction! I think it is better suited as LDC extension and would discourage its usage in public open-source projects sticking to old way of C binding generation instead. For more in-house projects it looks like an absolute killer and exactly the thing Facebook guys wanted :)
