Feature request: A browser-friendly version of or-tools (emscripten) #2997

franzen · 2019-10-25T20:32:59Z

franzen
Oct 25, 2019

With web development frameworks such as Vue, React and Angular, a web-based version (WASM) of or-tools would make a big difference for us developers. The ability to solve many optimization problems directly in the browser would provide a better user experience and the opportunity to do work in the browser when offline.

Unfortunately, I'm not a star on tools like https://emscripten.org/, otherwise I would have made the first attempt myself. But can it be a simple task for someone else in this community?

Thank you for your hard work on this project!

lperron · 2019-10-25T22:10:31Z

lperron
Oct 25, 2019
Maintainer

As expected, you, or somebody else can try. :-) But I will not spend some time on it. I prefer the client server approach.

…

--Laurent Le ven. 25 oct. 2019 à 22:33, Nils Franzen <[email protected]> a écrit :

With web development frameworks such as Vue, React and Angular, a web-based version (WASM) of or-tools would make a big difference for us developers. The ability to solve many optimization problems directly in the browser would provide a better user experience and the opportunity to do work in the browser when offline. Unfortunately, I'm not a star on tools like https://emscripten.org/, otherwise I would have made the first attempt myself. But can it be a simple task for someone else in this community? Thank you for your hard work on this project! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1670?email_source=notifications&email_token=ACUPL3M3BNH2CW3WA4RVH7DQQNJYHA5CNFSM4JFI2YQKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HUPJYYQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3NRZ4K4X67RI4PG3OLQQNJYHANCNFSM4JFI2YQA> .

0 replies

CervEdin · 2019-10-26T11:48:50Z

CervEdin
Oct 26, 2019

There's a reason solvers and local search algorithms aren't implemented in high level languages. They're not suited for solving NP-hard problems.

If you really need to do this client side, you could look into packages like https://www.npmjs.com/package/simulated-annealing or https://github.com/njoubert/csp.js.

If you just need a simpler interface for modelling optimization problems client-side, check out the MiniZinc project.

0 replies

kjartanm · 2020-08-13T14:36:07Z

kjartanm
Aug 13, 2020

An experimental/poc wasm-version of or-tools is available at https://github.com/kjartanm/wasm-or-tools (and wasm is not exactly high level :) )

0 replies

Mizux · 2020-09-02T09:24:29Z

Mizux
Sep 2, 2020
Maintainer

Copy of the mailing list topic: Proof of concept WASM-build of OR-Tools

Few comments for myself (and sorry, I should have done this feedback 20 days ago when you reply in the issue):

Build on top of stable branch (v7.8)
https://github.com/kjartanm/wasm-or-tools/commits/stable
Basically use the CMake based build with an emscripten CMAKE_TOOLCHAIN_FILE -> GOOD
ed: While we still not support cmake toolchain files (i.e. not tested and out of our current scope), it is the way to go to support Android NDK and emscripten in the near future..
So any clean patch (i.e. without breaking change) to ease this future usage will be reviewed and integrated if possible !
Have some dirty hack to "fix" dependencies (glog and protobuf)
kjartanm@ef4b4fa
note: For Glog why did we need to use "HAVE_SYMBOLIZE 0" ? and the hack of raw_looging -> provide a clean patch to glog to better support toolchain and/or emscripten target should be better IMHO...
note: For Protobuf, it should be better to check for CMAKE_CROSSCOMPILING and in this case disable the build of the protoc binary during the fetch_content() (i.e. set protobuf_BUILD_PROTOC_BINARIES=OFF when CMAKE_CROSSCOMPILING is true using generator expression ?) AND build an HOST version instead...
Then we can replace the protobuf::protoc by a host_protoc alias target etc...
According to the emscripten doc:

The preprocessor define EMSCRIPTEN is always defined when compiling programs with Emscripten.

ref: https://emscripten.org/docs/compiling/Building-Projects.html#detecting-emscripten-in-preprocessor
So it should be better to properly fix the code by checking this define instead of this hack ;)
e.g. kjartanm@17a87e1#diff-afde8dfcb72625759b3232fdcf38f378L164-L166

