[gecode-users] Interacting with FlatZincSpaces, or: Gecode/JS bindings

[Guido Tack]

> On 11 Apr 2015, at 11:56 am, Sebastian Kosch <sebastian.kosch at mail.utoronto.ca> wrote:
> 
> Thanks Guido, that's helpful!
> 
> Before I get started on c) then -- to start, I would probably just drop in mzn2fzn.cpp + friends, turn its output into a FlatZincSpace and run it

We already have a version of the Gecode/FlatZinc interpreter that is fully integrated into libminizinc (i.e. without the detour of producing a FlatZinc text file).  We hope to be able to release at least a preview of this soon (this is with my MiniZinc hat on, it's not really related to Gecode).

> -- I have two more questions:
> 
>> a) There are a few options here.  You can change the parser to also export its symbol table, which you can use to look up variables in the FlatzincSpace by their name.
> 
> That sounds really convenient, but I'm afraid I'll need a bit more hand-holding. As far as I can see, my named variable arrays in Minizinc turn into dozens of X_INTRODUCED_### variables in Flatzinc. How do I keep track of them?

Yes, that's a problem, this mapping is currently not available.  All you can do at the Gecode level is to use the names in the FlatZinc (and that's the symbol table you could use).  If you want to discuss more about the MiniZinc side of things, I'd suggest we move the discussion to the MiniZinc forums (or private email) instead.

> 
>> I also have some ideas on making Gecode much more compact (by removing much of the template instantiation), I think that should help make the generated Javascript more manageable.
> 
> That's an interesting and promising idea. Is this on your short-term agenda? If not, and if I decide to look into it myself, where would be the best place to start (in terms of refactoring effort/bloat reduction ratio)?

First of all I'd try out the usual compiler options, i.e. turning off inlining, and setting the optimiser to focus on code size.

After that it's really a refactoring job. Most propagators in Gecode use "views" to implement different versions of a constraint, and each version requires a different template instantiation.  That blows up the code size.  Instead, it would be possible to implement the different versions using views with virtual functions, and then instantiate the propagators only with the base view class and derive the different versions by inheritance.  I haven't fully thought this through yet, it's possible that it would involve quite a lot of code duplication and copy/paste, no idea if it's possible to do it more systematically.

Cheers,
Guido

> 
>> b) The serialisation interface was part of Gecode 2 but we removed it in Gecode 3 (I think), mainly because it was an incredibly invasive part of the code (IIRC it made up about 30% of the overall Gecode code base!).
> 
> Ah, I see.
> Thanks again!
> 
> Seb
> 
>> 
>>> On 11 Apr 2015, at 12:03 am, Sebastian Kosch <sebastian.kosch at mail.utoronto.ca> wrote:
>>> 
>>> Hi,
>>> 
>>> I am playing with the idea of building a simple browser interface to
>>> Gecode. I have tweaked the source so that it compiles to a asm.js blob
>>> via emscripten -- notwithstanding the dozens of obvious reasons why
>>> doing this is a dumb idea, I can now solve Flatzinc models in the
>>> browser, and that's pretty cool.
>>> 
>>> I would like to do more than just input a Flatzinc string, of course,
>>> and build something closer to Gist maybe. So I would like to either
>>> 
>>> a) write wrapper functions in C++ to interact with the Flatzinc model
>>> after it's been read in. This code would go into the JS blob and allow
>>> me to interact with the space from the browser (e.g. add/remove
>>> variables and constraints, change options, restart searches etc.) -- or:
>>> 
>>> b) have an easier way of passing Javascript objects directly to Gecode
>>> to manipulate the space.
>>> 
>>> (a potential option c) might be to integrate the Minizinc parser into
>>> the JS blob, and to create a "proper" space in Gecode directly from
>>> Minizinc instead of compiling to Flatzinc first, and then use a) ... but I'd rather not.)
>>> 
>>> In terms of a), what are my options beyond finding out which of the
>>> variables are part of the optimization? Can I access Flatzinc
>>> annotations on variables somehow? Is there a way to predict which
>>> objects in the space correspond to which of the parts in the "original"
>>> Minizinc model?
>>> 
>>> In terms of b), it appears that this was planned at some point (see
>>> https://github.com/mattetti/Gecoder/blob/0352cf3b879d2f6764a4da6efe3fb2b1ff1b819c/vendor/gecode/win32/include/gecode/serialization.hh),
>>> but then dropped. Could I investigate this further, or did you come up
>>> against hard reasons why that's not an option at all?
>>> 
>>> I hope all of this doesn't sound too crazy or convoluted. I'm looking
>>> forward to your thoughts!
>>> 
>>> Sebastian
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Gecode users mailing list
>>> users at gecode.org
>>> https://www.gecode.org/mailman/listinfo/gecode-users
>> 
> 
> 
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users