Hi Kish, Creating as many choicepoints (or considering anything as a choicepoint) is fine. No problems.
Then, all the stuff can be done with Gecode's API. So, when I talk about shipping it with Gecode it will be one module that comes with Gecode as an example interface. There is definitely no need for hacking inside Gecode's guts for doing this. Then the only thing that worries me is "Eclipse semantics requires that constraints are immediately propagated". That you can of course do as well (however it is a real performance killer. I luckily forgot about this major flaw in CLP ;-) ) As it comes to licensing. MIT is as liberal as is gets, so no problem: according to your license and the MIT license you can include all of Gecode into Eclipse. The only thing interesting is that we keep and maintain one part that's Gecode specific and you keep and maintain the Eclipse specific part. That will require a little bit of bargaining ;-) Christian -- Christian Schulte, www.it.kth.se/~cschulte/ -----Original Message----- From: Kish Shen [mailto:kiss...@cisco.com] Sent: Tuesday, January 27, 2009 5:11 PM To: Christian Schulte Cc: 'Guido Tack'; us...@gecode.org Subject: Re: [gecode-users] Interfacing GeCode to ECLiPSe Hi Christian and Guido, Thanks for your replies! Christian Schulte wrote: > Hi Kish, > > As it comes to the search interface: I have been discussing with other > LP-minded people and from these discussions I do recall the following design > outline: > > Search: > (1) Eclipse tells Gecode to create a choicepoint > (2) Eclipse tells Gecode to backtrack until the next choicepoint (or some > choicepoint if you want it to be > more powerful than that) > > Interfacing: > (3) Eclipse tells Gecode about variable modifications > (4) Eclipse tells Gecode to create new variables and propagators > (5) Eclipse instructs Gecode to do propagation and queries Gecode about > changes to variable domains > > Then, a starting point for implementing backtracking would be to just use > cloning to make it work (that should be really use but inefficient). Then, > in a second step one could use a hybrid of recomputation and cloning (just > replay what has been done by (3) and (4) and redo propagation). For a > realistic interface Gecode must use recomputation. After Guido's last post, I remember some of our (you, Joachim Schimpf and I) discussion about this during CP a couple of years ago. My thinking is that for ECLiPSe (and I suspect for other Prolog-like languages), it is difficult to be explicit about the creation of a choicepoint, so potentially any changes ECLiPSe tells GeCode about (poinys 3,4) are possible choicepoints. After reading Guido's e-mail (but before seeing yours), I was thinking of maintaining a chronological list of the `events' that are sent to GeCode, with a counter incremented for each event. I think this corresponds to the `choicepoint' you mentioned. So ECLiPSe can tell GeCode to `backtrack' (or more properly recreate) the GeCode state when counter = N. Can this be done with GeCode with the existing API, without the ECLiPSe side maintaining the list of events? 3) and 4) are needed for the backbox interface, because to keep close ECLiPSe's native finite domain solvers' semantics, propagation happens when a constraint is posted. So if I use the Reflection interface, I need to be able to incrementally add variables and propagators. > > I think this kind of interface would be quite useful also for other > languages/systems based on backtracking. Provided that: > - you come up with a naïve implementation that is not Eclipse specific > (say, there will be one part that is Gecode specific and then a separate > part that is Eclipse specific, and the Gecode part can be used without > Eclipse) > - you put the Gecode-specific part under the MIT license > From our perspective, we'd like the ECLiPSe interface to be as general as possible, i.e. ideally we can plug in another constraint solver engine other than GeCode with ease. I think your points 1) and 2) are not solver specific, and indeed can be used by other backtracking languages. I guess this will be the `ECLiPSe specific' part, as well as the actual 'events' themselves -- ideally I'd like the events to be non-GeCode specific. Then there is the part of getting GeCode to recreate the state at a choicepoint/counter. This is probably specific to GeCode (or at least a recomputation system). As I asked earlier, can you do this with the GeCode APU, and if not, should the code for this be put into GeCode, rather than be on the `ECLiPSe side'? ECLiPSe is now under a "Cisco style" Mozilla license (I am not a lawyer, but I believe Cisco style means that Cisco was substituted for Mozilla in the license, i.e. Cisco has the right to change the licensing terms etc.). I guess the question of license will only kick in if some of the GeCode specific code needs to be kept on the ECLiPSe side (i.e. distributed as part of ECLiPSe). I don't know if the MIT license is compatible with Mozilla license (i.e. can you have a distribution with code that has both licenses). I do recall the lawyers telling me that the Mozilla license is not compatible with GPL, and we had to remove some GPL licensed code from the ECLiPSe distribution. Cheers, Kish -- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. Cisco Systems Limited (Company Number: 02558939), is registered in England and Wales with its registered office at 1 Callaghan Square, Cardiff, South Glamorgan CF10 5BT. _______________________________________________ Gecode users mailing list us...@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
