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.ko...@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@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
_______________________________________________
Gecode users mailing list
users@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
