Abseil logging library

[James Bruce]

Hi all,
Now that Abseil's logging & flags libraries is slowly displacing glog & gflags in various repos, mixing those with Ceres is becoming challenging.  In particular Ceres is using CHECK macros in the public headers, so there are name collisions.

First, I am wondering how folks here feel in general about moving to Abseil's logging & flags libraries.  I have ported some repos and willing to take  pass at this work, if the maintainers aren't opposed to migrating.  CERES_GET_FLAG will definitely help on the flags side.

Second, would the maintainers consider patches using the ABSL_ prefix, at least for header files?  That way clients wouldn't have name collisions regardless of whether they are using.  gRPC gets around this by not allowing LOG/CHECK in any header/api, but for something numerical like Ceres having those consistency checks seems far too useful to skip.  Perhaps the ABSL_ prefix for header-file check statements is a good middle ground (or changing all CHECK/LOG statements for consistency, which also has a reasonable argument).

Thoughts?
  - Jim Bruce

[Sameer Agarwal]

Hi James,

We would very much like to move to Abseil. Not just for logging and flags, but for a bunch of other internal functions like StringPrintf and classes like FixedArray. 

https://github.com/ceres-solver/ceres-solver/issues/780

There is only one blocker, Abseil's version of glog does not support vlog yet and we depend quite heavily on vlog in ceres internals.

As soon as it is available, we should move to using Abseil.

Sameer

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/a3341728-868e-450b-900f-600fa8f7b659n%40googlegroups.com.

[Patrik Huber]

Hi all,

I'm not really a big fan of Ceres taking Abseil as a required dependency. One of the big benefits of Ceres is that it's pretty much self-contained and doesn't require any dependencies, apart from Eigen (which most downstream users use anyway). I'm not counting miniglog as it's so small, and gflags is optional. That's, in practice, essentially (almost) zero dependencies.

Requiring Abseil is a big step away from that, as Abseil is quite a medium-sized "utilities" library. It also contains many things that downstream projects will never need, either because they don't need the functionality, or they use C++17 or upwards, which contains some of the things that Abseil provides for older compilers.

Best wishes,

Patrik

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUDsT4ormTsg6NUs4xoCezzeP%3DgrFVH%3DSmt0nz48kV1FGw%40mail.gmail.com.

[Sameer Agarwal]

Hi Patrik,

Thanks for the feedback. I understand the desire for keeping Ceres minimal, but there are a number of reasons why we will likely end up moving to abseil.

1. The gunit testing framework we use is taking a dependency on abseil.

2. The open source versions of glog and gflags are going to slowly drift from the versions used at google which is what is in abseil.

3. Ceres has a bunch of code which has not been touched or updated since ceres was originally open sourced, but that code is now maintained as part of abseil. Two examples are FixedArray and some of the string handling routines. Abseil also has some other nice data structures that we would like to be able to use e.g. efficient replacement for unordered_map and unordered_sets.

4. Using abseil will also allow us not to pollute the user's name space with poorly named logging related macros/symbols.

Last but not the least, miniglog continues to be a weird little stepchild of glog and is regularly a source of surprise to new users. 

Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAD7zOaQmKXZN8%3DD9R7AS1vMjtf2PmL9jMk-DkGY07StOEy%3DSgQ%40mail.gmail.com.

[Patrik Huber]

Hi Sameer,

Thank you, I certainly understand. There are always trade-offs.

Thank you (to you & the whole team) for all the amazing work on Ceres.

Best wishes,

Patrik

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUBNuukM7etvvyD4Pc3TeXE2D3X8rdL_JOzhLdEFYhmgkg%40mail.gmail.com.

[James Bruce]

Hi Sameer,
Ok that makes sense.  If VLOG is coming, it makes sense to wait for the conversion.  In the meantime, one thing that would help codebases that are already transitioned is to make the ceres versions to use different names in the public headers (and transitive includes); something like CERES_CHECK, CS_CHECK or similar.

It looks like LOG is not used in any public header, which is helpful:
  % find include/ceres -type f | xargs grep LOG
  include/ceres/iteration_callback.h://         VLOG(1) << output;
  include/ceres/jet.h://   LOG(INFO) << "df/dx = " << z.v[0]
  include/ceres/gradient_problem_solver.h:    // By default the Minimizer progress is logged to VLOG(1), which
  include/ceres/solver.h:    // By default the Minimizer progress is logged to VLOG(1), which

There are uses of various forms of CHECK though:
  % find include/ceres -type f | xargs grep "^ .*CHECK" | sed "s|.*[^A-Z_]\([A-Z]*CHECK[A-Z_]*\)[^A-Z_].*|\1|" | sort | uniq -c | sort -rn
     12 CHECK_EQ
      7 DCHECK_NE
      6 DCHECK
      6 CHECK
      5 CHECK_GT
      4 CHECK_GE
      3 CHECK_LT
      2 DCHECK_LT
      1 DCHECK_GT
      1 DCHECK_EQ
      1 CHECK_NE

If the public headers used a "public log api" with a unique name, the internal counterpart could define CHECK -> CERES_CHECK, and none of the non-header code would need to change.  This is pretty similar to how Abseil is defining ABSL_CHECK with the optional short CHECK name with a second include.

Just a suggestion, and I'd be willing to help if this seems worth trying.  Also I totally get it if this sounds like too much trouble prior to the later full transition.

  - Jim Bruce

[Sameer Agarwal]

Jim,

I think it would make sense to wait till we move to abseil so that we are not churning on the macro names. I'd rather not maintain a layer of macros on top of abseil.

Sameer

--

You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAPbAY7jBRz5TACr6d8LYhGoajtYW%3DNCD5mC9ivdPtxPmh1O2Dg%40mail.gmail.com.