Conversation
|
What is the downside to adding JuliaC as an explicit test dependency? Does it work with Julia v1.10? |
|
This is the way to do it though. We just gradually add more things to the |
Why? |
| image_recipe = JuliaC.ImageRecipe( | ||
| output_type = "--output-exe", | ||
| file = joinpath(@__DIR__, "MyApp"), | ||
| trim_mode = "no", |
There was a problem hiding this comment.
So there's a design question here: what's the point of testing this with trim_mode = no? Shouldn't we test only with safe or unsafe-warn? I don't see how writing a JSON file can ever be type-stable.
There was a problem hiding this comment.
I'm mimicking your approach with HiGHS of starting with no then fixing it. We can wait to have the required PRs though before merging this one. We can make it work if nothing is in the UniversalFallback and we specialize on GenericModel.
In NexOR, we have web servers running Odoo with Python will all the data we need to model the optimization problem with JuMPy. And we need to send the problem to servers that will run the actual optimization. The idea is to use MOF for that, the prototype is https://github.com/NexOR-Optimization/NexOR.jl. I'd be nice to be able to compile NexOR.jl with JuliaC to add it as backend of JuMPy so that we just run compiled code on the web servers without needing Julia. |
For JuMPy, I'd like to have, in addition to the HiGHS backend, a backend that just writes a MOF so it would be nice to have the MOF writer trimable. It was actually not too hard if we just want
--trim=unsafe-warn, the full change is inbl/juliacbut I split it in separate PRs.--trim=safeis quite hard but it's easy to know whether the warning thrown by--trim=unsafe-warnare going to be an issue or not. If a user ends up calling a method that was missing from the JuliaC binary, he just gets aMethodErrorso it's easy to see what's happening. So--trim=unsafe-warnis a nice target.We start with
--trim=no, same reason as jump-dev/HiGHS.jl#372 (comment)