Matthew Rocklin

Yes, at some point we should handle exceptions. Also stopping signals. I don't have a short term plan for this or any concrete thoughts.

If you're curious then I recommend looking at what ReactiveX does here On Tue, Oct 10, 2017 at 11:26 AM, Christopher J. Wright < [email protected]> wrote: > This reminds me...

We currently pass messages forward and futures backwards with the emit/update methods. My guess is that we would do something similar with exception and stop signals.

I ran into problems with LSFCluster where it was injecting lines into the header that LSF would not accept. I wanted something like a `job_remove=` keyword. But this can probably...

One approach would be to allow users to explicitly skip lines that their cluster manager finds troublesome. I put this into a commit in the spec-rewrite branch for now (I...

To get things to work on Summit (Oak Ridge National Labs machine, currently `#1` in the Top 500) I had to remove `-R`, `-M` and `-n`.

So we would have something like: ```python header = """ #PBS -l walltime={walltime} #PBS -l select=1:ncpus={nthreads}:mem={memory} ... """ ``` And then rather than build up the `job_header` we just plug...

If so, I'm in favor

It might be tricky though. I think that there are some lines that are added only conditionally.

> @mrocklin could you let us know what you replaced -R, -M and -n with. I am guessing you still need to specify somehow: Nothing. I suspect that it is...