On 2012-01-06 11:09-0000 Andrew Ross wrote: > > The current D language bindings were semi-automatically generated using > htod by Werner. They support the D1 version of the language. This has > been fine until now, but with the advent of version 4.6 gdc now > support D2 by default. The current D bindings won't work with gdc-4.6 > both because of cmake issues (I can work round these) and also because > of language issues. gdc-4.6 does have a compatibility flag to enable > D1 language support, but this is still stricter than gdc-4.4 and > the bindings don't compile out of the box. > > One other thing I noticed was that subsequent hand edits of the > bindings (by me among others) had introduced code that worked > with gdc-4.4 but was rejected by gdc-4.6, even with D1 support > enabled. Maintaining the bindings in this non-automatic way is > a little tedious and tricky, especially for lesser used bindings > like D. > > This first came to light testing out the new Debian packages. There > I (for now) force the gdc-4.4 compiler to be used (Debian provides > a gdc-v1 package for this). I think we need to think about the long > term plan here. I notice that swig has support for the D language > (both D1 and D2). I think this would probably be a good way to go > as we are already widely using swig and this makes management > of API updates much simpler. It might not be compatible > > I know next to nothing about D other than what I've learnt trying > to get our bindings to work, so if anyone is willing to pick up this > project to convert our D bindings to swig, then please step forward. > I can offer advice on using swig (as can Alan). Of course, if anyone > thinks this is a bad idea then please also say so. In the absence of > volunteers, I'll add it to my list of things to do, but this may be > some time.
Hi Andrew: First of all, according to http://digitalmars.com/d/1.0/index.html D version 2 is recommended for new projects while D version 1 is just in maintenance mode. Obviously we want PLplot to be useful for the increasing numbers of D2 users, and obviously from your experience D1 support under Linux is getting more problematic in any case. So I think our overall goal should be unequivocally to move to D2. Furthermore, I think that your idea of generating our D2 bindings with swig is a viable idea. For example, from http://swig.org/Doc2.0/D.html#D_introduction the D support under swig sounds pretty solid. The Java module was the basis of the C# module which in turn was the basis for the D module. We already have good experience with the Java module so it is reassuring tht the D module is related to it. Furthermore, the -d2 option allows swig-generated D bindings to target D2. Although I am a big fan of swig, and I am virtually positive this idea would work, I think of swig as a last resort for D since maintaining our current htod-generated plplot.d file is probably going to be much simpler. Those who have implemented the D compiler obviously take great pride in how easy it is to interface with C from D. For example, see http://www.d-programming-language.org/interfaceToC.html. My understanding from skimming http://www.d-programming-language.org/htod.html is that htod is a tool to automate such interfacing. So here are some of my ideas to help implement the goal of moving from D1 to D2. 1. Convert our examples code written in D from D1 to D2 following the ideas at http://www.d-programming-language.org/D1toD2.html. Note we have to do this step regardless of what method we use to change bindings/d/plplot.d from D1 to D2. 2. Change our bindings/d/plplot.d code from D1 to D2. The earliest version of a D2 compiler was implemented about 5 years ago while plplot.d was generated by htod some 4 years ago which is probably why the plplot.d result is D1 rather than D2. However, there is now a more modern htod you can download from http://www.d-programming-language.org/htod.html that was dated two years ago. I think there is a good chance that one (updated 3 years after the earliest version of the D2 compiler was released) will produce a D2 version of plplot.d. So it might be worthwhile to start over using the latest htod following the cookbook in bindings/d/README.txt. Note, I have just now confirmed by doing the download and analyzing the results that htod is a Windows executable. So it will require access to a Windows platform (wine is likely to be suitable and certainly some of our developers have access to Microsoft Windows in case htod doesn't work on the wine platform) to regenerate plplot.d this way. Of course, if this regeneration idea does not work for some reason we could fall back on hand-editing the current plplot.d to convert it to D2 following the ideas in http://www.d-programming-language.org/D1toD2.html. Anyhow, these are just my ideas about some good possibilities for our fairly urgent need to move PLplot from D1 to D2, but ultimately we need a volunteer to make that happen, and it will be their decision which path they want to take to achieve the goal. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