Using make_third_party, i.e. the Make based build, to retrieve all dependencies headers is not a "clean" CMake way to say the least ;)
Also I don't deeply understand why you should do it...
note: Our goal is to replace (i.e. remove) the Makefile based build by the CMake based build...
Instead of modifying the default value of few CMake options you should pass it in your call to CMake.
i.e. in cmake-build.sh:

-    cmake -DCMAKE_TOOLCHAIN_FILE=${EMSCRIPTEN_CMAKE_PATH} ..
+   cmake -DCMAKE_TOOLCHAIN_FILE=${EMSCRIPTEN_CMAKE_PATH} -DBUILD_DEPS=ON -DBUILD_SAMPLES=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TESTING=OFF ..

ref: kjartanm@ed4d870

wasn-build.sh should be refactored as a CMake file using a function and you shouldn't have to list by hand all dependent libraries of ortools (out of sync and should be already provided by the target attribute)
ref: https://github.com/kjartanm/wasm-or-tools/blob/17a87e1e582af581eb191609effe8363ee91c920/wasm-build.sh#L19-L87
note: need to check if there is already an "emscripten" CMake module providing this kind of tools (i.e. wrapper function for "emcc" and "emscripten") on the internet...

0 replies

Mizux · 2020-09-02T09:35:33Z

Mizux
Sep 2, 2020
Maintainer

On archlinux:

pacman -S emscripten
cat /usr/lib/emscripten/cmake/Modules/Platform/Emscripten.cmake

0 replies

luiscastro193 · 2021-02-14T18:53:51Z

luiscastro193
Feb 14, 2021

This would be very useful. Is there an easy way to compile or-tools with emscripten?

0 replies

Mizux · 2021-02-15T08:20:19Z

Mizux
Feb 15, 2021
Maintainer

@luiscastro193 now or-tools, on master branch, support CMAKE_TOOLCHAIN_FILES for C++, see https://github.com/google/or-tools/blob/master/tools/cross_compile.sh

0 replies

luiscastro193 · 2021-02-15T10:32:00Z

luiscastro193
Feb 15, 2021

Ok so I followed these steps:

Cloned the branch
Edited line 209 of the file at the build function as emcmake cmake -S. -B"${BUILD_DIR}" "${CMAKE_DEFAULT_ARGS[@]}" "${CMAKE_ADDITIONAL_ARGS[@]}"
Set export TARGET=x86_64 and export PROJECT=or-tools
Executed ./cross_compile.sh build

However, the building process fails at some point: output.txt

Am I doing something wrong?

0 replies

kjartanm · 2021-02-16T11:33:36Z

kjartanm
Feb 16, 2021

I added

  case ${TARGET} in
    wasm32)
      expand_wasm_config
      declare -r QEMU_ARCH=DISABLED ;;
    x86_64)

to have wasm as a target, and

function expand_wasm_config() {
  declare -r TOOLCHAIN_FILE=${PROJECT_DIR}/emscripten/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake
  CMAKE_ADDITIONAL_ARGS+=( -DCMAKE_TOOLCHAIN_FILE="${TOOLCHAIN_FILE}" -DBUILD_SAMPLES=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TESTING=OFF)
}

to set the toolchain and turn off some parts of the process.

It runs for a good while, but kicks the bucket around 85%, after Built target ortools_constraint_solver.

0 replies

kjartanm · 2021-02-17T07:40:43Z

kjartanm
Feb 17, 2021

