UI Improvements for Really Long Builds.

[Drup]

It would be nice to have a way to, interactively during builds, show the log, or to start showing the logs when a command has been going for a really long time.

I'm not thinking core-long, more like z3, full-llvm, coq.

[Drup]

A nicer lock management for these cases would be nice too.

[AltGr]

This is feasible, we are using a sigalarm, so it would be possible to do the same in non-verbose mode, but with a longer delay (eg 5min) the first time, when the command starts.
On the lock management, that may be tricky, what are the specific cases (commands) that are itching ?

[Drup]

well, opam install Z3 (not yet in normal opam, but the problem is the same with coq, I heard) takes at least 20 minutes on my not-very-fast laptop. Releasing the lock during building (and retaking it for the end) would be nice.

[AltGr]

Releasing the switch lock completely would be quite dangerous: what if other packages were added / removed in the meantime ? Weakening it to a read lock during build could work, but I am not sure that would allow to do much more. What is it you're missing during these 20 minutes ?
A consistent improvement would be to stage the build somewhere, then re-run the solver after the build to check and install. But that'd be quite some work to implement.

Another way would be to add an option to disable the lock with a "You're on your own" disclaimer... but I'd rather avoid this kind of non-features.

[avsm]

Just a read lock would be useful for opam search, opam info and friends. But not particularly highly importantly in my case.

On 16 Feb 2015, at 00:29, Louis Gesbert notifications@github.com wrote:

Releasing the switch lock completely would be quite dangerous: what if other packages were added / removed in the meantime ? Weakening it to a read lock during build could work, but I am not sure that would allow to do much more. What is it you're missing during these 20 minutes ?
A consistent improvement would be to stage the build somewhere, then re-run the solver after the build to check and install. But that'd be quite some work to implement.

Another way would be to add an option to disable the lock with a "You're on your own" disclaimer... but I'd rather avoid this kind of non-features.

—
Reply to this email directly or view it on GitHub #1991 (comment).

[AltGr]

These shoud work already: opam install only takes a write lock on the switch (and a global read lock), and show, list and consorts only need the global read lock. The global write lock is only taken by operations on repositories, updates and some switch operations.

[Drup]

A consistent improvement would be to stage the build somewhere, then re-run the solver after the build to check and install. But that'd be quite some work to implement.

I was actually thinking of something like that, yes. But you're the one to know what is hard to implement, I'm just wishing. ;)

Is it possible for opam to wait for the lock to be released and then proceed as usual, instead of failing ?

[AltGr]

Is it possible for opam to wait for the lock to be released and then proceed as usual, instead of failing ?

I wouldn't do it by default, but adding an env variable for infinite wait would be very easy (a command-line option being slightly more work). Something like OPAMLOCKRETRIES=0.

[AltGr]

Lock handling is much finer now, and you shouldn't get stuck. Also, waiting until the lock is released is the default behaviour in interactive mode (and there is no wait, but a failure, in scripts). There is still no auto-verbose-toggle-after-5-mins, though

[Drup]

I agree that the problem is mostly gone, but I'm not compiling a 20-minute project on a daily basis anymore. :)

[dra27]

If the problem is solved, can the issue be closed?

[Drup]

The lock issues are mostly gone, but @AltGr might still want to improve the UI.