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

[Sebastian Kosch]

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 -- 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?

> 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)?

> 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
>