The blockers for compiling seems to be the same 2 minor points that I addressed in my PoC-build (https://github.com/kjartanm/wasm-or-tools -- I cleaned it up a bit, so it is less hacky than to begin with :) )

It can be handled using EMSCRIPTEN preprocessor variable. Would something like this be an option?

glop/lp_solver.cc, 160:

  // Note that we only activate the floating-point exceptions after we are sure
  // that the program is valid. This way, if we have input NaNs, we will not
  // crash.
#ifndef __EMSCRIPTEN__  
  ScopedFloatingPointEnv scoped_fenv;
  if (absl::GetFlag(FLAGS_lp_solver_enable_fp_exceptions)) {
#ifdef _MSC_VER
    scoped_fenv.EnableExceptions(_EM_INVALID | EM_ZERODIVIDE);
#else
    scoped_fenv.EnableExceptions(FE_DIVBYZERO | FE_INVALID);
#endif
  }
#endif

base/raw_logging.cc, 28:

#if !defined(_MSC_VER) && !defined(__EMSCRIPTEN__)
#include <sys/syscall.h>  // for syscall()
#define safe_write(fd, s, len) syscall(SYS_write, fd, s, len)
#else
#if !defined(__EMSCRIPTEN__)
#include <io.h>  // _write()
// Not so safe, but what can you do?
#define safe_write(fd, s, len) _write(fd, s, len)
#else
#define safe_write(fd, s, len) write(fd, s, len)
#endif
#endif

0 replies

lperron · 2021-02-17T08:26:13Z

lperron
Feb 17, 2021
Maintainer

Yes send us a PR. Le mer. 17 févr. 2021 à 08:41, Kjartan Müller <[email protected]> a écrit :

…

The blockers for compiling seems to be the same 2 minor points that I addressed in my PoC-build (https://github.com/kjartanm/wasm-or-tools -- I cleaned it up a bit, so it is less hacky than to begin with :) ) It can be handled using *EMSCRIPTEN* preprocessor variable. Would something like this be an option? glop/lp_solver.cc, 160: // Note that we only activate the floating-point exceptions after we are sure // that the program is valid. This way, if we have input NaNs, we will not // crash. #ifndef __EMSCRIPTEN__ ScopedFloatingPointEnv scoped_fenv; if (absl::GetFlag(FLAGS_lp_solver_enable_fp_exceptions)) { #ifdef _MSC_VER scoped_fenv.EnableExceptions(_EM_INVALID | EM_ZERODIVIDE); #else scoped_fenv.EnableExceptions(FE_DIVBYZERO | FE_INVALID); #endif } #endif base/raw_logging.cc, 28: #if !defined(_MSC_VER) && !defined(__EMSCRIPTEN__) #include <sys/syscall.h> // for syscall() #define safe_write(fd, s, len) syscall(SYS_write, fd, s, len) #else #if !defined(__EMSCRIPTEN__) #include <io.h> // _write() // Not so safe, but what can you do? #define safe_write(fd, s, len) _write(fd, s, len) #else #define safe_write(fd, s, len) write(fd, s, len) #endif #endif — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3NBSXU2JKWZCVCQR5TS7NXI7ANCNFSM4JFI2YQA> .

0 replies

kjartanm · 2021-02-20T09:47:30Z

kjartanm
Feb 20, 2021

I have sent a PR for glop/lp_solver.cc and base/raw_logging.cc, but I also have a suggestion for cross_compile.sh that is currently in master. I have understood it so that you only want PRs on stable?

0 replies

lperron · 2021-02-20T11:55:47Z

lperron
Feb 20, 2021
Maintainer

No, on master Le sam. 20 févr. 2021 à 10:47, Kjartan Müller <[email protected]> a écrit :

…

I have sent a PR for glop/lp_solver.cc and base/raw_logging.cc, but I also have a suggestion for cross_compile.sh that is currently in master. I have understood it so that you only want PRs on stable? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3PSVASPUOUZXDWP633S76AMFANCNFSM4JFI2YQA> .

0 replies

abhijith96 · 2022-04-11T11:06:16Z

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature request: A browser-friendly version of or-tools (emscripten) #2997

{{title}}

Replies: 14 comments 9 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Feature request: A browser-friendly version of or-tools (emscripten) #2997

Replies: 14 comments · 9 replies

lperron Oct 25, 2019 Maintainer

Mizux Sep 2, 2020 Maintainer

Mizux Sep 2, 2020 Maintainer

Mizux Feb 15, 2021 Maintainer

lperron Feb 17, 2021 Maintainer

lperron Feb 20, 2021 Maintainer

Replies: 14 comments 9 replies

lperron
Oct 25, 2019
Maintainer

Mizux
Sep 2, 2020
Maintainer

Mizux
Sep 2, 2020
Maintainer

Mizux
Feb 15, 2021
Maintainer

lperron
Feb 17, 2021
Maintainer

lperron
Feb 20, 2021
Maintainer