On Sun, Jan 08, 2012 at 11:48:58AM +0100, Werner Smekal wrote: > Hi, >> Alan W. Irwin <mailto:ir...@beluga.phys.uvic.ca> >> January 7, 2012 10:56 PM >> >> >> >> 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. > The reason I chose D1 over D2 was since at that time D2 was > experimental. In addition some "Standard Library War" was going on > between phobos and tango and it wasn't clear, which way D2 is going (at > that time). So I used D1 and phobos. AFAIK D2 is using Tango now. I > think the major problems are not the bindings, which were rather easy to > create (and maintain), but porting our samples to D2 (which should be > easy) and Tango (which is more work). > > Regarding the cmake bindings, there is this cmaked2 > (http://code.google.com/p/cmaked2/) available, which somehow doesn't > make it into the cmake releases (although they tried several times). > Maybe we can put it into our package until cmake eventually includes it? > > I can have a look at the bindings, but as in the past months (and years > :( ) time is limited.
Alan, Werner, Thanks for the comments. I was concerned about the fact that htod is a windows executable only solution. The old version I found was D1 only. This was one big reason for considering swig. Your comments reassure me somewhat about this, although I'm still a little dubious about requiring a non-free (in the GNU sense) tool. Further checking shows that D support only appeared in swig in version 2, which would require a more stringent version check than at the moment which may not be desirable yet. If htod version 2 support is available that would be good. Werner, your comments on library support are also interesting since Debian is shipping with gdc-4.6 (D2 support) and libphobos2 rather than tango. It also ships the ldc compiler with tango. So at the moment it looks like both are widely used. Interestingly swig produces code for D1/tango or D2/phobos which seems to contradict Werner's take on the situation! So all in this appears to be more of a mess than I first thought. I'm happy to stick with the htod solution, but sounds like we'll need to think carefully about which compiler / library to target. P.S. I've seen the cmaked2 support - it's partly how I figured out the problems with the current support. Andrew ------------------------------------------------------------------------------ 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
