Hi Vivek, Vivek Balaraman wrote: > My constraint computation on a design problem requires anywhere from > 40-50 parameters. The constraint program itself will be embedded in a > java program. > > What would be the most scalable and robust way of passing and > returning such a large number of values to the program? I would suggest that you set up two peer queues (one to-eclipse, one from-eclipse), to pass the data between Java and ECLiPSe. You could then pass the data as pairs of parameter name and value using the queue. Using the parameter name avoid the problem of scheme that relies on the position of the data to determine which parameter it is for, which is easy to get wrong, and hard to modify. The high-level generic interface paper I mentioned previously posting to this mailing list, available at: http://eclipse.crosscoreop.com/reports/index.html has an example of using the peer queues (although it is described mainly using Tcl/Tk as the external language, the example applies equally well to Java as the external language). There is also an example in the Java examples directory: EclipseMapColourer.java. > > a) Both calling program and constraint program write / read to DB or > some such persistent storage accessible by both programs This is probably not as good a solution as using peer queues, but you can use MySQL as the database with lib(dbi) for this. If you do want to use persistent storage instead of peer queues, you are probably better off using files, and passing the file name between ECLiPSe and Java. > b) As part of the parameter list It is probably not a good idea to use RPC to do this -- you should avoid constructing/parsing large complex ECLiPSe data structures on the Java side. Cheers, Kish > > Thanks > > Vivek Balaraman > ------------------------------------------------------------------------ > > _______________________________________________ > ECLiPSe-Users mailing list > ECLiPSe-Users_at_crosscoreop.com > http://www.crosscoreop.com/mailman/options/eclipse-users >Received on Fri Aug 17 2007 - 12:39:48 CEST
This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 02:31:58 CET